SeaBIOS May 2011

seabios@seabios.org

41 participants
31 discussions

Re: [SeaBIOS] [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel

by Kevin O'Connor

On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote: > > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > >> Should a kernel fail during boot, I'd suspect it doesn't like one of > >> the apm/pcibios callbacks, or it doesn't like one of the > >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code > >> (see http://seabios.org/Download ) and increasing the debugging by > >> modifying src/config.h. Specifically, you could increase > >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to > >> 1. Also, you could try disabling some of the features to see if that > >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / > >> CONFIG_MPTABLE). > > > > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the > image boots up fine. Gleb, have you seen this thread? Some of the recent changes to smbios that look like possible culprits are: Make SMBIOS table pass MS SVVP test Use MaxCountCPUs during building of per cpu tables. Add malloc_high/fseg() and rework bios table creation to use them. There were other changes, but the comments indicate they were only ports of changes already in bochs. I suppose it's also possible the lack of smbios is turning off some other feature in the guest (eg, acpi) that's the real culprit. -Kevin

10 years

[PATCH] support piix PAM registers in KVM

by Gleb Natapov

Without this BIOS fails to remap 0xf0000 memory from ROM to RAM so writes to F-segment modify ROM content instead of memory copy. Since QEMU does not reloads ROMs during reset on next boot modified copy of BIOS is used. Signed-off-by: Gleb Natapov <gleb(a)redhat.com> diff --git a/hw/piix_pci.c b/hw/piix_pci.c index 933ad86..0bf435d 100644 --- a/hw/piix_pci.c +++ b/hw/piix_pci.c @@ -99,10 +99,6 @@ static void i440fx_update_memory_mappings(PCII440FXState *d) int i, r; uint32_t smram, addr; - if (kvm_enabled()) { - /* FIXME: Support remappings and protection changes. */ - return; - } update_pam(d, 0xf0000, 0x100000, (d->dev.config[I440FX_PAM] >> 4) & 3); for(i = 0; i < 12; i++) { r = (d->dev.config[(i >> 1) + (I440FX_PAM + 1)] >> ((i & 1) * 4)) & 3; -- Gleb.

10 years, 1 month

[patch] Add IDE_TO_AHCI config

by Chuang, Alex

Hi, I add one config 'IDE_TO_AHCI' in 'src\Kconfig' and modify 'src\ata.c'. Please help me to review and check-in. This 'IDE_TO_AHCI' function can let SeaBIOS handle AHCI controller as IDE controller when 'ATA' enable, and also let Windows OS to load AHCI inbox driver or chipset vender's AHCI driver. In other words, it means that SATA Hard Disk ran as IDE mode in SeaBIOS but AHCI mode in Windows OS. Attached file: A.patch B.patch. Signed-off-by: Alex Chuang <Alex.Chuang(a)amd.com> Best regards, Alex

10 years, 1 month

[RfC PATCH 0/2] pci: two pass initialization

by Gerd Hoffmann

Hi, This patch set switches seabios to a two-pass pci initialization. The first pass figures the memory requirements which are then used by the second pass to pack the regions. I've splitted it into two patches to make it easy to check out. The first patch does all the calculations and prints what it would do to the debug log. The second patch switches the new allocation code live. The patches have been tested with the upcoming q35 emulation for qemu. They are based on the q35 seabios too, but rebasing to master shouldn't be hard. Below you can see the allocations created by the patch. Comments? cheers, Gerd ========== /proc/iomem ============== 00000000-00000fff : reserved 00001000-0009e7ff : System RAM 0009e800-0009ffff : reserved 000c0000-000c8bff : Video ROM 000c9000-000c97ff : Adapter ROM 000f0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-3fffcfff : System RAM 01000000-014e5a17 : Kernel code 014e5a18-01ba42ef : Kernel data 01ce4000-01f474e3 : Kernel bss 3fffd000-3fffffff : reserved e0000000-efffffff : PCI MMCONFIG 0 [00-ff] e0000000-efffffff : reserved fa000000-fbffffff : 0000:00:02.0 fa000000-fbffffff : cirrusfb fc000000-fc3fffff : PCI Bus 0000:0c fc000000-fc0fffff : PCI Bus 0000:0d fc100000-fc1fffff : PCI Bus 0000:0e fc200000-fc2fffff : PCI Bus 0000:0f fc300000-fc3fffff : PCI Bus 0000:10 fc400000-fc4fffff : PCI Bus 0000:01 fc500000-fc5fffff : PCI Bus 0000:02 fc600000-fc6fffff : PCI Bus 0000:03 fc600000-fc6fffff : PCI Bus 0000:04 fc600000-fc6fffff : PCI Bus 0000:05 fc700000-fc7fffff : PCI Bus 0000:06 fc800000-fc8fffff : PCI Bus 0000:07 fc900000-fc9fffff : PCI Bus 0000:08 fca00000-fcafffff : PCI Bus 0000:09 fcb00000-fcbfffff : PCI Bus 0000:0a fcc00000-fccfffff : PCI Bus 0000:0b fdc00000-fdffffff : PCI Bus 0000:0c fdc00000-fdcfffff : PCI Bus 0000:0d fdd00000-fddfffff : PCI Bus 0000:0e fde00000-fdefffff : PCI Bus 0000:0f fdf00000-fdffffff : PCI Bus 0000:10 fe000000-fe0fffff : PCI Bus 0000:01 fe100000-fe1fffff : PCI Bus 0000:02 fe200000-fe2fffff : PCI Bus 0000:03 fe200000-fe2fffff : PCI Bus 0000:04 fe200000-fe2fffff : PCI Bus 0000:05 fe300000-fe3fffff : PCI Bus 0000:06 fe400000-fe4fffff : PCI Bus 0000:07 fe500000-fe5fffff : PCI Bus 0000:08 fe600000-fe6fffff : PCI Bus 0000:09 fe700000-fe7fffff : PCI Bus 0000:0a fe800000-fe8fffff : PCI Bus 0000:0b fe900000-fe90ffff : 0000:00:02.0 fe910000-fe91ffff : 0000:00:03.0 fe920000-fe920fff : 0000:00:02.0 fe920000-fe920fff : cirrusfb fe921000-fe921fff : 0000:00:03.0 fe921000-fe921fff : virtio-pci fe922000-fe922fff : 0000:00:1f.2 fe922000-fe922fff : ahci fec00000-fec00fff : IOAPIC 0 fed00000-fed003ff : HPET 0 fee00000-fee00fff : Local APIC feffc000-feffffff : reserved fffc0000-ffffffff : reserved

10 years, 1 month

Issues with ASRock E350M1

by Marshall Buschman

Hello: I was instructed to send mail to you by Carebear from #coreboot. I have some issues to report based on the "Golden Image" I received from him, which was created for the ASRock E350M1. The first is with hard drive detection - there is a reliability problem here - only once out of every 5 to 12 times the machine posts will it detect the hard drive successfully. The hard drive is a Corsair F120 SSD. I do have another, smaller 16GB Kingston SSD I can test with. The second problem is that on booting, GRUB (I do not have the version on hand -- whatever gentoo is shipping as stable at this point) behaves very, very strangely with my USB keyboard. I should point out that it does not work 100% correctly on another machine under Fedora's grub, so this may bear further testing with another keyboard. The following video demonstrates the issue - this is very reproduceable (I gave exactly this input on the keyboard: "<down>, e, hello there, test, one, two, three", and only once. You can hear the clicking of my keyboard.) http://www.lucidmachines.com/coreboot/weird-usb-in-grub.avi I will be traveling until May 31st, and so unable to reply to mail until then, but I do look forward to working with you all on this. Thank you! -Marshall Buschman

10 years, 1 month

[RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM

by Ian Campbell

As you may know we (the Xen project) are hoping to transition to SeaBIOS at the same time as we transition to the recently upstreamed qemu support for Xen. The following patches add very basic support for running SeaBIOS as the BIOS for a Xen HVM (fully virtualised) guest. These patches really do very little but they are sufficient to allow me to boot an HVM Linux guest to a prompt. SeaBIOS boots indirectly as an hvmloader payload with the first patch and directly if using the second (this second case requires a short patch series on the Xen side, see [0]). This is presented more as a proof of concept since it's not obvious yet which approach will be best from either Xen or SeaBIOS's point of view. I'm generally leaning towards the second option since much of the setup currently done in hvmloader appears to be more down to the limitations of ROMBIOS than any particular design decision. For example SeaBIOS is perfectly happy loading option ROMS from the appropriate BAR so that aspect of hvmloader goes away entirely, similarly with building ACPI, SMBIOS, MP tables etc. I'd be glad to hear any opinions from either side on the matter. One problem I have with the first patch is that I'm lacking the vocabulary to describe the configuration which is currently represented by COREBOOT=n. I wanted to switch the coreboot option to a Kconfig choice (so I can add XEN as another option) so I needed a name for the other option. I went with GENERIC but I've no idea if that is accurate. Is "EMULATOR" more accurate? Suggestions welcome. FWIW I expect (however naive it might be to make such predictions) the majority of the work to integrate SeaBIOS into Xen (other than test, test and more test with different OSes) will be to understand he differences in the various BIOS tables and figure out what is "just because", what represents real bug fixes on one side or the other, what is actually down to implementation details in Xen and what is down to differences between the old qemu-xen and upstream qemu. Having worked through all that I hope that actually finding a clean way to integrate the differences with SeaBIOS (or possibly qemu) will be comparatively trivial... Ian. [0] http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00770.html

10 years, 1 month

Re: [SeaBIOS] [coreboot] Keyboard not working on Thinkpad X60/T60

by Sven Schnelle

Sven Schnelle <svens(a)stackframe.org> writes: > Hi Setfan, > > Stefan Reinauer <stefan.reinauer(a)coreboot.org> writes: > >> * Sven Schnelle <svens(a)stackframe.org> [110503 21:41]: >>> Stefan Reinauer <stefan.reinauer(a)coreboot.org> writes: >>> > Can you do a new analysis on where the boot time goes now? It would be >>> > nice to see if there are more optimizations we can do... >>> >>> Will do. But right now i have the problem that the Keyboard isn't >>> working on cold boot - seabios is probably started so early that some >>> hardware parts are not finished with reset or similar things. >>> >>> Just enabling debug output in coreboot slows down things enough to >>> make the Keyboard working again. >> >> Does just putting in a delay of some 100ms fix the issue, too? Do you do >> keyboard init in coreboot? Did you do it before? >> Just want to make sure there are no side effects coming in through >> debugging. However, having an EC/SuperIO that needs more than 200ms to boot up >> does not sound too unlikely. > > I do not initialize the Keyboard in coreboot, i'll leave that to > seabios. (Enabling it in coreboot doesn't help either). > >>> The original Vendor BIOS talks after around ~1s to the Keyboard >>> controller, so that's quite different to coreboot (coreboot is handing >>> over to seabios after ~200ms) >> >> Getting through all of coreboot in as little as 200ms? This is totally >> awesome! >> >>> So i want to figure out first if there's some >>> 'i-finished-reset-you-can-talk-to-me' flag, or if that problem is caused >>> by another reason. >> >> Does the keyboard init code get any type of timeout? > > > Well, i've enabled some debugging in seabios, and it's pretty obvious > what's happening here. SeaBIOS sends command 0xff (which is RESET i > think), and SeabIOS gets 0xfe as response (which is RESEND, but seabios > handles that as NAK, and doesn't resend the command). > > You can find the boot log here: > > http://stackframe.org/seriallog-20110503_175245.log I've just modified seabios to resend commands when 0xfe is received as a quick hack. It makes my keyboard working again. I'm not sure if SeabIOS should handle 0xfe as RESEND or not - have not monitored much Keyboards, and don't know wether this has any side effects. The boot log can be found here: http://stackframe.org/seriallog-20110504_100837.log The diff i've made to seabios is: (beware, it's just an ugly hack just for testing) diff --git a/src/ps2port.c b/src/ps2port.c index d1e6d48..a4cd4de 100644 --- a/src/ps2port.c +++ b/src/ps2port.c @@ -186,7 +186,8 @@ ps2_recvbyte(int aux, int needack, int timeout) static int ps2_sendbyte(int aux, u8 command, int timeout) { - dprintf(7, "ps2_sendbyte aux=%d cmd=%x\n", aux, command); +resend: + dprintf(7, "ps2_sendbyte aux=%d cmd=%x\n", aux, command); int ret; if (aux) ret = i8042_aux_write(command); @@ -199,6 +200,8 @@ ps2_sendbyte(int aux, u8 command, int timeout) ret = ps2_recvbyte(aux, 1, timeout); if (ret < 0) return ret; + if (ret == 0xfe) + goto resend; if (ret != PS2_RET_ACK) return -1; @@ -232,7 +235,7 @@ __ps2_command(int aux, int command, u8 *param) ret = i8042_command(I8042_CMD_CTL_WCTR, &newctr); if (ret) goto fail; - +resend: if (command == ATKBD_CMD_RESET_BAT) { // Reset is special wrt timeouts and bytes received. @@ -243,10 +246,14 @@ __ps2_command(int aux, int command, u8 *param) // Receive parameters. ret = ps2_recvbyte(aux, 0, 4000); + if (ret == 0xfe) + goto resend; if (ret < 0) goto fail; param[0] = ret; ret = ps2_recvbyte(aux, 0, 100); + if (ret == 0xfe) + goto resend; if (ret < 0) // Some devices only respond with one byte on reset. ret = 0; @@ -261,6 +268,8 @@ __ps2_command(int aux, int command, u8 *param) // Receive parameters. ret = ps2_recvbyte(aux, 0, 500); + if (ret == 0xfe) + goto resend; if (ret < 0) goto fail; param[0] = ret; @@ -268,6 +277,8 @@ __ps2_command(int aux, int command, u8 *param) || ret == 0x60 || ret == 0x47) { // These ids (keyboards) return two bytes. ret = ps2_recvbyte(aux, 0, 500); + if (ret == 0xfe) + goto resend; if (ret < 0) goto fail; param[1] = ret; @@ -291,6 +302,8 @@ __ps2_command(int aux, int command, u8 *param) // Receive parameters (if any). for (i = 0; i < receive; i++) { ret = ps2_recvbyte(aux, 0, 500); + if (ret == 0xfe) + goto resend; if (ret < 0) goto fail; param[i] = ret;

10 years, 1 month

[PATCH] Support more than one vga card

by Glauber Costa

It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU. This patch makes seabios continue searching the pci range looking for vga cards, even if it finds one. The first card to be found is assigned to VGAbdf, being the main one. The others, just have their initializatiom roms called and are listed in the pci bus. Signed-off-by: Glauber Costa <glommer(a)redhat.com> --- src/optionroms.c | 11 ++++++++--- src/pci.c | 6 ++++-- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/src/optionroms.c b/src/optionroms.c index 37a4e6c..2d0a258 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -462,13 +462,18 @@ vga_setup(void) // Option roms are already deployed on the system. init_optionrom((void*)BUILD_ROM_START, 0, 1); } else { + int bdf; // Clear option rom memory memset((void*)RomEnd, 0, _max_rom() - RomEnd); // Find and deploy PCI VGA rom. - int bdf = VGAbdf = pci_find_vga(); - if (bdf >= 0) - init_pcirom(bdf, 1, NULL); + do { + bdf = pci_find_vga(); + if (!VGAbdf) + VGAbdf = bdf; + if (bdf >= 0) + init_pcirom(bdf, 1, NULL); + } while ((bdf >= 0)) // Find and deploy CBFS vga-style roms not associated with a device. run_file_roms("vgaroms/", 1, NULL); diff --git a/src/pci.c b/src/pci.c index 944a393..6f124cf 100644 --- a/src/pci.c +++ b/src/pci.c @@ -107,7 +107,9 @@ pci_next(int bdf, int *pmax) int pci_find_vga(void) { - int bdf = 0x0000, max = 0x0100; + static int bdf; + int max = 0x0100; + for (;;) { if (bdf >= max) { if (CONFIG_PCI_ROOT1 && bdf <= (CONFIG_PCI_ROOT1 << 8)) @@ -132,7 +134,7 @@ pci_find_vga(void) u16 cmd = pci_config_readw(bdf, PCI_COMMAND); if (cmd & PCI_COMMAND_IO && cmd & PCI_COMMAND_MEMORY) // Found active vga card - return bdf; + return bdf++; } // Check if device is a bridge. -- 1.7.4.2

10 years, 1 month

[coreboot] Add IDE_TO_AHCI config

by Chuang, Alex

Hi, I add one config 'IDE_TO_AHCI' in 'seabios\src\Kconfig' and modify 'seabios\src\ata.c'. Please help me to review and check-in. This 'IDE_TO_AHCI' function can let SeaBIOS handle AHCI controller as IDE controller when 'ATA' enable, and also let Windows OS to load AHCI inbox driver or chipset vender's AHCI driver. In other words, it means that SATA Hard Disk ran as IDE mode in SeaBIOS but AHCI mode in Windows OS. Best regards, Alex In 'seabios\src\Kconfig': menu "Hardware support" config ATA depends on DRIVES bool "ATA controllers" default y help Support for IDE disk code. config ATA_DMA depends on ATA bool "ATA DMA" default n help Detect and try to use ATA bus mastering DMA controllers. config ATA_PIO32 depends on ATA bool "ATA 32bit PIO" default n help Use 32bit PIO accesses on ATA (minor optimization on PCI transfers). config IDE_TO_AHCI <- New add. depends on ATA <- New add. bool "IDE to AHCI support" <- New add. default n <- New add. help <- New add. Handle AHCI controller as ATA controller when POST. <- New add. config AHCI depends on DRIVES bool "AHCI controllers" default n help Support for AHCI disk code. In 'seabios\src\ata.c': static void ata_init(void) { // Scan PCI bus for ATA adapters int count=0, pcicount=0; int bdf, max; foreachpci(bdf, max) { pcicount++; if (pci_config_readw(bdf, PCI_CLASS_DEVICE) != PCI_CLASS_STORAGE_IDE) if ((! CONFIG_IDE_TO_AHCI) || (pci_config_readw(bdf, PCI_CLASS_DEVICE) != 0x0106)) <- New add. continue; u8 pciirq = pci_config_readb(bdf, PCI_INTERRUPT_LINE); u8 prog_if = pci_config_readb(bdf, PCI_CLASS_PROG); if (CONFIG_IDE_TO_AHCI && (pci_config_readw(bdf, PCI_CLASS_DEVICE) == 0x0106)) <- New add. prog_if = 0x8F; <- New add. int master = 0;

10 years, 1 month

[PATCH] Consider a VGA to be active if it responds to either IO or memory access

by Ian Campbell

Under Xen the VGA card ends up configured for memory access only. Signed-off-by: Ian Campbell <ian.campbell(a)citrix.com> --- src/pci.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/pci.c b/src/pci.c index 944a393..471733c 100644 --- a/src/pci.c +++ b/src/pci.c @@ -130,7 +130,7 @@ pci_find_vga(void) } if (cls == PCI_CLASS_DISPLAY_VGA) { u16 cmd = pci_config_readw(bdf, PCI_COMMAND); - if (cmd & PCI_COMMAND_IO && cmd & PCI_COMMAND_MEMORY) + if (cmd & PCI_COMMAND_IO || cmd & PCI_COMMAND_MEMORY) // Found active vga card return bdf; } -- 1.7.2.5

10 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS May 2011