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

Geert Uytterhoeven
2023-07-27T07:30:13Z

CC rz, to make him aware of this thread

On Wed, Jul 26, 2023 at 10:13 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> 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.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds