OpenBIOS May 2012

openbios@openbios.org

10 participants
42 discussions

[commit] r1058 - in trunk/openbios-devel: drivers include/drivers
by repository service 19 May '12

19 May '12

Author: blueswirl Date: Sat May 19 12:38:24 2012 New Revision: 1058 URL: http://tracker.coreboot.org/trac/openbios/changeset/1058 Log: pci: identify virtio-scsi devices Identify virtio SCSI device in PCI probe. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/drivers/pci_database.c trunk/openbios-devel/include/drivers/pci.h Modified: trunk/openbios-devel/drivers/pci_database.c ============================================================================== --- trunk/openbios-devel/drivers/pci_database.c Sat May 12 13:43:57 2012 (r1057) +++ trunk/openbios-devel/drivers/pci_database.c Sat May 19 12:38:24 2012 (r1058) @@ -45,6 +45,23 @@ }, }; +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_subclass_t mass_subclass[] = { { PCI_SUBCLASS_STORAGE_SCSI, "SCSI bus controller", - NULL, NULL, NULL, + "scsi", scsi_devices, NULL, NULL, NULL, }, { Modified: trunk/openbios-devel/include/drivers/pci.h ============================================================================== --- trunk/openbios-devel/include/drivers/pci.h Sat May 12 13:43:57 2012 (r1057) +++ trunk/openbios-devel/include/drivers/pci.h Sat May 19 12:38:24 2012 (r1058) @@ -205,6 +205,9 @@ #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 0

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

18 May '12

On 2012-May-13 03:08 , Artyom Tarasenko wrote: > Yes, this is how it's wired in qemu too. But I meant the OBP level. > What worries me is that this construction seems to be never used in > sun4u OBP: > > $ grep interrupts linux/kernel/git/davem/prtconfs/* | grep -c 00000001 > 402 > $ grep interrupts linux/kernel/git/davem/prtconfs/* | grep -c 00000000 > 2 > > And the both hits are sun4v: > > $ grep interrupts ~/openbios/linux/kernel/git/davem/prtconfs/* | grep 00000000 > linux/kernel/git/davem/prtconfs/t1000: interrupts: 00000000 > linux/kernel/git/davem/prtconfs/t2000_1: interrupts: 00000000 > > Can it be, that 0 is (or used to be) some magic constant? I'll check on monday and get back to you.

2 1

Adding to a definition
by Programmingkid 17 May '12

17 May '12

Is there a way to add words to the end of a definition? If my word is declared like this: : myword firstWord secondWord ; is there a way to append a word to the end of this word so it looks like this: : myword firstWord secondWord thirdWord ;

4 6

Re: [OpenBIOS] fdthree
by Blue Swirl 15 May '12

15 May '12

On Tue, May 15, 2012 at 4:44 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Mon, May 14, 2012 at 10:22 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Mon, May 14, 2012 at 4:26 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >>> Since none of the current Linux/sparc64 distributions has virtio >>> drivers out of the box, it were nice to give the user ability to load >>> them from a removable media. >>> Currently Linux doesn't recognize our fdthree drive. The reason is >>> simple - in OpenBIOS >>> >>> 0 > cd /pci/ebus/fdthree ok >>> 0 > .properties >>> name "fdthree" >>> reg 00000000 00000000 00000000 >>> >>> in ultra5's prtconf this property looks like this: >>> >>> reg: 00000014.003023f0.00000008.00000014.00706000.00000010.00000014.00720000.00000004 >>> >>> The meaning of the first triple is clear - these are the fdc control >>> registers. But what are the two other register sets? >>> >>> It looks like qemu has a normal PC floppy, connected to EBus. Probably >>> it's not what Sun used to call fdthree? >>> If fdthree is really something else, were there any UltraSPARC >>> machines with PC floppy drives? >> >> I think the FDC was pretty standard 82077. The additional registers >> could implement a DMA controller. > > It seems that in qemu the DMA controller sits on ISA, not on fdc? And > that we don't have it in EBus? > But I guess dma.c could be used directly as-is? I'd expect the DMA controller (if the registers are DMA) to be more like other Sparc DMA controllers, not 8237. > >> At least OpenBSD only seems to use >> the 82077 registers: >> http://fxr.watson.org/fxr/source/arch/sparc64/dev/fd.c?v=OPENBSD >> > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] fdthree
by Artyom Tarasenko 15 May '12

15 May '12

On Mon, May 14, 2012 at 10:22 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Mon, May 14, 2012 at 4:26 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> Since none of the current Linux/sparc64 distributions has virtio >> drivers out of the box, it were nice to give the user ability to load >> them from a removable media. >> Currently Linux doesn't recognize our fdthree drive. The reason is >> simple - in OpenBIOS >> >> 0 > cd /pci/ebus/fdthree ok >> 0 > .properties >> name "fdthree" >> reg 00000000 00000000 00000000 >> >> in ultra5's prtconf this property looks like this: >> >> reg: 00000014.003023f0.00000008.00000014.00706000.00000010.00000014.00720000.00000004 >> >> The meaning of the first triple is clear - these are the fdc control >> registers. But what are the two other register sets? >> >> It looks like qemu has a normal PC floppy, connected to EBus. Probably >> it's not what Sun used to call fdthree? >> If fdthree is really something else, were there any UltraSPARC >> machines with PC floppy drives? > > I think the FDC was pretty standard 82077. The additional registers > could implement a DMA controller. It seems that in qemu the DMA controller sits on ISA, not on fdc? And that we don't have it in EBus? But I guess dma.c could be used directly as-is? > At least OpenBSD only seems to use > the 82077 registers: > http://fxr.watson.org/fxr/source/arch/sparc64/dev/fd.c?v=OPENBSD > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Solaris 8 on Sparc32 - Broken by 1056 changes
by P. Wilhelm 15 May '12

