On Mon, 2 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 21:30, BALATON Zoltan wrote:
On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
On 01/03/2020 18:53, BALATON Zoltan wrote:
On Sun, 1 Mar 2020, BALATON Zoltan wrote:
is not legacy mode but "not 100% native mode". The prog-if is set to 0x8a which
corresponds to native mode but this is what the Linux fixup function does,
firmware
sets it to 0x8f which means native mode.
I mean, 0x8a legacy mode and 0x8f native mode, I see firmware poking 0x8f and
Amiga
like OSes reading that yet expecting legacy interrupts. Linux fixes up prog-if
so its
driver detects legacy interrupts but still uses ioports from PCI BARs.
I see. Note that it is also possible to have a prog-if value of 0x80 which is
where
the hardware is locked into legacy mode via a pull-down resistor. Perhaps this
is the
case for Pegasos, since it would explain why attempts to switch the mode via
prog-if
are ignored?
I've seen such option in CMD646 docs but couldn't find similar in VT8231.
Genesi has
published the schematics of Pegasos II (linked from my
https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 page) so we could check
if
you can tell which pin is that. But we get 0x8a in Linux lspci output on real
hardware for prog-if which is explained by firmare setting it to 0x8f then Linux
fixup function clearing bits 0 and 2 so does not seem it started as 0x80
because then
firmware should not be able to set it to 0x8f either.
I had a quick look at the schematics linked from the page above, and they
confirm
that the VIA IDE interface is connected directly to IRQs 14 and 15 and not to
the PCI
interrupt pins.
Where did you see that? What I got from trying to look this up in the
schematics was that VT8231 has two pins named IRQ14 and IRQ15 (but
described as Primary and Secondary Channel Interrupt Request in doc) where
the interrupt lines of the two IDE ports/channels are connected but how
they are routed within the chip after that was not clear. The chip doc
says that in native mode the interrupt should be configurable and use a
single interrupt for both channels and in legacy mode they use the usual
14 and 15 but this is not what guest drivers expect so I think not how
really works on PegasosII. It is true however that connection to PCI
interrupts aren't mentioned so it always uses ISA IRQ numbers, it just
depends on legacy vs. native mode which line is raised. But that was never
really a question for VT8231 and maybe only CMD646 could have such
interconnection with PCI interrupts. (Proabable reason is that via-ide is
part of a southbridge chip where it has connections to ISA bus while
CMD646 is a PCI IDE controller but I could be wrong as my knowledge is
limited about these.)
So on that basis the best explanation as to what is happening is the
comment in the link you provided here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/powerpc/platforms/chrp/pci.c?h=v4.14.172#n353
/* Pegasos2 firmware version 20040810 configures the built-in IDE controller
* in legacy mode, but sets the PCI registers to PCI native mode.
* The chip can only operate in legacy mode, so force the PCI class into legacy
* mode as well. The same fixup must be done to the class-code property in
* the IDE node /pci@80000000/ide@C,1
*/
I'm not sure that it makes much sense that the firmware configures the
chip one way then puts info about a different way in the device tree.
There could be bugs but this is not likely. Especially because I see in
traces that the firmware does try to configure the device in native mode.
These are the first few accesses of the firmware to via-ide:
pci_cfg_write via-ide 12:1 @0x9 <- 0xf
pci_cfg_write via-ide 12:1 @0x40 <- 0xb
pci_cfg_write via-ide 12:1 @0x41 <- 0xf2
pci_cfg_write via-ide 12:1 @0x43 <- 0x35
pci_cfg_write via-ide 12:1 @0x44 <- 0x18
pci_cfg_write via-ide 12:1 @0x45 <- 0x1c
pci_cfg_write via-ide 12:1 @0x46 <- 0xc0
pci_cfg_write via-ide 12:1 @0x50 <- 0x17171717
pci_cfg_write via-ide 12:1 @0x54 <- 0x14
pci_cfg_read via-ide 12:1 @0x0 -> 0x5711106
pci_cfg_read via-ide 12:1 @0x0 -> 0x5711106
pci_cfg_read via-ide 12:1 @0x8 -> 0x1018f06
pci_cfg_read via-ide 12:1 @0xc -> 0x0
pci_cfg_read via-ide 12:1 @0x2c -> 0x11001af4
pci_cfg_read via-ide 12:1 @0x3c -> 0x10e
pci_cfg_read via-ide 12:1 @0x4 -> 0x2800080
pci_cfg_read via-ide 12:1 @0x3c -> 0x10e
pci_cfg_write via-ide 12:1 @0x3c <- 0x109
The very first write is to turn on native mode, so I think it's not about
what the firmware does but something about how hardware is wired on
Pegasos II or the VT8231 chip itself that only allows legacy interrupts
instead of 100% native mode for IDE.
Given that the DT is wrong, then we should assume that all OSs would have to
compensate for this in the same way as Linux, and therefore this should be
handled
automatically.
AFAICT this then only leaves the question: why does the firmware set
PCI_INTERRUPT_LINE to 9, which is presumably why you are seeing problems running
MorphOS under QEMU.
Linux does try to handle both true native mode and half-native mode. It
only uses half-native mode if finds IRQ14 on Pegasos, otherwise skips
Pegasos specific fixup and uses true native mode setup. I don't know what
MorphOS does but I think it justs knows that Pegasos2 has this quirk and
does not look at the device tree at all.
Could it be that setting prog-if to 0x8a legacy mode also resets
PCI_INTERRUPT_LINE
to 14? You should be able to confirm this easily on real hardware using the
Forth
config-* words on the IDE node and reading the prog-if byte before and after.
I don't have direct access to real hardware and would also need to come up
with some Forth to verify that but given the above trace that the firmware
does before we can enter any Forth we would likely find @0x9 = 0x8f and
@0x3c = 0x0e because after booting Linux we see 0x8a and 0x0e and Linux
only touches the two mode bits.
So I don't know the ultimate reason why it works that way but I'm quite
sure that this emulation is close enough and guests are happy with it too.
Regards,
BALATON Zoltan
