Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

[Mark Cave-Ayland]

On 02/03/2020 21:40, BALATON Zoltan wrote:

>> 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.)

Presumably the VIA southbridge has its own internal pair of cascaded 8259s so 
the IRQ
line from the drive is connected to IRQ14/15 as per an typical ISA PC. You can 
see
this in the "Common Hardware Reference Platform: I/O Device Reference" PDF 
section 4.1.

>> 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:

But that is exactly what is happening! The comment above clearly indicates the
firmware incorrectly sets the IDE controller in native mode which is in exact
agreement with the trace you provide below. And in fact if you look at
https://www.powerdeveloper.org/platforms/pegasos/devicetree you can see the 
nvramrc
hack that was released in order to fix the device tree to boot Linux which 
alters the
class-code and sets interrupts to 14 (which I believe is invalid, but seemingly 
good
enough here).

> 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.

Again to summarise: this is a known bug in Pegasos2 firmware and the VIA is a
standard chip, so let's try and figure out exactly what is happening using a 
real
firmware and emulate that behaviour in QEMU. This should then make all guests 
happy,
regardless of architecture, without requiring the introduction of feature bits 
or
risk of introducing other incompatibilities.


ATB,

Mark.