On Fri, 21 Aug 1998 13:39:02 +0200, Manuel Bouyer wrote:
> On Aug 21, Ken Nakata wrote
> > Thanks, but I'm confused.
> > 
> > Let us consider the Macintosh IDE interface.  IDE bus is a little
> > endian bus, whereas host bus is big endian.  And there is a
> > byte-swapping bus bridge between the two so that bits 0-7 of IDE bus
> > are wired to bits 24-31 of the host bus, and bits 8-15 to bits 16-23.
> 
> So it does byte-swap of 32-bits, where IDE access are all 8 or 16bits
> (32bits access to the data port is a controller's feature: it turns this
> out to 2 16bits access to the disk).
> This may cause some problems, yes.
> 
> This also means that you have to do all the access with 32bits I/O ?

No, 

> > When CPU transfers a data block to/from the drive, byte N in host byte
> > order is also byte N in I/O bus byte order because of the bridge.
> > 
> > Now, wdc.c uses bus_space_{read,write}_multi_stream_[24]() for data
> > transfer.  If these functions cancell out the effect of the bridge,
> > byte 2*N in host byte order will be byte 2*N+1 in I/O bus byte order,
> > and byte 2*N+1 will be 2*N.  This is not desirable.
> 
> I'm not sure why you say it's not desireable.

Why not?  In host byte order (BE) "NetBSD is cool" becomes in IDE bus
byte order "eNBtDSi soclo" if the bridge's byte-swapping is cancelled
out.  This is not cool.

> The ATARI mainbus IDE controller also does byte-swap.
> Unless the bus_space_{read,write}_multi_stream_[24]() functions byte-swap
> so that raw access are really raw access, you can't use ATAPI devices.
> Also, suppose that you have a disk made on an i386 (LE FFS format).
> If you put it in your mac, you want to have the raw data, and let the
> filesystem do the byte-swap only where needed.

The "raw" byte-order will not be correct if the bridge's byte-swapping
is cancelled out!  Am I saysing something strange?

> Now, for the IDE drive, it may not be desirable to undo the bridge byte-swap,
> because the bios doesn't do it,

What bios?  Macs don't have the BIOS in the sense i386 does.  If you
are talking about i386, thie is all moot since i386's host byte order
coincides the IDE bus byte order.

> so this will prevent the drive from being
> bootable. This is why stream/non-stream data port access for ata is
> conditionned by the 'WDC_CAPABILITY_ATA_NOSTREAM' flag in the bouyer-ide branch

How do I get it?

> (the stock -current ATA/ATAPI driver doesn't work properly with the on-board
> controller on the atari).

Ah ha!  I was mislead (perhaps by myself) to believe that it does.

> > However, when reading the parameter block from the drive
> > (WDCC_IDENTIFY), I want the upper bytes of the block being read from
> > the drive to be the upper bytes of the block read into the host's
> > memory, the lower bytes to be the lower bytes.  That is, I want to
> > cancell out the effect of the bridge.  
> > 
> > Wdc.c uses bus_space_read_multi_2() for this, which is supposed to let
> > the bridge byte-swap (?).
> 
> In your case, yes. But you're supposed to do 16 bit byte access, so your
> bridge should swap byte N with N+1

It does not.  The wiring I described in my previous post is
hard-wired.  I have no choice; it's Apple engineer's.

> Then, look at the function wdc_get_parms(): it will restore the byte order
> for the strings.

No, it does not (unless bus_space_read_multi_2() does), since ntohs()
does nothing on m68k.

> In theory, whe should use stream access here, and then byte-swap the
> numeric fields. But as all the fields in sc_params are 16bit quantities,
> exept the strings, it's simpler to do 16-bit byte-swapping access and
> restore byte-order of the strings.

"16-bit byte-swapping access"?  On mac68k and Mac IDE i/f, the bus
bridge does byte-swapping but not the bus_space_read_multi_2()
functions.  Does this count as "16-bit byte-swapping access"?  If so,
why does it not work? (I had to add a piece of code that byte-swapps
every word in the parameter block)

> > It seems that bus_space_*_stream_*() and bus_space_*_*() do the
> > opposite of what I want them to do.  What's the source of my
> > confusion?
> 
> 1) the WDCC_IDENTIFY command for ATA is a bit hacky

Yes, it is hacky, but I don't think it's the source of my confusion.

> 2) the bride byte-swapping is needed for ATA only because of the BIOS,
>    and it breaks filesystem compatibility with other architectures.

Again, what BIOS are you talking about?

Am I misunderstanding the meaning of the term "byte-swapping"?  I
thought it was said to be byte-swapping when the I/O bus' upper and
lower bytes were wired to the host bus' lower and upper bytes
respectively.

Why do I have such a problem understanding something which other
people have no to little problem understanding?  I feel like I'm an
idiot.

Ken