CC rz, to make him aware of this thread
On Wed, Jul 26, 2023 at 10:13 PM Michael Schmitz <schmitzmic@xxxxxxxxx> 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@xxxxxxxxxxxxxx
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
