On August 14, 2023 7:52:18 PM UTC, Richard Z <rz@xxxxxxxxxxxxxx> wrote:
On August 14, 2023 11:18:44 AM UTC, William R Sowerbutts <will@xxxxxxxxxxxxxx> wrote:
On Mon, Aug 14, 2023 at 10:54:54AM +1200, Michael Schmitz wrote:
On 14/08/23 10:24, William R Sowerbutts wrote:
* 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO
access")
That might be fixed by my second RFC patch, just gone out today.
6.4.10 + your "RFC v2" patch boots without the "Bad IO access" errors!
Your patch looks correct to me.
This one still byte-swaps the data from disk though. I understood that was
always the case for Q40, but I may have been mistaken there.
It is indeed returning byte-swapped data. This is easily fixed, I'm using
the attached patch.
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.
The Q40 does NOT have hardware to reverse the byte-swapping. The CPU has to
byte-swap data if you want to use disks with standard/compatible 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).
I have learned that the "standard" firmware for the Q40, SMSQ/E, does not
byte-swap data (it also uses an obscure partition scheme and filesystem).
It doesn't use any obscure partition scheme, just the Atari partition table. It used to require some special magic word but the kernel code and all Linux tools would work just like if it was a normal Atari partition table. I have only modified atari-fdisik to add that magic number if it wasn't there yet to make original firmware happy.
Personally, I am strongly in favour of Linux on the Q40 using standard
byte-order disks that are compatible with other machines. This feels like the
right thing to do and it is what I think most users would expect.
Users (if there are any!) with legacy byte-swapped disks can always use the
standard tools to byte swap them into the correct, compatible format.
Most users that I know have a dual boot system so this won't work until the other available OSes are modified to support byte swapping. This would be doable but the problem is for quite some time the kernel would have to understand both variants. Think of it, if you want to boot an older kernel you don't want to byteswap your whole hard disk back and forth every time when testing an older or newer kernel. Also, I would like to see data on the speed impact of the byte swapping, making the old hardware even 5% slower isn't something I would be enthusiastic about and my guess is it would more than that.
Other than that it would be nice to use the "normal" byte order because exchangeable devices became much more common, I do even have an SD card reader on the IDE port.
Richard
