Hello Thank you for your interest and patience! Sorry for the delay in providing more information. The only method I had to transfer test kernels onto the Q40 was painfully slow and involved swapping ISA cards which is itself problematic as the pins in one of the ISA slots are breaking. In the end I decided my best option was to dispose of the standard operating system (SMSQ/E) and write a new boot ROM for the machine with support for FAT32 filesystems on an IDE disk and TFTP transfers using an NE2000 card. It's still in development but is now working well enough to use. The source code is at https://github.com/willsowerbutts/q40boot During the process I learned a bit more about the Q40 hardware, and transferring a kernel now takes 7 seconds instead of over 20 minutes. I've run the various tests as requested; * 5.13.19 -- IDE works (but the data on disk is byte-swapped, see below) * 5.13.19+44b1fbc0f5f30e66a56d29575349f0b1ebe2b0ee -- IDE fails (crash) * 5.14.21 -- IDE fails (crash) * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO access") * 6.4.10 + my patch -- IDE works, data on disk is NOT byte-swapped Copies of the boot output for each kernel are attached to this email. I've also attached the patch I am currently using on my Q40 kernel. It's based in part on Michael's patch. It bodges up "ioport_map" to apply the offset required to convert raw ISA address into "cookies" and thus allow the IDE to work without "Bad IO" complaints. To be crystal clear I am NOT proposing this as a solution, it's obviously a hack job, but I wanted to illustrate at least one way that *does* work on the Q40. I think one proper solution might involve enabling CONFIG_HAS_IOPORT_MAP but I've not yet looked properly into the implications of doing so. I'm very open to alternative solutions too. As a side note, the NE2000 driver, which is also using 8- and 16-bit ISA I/O, works correctly with both 5.13 and 6.4. If one allows it to auto-probe the card's interrupt it locks up the machine due to limitations of the interrupt controller, but I understand this was always the case; I've made a tiny patch to ne.c to prevent it trying this. On Tue, Jul 25, 2023 at 08:26:28AM +1200, Michael Schmitz wrote: >Note that this also means that the address hardcoded for IDE may be >incorrect (AFAIR, IDE cards could have their IO base reassigned by >firmware). The W83757 on my ISA IO card, and the W83787IF on the ISA IO card that shipped with the machine, are configurable only using jumpers. They can only use the two standard base addresses (0x1F0 or 0x170). On Fri, Jul 28, 2023 at 9:52 AM Michael Schmitz 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. 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. For my Q40boot ROM I wrote an IDE driver. It just treats the IDE interface as a regular legacy PC style IDE interface (which is exactly what it is!) plus byte swapping of 16-bit transfers. See the functions q40_ide_read_sector_data and q40_ide_write_sector_data in the IDE driver (q40ide.c, q40isa.h in the q40boot github repository linked above). I am going to look at the pata_legacy driver and see if it might be usable on the Q40 instead of pata_falcon. As a long term fix I think I need to read up on CONFIG_HAS_IOPORT_MAP to try and understand how I might enable this. I expect enabling it will have implications for all M68K machines, so maybe someone with more experience should be making that decision. I would be very happy to run further tests or to rewrite my hacky patch in response to pointers on how to improve it. Thanks Will On Sun, Aug 13, 2023 at 05:38:00PM +1000, Finn Thain wrote: >Michael, William, > >On Sun, 13 Aug 2023, Michael Schmitz wrote: > >> Am 28.07.23 um 11:47 schrieb Finn Thain: >> > On Thu, 27 Jul 2023, Michael Schmitz wrote: >> > >> >>>> And yes, I'm painfully aware the m68k low level IO code is becoming >> >>>> a bit of a maintainance legacy, in no small part due to my hacks >> >>>> around Atari EtherNEC. >> >>>> >> >>> I guess you and I both can share the blame for 44b1fbc0f5f30e66... >> >>> >> >>> Anyway, you make a good point about on-going maintenance. Do you >> >>> think that by supporting standard ISA drivers we might actually >> >>> reduce the ideosyncracies in m68k IO code? >> >> You and DaveM ought to have a chat about that - abstracting the >> >> legacy drivers from the ISA constraints was his preferred option when >> >> I last attempted to get the Gayle network driver patches merged. When >> >> I say 'preferred', I'm probably understating a little. >> >> >> > A discussion with maintainers probably won't get far without working >> > code to look at. Perhaps William will send an RFC patch to illustrate >> > his approach. >> >> Haven't seen anything yet, so I've just sent a patch switching >> pata_falcon.c to use the IO resources instead of the memory resources. > >Thanks for sending that. > >> Survived compile and ARAnyM boot tests only so far. I've checked and >> confirmed the entire 0xffxxxxx range is mapped transparent in head.S for >> Q40 so I don't see what else might be missing. >> > >In the message that Geert originally forwarded, William was quoted as >saying it was necessary to "fix up the pata_falcon_data_xfer function". He >also said that using the IO port resources "causes the ioread8/iowrite8 >functions to complain loudly". >https://lore.kernel.org/linux-m68k/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com/ > >I think your patch is taking the same approach and may run into the same >issues... I guess we shall see when William tests it. > >> Please have a look and test if possible. Haven't yet bothered >> linux-block or linux-ide... the patch still needs a Fixes: and other >> trimmings so isn't ready for submission anyway. >> > >Right. You'll want to run checkpatch.pl on it at some stage. _________________________________________________________________________ William R Sowerbutts will@sowerbutts.com "Carpe post meridiem" http://sowerbutts.com main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<