ppc LE questions (seeking help hand info pointers)
I am familiar with the fact that little endian ppc linux is an unpopular concept, but I would like to discuss it and ask a few questions about it anyway. I do _NOT_ want to start a flame war, so if you feel the need to flame me for this, pleas flame me directly offline and do not pollute the list.
assume I have a valid reason for wanting to run ppc's in LE mode
assume I already have a (non-linux) ppc OS running LE mode (actually compiles and runs in either mode, which you run depends on which flavor of our hardware you use) the differences in the code are limited to a few header files, some startup code and some context switch code. (to get an idea of the hardware see www.mc.com)
assume I am also aware of the limitations of the chip in LE mode, and the intended target is 7400+ processors
question 1. are there already existing patch sets (rejected from mainline inclusion) available for use as a starting point?
question 2. if 1, what is the primary reason for rejection.
question 3. is there a general issue of endian safety in linux (I would think not) or just in the ppc-specific code?
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
thanks for your time,
Mark
-- /*------------------------------------------------**
** Mark Salisbury | Mercury Computer Systems ** ** [email protected] | System OS - Kernel Team **
**------------------------------------------------*/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines · Mark Salisbury
question 1. are there already existing patch sets (rejected from mainline inclusion) available for use as a starting point?
There was a bit of work, just for the kernel. Nothing on the toolchain side.
Quoted 1 line
question 2. if 1, what is the primary reason for rejection.
Being a LE & BE arch becomes a giant PITA for no gain.
Quoted 2 lines
question 3. is there a general issue of endian safety in linux (I would think not) or just in the ppc-specific code?
In theory the generic code is endian safe, by and large. The arch/ppc and include/asm-ppc stuff assumes BE.
Quoted 4 lines
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
The objection to being an arch that attempts to support both LE and BE.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 7 lines · Tom Rini
Quoted 4 lines · Mark Salisbury
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
The objection to being an arch that attempts to support both LE and BE.
Note that we already have a precedent: mips and mipsel, both in arch/mips/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 10 lines · Geert Uytterhoeven
Quoted 7 lines · Tom Rini
Quoted 4 lines · Mark Salisbury
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
The objection to being an arch that attempts to support both LE and BE.
Note that we already have a precedent: mips and mipsel, both in
arch/mips/.
And SH too, iirc. I know it can be done. But do we want to do it is the question.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 8 lines · Tom Rini
Quoted 7 lines · Geert Uytterhoeven
Quoted 6 lines · Tom Rini
Quoted 4 lines · Mark Salisbury
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
The objection to being an arch that attempts to support both LE and BE.
Note that we already have a precedent: mips and mipsel, both in
arch/mips/.And SH too, iirc. I know it can be done. But do we want to do it is the question.
At least in the case of SH, there's a good reason. There's an external pin that controls the native endianness of the processor, and most setups just have it forcibly pulled high or low. I suspect the MIPS is the same reason, since it's used in similar situations. We don't have that excuse with ppc. Someone would have to come up with an excuse along the lines of "existing hardware won't work unless we do this" like it would have been for SH. (I had to work with the SH4e as used by Sega in the Dreamcast...)
Brad Boyer
[email protected]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 13 lines · Brad Boyer
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
The objection to being an arch that attempts to support both LE and BE.
Note that we already have a precedent: mips and mipsel, both in
arch/mips/.And SH too, iirc. I know it can be done. But do we want to do it is the question.
Quoted 7 lines
At least in the case of SH, there's a good reason. There's an external pin that controls the native endianness of the processor, and most setups just have it forcibly pulled high or low. I suspect the MIPS is the same reason, since it's used in similar situations. We don't have that excuse with ppc. Someone would have to come up with an excuse along the lines of "existing hardware won't work unless we do this" like it would have been for SH. (I had to work with the SH4e as used by Sega in the Dreamcast...)
well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc, ppc/ppc, mips/ppc) shared memory multicomputer.
when dealing w/ direct mapped, shared memory, uniformity of endian-ness makes many multicomputer problems easier to solve.(not to mention easier for the customer to program...)
-- /*------------------------------------------------**
** Mark Salisbury | Mercury Computer Systems ** ** [email protected] | System OS - Kernel Team ** **------------------------------------------------** ** Thanks to all who sponsored me for the ** ** Multiple Sclerosis Great Mass Getaway!! ** ** Robert, Michele and I raised $10,000 and the ** ** raised over $1,000,000 ride as a whole. The ** ** ride was great, and we didn't get rained on! ** ** Thanks again to all of you who made this ** ** possible!! **
**------------------------------------------------*/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Mark Salisbury <[email protected]> writes:
[... linux in ppc little endian mode ...]
Quoted 7 lines
well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc, ppc/ppc, mips/ppc) shared memory multicomputer.
when dealing w/ direct mapped, shared memory, uniformity of endian-ness makes many multicomputer problems easier to solve.(not to mention easier for the customer to program...)
You are aware that a PPC in little endian mode is merely tricking with the low order address bits, but does not actually lay out its data in a little endian fashion in physical memory?
Holger
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Holger Bettag writes:
Holger> You are aware that a PPC in little endian mode is merely tricking with the Holger> low order address bits, but does not actually lay out its data in a little Holger> endian fashion in physical memory?
This is why Mark said "assume I am also aware of the limiations of
the chip in LE mode and the intended target is 7400+ processors". Motorola has added a more complete LE mode.
David
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 7 lines · Holger Bettag
Mark Salisbury <[email protected]> writes:
[... linux in ppc little endian mode ...]
Quoted 3 lines
well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc, ppc/ppc, mips/ppc) shared memory multicomputer.
Quoted 9 lines
Quoted 5 lines
when dealing w/ direct mapped, shared memory, uniformity of endian-ness makes many multicomputer problems easier to solve.(not to mention easier for the customer to program...)
You are aware that a PPC in little endian mode is merely tricking with the low order address bits, but does not actually lay out its data in a little endian fashion in physical memory?
not according to section 3.1 of the motorola ppc "green book"
according to that it is a sort of munged le representation,
which thanks to a "one trick pony" PCI bridge looks like standard LE to the PCI based x86 host.
understand please that what I am proposing is a config option. as a sub-architecture port. it would not affect any code that it didn't absolutely need to, and would only be compiled if sombody selected that particular config.
I am _NOT_ suggesting running pmacs in LE mode.
as in:
ppc---
|-- PREP
|-- CHRP
|-- MAC
|-- MERCURY --- |-- Big Endian
|-- Little Endian
-- /*------------------------------------------------**
** Mark Salisbury | Mercury Computer Systems ** ** [email protected] | System OS - Kernel Team **
**------------------------------------------------**
** Infinite Justice is niether. **
**------------------------------------------------*/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 9 lines · Mark Salisbury
Quoted 3 lines · Holger Bettag
You are aware that a PPC in little endian mode is merely tricking with the low order address bits, but does not actually lay out its data in a little endian fashion in physical memory?
not according to section 3.1 of the motorola ppc "green book"
according to that it is a sort of munged le representation,
Nope. Read section 3.1 very carefully. Data in memory is still organized in BE order. Another reference: 9.3.2 in the MPC7400 manual.
The "munging" plays with low order address bits in an attempt to make porting LE software easier. When software tries to access a multibyte data item with a granularity other than that native to the data (e.g. a library routine for printing FP numbers which accesses floats & doubles a byte at a time), it assumes either LE or BE offsets within the larger data item. Munging makes it possible to run software that assumes LE internal offsets even though the processor and memory layout are BE.
Quoted 2 lines
which thanks to a "one trick pony" PCI bridge looks like standard LE to the PCI based x86 host.
As a hardware guy, I recommend that (if you have not done so already) you get with your hardware guys and make Really, Really Sure that the PCI bridge actually can translate PPC pseudo-LE address munging to real LE. It will have to demunge/munge addresses that travel through the bridge *and* swap bytes.
IMO, munging is likely to make your life (and that of all who use your platform with munging turned on) harder rather than easier.
Actually, even just swapping in the bridge is likely to do that too, unless you have enough control over when the bridge swaps to restrict it to very specific things. (e.g. if you can tell it "swap everything in this address region with a granularity of 32 bits", that's useful, but "swap everything" is likely to be a pain.)
Quoted 4 lines
understand please that what I am proposing is a config option. as a sub-architecture port. it would not affect any code that it didn't absolutely need to, and would only be compiled if sombody selected that particular config.
I don't think anybody had assumed otherwise, but the thing is that given the way it works, PPC LE would require large changes in the kernel tree regardless. Linux has the infrastructure needed to support LE and BE architectures, but has none for anything like PPC LE mode. I submit that the changes necessary are unlikely to be accepted into standard trees, because it will uglify huge swaths of code in order to support a CPU mode that can best be described as a bizarre hack.
(Specifically: in order to support PPC-LE, all the hardware drivers needed for your platform will need to be rewritten to be aware of munging. The alternative is to make the kernel run in regular BE mode while some or all of userspace runs in the hack mode, but *that* requires an astounding ugliness: a translation layer sitting between the kernel and userland.)
I'm pretty certain PPC-LE would require modifications to the toolchain too.
Finally, Book E has been mentioned. I read through the relevant stuff and it looks to me like Book E PowerPC does offer a useful
feature: a TLB entry bit (bit 'E' for endian) which marks a page as little endian. The semantics are that a regular load/store whose effective address lies inside a page with bit E set operates like a byteswapping form of the same load/store instruction, and vice versa. Advantage compared to simply using the byteswapping forms of the
instructions: you get the full range of load/store instructions rather than just the subset that have explicit byteswapping variants, and no use of assembly or funky compiler tricks is required when writing code to access such a memory region.
Unfortunately, Book E does not guarantee that the 'E' TLB entry bit is really supported in hardware: the CPU may have to take exceptions to emulate it. Even when hardware support is there, they still allow for implementations that must take an exception to perform a static mode switch whenever a page differing in endianness from the last memory access is touched.
But so far as I can tell, the 750, 7400, 7450, etc. are not Book E PowerPC, so the only thing they have is the MSR[LE] mode bit (address munging).
Too bad this part of Book E wasn't in the architecture from the start... --
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 1 line · Timothy A. Seufert
Finally, Book E has been mentioned.
Too bad.....
Quoted 2 lines
... a TLB entry bit (bit 'E' for endian) which marks a page as little endian.
This has been discussed in the past and suffers from the same problem as trying to byte swap in a bridge. Although you can use any load/store in this space, unless you are performing the access on the natural size of the object it won't have the proper effect. Since you must require that knowledge, it is just as easy to choose the proper byte swapping variant of the instruction.
Quoted 2 lines
Unfortunately, Book E does not guarantee that the 'E' TLB entry bit is really supported in hardware:
For all practical purposes, the engineering world is already used to working with the advantages of a big endian processor and dealing with the issues of accomodating little endian when necessary. Adding a feature like this only complicates the use of legacy software and creates significant discussion for a feature trying to find a problem to solve. This feature isn't a performance enhancement, only a detriment because it requires additional software to manage something not natural to use. I suspect it was just easier to write this into the specification (i.e. it's there but not required) than spending time discussing it's technical merit.
Quoted 1 line
But so far as I can tell, the 750, 7400, 7450, etc. are not Book E
Thankfully.
Quoted 1 line
Too bad this part of Book E wasn't in the architecture from the start...
You are one of few to feel that way. Those of us that have worked with PowerPC from the start, and were part of the original design discussions, view Book E as a totally new processor that may execute similar instructions to traditional PowerPC. I have spoken with several embedded product companies, a couple very large, that have huge investments in PowerPC software that are now trying to determine what to do. They are quite upset that they now have to invest in a new processor design, and it makes them likely to choose something else. Motorola has proven you can build some very powerful embedded processors with the traditional PowerPC core and memory mapped I/O peripherals, a very nice and efficient programming environment. The Book E appears to be a marketing vehicle put together by people that didn't understand or appreciate the previous PowerPC architecture specifications. We can hope the where Book E allows variation and extension, designers will borrow from traditional PowerPC and not go in some other "creative" direction :-).
I'm not really saying anything new here, this has been discussed among all of us that work on PowerPC ever since the Book E announcement long ago.
I guess I better go looking for those m68k projects now :-).
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 8 lines · Dan Malek
Quoted 1 line · Timothy A. Seufert
Finally, Book E has been mentioned.
Too bad.....
Quoted 2 lines
... a TLB entry bit (bit 'E' for endian) which marks a page as little endian.
Quoted 6 lines
This has been discussed in the past and suffers from the same problem as trying to byte swap in a bridge. Although you can use any load/store in this space, unless you are performing the access on the natural size of the object it won't have the proper effect. Since you must require that knowledge, it is just as easy to choose the proper byte swapping variant of the instruction.
Anyone who knows how this differs from the similar bit on UltraSPARC?
Quoted 1 line
I guess I better go looking for those m68k projects now :-).
Good! We can use some help to keep the old platforms alive... AFAIK the working platform support decreased to Amiga, Q40, Sun3[x], and Mac in 2.4.x...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 1 line · Geert Uytterhoeven
Anyone who knows how this differs from the similar bit on UltraSPARC?
Hmmm...I guess it's time to go fishing again in another architecture. I haven't visited SPARC for a while. Do they actually use it in Linux?
Quoted 1 line
Good! We can use some help to keep the old platforms alive...
...and I have old platforms :-). I'm afraid to apply power to some of them.....
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 5 lines · Dan Malek
Quoted 1 line · Geert Uytterhoeven
Anyone who knows how this differs from the similar bit on UltraSPARC?
Hmmm...I guess it's time to go fishing again in another architecture. I haven't visited SPARC for a while. Do they actually use it in Linux?
AFAIK they do, for PCI accesses.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 1 line · Geert Uytterhoeven
AFAIK they do, for PCI accesses.
They do the same thing we do. The ULTRASparc has address modifiers on the load/store instructions to do byte swapping in the io macros, just like us. The "other" Sparcs do it the hard way with actual byte swap code in the macros. There are comments in various files that clearly state Sparc is big-endian without exception :-).
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I just wanted to clear up some inaccuracies in this previous note.
Quoted 10 lines · Dan Malek
Quoted 1 line · Timothy A. Seufert
Finally, Book E has been mentioned.
Too bad.....
Quoted 2 lines
... a TLB entry bit (bit 'E' for endian) which marks a page as little endian.
Quoted 7 lines
This has been discussed in the past and suffers from the same problem as trying to byte swap in a bridge. Although you can use any load/store in this space, unless you are performing the access on the natural size of the object it won't have the proper effect. Since you must require that knowledge, it is just as easy to choose the proper byte swapping variant of the instruction.
This is NOT true on the 405 core processors. They support TRUE little endian.
Quoted 14 lines
Quoted 2 lines
Unfortunately, Book E does not guarantee that the 'E' TLB entry bit is really supported in hardware:
For all practical purposes, the engineering world is already used to working with the advantages of a big endian processor and dealing with the issues of accomodating little endian when necessary. Adding a feature like this only complicates the use of legacy software and creates significant discussion for a feature trying to find a problem to solve. This feature isn't a performance enhancement, only a detriment because it requires additional software to manage something not natural to use. I suspect it was just easier to write this into the specification (i.e. it's there but not required) than spending time discussing it's technical merit.
The book E specification requires the little endian bit. It must be there for the processor to be a Book E.
Quoted 6 lines
Quoted 1 line
But so far as I can tell, the 750, 7400, 7450, etc. are not Book E
Thankfully.
Quoted 1 line
Too bad this part of Book E wasn't in the architecture from the start...
Quoted 16 lines
You are one of few to feel that way. Those of us that have worked with PowerPC from the start, and were part of the original design discussions, view Book E as a totally new processor that may execute similar instructions to traditional PowerPC. I have spoken with several embedded product companies, a couple very large, that have huge investments in PowerPC software that are now trying to determine what to do. They are quite upset that they now have to invest in a new processor design, and it makes them likely to choose something else. Motorola has proven you can build some very powerful embedded processors with the traditional PowerPC core and memory mapped I/O peripherals, a very nice and efficient programming environment. The Book E appears to be a marketing vehicle put together by people that didn't understand or appreciate the previous PowerPC architecture specifications. We can hope the where Book E allows variation and extension, designers will borrow from traditional PowerPC and not go in some other "creative" direction :-).
I know the discussions on Book E are incorrect. I have had the privilege here in
IBM to work on the 440gp processor. Although my knowledge of powerpc is far from complete, I can tell everybody that from my experience that the Book E architecture is superior.
There are two things that make it superior.
1)Not turning off translation when an interrupt is taken 2)The IVOR registers which allow the system interrupts to be place correctly.
If one stops to think about it, running Linux out of Ram on a PCI card becomes very easy. This is because the processor does NOT have to fetch all interrupts from
physical location 0. And now the interrupt routines run with protection ON, so protection of task by bad operations in the interrupt handler is now possible.
This will lead to a more secure OS.
I believe that Book E processor which have been announced by both Motorola and IBM
will be VERY successful.
Quoted 6 lines
I'm not really saying anything new here, this has been discussed among all of us that work on PowerPC ever since the Book E announcement long ago.
I guess I better go looking for those m68k projects now :-).
Too bad you feel this way. Book E is definitely better and I am sure, that once you
got one, you would have 100 great ideas on how linux could use its features.
I am personally excited by the future of book E. The Engineers here working on delivering it are simply the best with whom I have every worked. ( I have been at IBM for over 20 years).
Quoted 3 lines
-- Dan** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ralph Blach writes:
Ralph> I know the discussions on Book E are incorrect. I have had the Ralph> privilege here in
Ralph> IBM to work on the 440gp processor. Although my knowledge of powerpc is Ralph> far from complete, I can tell everybody that from my experience that the Ralph> Book E architecture is superior.
Ralph> I believe that Book E processor which have been announced by both Ralph> Motorola and IBM
Ralph> will be VERY successful.
Ralph> I am personally excited by the future of book E. The Engineers here Ralph> working on delivering it are simply the best with whom I have every Ralph> worked. ( I have been at IBM for over 20 years).
I wish that you had not made these statements because you now
force others from IBM to disagree with you in public or let people assume your opinion uniformly represents IBM. This isn't a question of the quality of the implementation by engineers, it is a question of the design itself. Making categorical statements that "you know" something is very dangerous.
PowerPC Book E effectively is a different architecture. The User
Instruction Set Architecture (UISA) changes address perceived problems which never really existed. It is a fine architecture for its purpose, but it complicates the ability to share user code and tools with the rest of the PowerPC world and undermines the unifying opportunity for the PowerPC architecture scaling across a wide range of uses.
Your comments of praise focus completely on Supervisor mode
changes. If the designers of the Book E architecture had left the Book I UISA alone for compatibility with the original PowerPC archiecture, I believe that everyone would be a lot happier and more uniformly supportive. There is a lot more agreement that the Supervisor mode changes are useful for the embedded market -- the target of "Book E". I wish that the PowerPC Book E architecture designers had limited themselves to modifications which were not visible to user programs.
Change comes with a cost; compatibility is important too.
David
P.S. The above comments are my own opinion and are not intended to
imply that they represent any company or organization. The same applies to Ralph's comments which should have included an equivalent disclaimer.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Ralph Blach writes:
Ralph> Although my knowledge of powerpc is
Ralph> far from complete, I can tell everybody that from my experience that the Ralph> Book E architecture is superior.
Ralph> I believe that Book E processor which have been announced by both Ralph> Motorola and IBM will be VERY successful.
Let me clarify a point in my previous reply: the PowerPC Book E
changes to the PowerPC Book I UISA affect 64-bit PowerPC only. The 32-bit subset of PowerPC Book E is compatible with the rest of the PowerPC architecture family. IBM's PowerPC 440GP implements the 32-bit PowerPC Book E architecture.
As I said in my original message, the supervisor and non-UISA
changes are very useful and have a lot of support from the embedded PowerPC developer community. The IBM PowerPC 440GP and other 32-bit PowerPC Book E chips implement the areas of agreement and compatibility which create broad support for the PPC 440GP chip and the PowerPC architecture. I am happy when the various chip implementations in the PowerPC architecture family complement and reinforce each other.
David
P.S. The above comments are my own opinion and are not intended to
imply that they represent any company or organization.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 1 line · Ralph Blach
I just wanted to clear up some inaccuracies in this previous note.
Ok, before this discussion gets further out of control, and I get blamed for many things, I want you to know that Book E has been discussed among many people on these mailing lists ever since the specification was public. I just happened be working at 4 AM when these previous messages were posted, and (as I indicated) I was posting a summary of lots of discussions that have occurred in the past. Unfortunetly, this gets represented as _my_ view, when the purpose is to discuss what we are going to do to accomodate these new architectures.
The 405GP is the first Book E type processor that has had a significant impact in Linux. Yes, there was some early 403 that Tivo used successfully, but those were some localized modifications specific to the product and didn't lend themselves to be merged and carried forward without breaking other things.
In the case of the 405, for the past six months about all I have been doing is taking patches from many others, making the necessary changes so they can be applied to the current trees, and then testing to ensure we didn't break something else. This is a very time consuming process, some of it done on my own free time (as I have other development obligations), and I can hardly take credit for any new development. All I have done is tried to make the 4xx port better fit with the others. This must have been somewhat successful, because the software updates from people around the world keep increasing, and we are able to immediately use the latest software enhancements to Linux.
The first discussions about Book E among the PowerPC developers was whether we treat it as a new architecture or try to integrate it with the traditional PowerPC source code base. Although from a user application perspective it will likely execute 32-bit code like past PowerPC cores, from the kernel perspective it is very different. No one was interested in starting up a new architecture, especially for a new processor that wasn't even available to those of us working on Linux. The only way Book E was going to be initially successful was to make it somehow fit into the traditional PowerPC baseline. That, too, seems like a pretty good decision, as the interest in Linux and 405 is high and continues to grow.
Now that we have established a base of software and a growing group of users, after we get to look at another processor from the Book E family perhaps it is time to start a new architecture tree. This isn't something to be taken lightly, as it requires a dedication to the development like we have for the existing PowerPC development. I'm certain some of us will play in both camps (at least I hope so :-), but we can't afford to spread our existing PowerPC resources even thinner, as no one will benefit.
There are advantages to using Book E over other processors, but keep in mind there are few architectural features that haven't been used in the past or currently exist on other processors. Processors support a wide range of features to address a wide range of (sometimes disparate) requirements that just simply don't allow reasonably using all of the features all of the time. We need to venture into the other architecture spaces and learn from them. The recently highly contentious byte swap page mapping is clearly one of these. Other processors appear to support it, but developers haven't chosen to use it in a Linux environment.
I have had lots of fun and much success developing software for the PowerPC processor family. The Book E is now part of that development and I intend to do the same for it. From the perspective of the Linux kernel, Book E is very different from the traditional PowerPC, we have to admit that, adjust for it, and continue to make it successful. The current PowerPC is about 10 years old, and some of the best things just don't happen overnight.
The Linux software development has to continue in the same democratic way it has in the past that has made it so successful. Simply demanding something and getting pissed when _I_ don't immmediately implement it is not the road to success and happiness. Like many others, I have invested years of personal time at the expense of other life opportunities on PowerPC Linux development. There are things I would like to change, but consensus is necessary among everyone to ensure features are properly implemented and maintained.
So, let's keep some constructive technical discussions going and please keep sending your source code updates.
Thanks.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 6 lines
There are two things that make it superior.
1)Not turning off translation when an interrupt is taken 2)The IVOR registers which allow the system interrupts to be place correctly.
Quoted 7 lines
If one stops to think about it, running Linux out of Ram on a PCI card becomes very easy. This is because the processor does NOT have to fetch all interrupts from
physical location 0. And now the interrupt routines run with protection ON, so protection of task by bad operations in the interrupt handler is now possible.
This will lead to a more secure OS.
While I don't want to take a side in the LE vs. not LE debate, I don't agree with you on this specific point about interrupts running with MMU enabled.
First of all, on Linux, and I beleive any sane OS, the exceptions vectors do their job of saving the context, and then jump to the high level (read "C") exception handling with the MMU turned back on. So except for the exception handler low level code itself, there's no security gain here. And if the exception handler itself is bogus or has holes, then there's nothing we can do against programmer incompetence.
On the other side, running with MMU ON makes that small task of setting up the kernel environement on exception entry and unwiding it on exception exit a lot more tricky. It prevents using MMU off as an efficient way of using SRR0/SRR1 without caring about taking TLB misses during critical code patBeWell, I won't argue with you on this ;)
While I don't say the Book E is better or worse than other PPCs (I didn't look at the specs well enough to say, it might actually be the "killer" architecture you are talking about ;), I don't agree on the benefit of the feature outlined above.
Regards,
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Sorry, part of my previous post got "eaten" by my mailer, here it is.
Quoted 5 lines
On the other side, running with MMU ON makes that small task of setting up the kernel environement on exception entry and unwiding it on exception exit a lot more tricky. It prevents using MMU off as an efficient way of using SRR0/SRR1 without caring about taking TLB misses during critical code pat....
So, I was saying that it prevents using MMU off as an efficient wau to avoid taking TLB misses during those critical code path. Having the translations always enabled force you to pin down at least one TLB entry which makes the TLB handlers more complicated (and so adds overhead). It also make the exception entry/exit path more tricky as those have to touch datas not covered by pinned TLB entries (like process stacks), more or less forcing us to use specific exception stacks (pinned down) to avoid horrible bloat.
This will make some bits of the 32 bits kernel almost as tricky as when running below Hypervisor on LPAR :)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 5 lines · Timothy A. Seufert
Quoted 1 line · Mark Salisbury
Holger Bettag wrote:
(Specifically: in order to support PPC-LE, all the hardware drivers needed for your platform will need to be rewritten to be aware of munging. The alternative is to make the kernel run in regular BE
But PCI drivers already use readl() and friends, so the differences can be hidden there? => no driver changes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
keyb
In reply to Mark SalisburyCan someone explain briefly the relations between the input layer, the lowlevel driver, the usb hid, etc. ? I want to make a patch to deliver unknown keycodes to user space and I don't like to browse 100MB of sources just to understand where to look for...
Bye.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
One the 405 processors, with the endian bit set, the data is will be true little endian.
Chip
Quoted 11 lines · Holger Bettag
Mark Salisbury <[email protected]> writes:
[... linux in ppc little endian mode ...]
Quoted 7 lines
well, this is in the context of a multi-CPU type (x86/ppc, sparc/ppc, ppc/ppc, mips/ppc) shared memory multicomputer.
when dealing w/ direct mapped, shared memory, uniformity of endian-ness makes many multicomputer problems easier to solve.(not to mention easier for the customer to program...)
Quoted 6 lines
You are aware that a PPC in little endian mode is merely tricking with the low order address bits, but does not actually lay out its data in a little endian fashion in physical memory?
Holger
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
At 1:32 PM -0500 9/20/01, Mark Salisbury wrote:
[...]
Quoted 3 lines
when dealing w/ direct mapped, shared memory, uniformity of endian-ness makes many multicomputer problems easier to solve.(not to mention easier for the customer to program...)
[...]
Endian-safe code isn't terribly difficult to write. The PPC even has some very nice little-endian load and store operations which are easily accessable in big-endian mode, and obviously don't carry any of the baggage of running in le mode.
Not to flame or anything, but "my customers are lazy and don't want to write portable code" isn't a very good reason to change the kernel.
Cheers - Tony 'Nicoya' Mantler :)
--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - [email protected]
Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 6 lines · Tom Rini
Quoted 2 lines · Mark Salisbury
question 1. are there already existing patch sets (rejected from mainline inclusion) available for use as a starting point?
There was a bit of work, just for the kernel. Nothing on the toolchain side.
could you point me to the author/code?
toolchain is not a problem, I have gcc sparc/ppc_le crosscompiler etc...
-- /*------------------------------------------------**
** Mark Salisbury | Mercury Computer Systems ** ** [email protected] | System OS - Kernel Team ** **------------------------------------------------** ** Thanks to all who sponsored me for the ** ** Multiple Sclerosis Great Mass Getaway!! ** ** Robert, Michele and I raised $10,000 and the ** ** raised over $1,000,000 ride as a whole. The ** ** ride was great, and we didn't get rained on! ** ** Thanks again to all of you who made this ** ** possible!! **
**------------------------------------------------*/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 10 lines · Mark Salisbury
Quoted 6 lines · Tom Rini
Quoted 2 lines · Mark Salisbury
question 1. are there already existing patch sets (rejected from mainline inclusion) available for use as a starting point?
There was a bit of work, just for the kernel. Nothing on the toolchain side.
could you point me to the author/code?
Unfortunatly all I've got in my inbox is 4xx-specific. Try the archives.
Quoted 1 line
toolchain is not a problem, I have gcc sparc/ppc_le crosscompiler etc...
That doesn't mean there aren't issues. PPC-LE isn't that well tested..
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 1 line · Mark Salisbury
assume I have a valid reason for wanting to run ppc's in LE mode
This is where it starts to fall apart. I didn't know there were any valid reasons to support LE mode, except to run some software from a certain company that never materialized. I was fortunate to be part of the PowerPC design discussions from the beginning. The LE mode was never popular.
A technical reason is the PowerPC never supported a true little endian mode. It basically does byte swapping between the cache and core processing units, and I believe always (or at least usually) supported a big endian bus. You can't properly attach the processor to true little endian busses or devices when this is done, so you don't gain any hardware design advantage. As you know, properly byte swapping depends upon the size of the object, so if you happen to access something in smaller units than it's natural size you aren't going to get the results you expect. For someone that is comfortable programming in an LE environment (is there anyone? :-), this will eventually bite you.
Another technical reason is as the processor family moves forward, less and less little endian support is provided. In the case of the 7450, there are instructions that trap to the kernel to be emulated in LE mode, that are executed in the core in BE mode.
Quoted 1 line
question 2. if 1, what is the primary reason for rejection.
It was LE (sorry, couldn't resist :-)?
Quoted 2 lines
question 3. is there a general issue of endian safety in linux (I would think not) or just in the ppc-specific code?
Linux is very aware of endian issues. For all but I guess two of you now, everyone assumes PowerPC is big endian and we make adjustments when working on little endian I/O. Without hardware for testing, the rest of us are just likely to break any LE software, and you are just going to end up chasing fixes behind lots of the rest of us.
Quoted 2 lines
..........what would be the primary
obstacle to inclusion in the main line.
Like I always say, the kernel is the easy part. None of us have the hardware, tools, libraries, or applications to utilize a LE kernel. It more than doubles the work we need to do trying to keep the software up to date, if we had all of that for testing. It may be easier to just keep your patch up to date, than to try and keep up with the rest of us making changes to software we can't test.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 5 lines
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
I think the primary obstacle is that we already have enough problems breaking obscure machines (embedded, or some old PReP box) whenever something gets changed.
I suspect it's going to be a signifigant workload to keep a 'ppcle' up-to-date, and most importantly, working.. you may be better off maintaining a patch for LE support for the near future.
I for one, would like to see how small one could get a clean, working LE patch for linux.
If the code isn't intrusive, and forces us to clean up abstraction layers in headers and such, it could probably be a good thing.
This whole discusion is mostly academic and (in this case) somewhat incendiary until someone shows up with working code.
My suggestion is go make it work, and if you find ways to clean up the general PPC code in the process, this will definitely help.
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | [email protected] -----"If this message isn't misspelled, I didn't write it" -- Me ----- "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines · Mark Salisbury
question 1. are there already existing patch sets (rejected from mainline inclusion) available for use as a starting point?
Hmmm, I think there was someone who was looking at this, but I don't recall who it was.
Quoted 2 lines
question 3. is there a general issue of endian safety in linux (I would think not) or just in the ppc-specific code?
Given that Linux runs on both big and little-endian machines, yes the endian issues have largely been addressed, with the exception of some drivers.
Quoted 4 lines
question 4. assuming I was willing to deliver a clean, complete LE enabling patch (including devices that are relevant to me), as a compile time config option and maintain that patch, what would be the primary obstacle to inclusion in the main line.
It would depend on how much needed to be changed just for the benefit of the LE machines, and how much it would complicate future maintenance of the rest of the code. If there are suddenly lots of places where we have to do things differently now because of the existence of the LE port, then that would make it easy for people to break things in the future without realizing, and that would be a reason for rejection.
I am not opposed to LE support but I would be opposed to large-scale changes to the code for the sake of one platform which isn't widely used - unless of course you can argue that the changes result in us doing things the "right" way for all platforms.
It ultimately comes down to "show us the code".
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/