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

[BALATON Zoltan]

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

Regards,
BALATON Zoltan