OpenBIOS May 2012

openbios@openbios.org

10 participants
42 discussions

Oops: 1056 breaks Solaris 8 on Sparc 32 Qemu
by P. Wilhelm 13 May '12

13 May '12

Friday I tried the 1056 version of sparc32 openbios and found that Solaris 8 hangs during the OS initialization (during the second period when the spinning line (-, \, |, /, -) occurs). The last version of openbios I had been using was 1047 which seemed to work Ok. So, I incrementally checked versions 1048-1056. The boot works on all but 1056, so it looks like something with the memory changes in 1055 broke the Solaris 8 boot. Let me know if you need any specific information about Qemu arguments. Respectfully, Paul

1 0

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Jakub Jermar 13 May '12

13 May '12

On 05/13/2012 12:00 AM, Artyom Tarasenko wrote: > On Sat, May 12, 2012 at 7:06 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Sat, May 12, 2012 at 6:29 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> On Sat, May 12, 2012 at 3:57 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >>>> On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>>> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >>>>> support for virtio-block and interrupt nodes. >>>>> >>>>> With these patches and QEMU HEAD, Linux can boot like Artyom describes in >>>>> http://tyom.blogspot.de/2012_05_01_archive.html >>>>> but without any manual OpenBIOS setup. >>>> >>>> My test kernel - 3.3.2 - still needs the ebus interrupt mapping properties: >>>> >>>> cd /pci@1fe,0/ebus >>>> 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ >>>> ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property >>>> 000001ff encode-int ffffffff encode-int encode+ 00000003 encode-int encode+ >>>> " interrupt-map-mask" property >>>> device-end >>>> boot >>> >>> Updated patch attached. This change seems to help the serial driver. >> >> Looks good. The result seems to be identical with my hack, but there >> is one point I'd like to discuss: >> >> cd /pci@1fe,0/pci-ata ok >> .properties >> name "pci-ata" >> [...] >> interrupts 0 >> >> I'm not sure that this is a valid value for the interrupts property. > > Tarl, Jakub, can you comment whether 0 is allowed? According to the UltraSPARC IIi User's Manual, section 19.3.3, INO 0 (again, relative to the parent node mapping), would be INTA# on bus 0 and INO 1 would be INTB#. Jakub

2 1

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Artyom Tarasenko 13 May '12

13 May '12

On Sat, May 12, 2012 at 7:06 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sat, May 12, 2012 at 6:29 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Sat, May 12, 2012 at 3:57 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >>> On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >>>> support for virtio-block and interrupt nodes. >>>> >>>> With these patches and QEMU HEAD, Linux can boot like Artyom describes in >>>> http://tyom.blogspot.de/2012_05_01_archive.html >>>> but without any manual OpenBIOS setup. >>> >>> My test kernel - 3.3.2 - still needs the ebus interrupt mapping properties: >>> >>> cd /pci@1fe,0/ebus >>> 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ >>> ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property >>> 000001ff encode-int ffffffff encode-int encode+ 00000003 encode-int encode+ >>> " interrupt-map-mask" property >>> device-end >>> boot >> >> Updated patch attached. This change seems to help the serial driver. > > Looks good. The result seems to be identical with my hack, but there > is one point I'd like to discuss: > > cd /pci@1fe,0/pci-ata ok > .properties > name "pci-ata" > [...] > interrupts 0 > > I'm not sure that this is a valid value for the interrupts property. Tarl, Jakub, can you comment whether 0 is allowed? > If it's not, I guess it has to be changed back to 1, and the > additional interrupt mappings have to be added to the root pci node. > On the other hand, if no one objects, we can apply the patch as-is, > and say that it's good enough for the only guest OS which currently > supports these devices (virtio and cmd646). > >>>> Blue Swirl (2): >>>> pci: identify virtio-scsi devices >>>> Sparc64: fix interrupt properties >>>> >>>> drivers/ide.c | 2 ++ >>>> drivers/pc_serial.c | 3 +++ >>>> drivers/pci.c | 23 +++++++++++++++++++++++ >>>> drivers/pci_database.c | 19 ++++++++++++++++++- >>>> drivers/pci_database.h | 1 + >>>> include/drivers/pci.h | 3 +++ >>>> 6 files changed, 50 insertions(+), 1 deletion(-) >>>> >>>> -- >>>> 1.7.10 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 12 May '12

12 May '12

