Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,

On 14/08/23 11:37, Finn Thain wrote:
>
>>> The Q40 does not have an on-board IDE controller.  IDE is accessed via
>>> a common ISA PC Super-IO card.  When you do a 16-bit transfer from the
>>> ISA I/O address the data comes out backwards and the CPU needs to
>>> byteswap it.
>>>
>>> I found it interesting and quite unexpected that 5.13 read data from
>>> the IDE drive byte-swapped.  I had prepared a drive for the machine
>>> with an MBR partition table and an ext4 filesystem but the kernel did
>>> not recognise either.  After a while I realised I had to byte swap the
>>> entire drive with 'dd conv=swab', and then it worked.
>>>
>>> For my 6.4 patch I enabled byte swapping in the
>>> pata_falcon_data_xfer() function -- this allows me to use an IDE drive
>>> with everything in the normal/compatible byte ordering, which makes
>>> life much easier. I assume this is the intended behaviour.
>> That would be the sane behaviour, but the designers of both the Falcon
>> and apparently the TiVo decided otherwise, wired up the IDE data bus
>> byte-swapped and saved the byteswap operations in the driver. I'm unsure
>> how this was intended to work on Q40.
> Why did Atari do that? Was it because they wanted to interoperate with
> exotic filesystems (i.e. Microsoft) without paying a byte swapping tax in
> software? (Despite the 68000 instructions for that purpose.)

Interoperability cannot have been a concern - otherwise they would have 
made sure the on-disk format was compatible. Saving a byte swap 
operation for each word transferred must have seemed worth it.

They just took what was available in terms of hard drive interfaces 
(SCSI as well as IDE). IDE was 16 bytes wide, and the drive identify 
data were ending up in the 'wrong' byte order, so they just swapped 
those data.

As far as I know, neither floppy nor disk FAT formats are 100% identical 
to the PC ones, just somewhat compatible.

>
>>> I wonder if any existing Q40 users are actually storing all the data
>>> on their drives byte-swapped just to avoid the overhead of
>>> byte-swapping on every read/write. I suppose this would work just fine
>>> until you need to connect that drive to another machine.
>> Yes, it does work just fine with that little inconvenience. (When I had
>> to fix a corrupted partition table an FAT, I had to hook the Falcon disk
>> up to a PC and run ARAnyM on it to get byte-swapped access to the data.)
>>
>> Now the question is how data on legacy Q40 IDE disks have been stored.
>> If it's byte-swapped, we'd better keep that byte order in the current
>> driver (meaning your changes to pata_falcon_data_xfer() won't be needed,
>> but you would have to swap back data on your disk). If it's always been
>> in PC compatible byte order, all data (not just the identify data) must
>> be swapped.
>>
>> I'd like to have Richard's opinion on this (or hear from any other
>> former Q40 user).
>>
> Yes.
>
> If the Linux port for Q40 could use pata_legacy unmodified, that has to be
> more maintainable. However, I could imagine a scenario where the standard
> Q40 firmware, bootloader and/or vendor operating system would cease to
> interoperate with Linux if Linux has no byteswapping IDE driver. If true,
> would it matter?

I use the Atari TOS partition that the Falcon boots into to run the boot 
loader from, and I transfer kernels to that partition from Linux using 
the vfat file system (after copying them to the Linux partition over 
ethernet). That would all break without a byte swapping IDE driver.

Something similar may be true for Q40 users, but there can't be many of 
these left, otherwise I'd have expected to hear about the broken 
pata_falcon issue a lot sooner.

> Unix has a long tradition of pushing the byteswapping problem onto
> userland for those who need to migrate data. Hence tools like cpio and dd
> which are able to do byteswapping. One has to wonder whether drivers and
> peripherals are the wrong places for that.

Probably not - in that regard, not caring about the on-disk format might 
even be the Right Thing to do.

I suspect there's a way to do byte swapping on the fly using a loopback 
device and some dm magic, so disks with the 'wrong' byte order could be 
accessed on non-native systems. I just have never been bothered enough 
about the issue to find out.

Most other Falcon users might use SCSI (and SCSI-SD adapters) to 
transport data between systems. Not an option for Q40.

Cheers,

     Michael