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

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,

On 26/07/23 21:22, Finn Thain wrote:
>
>>> There are two ISA slots where all other I/O devices are connected. These are
>>> described (concisely!) on page 7 of the linked manual:
>>>
>>> 8-bit ISA I/O cycles are performed for CPU byte accesses to 0xFF400001 + 4 *
>>> ISA address
>>>
>>> 16-bit ISA I/O cycles are performed for CPU word accesses to 0xFF400000 + 4
>>> * ISA address
>>>
>>> 8-bit ISA memory cycles are performed for CPU byte accesses to 0xFF800001 +
>>> 4 * ISA address
>>>
>>> 16-bit ISA memory cycles are performed for CPU word accesses to 0xFF800000 +
>>> 4 * ISA address
>> Yep, that much is evident from the Q40 address translation scheme. But a
>> similar sort of scheme is used on other m68k platforms to wire up
>> peripherals that were originally designed for Intel systems, and these
>> are not connected through an ISA bus.
> I can't figure out why those platforms don't suffer from the same "double
> translation" problem that William described on q40.

There are only two other address translation schemes in effect - Amiga 
Gayle, which handles byte/word address offsets, and gets passed IO 
addresses (in the sense that these are the addresses where registers are 
mapped in memory), and Atari EtherNEC, which handles IO ports (from the 
ne.c legacy ISA driver).

The Gayle address translation, taking MMIO addresses does not add an IO 
base address. The EtherNEC address translation, OTOH, takes IO ports and 
must add the ROM port base address as IO base.

What I did not realize at the time I rewrote the Q40 driver as platform 
driver is that the old driver used IO ports, not MMIO addresses. In 
order to reserve the IDE register area (we don't have a MMIO area 
corresponding to the IO ports range mapped on m68k), I did add the Q40 
ISA base address to the IO port range to populate the platform memory 
resources, forgetting that the same base address is then added a second 
time through the IO address translation.

Seeing as the address passed into address translation already has the IO 
base offset of 0xff400000 and register scaling of 4 applied, it could be 
sufficient to change the address translations to only add the additional 
IO mem offset of 0x00400000:

#define q40_io_mem_offset 0x00400000

#define Q40_ISA_IO_B(ioaddr) ((unsigned long)(ioaddr))
#define Q40_ISA_IO_W(ioaddr) ((unsigned long)(ioaddr))
#define Q40_ISA_MEM_B(madr)  (q40_io_mem_offset + ((unsigned long)(madr)))
#define Q40_ISA_MEM_W(madr)  (q40_io_mem_offset + ((unsigned long)(madr)))

Note that this will play havoc with all other ISA drivers on Q40, so I'd 
just suggest that to test my hypothesis about how the address 
translation affects the IDE IO.


A correct fix would keep the current IO translation intact, and instead 
use the platform mem resource to register the driver IO range, and the 
platform IO resource as base offset to populate the port ioaddr struct 
(minus the register scaling and byte offset, mind you).

I'll give this some more thought ASAP.

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.

Cheers,

     Michael


>
>>> I understand that the machines originally shipped with a 16-bit ISA card
>>> based on the W83787IF "PC super I/O" chip, integrating a floppy controller,
>>> IDE interface, game port, parallel port, and two 16550A UARTs.
>> OK.
>>> My Q40 came without this card, so I am using a card based on the similar
>>> W83757 chip (the serial ports are 16450 instead of 16550A, it doesn't
>>> support
>>> the fancy EPP/ECP parallel port modes).
>>>
>>>>>> It might be a good idea to verify that IDE works in v5.13
>>>>> Yes, please do.
>>> It did.
>>>
>>>> And please also verify it's broken after 44b1fbc0f5f30e66 was applied.
>>> I will try to do that!
>> Probably just try v5.14 - in my tree, 44b1fbc0f5f30e66 came on top of 5.13-rc2
>> so 5.14 ought to have it applied (but rather check, just the same).
>>
> If git is an obstacle, one may obtain the 44b1fbc0f5f30e66 tree (as
> easily as the v5.14 tree) by clicking the 'download' button here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44b1fbc0f5f30e66