On 2012-May-12 09:48 , Artyom Tarasenko wrote: > Btw, thanks Tarl for pointing in the right direction. The problem was that > the combination of the interrupt map and mask properties matched _more > than one_ "reg". > That was confusing the Linux OF tree parser. > > Out of curiosity: should this mappings be really unique? Not sure. We write them such that they are in our platforms, but I don't know the degree of uniqueness required.

1 0

SPARC32 SBus probing with OBP
by Mark Cave-Ayland 12 May '12

12 May '12

Hi all, Does anyone know how OBP probes for in-built SBus devices on SPARC32? The reason I'm asking is that I'm looking at trying to detect in-built devices in OpenBIOS, and the SBus documentation suggests that each slot contains Fcode mapped at offset 0 which is executed to build the device tree. Now QEMU currently doesn't do any Fcode mapping within SBus slots, but according to its boot output OBP still manages to detect hardware such as graphics cards etc. within certain slots during boot. Is there a different mechanism used for detecting in-built devices, or is it just something as simple as a hardcoded list based upon the current machine type? Many thanks, Mark.

2 1

Re: [OpenBIOS] [PATCH 1/2] pci: identify virtio-scsi devices
by Artyom Tarasenko 12 May '12

12 May '12

Acked-by: Artyom Tarasenko <atar4qemu(a)gmail.com> On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > Identify virtio SCSI device in PCI probe. > > Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> > --- > drivers/pci_database.c | 19 ++++++++++++++++++- > include/drivers/pci.h | 3 +++ > 2 files changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci_database.c b/drivers/pci_database.c > index ac47621..7d420c3 100644 > --- a/drivers/pci_database.c > +++ b/drivers/pci_database.c > @@ -45,6 +45,23 @@ static const pci_subclass_t undef_subclass[] = { > }, > }; > > +static const pci_dev_t scsi_devices[] = { > + { > + /* Virtio-block controller */ > + PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_DEVICE_ID_VIRTIO_BLOCK, > + NULL, "virtio-scsi", NULL, > + "pci1af4,1001\0pci1af4,1001\0pciclass,01018f\0", > + 0, 0, 0, > + NULL, NULL, > + }, > + { > + 0xFFFF, 0xFFFF, > + NULL, NULL, NULL, NULL, > + -1, -1, -1, > + NULL, NULL, > + }, > +}; > + > static const pci_dev_t ide_devices[] = { > { > PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_CMD_646, /* CMD646 IDE controller */ > @@ -64,7 +81,7 @@ static const pci_dev_t ide_devices[] = { > static const pci_subclass_t mass_subclass[] = { > { > PCI_SUBCLASS_STORAGE_SCSI, "SCSI bus controller", > - NULL, NULL, NULL, > + "scsi", scsi_devices, NULL, > NULL, NULL, > }, > { > diff --git a/include/drivers/pci.h b/include/drivers/pci.h > index 562a43e..4c996c0 100644 > --- a/include/drivers/pci.h > +++ b/include/drivers/pci.h > @@ -205,6 +205,9 @@ extern const pci_arch_t *arch; > #define PCI_VENDOR_ID_QEMU 0x1234 > #define PCI_DEVICE_ID_QEMU_VGA 0x1111 > > +#define PCI_VENDOR_ID_REDHAT_QUMRANET 0x1af4 > +#define PCI_DEVICE_ID_VIRTIO_BLOCK 0x1001 > + > #define PCI_VENDOR_ID_INTEL 0x8086 > #define PCI_DEVICE_ID_INTEL_82441 0x1237 > > -- > 1.7.10 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Artyom Tarasenko 12 May '12

12 May '12

On Sat, May 12, 2012 at 6:29 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sat, May 12, 2012 at 3:57 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >>> support for virtio-block and interrupt nodes. >>> >>> With these patches and QEMU HEAD, Linux can boot like Artyom describes in >>> http://tyom.blogspot.de/2012_05_01_archive.html >>> but without any manual OpenBIOS setup. >> >> My test kernel - 3.3.2 - still needs the ebus interrupt mapping properties: >> >> cd /pci@1fe,0/ebus >> 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ >> ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property >> 000001ff encode-int ffffffff encode-int encode+ 00000003 encode-int encode+ >> " interrupt-map-mask" property >> device-end >> boot > > Updated patch attached. This change seems to help the serial driver. Looks good. The result seems to be identical with my hack, but there is one point I'd like to discuss: cd /pci@1fe,0/pci-ata ok .properties name "pci-ata" [...] interrupts 0 I'm not sure that this is a valid value for the interrupts property. If it's, not I guess it has to be changed back to 1, and the additional interrupt mappings have to be added to the root pci node. On the other hand, if no one objects, we can apply the patch as-is, and say that it's good enough for the only guest OS which currently supports these devices (virtio and cmd646). >>> Blue Swirl (2): >>> pci: identify virtio-scsi devices >>> Sparc64: fix interrupt properties >>> >>> drivers/ide.c | 2 ++ >>> drivers/pc_serial.c | 3 +++ >>> drivers/pci.c | 23 +++++++++++++++++++++++ >>> drivers/pci_database.c | 19 ++++++++++++++++++- >>> drivers/pci_database.h | 1 + >>> include/drivers/pci.h | 3 +++ >>> 6 files changed, 50 insertions(+), 1 deletion(-) >>> >>> -- >>> 1.7.10 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Blue Swirl 12 May '12

12 May '12

On Sat, May 12, 2012 at 3:57 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >> support for virtio-block and interrupt nodes. >> >> With these patches and QEMU HEAD, Linux can boot like Artyom describes in >> http://tyom.blogspot.de/2012_05_01_archive.html >> but without any manual OpenBIOS setup. > > My test kernel - 3.3.2 - still needs the ebus interrupt mapping properties: > > cd /pci@1fe,0/ebus > 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ > ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property > 000001ff encode-int ffffffff encode-int encode+ 00000003 encode-int encode+ > " interrupt-map-mask" property > device-end > boot Updated patch attached. This change seems to help the serial driver. > >> Blue Swirl (2): >> pci: identify virtio-scsi devices >> Sparc64: fix interrupt properties >> >> drivers/ide.c | 2 ++ >> drivers/pc_serial.c | 3 +++ >> drivers/pci.c | 23 +++++++++++++++++++++++ >> drivers/pci_database.c | 19 ++++++++++++++++++- >> drivers/pci_database.h | 1 + >> include/drivers/pci.h | 3 +++ >> 6 files changed, 50 insertions(+), 1 deletion(-) >> >> -- >> 1.7.10 > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Mark Cave-Ayland 12 May '12

12 May '12

On 12/05/12 15:14, Artyom Tarasenko wrote: > On Sat, May 12, 2012 at 3:54 PM, Blue Swirl<blauwirbel(a)gmail.com> wrote: >> On Sat, May 12, 2012 at 1:34 PM, Artyom Tarasenko<atar4qemu(a)gmail.com> wrote: >>> On Sat, May 12, 2012 at 1:42 PM, Blue Swirl<blauwirbel(a)gmail.com> wrote: >>>> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >>>> support for virtio-block and interrupt nodes. >>> >>> Hey, that was fast! Does it mean your patches also allow booting from >>> a virtio device? >> >> No, only a warning for the unknown device is avoided and Linux can use >> the interrupts. >> >> Making a simple driver does not look very difficult, here are some examples: >> http://fxr.watson.org/fxr/source/dev/virtio/block/virtio_blk.c >> http://fxr.watson.org/fxr/source/drivers/block/virtio_blk.c?v=linux-2.6 >> http://git.qemu.org/?p=seabios.git;a=blob;f=src/virtio-blk.c;h=194deaf98b41… >> > > Fair enough. On the other hand, if we implement it too soon, there > will be less motivation in fixing the cmd646 emulation in qemu... ;-) What's the actual bug with cmd646 in QEMU? ATB, Mark.

2 1

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Artyom Tarasenko 12 May '12

12 May '12

On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal > support for virtio-block and interrupt nodes. > > With these patches and QEMU HEAD, Linux can boot like Artyom describes in > http://tyom.blogspot.de/2012_05_01_archive.html > but without any manual OpenBIOS setup. My test kernel - 3.3.2 - still needs the ebus interrupt mapping properties: cd /pci@1fe,0/ebus 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property 000001ff encode-int ffffffff encode-int encode+ 00000003 encode-int encode+ " interrupt-map-mask" property device-end boot > Blue Swirl (2): > pci: identify virtio-scsi devices > Sparc64: fix interrupt properties > > drivers/ide.c | 2 ++ > drivers/pc_serial.c | 3 +++ > drivers/pci.c | 23 +++++++++++++++++++++++ > drivers/pci_database.c | 19 ++++++++++++++++++- > drivers/pci_database.h | 1 + > include/drivers/pci.h | 3 +++ > 6 files changed, 50 insertions(+), 1 deletion(-) > > -- > 1.7.10 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0