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

Finn Thain
2023-08-13T23:37:53Z

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

On Mon, 14 Aug 2023, Michael Schmitz wrote:

> > On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@gmail.com>
> > wrote:
> >> Yes, but Q40 and Falcon are impossible to support any other way, and
> >> byte swapping the IDE interface in hardware was never repeated
> >> anywhere else, fortunately. We will have to keep pata_falcon around
> >> for that cause in any event.
> > I wonder if this is a misunderstanding about Q40 IDE.
> >
> > 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.)

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

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.