On Aug 22, Ken Nakata wrote
> And you say wrong byte-order will occur WITH a byte-swapper.  Why?  I
> suspect we speak two different languages; i.e. I don't call something
> what you call a byte-swapper a byte-swapper.

I suspect the confusion is in the endian byte order notion.

suppose you have the string "NetBSD". This is an endian-independant quantity
That is, on your IDE drive you will have 'N' in byte 0, 'e' in 1, 't' in 2, ...
If you transfert this in the mac's memory you will have, because of
the bridge conversion, 'e' in byte 0, 'N' in byte 1, 'B' in byte 2,
't' in byte 3 ... and this will be printed "eNBtDS".

Now, a 16-bit number, let says, 0xbeef. On the ide device, wich is
little-endian, you will have 0xef in byte 0 and 0xbe. When transfered in
the mac's memory you will have 0xbe in byte 0 and 0xef in byte 1, which is
interpreted as 0xbeef by the processor because it's big-endian.

byte-order is only important for 16 and 32 bit integer values. So only
these integer values will be stored differently in memory for a little-endian
and a big-endian CPU. All other values (8-bit integers, strings, ieee floating
points numbers) are identical.
So doing byte-swapping at hardware level is plain wrong, because only some
values need to be byte-swapped.

> [...]
> No.  The stupid bridge always does its only job to preserve the byte
> order, and that's why I'm getting every short in the wrong order (in
> little endian, that is).

So  there's something wrong: either the bridge doens't do byte-swapping, or
bus_space_read_2 does.

It's a standart IDE drive (i.e a quantun, IBM or something else you've
purchased in a PC hardware reseller) or an APPLE one ?

With a standart IDE drive, in datas returned by the IDENTIFY command,
shorts are in little-endian format and strings are their letters
swapped 2 by 2 (i.e. for "IBM" you have B in byte 0, I in byte 1, ' ' in byte 2
and M in byte 3. That's not because it's little-endian, that's because
ATA(PI) specs are silly).

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--