diff mbox

pci: fix bridge IO/BASE

Message ID 20120304164044.GA15384@redhat.com
State New
Headers show

Commit Message

Michael S. Tsirkin March 4, 2012, 4:42 p.m. UTC 
On Sun, Mar 04, 2012 at 02:26:13PM +0000, Blue Swirl wrote:
> > It seems to have to do with the host bridge.
> > It's unusual to have host bridge present itself
> > as a pci to pci bridge but there it is.
> 
> It looks like the I/O base calculations in OpenBIOS are confused

Where's the source for that, BTW? Have build instructions?

> by
> host bridge, after that all BARs are wrong. OpenBIOS also thinks that
> the host bridge is a device and attempts to configure six BARs instead
> of two.

According to the spec it is a device, so should be ok?
If I just make BAR4 writeable we get past the
bios screen at least.
Maybe openbios gets confused if a device has no BARs?
Do things work for you with the patch below?
All it does is make BAR4 writeable, accesses go nowhere.

Comments

Blue Swirl March 4, 2012, 5:49 p.m. UTC | #1 
On Sun, Mar 4, 2012 at 16:42, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Sun, Mar 04, 2012 at 02:26:13PM +0000, Blue Swirl wrote:
>> > It seems to have to do with the host bridge.
>> > It's unusual to have host bridge present itself
>> > as a pci to pci bridge but there it is.
>>
>> It looks like the I/O base calculations in OpenBIOS are confused
>
> Where's the source for that, BTW? Have build instructions?

Under roms/openbios or www.openbios.org. You need xsltproc.
../config/scripts/switch-arch sparc64
make build-verbose
qemu-system-sparc64 -bios obj-sparc64/openbios-builtin.elf.nostrip

>> by
>> host bridge, after that all BARs are wrong. OpenBIOS also thinks that
>> the host bridge is a device and attempts to configure six BARs instead
>> of two.
>
> According to the spec it is a device, so should be ok?
> If I just make BAR4 writeable we get past the
> bios screen at least.
> Maybe openbios gets confused if a device has no BARs?
> Do things work for you with the patch below?
> All it does is make BAR4 writeable, accesses go nowhere.

Looking at serial console, there is no crash, but VGA still does not work.

