* IBM 850 - Open Firmware or not? and more on the ide byteswap game... @ 2000-03-06 22:15 David Monro 2000-03-07 10:26 ` Gabriel Paubert 0 siblings, 1 reply; 7+ messages in thread From: David Monro @ 2000-03-06 22:15 UTC (permalink / raw) To: Linux/ppc Dev List Did the IBM 850 implement Open Firmware as described in the PReP spec? I'm guessing not, which is a pity. Can anybody enlighten me for certain? btw I've figured out why the 850 needs byteswapping of the IDE hard drives to work properly - I just realized that NT/ppc ran little endian, and the firmware understands little-endian FDISK style partition tables. Since we understand them too, but we are running big-endian, we end up in a mess. Why are we running big-endian btw? This causes my first drive (which is byteswapped so I can boot from it) to consume a lot more cpu when doing IO than the second drive (which is in native endian format). I guess that AIX had a hack whereby it created a little-endian FDISK partition table with the bootloader in a PReP boot partition and then played around without byteswapping with the rest of the disk. I'll have to find one running AIX and have a look at the disk with linux and see what I see. Maybe we could adopt this trick - how easy would it by to write a new chunk of partition table code which grokked the partition table in byteswapped format? The we would just have to remember to byteswap the kernel image before writing it to the boot partition and everything would be neat. Actually I guess we could define our own partition table format within the second partition (isn't this what solaris does on intel? what did it do on PPC - has anybody actually seen a live Solaris/PPC machine?). I would also guess that really the 850 was for NT, and the closely related 7248 43P machines were what you were supposed to use for AIX (and I think they had onbard SCSI which gets around the whole problem). Cheers, David ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IBM 850 - Open Firmware or not? and more on the ide byteswap game... 2000-03-06 22:15 IBM 850 - Open Firmware or not? and more on the ide byteswap game David Monro @ 2000-03-07 10:26 ` Gabriel Paubert 2000-03-07 20:19 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Monro 0 siblings, 1 reply; 7+ messages in thread From: Gabriel Paubert @ 2000-03-07 10:26 UTC (permalink / raw) To: David Monro; +Cc: Linux/ppc Dev List On Mon, 6 Mar 2000, David Monro wrote: > > Did the IBM 850 implement Open Firmware as described in the PReP spec? > I'm guessing not, which is a pity. Can anybody enlighten me for certain? > > btw I've figured out why the 850 needs byteswapping of the IDE hard > drives to work properly - I just realized that NT/ppc ran little endian, > and the firmware understands little-endian FDISK style partition tables. > Since we understand them too, but we are running big-endian, we end up > in a mess. Why are we running big-endian btw? Hmm, I'm starting to wonder, are you sure that the system is completely reset to big endian mode ? If the ARC firmware is designed to run NT, it might set all the bits to little endian mode (that's not only the processor but also the bridge and maybe more bits here and there). Or is it that we should make the firmware believe that Linux/PPC is little endian and then switch to big endian the whole system ourselves. My interpretation is that the firmware might attempt to run both big and little endian OS but that the disk access and especially partition table interpretation routines only work correctly when the processor is in little endian mode. IOW the firmware is hopelessly buggy. BTW: big endian is the right way for PPC, you don't want to run a PPC in niadne-elttil mode under any circumstance. The solution might be an endian agnostic bootloader (probably hard to write) which switches everything to big endian and then passes control to the kernel. Or alternatively a bootloader option to run from ARC, The best devices to make tests are CDROMs, but I suspect that ARC can't read from a CD. Does your system boot from PreP partition (0x41) and provide residual data ? And does the residual data look correct or is it byteswapped (wouldn't be too surprising) ? > This causes my first drive (which is byteswapped so I can boot from it) > to consume a lot more cpu when doing IO than the second drive (which is > in native endian format). > > I guess that AIX had a hack whereby it created a little-endian FDISK > partition table with the bootloader in a PReP boot partition and then > played around without byteswapping with the rest of the disk. I'll have > to find one running AIX and have a look at the disk with linux and see > what I see. At a time due to these problems, I had code in the kernel which could grok a partition table in any endianness but the rest of the disk was in normal order (even the extended partition tables). Gabriel. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame... 2000-03-07 10:26 ` Gabriel Paubert @ 2000-03-07 20:19 ` David Monro 2000-03-07 22:22 ` What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...) Tony Mantler ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: David Monro @ 2000-03-07 20:19 UTC (permalink / raw) To: Gabriel Paubert; +Cc: Linux/ppc Dev List Gabriel Paubert wrote: > > On Mon, 6 Mar 2000, David Monro wrote: > > > > > Did the IBM 850 implement Open Firmware as described in the PReP spec? > > I'm guessing not, which is a pity. Can anybody enlighten me for certain? > > > > btw I've figured out why the 850 needs byteswapping of the IDE hard > > drives to work properly - I just realized that NT/ppc ran little endian, > > and the firmware understands little-endian FDISK style partition tables. > > Since we understand them too, but we are running big-endian, we end up > > in a mess. Why are we running big-endian btw? > > Hmm, I'm starting to wonder, are you sure that the system is completely > reset to big endian mode ? If the ARC firmware is designed to run NT, it > might set all the bits to little endian mode (that's not only the > processor but also the bridge and maybe more bits here and there). > Oh, I think it is properly set up etc; I just finally had a realization that since NT was running little-endian, it didn't have the overhead of swapping the disk in order to run the same way round as the partition table indicated it was running. > Or is it that we should make the firmware believe that Linux/PPC is little > endian and then switch to big endian the whole system ourselves. My > interpretation is that the firmware might attempt to run both big and > little endian OS but that the disk access and especially partition table > interpretation routines only work correctly when the processor is in > little endian mode. IOW the firmware is hopelessly buggy. It isn't really that bad - basically they picked one format for the parition table (which happened to be the NT one). Other OSs can do what they like as long as the firmware sees a valid little-endian FDISK partition table with a PReP boot partition in it (and then the OS has to make sure it doesn't stomp on the boot partition). This afternoon I had a look at an AIX disk and discovered it was partitioned with a 3M PReP partition starting 2M from the front of the disk and nothing else. So I'd imagine that AIX probably stores something in the first 2M, and then uses everything execpt the first 5M of the disk under its own scheme. > BTW: big endian is the right way for PPC, you don't want to run a PPC > in niadne-elttil mode under any circumstance. Unless you are Micro$oft :-) For that matter, Workplace OS (ie OS/2 for ppc) ran little-endian. I would guess in both cases the compaines decided that the endian cleanup of the source wasn't worth the hassle. Actually, why does it matter which way up you run the CPU? According to the PREP spec Solaris/PPC was also little-endian! Presumably they decided PReP machines looked more like PCs than sparcs. In which case the only OS that the PReP spec mentions which runs big-endian is AIX. (What was Taligent - something from Apple maybe? The name in mentioned in the spec, but all the slots in the tables under that heading are blank, and so is the appendix for it :-)) [..] > At a time due to these problems, I had code in the kernel which could grok > a partition table in any endianness but the rest of the disk was in normal > order (even the extended partition tables). Have you still got this code anywhere? This is exactly what we need; to grok the primary partition table little-endian but everything else native. Then we just need to write an fdisk to work with it :-) Cheers, David ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...) 2000-03-07 20:19 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Monro @ 2000-03-07 22:22 ` Tony Mantler 2000-03-07 23:17 ` [OFF TOPIC] Re: What is Taligent? {Was: Re: IBM 850} Bill Brooks 2000-03-08 6:30 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Edelsohn 2000-03-08 12:44 ` Gabriel Paubert 2 siblings, 1 reply; 7+ messages in thread From: Tony Mantler @ 2000-03-07 22:22 UTC (permalink / raw) To: David Monro; +Cc: Linux/ppc Dev List At 2:19 PM -0600 3/7/2000, David Monro wrote: [...] >According to the PREP spec Solaris/PPC was also little-endian! >Presumably they decided PReP machines looked more like PCs than sparcs. >In which case the only OS that the PReP spec mentions which runs >big-endian is AIX. (What was Taligent - something from Apple maybe? The >name in mentioned in the spec, but all the slots in the tables under >that heading are blank, and so is the appendix for it :-)) <http://wais.sensei.com.au/macarc2/semper_fi/1995/9512/455-95dec22.txt>, search for 'Taligent' In short, Taligent/Pink was a 'next best thing' OS with the kind of cool technologies that would make any developer's toes tingle with excitement. I belive Taligent was actually an independant company, but I think it's safe to say that there was quite a bit of involvement from both Apple and IBM. It's a shame that old dead OSes like Taligent and the like aren't put out to pasture as opensource, if only so all the Linux/BSD/whatever kernel hackers can have some sort of refrence as to what an OS that isn't *nix looks like. Heaven forbid it might inspire some original innovation. ;) Cheers - Tony :) -- Tony Mantler Renaissance Nerd Extraordinaire eek@escape•ca Winnipeg, Manitoba, Canada http://www.escape.ca/~eek ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OFF TOPIC] Re: What is Taligent? {Was: Re: IBM 850} 2000-03-07 22:22 ` What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...) Tony Mantler @ 2000-03-07 23:17 ` Bill Brooks 0 siblings, 0 replies; 7+ messages in thread From: Bill Brooks @ 2000-03-07 23:17 UTC (permalink / raw) To: Linux/ppc Dev List On Tue, 7 Mar 2000, Tony Mantler wrote: > [...] > I belive Taligent was actually an independant company, but I think it's > safe to say that there was quite a bit of involvement from both Apple and > IBM. It was wholy-owned jointly by Apple, IBM and later even HP bought in. That was the problem. Instead of concentrating on the kernel, they decided to make the CommonPoint system (roughly analagous to what MacApp does, with a dramatically wider scope) run on top of AIX, Copeland and HP/UX. > It's a shame that old dead OSes like Taligent and the like aren't put out > to pasture as opensource, if only so all the Linux/BSD/whatever kernel > hackers can have some sort of refrence as to what an OS that isn't *nix > looks like. Heaven forbid it might inspire some original innovation. ;) Indeed. Bill ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame... 2000-03-07 20:19 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Monro 2000-03-07 22:22 ` What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...) Tony Mantler @ 2000-03-08 6:30 ` David Edelsohn 2000-03-08 12:44 ` Gabriel Paubert 2 siblings, 0 replies; 7+ messages in thread From: David Edelsohn @ 2000-03-08 6:30 UTC (permalink / raw) To: David Monro; +Cc: Gabriel Paubert, Linux/ppc Dev List >>>>> David Monro writes: David> According to the PREP spec Solaris/PPC was also little-endian! David> Presumably they decided PReP machines looked more like PCs than sparcs. It's more that Sun used their x86 Solaris base for all of their non-SPARC ports, and their x86 base was little endian. Everyone thought that more software would be available for little-endian OSes. David ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame... 2000-03-07 20:19 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Monro 2000-03-07 22:22 ` What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...) Tony Mantler 2000-03-08 6:30 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Edelsohn @ 2000-03-08 12:44 ` Gabriel Paubert 2 siblings, 0 replies; 7+ messages in thread From: Gabriel Paubert @ 2000-03-08 12:44 UTC (permalink / raw) To: David Monro; +Cc: Linux/ppc Dev List On Tue, 7 Mar 2000, David Monro wrote: > Oh, I think it is properly set up etc; I just finally had a realization > that since NT was running little-endian, it didn't have the overhead of > swapping the disk in order to run the same way round as the partition > table indicated it was running. Actually I'm suspecting a bug in the firmware which has other consequences, but it does not matter. > It isn't really that bad - basically they picked one format for the > parition table (which happened to be the NT one). Other OSs can do what > they like as long as the firmware sees a valid little-endian FDISK > partition table with a PReP boot partition in it (and then the OS has to > make sure it doesn't stomp on the boot partition). This afternoon I had > a look at an AIX disk and discovered it was partitioned with a 3M PReP > partition starting 2M from the front of the disk and nothing else. So > I'd imagine that AIX probably stores something in the first 2M, and then > uses everything execpt the first 5M of the disk under its own scheme. The partition table format has a fixed endianness. I just suspect that the ARC firmware gets it wrong when it tries to load a big endian OS. But it does not matter (you don't read and parse the partition table often to make it a performance problem). > > > BTW: big endian is the right way for PPC, you don't want to run a PPC > > in niadne-elttil mode under any circumstance. > > Unless you are Micro$oft :-) For that matter, Workplace OS (ie OS/2 for > ppc) ran little-endian. I would guess in both cases the compaines > decided that the endian cleanup of the source wasn't worth the hassle. > Actually, why does it matter which way up you run the CPU? Because of a few tricks that help to make code more compact: all the multiple register load/store don't work in little endian. And early PPC processors would not perform misaligned little endian access so that for my x86 emulator I found it much simpler to run the PPC in big endian. For example in LE lhzx from an odd address woould trap, but lhbrx from an odd address in BE mode which has exactly the same effect simply proceeds (on 601, 603, and 604). There are many misaligned accesses in BIOSes because the design dates from the 8 bit 8088 data bus which did not care at all. Besides running in LE mode requires processor and host bridge dependant code, while using {l,st}[hw]brx does not... > According to the PREP spec Solaris/PPC was also little-endian! Yes, and Workplace OS and others.... > Presumably they decided PReP machines looked more like PCs than sparcs. > In which case the only OS that the PReP spec mentions which runs > big-endian is AIX. (What was Taligent - something from Apple maybe? The > name in mentioned in the spec, but all the slots in the tables under > that heading are blank, and so is the appendix for it :-)) Taligent was an Apple+IBM thing which apparently (i.e. at least for the general public) always stayed in the vapor phase and never condensed... AIX and linuxppc. I suspect that on some machines also the host bridge can't be put in LE mode, so the only way to be portable across all PPC machines is to run BE. (There are other problems which prevent from easily mixing LE and BE mode processes on PPC, the 601 weird mode switching being only the tip of the iceberg). > > [..] > > At a time due to these problems, I had code in the kernel which could grok > > a partition table in any endianness but the rest of the disk was in normal > > order (even the extended partition tables). > > Have you still got this code anywhere? This is exactly what we need; to > grok the primary partition table little-endian but everything else > native. Then we just need to write an fdisk to work with it :-) I think this was something different: at a time fdisk did not work correctly on BE systems because it would write multibyte fields in BE order. The code has also changed a lot since then :-( In any case, the fix for 2.3 might be to patch fs/partitions/msdos.c by inserting: ============================================================================= #ifdef __powerpc__ /* Some firmware insist on byte swapping the partition table */ if ((*(__u16 *) (bh->b_data+510)) == cpu_to_be16(MSDOS_LABEL_MAGIC)) { int i, __u16 * p; for (i=0, p=(__u16 *) (bh->b_data+0x1be); i<33; i++, p++) swab16s(p); } #endif ============================================================================= just before: if ((*(__u16 *) (bh->b_data+510)) != cpu_to_le16(MSDOS_LABEL_MAGIC)) goto done; There is similar code in drivers/block/genhd.c in 2.2.x Gabriel. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-03-08 12:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-03-06 22:15 IBM 850 - Open Firmware or not? and more on the ide byteswap game David Monro
2000-03-07 10:26 ` Gabriel Paubert
2000-03-07 20:19 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Monro
2000-03-07 22:22 ` What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...) Tony Mantler
2000-03-07 23:17 ` [OFF TOPIC] Re: What is Taligent? {Was: Re: IBM 850} Bill Brooks
2000-03-08 6:30 ` IBM 850 - Open Firmware or not? and more on the ide byteswapgame David Edelsohn
2000-03-08 12:44 ` Gabriel Paubert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox