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