>
>
> diff --git a/hw/apb_pci.c b/hw/apb_pci.c
> index 1d25da8..fae841f 100644
> --- a/hw/apb_pci.c
> +++ b/hw/apb_pci.c
> @@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d)
>     pci_set_word(d->config + PCI_STATUS,
>                  PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
>                  PCI_STATUS_DEVSEL_MEDIUM);
> +    pci_set_long(d->wmask + 0x20, 0xfffffff0);
>     return 0;
>  }
>
> @@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass, void *data)
>     k->vendor_id = PCI_VENDOR_ID_SUN;
>     k->device_id = PCI_DEVICE_ID_SUN_SABRE;
>     k->class_id = PCI_CLASS_BRIDGE_HOST;
> -    k->is_bridge = 1;
>  }
>
>  static TypeInfo pbm_pci_host_info = {
> --
> MST
Mark Cave-Ayland March 4, 2012, 6:11 p.m. UTC | #2 
On 04/03/12 17:49, Blue Swirl wrote:

>> According to the spec it is a device, so should be ok?
>> If I just make BAR4 writeable we get past the
>> bios screen at least.
>> Maybe openbios gets confused if a device has no BARs?
>> Do things work for you with the patch below?
>> All it does is make BAR4 writeable, accesses go nowhere.
>
> Looking at serial console, there is no crash, but VGA still does not work.

Note that I've just emailed the list about a VGA regression I've found 
on PPC caused by one of Avi's commits - perhaps Michael's fix does work, 
but you're being bitten by the same bug?


ATB,

Mark.
Michael S. Tsirkin March 4, 2012, 7:27 p.m. UTC | #3 
On Sun, Mar 04, 2012 at 05:49:04PM +0000, Blue Swirl wrote:
> On Sun, Mar 4, 2012 at 16:42, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Sun, Mar 04, 2012 at 02:26:13PM +0000, Blue Swirl wrote:
> >> > It seems to have to do with the host bridge.
> >> > It's unusual to have host bridge present itself
> >> > as a pci to pci bridge but there it is.
> >>
> >> It looks like the I/O base calculations in OpenBIOS are confused
> >
> > Where's the source for that, BTW? Have build instructions?
> 
> Under roms/openbios or www.openbios.org. You need xsltproc.
> ../config/scripts/switch-arch sparc64
> make build-verbose
> qemu-system-sparc64 -bios obj-sparc64/openbios-builtin.elf.nostrip

I don't see anything obviously wrong in there, but
the behaviour does seem to indicate some firmware bug ...
I don't have the right toolchain - care debugging?

> >> by
> >> host bridge, after that all BARs are wrong. OpenBIOS also thinks that
> >> the host bridge is a device and attempts to configure six BARs instead
> >> of two.
> >
> > According to the spec it is a device, so should be ok?
> > If I just make BAR4 writeable we get past the
> > bios screen at least.
> > Maybe openbios gets confused if a device has no BARs?
> > Do things work for you with the patch below?
> > All it does is make BAR4 writeable, accesses go nowhere.
> 
> Looking at serial console, there is no crash, but VGA still does not work.

What do info pci/ifo mtree show now?

> >
> >
> > diff --git a/hw/apb_pci.c b/hw/apb_pci.c
> > index 1d25da8..fae841f 100644
> > --- a/hw/apb_pci.c
> > +++ b/hw/apb_pci.c
> > @@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d)
> >     pci_set_word(d->config + PCI_STATUS,
> >                  PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
> >                  PCI_STATUS_DEVSEL_MEDIUM);
> > +    pci_set_long(d->wmask + 0x20, 0xfffffff0);
> >     return 0;
> >  }
> >
> > @@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass, void *data)
> >     k->vendor_id = PCI_VENDOR_ID_SUN;
> >     k->device_id = PCI_DEVICE_ID_SUN_SABRE;
> >     k->class_id = PCI_CLASS_BRIDGE_HOST;
> > -    k->is_bridge = 1;
> >  }
> >
> >  static TypeInfo pbm_pci_host_info = {
> > --
> > MST
Michael S. Tsirkin March 4, 2012, 7:27 p.m. UTC | #4 
On Sun, Mar 04, 2012 at 06:11:20PM +0000, Mark Cave-Ayland wrote:
> On 04/03/12 17:49, Blue Swirl wrote:
> 
> >>According to the spec it is a device, so should be ok?
> >>If I just make BAR4 writeable we get past the
> >>bios screen at least.
> >>Maybe openbios gets confused if a device has no BARs?
> >>Do things work for you with the patch below?
> >>All it does is make BAR4 writeable, accesses go nowhere.
> >
> >Looking at serial console, there is no crash, but VGA still does not work.
> 
> Note that I've just emailed the list about a VGA regression I've
> found on PPC caused by one of Avi's commits - perhaps Michael's fix
> does work, but you're being bitten by the same bug?
> 
> 
> ATB,
> 
> Mark.

It's not a fix as such - just a hack to see what makes
bios crash.
Michael S. Tsirkin March 4, 2012, 7:43 p.m. UTC | #5 
On Sun, Mar 04, 2012 at 06:11:20PM +0000, Mark Cave-Ayland wrote:
> On 04/03/12 17:49, Blue Swirl wrote:
> 
> >>According to the spec it is a device, so should be ok?
> >>If I just make BAR4 writeable we get past the
> >>bios screen at least.
> >>Maybe openbios gets confused if a device has no BARs?
> >>Do things work for you with the patch below?
> >>All it does is make BAR4 writeable, accesses go nowhere.
> >
> >Looking at serial console, there is no crash, but VGA still does not work.
> 
> Note that I've just emailed the list about a VGA regression I've
> found on PPC caused by one of Avi's commits - perhaps Michael's fix
> does work, but you're being bitten by the same bug?
> 
> 
> ATB,
> 
> Mark.

Can you pls try applying my patch on top of old tree where VGA
did work, and see what happens?
diff mbox

Patch

diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 1d25da8..fae841f 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -433,6 +433,7 @@  static int pbm_pci_host_init(PCIDevice *d)
     pci_set_word(d->config + PCI_STATUS,
                  PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
                  PCI_STATUS_DEVSEL_MEDIUM);
+    pci_set_long(d->wmask + 0x20, 0xfffffff0);
     return 0;
 }
 
@@ -444,7 +445,6 @@  static void pbm_pci_host_class_init(ObjectClass *klass, void *data)
     k->vendor_id = PCI_VENDOR_ID_SUN;
     k->device_id = PCI_DEVICE_ID_SUN_SABRE;
     k->class_id = PCI_CLASS_BRIDGE_HOST;
-    k->is_bridge = 1;
 }
 
 static TypeInfo pbm_pci_host_info = {