15 May '12

This past 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. I am booting from a virtual hard disk upon which I had previously installed Solaris 8 using Qemu (installed from Solaris 8 install CDs). Let me know if you need any specific information about Qemu arguments. Respectfully, Paul

1 0

Re: [OpenBIOS] fdthree
by Blue Swirl 14 May '12

14 May '12

On Mon, May 14, 2012 at 4:26 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > Since none of the current Linux/sparc64 distributions has virtio > drivers out of the box, it were nice to give the user ability to load > them from a removable media. > Currently Linux doesn't recognize our fdthree drive. The reason is > simple - in OpenBIOS > > 0 > cd /pci/ebus/fdthree ok > 0 > .properties > name "fdthree" > reg 00000000 00000000 00000000 > > in ultra5's prtconf this property looks like this: > > reg: 00000014.003023f0.00000008.00000014.00706000.00000010.00000014.00720000.00000004 > > The meaning of the first triple is clear - these are the fdc control > registers. But what are the two other register sets? > > It looks like qemu has a normal PC floppy, connected to EBus. Probably > it's not what Sun used to call fdthree? > If fdthree is really something else, were there any UltraSPARC > machines with PC floppy drives? I think the FDC was pretty standard 82077. The additional registers could implement a DMA controller. At least OpenBSD only seems to use the 82077 registers: http://fxr.watson.org/fxr/source/arch/sparc64/dev/fd.c?v=OPENBSD > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Mark Cave-Ayland 14 May '12

14 May '12

On 14/05/12 14:28, Artyom Tarasenko wrote: >>> It's to avoid VGA legacy mapping at 0xa0000. If I change >>> hwdefs.pci.pci_mem_base in arch/sparc64/openbios.c to 0, OpenBIOS will >>> crash during VGA init. Previously this worked because the PCI devices >>> were mapped somewhat randomly and by chance, VGA legacy low mem area >>> was avoided. >>> >>> I think the correct fix is to make QEMU VGA device disable the legacy >>> mapping unless explicitly enabled. Alternatively the child base >>> arithmetic could be fixed in OpenBIOS like proposed by Jakub. >> >> >> Did a patch ever come out of this discussion in the end? >> > > No. :-) Feel free to fix it, unless Blue prefers fixing it himself... I'm not sure I'm confident enough with PCI to do this, and I'm also not sure what Blue's recommended fix actually is? Is it to increase parent_base by 0x1000 or set child_base to zero? ATB, Mark.

2 1

fdthree
by Artyom Tarasenko 14 May '12

14 May '12

Since none of the current Linux/sparc64 distributions has virtio drivers out of the box, it were nice to give the user ability to load them from a removable media. Currently Linux doesn't recognize our fdthree drive. The reason is simple - in OpenBIOS 0 > cd /pci/ebus/fdthree ok 0 > .properties name "fdthree" reg 00000000 00000000 00000000 in ultra5's prtconf this property looks like this: reg: 00000014.003023f0.00000008.00000014.00706000.00000010.00000014.00720000.00000004 The meaning of the first triple is clear - these are the fdc control registers. But what are the two other register sets? It looks like qemu has a normal PC floppy, connected to EBus. Probably it's not what Sun used to call fdthree? If fdthree is really something else, were there any UltraSPARC machines with PC floppy drives? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Mark Cave-Ayland 14 May '12

14 May '12

On 12/05/12 10:11, Blue Swirl wrote: >> Agreed. On current SPARC, the only non-zero Range on PCI is for 64-bit >> memory. For the memory ranges we see: >> >> 0200.0000 0000.0000 0000.0000 8000.8090 0000.0000 0000.0007 0000.0000 >> 0300.0000 0000.0001 0000.0000 8000.8091 0000.0000 0000.0007 0000.0000 >> >> My recollection is that memory space PCI RA (real address rather than >> physical address, because now we're behind a hypervisor) ranges from >> 8000.8090.0000.0000 through 8000.8097.FFFF.FFFF - which would match your >> guess that the parent_base needs to be hacked if 0800.0000 is going to be >> the BAR and is going to represent 1ff.0800.0000. >> >> So, why does OpenBios have 0100.0000 as a child base in the first place? > > It's to avoid VGA legacy mapping at 0xa0000. If I change > hwdefs.pci.pci_mem_base in arch/sparc64/openbios.c to 0, OpenBIOS will > crash during VGA init. Previously this worked because the PCI devices > were mapped somewhat randomly and by chance, VGA legacy low mem area > was avoided. > > I think the correct fix is to make QEMU VGA device disable the legacy > mapping unless explicitly enabled. Alternatively the child base > arithmetic could be fixed in OpenBIOS like proposed by Jakub. Did a patch ever come out of this discussion in the end? ATB, Mark.

2 1