[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BALATON Zoltan
Subject: Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode
Date: Sun, 1 Mar 2020 22:30:31 +0100 (CET)
User-agent: Alpine 2.22 (BSF 395 2020-01-19)

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, 
sets it to 0x8f which means native mode.

I mean, 0x8a legacy mode and 0x8f native mode, I see firmware poking 0x8f and 
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 
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 
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 don't see the PCI BARs being a problem since native drivers wouldn't touch the
memory/IO space enable bits, and the BARs are disabled by default. It could 
just be
that the VIA chipset simply doesn't lock the PCI memory/IO space bits in
compatibility mode if an OS does decide to use them and program the BARs as it 
in native mode.

I think you mean legacy drivers should not touch BARs. That could also be a way (the docs do say that default values for BARs match legacy ports so it's possible that setting legacy mode resets these and uses them as they were enabled but does not prevent changes) but I don't see how could we implement that in QEMU because we either have legacy ports or PCI IDE in QEMU and BARs are handled by PCI code so to keep those enabled for legacy emulation even if they would be disabled for PCI would need some change in PCI code that's probably not a good idea to touch as a lot of things depend on that. This patch I've come up with is confined to PCI IDE code and the end result is the same for at least the boards and clients we care about so I'd go with this for now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]