On Mon, 14 Aug 2023, Michael Schmitz wrote:
On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz <schmitzmic@xxxxxxxxx>
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.
