IBM 850 - Open Firmware or not? and more on the ide byteswap game...

IBM 850 - Open Firmware or not? and more on the ide byteswap game...

[David Monro]

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/

Re: IBM 850 - Open Firmware or not? and more on the ide byteswap game...

[Gabriel Paubert]

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/

Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...

[David Monro]

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/

What is Taligent? (Was: Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...)

[Tony Mantler]

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/

[OFF TOPIC] Re: What is Taligent? {Was: Re: IBM 850}

[Bill Brooks]

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/

Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...

[David Edelsohn]

>>>>> 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/

Re: IBM 850 - Open Firmware or not? and more on the ide byteswapgame...

[Gabriel Paubert]

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/