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

[BALATON Zoltan]

On Fri, 6 Mar 2020, BALATON Zoltan wrote:
> On Thu, 5 Mar 2020, Mark Cave-Ayland wrote:
> > On 04/03/2020 22:33, BALATON Zoltan wrote:
> > another possibility: PCI configuration space register 0x3d (Interrupt pin) 
> > is
> > documented as having value 0 == Legacy IRQ routing which should be the 
> > initial value
> > on reset, but QEMU incorrectly sets it to 1 which indicates PCI IRQ 
> > routing.
>
> The VT8231 docs say this should always read 1 but may be this is somehow set 
> to 0 on the Pegasos2. What does that mean? Should we use this value instead 
> of the feature bit to force using legacy interrupts? We'd still need a 
> property in via-ide to set this reg or is it possible to set it from board 
> code overriding the default after device is created? That would allow to drop 
> patch 1. I can try this.

This seemed like it could simplify patches a bit but it does not work. 
Setting this reg to 0 breaks Linux and MorphOS which then think the device 
does not have an interrupt at all and fail as before waiting for the irq. 
So we still need the feature bit, cant use this reg to force legacy 
interrupts. I've spent considerable time testing different OSes before 
I've ended up with this patch series I've submitted and I could not find a 
simpler way that works with everything.

Regards,
BALATON Zoltan

> > In your previous email you included a trace of the PCI configuration 
> > accesses to the
> > via-ide device. Can you try this again with the following diff and post the 
> > same
> > output once again?
> >
> > diff --git a/hw/ide/via.c b/hw/ide/via.c
> > index 096de8dba0..db9f4af861 100644
> > --- a/hw/ide/via.c
> > +++ b/hw/ide/via.c
> > @@ -139,7 +139,7 @@ static void via_ide_reset(DeviceState *dev)
> >     pci_set_long(pci_conf + PCI_BASE_ADDRESS_2, 0x00000170);
> >     pci_set_long(pci_conf + PCI_BASE_ADDRESS_3, 0x00000374);
> >     pci_set_long(pci_conf + PCI_BASE_ADDRESS_4, 0x0000cc01); /* BMIBA: 
> > 20-23h */
> > -    pci_set_long(pci_conf + PCI_INTERRUPT_LINE, 0x0000010e);
> > +    pci_set_long(pci_conf + PCI_INTERRUPT_LINE, 0x0000000e);
> >
> >     /* IDE chip enable, IDE configuration 1/2, IDE FIFO Configuration*/
> >     pci_set_long(pci_conf + 0x40, 0x0a090600);
>
> This does not change much:
>
> 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 -> 0xe
> pci_cfg_read via-ide 12:1 @0x4 -> 0x2800080
> pci_cfg_read via-ide 12:1 @0x3c -> 0xe
> pci_cfg_write via-ide 12:1 @0x3c <- 0x9
>
> compared to
>
> > 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
>
> firmware does not seem to care about this value.
>
> Regards,
> BALATON Zoltan