SeaBIOS

seabios@seabios.org

3 participants
3799 discussions

Re: [SeaBIOS] Issues with ASRock E350M1
by mbuschman＠lucidmachines.com 04 Jun '11

04 Jun '11

Mystery solved - the drive's shipping firmware was causing this behavior - an upgrade to the latest firmware (2.0) resolves this. Thanks! -Marshall Buschman Quoting mbuschman(a)lucidmachines.com: > I should mention that a 16gb Kingston SSD I have works just fine, as > well as a 500gb traditional hard disk. > Looks like this might be a problem with the disk itself. I know the > Sandforce controllers do all kinds of "smart" things like > compressing data to achieve greater throughput. I'll investigate and > see what I can find. > > Quoting Kevin O'Connor <kevin(a)koconnor.net>: > >> On Fri, Jun 03, 2011 at 11:55:47PM -0500, mbuschman(a)lucidmachines.com wrote: >>> Thanks for the reply. I've spent the last week getting Coreboot >>> under my control with help from CareBear. >>> I'm running a patched Coreboot (latest, as of 6/3/11), and SeaBIOS >>> master (as of 6/3/11). >>> >>> Coreboot is presenting the drives as IDE. >>> >>> I've attached the logs of a successful and an unsuccessful boot, as >>> well as my SeaBIOS configuration - the debug level has been set to 8 >> >> The key part of the log is: >> >> bad: >> |1efd0000| powerup iobase=1420 st=7f >> |1efd0000| powerup iobase=1420 st=7f >> |1efd0000| ata_detect ata0-0: sc=ff sn=ff dh=ff >> >> good: >> |1efd0000| powerup iobase=1420 st=50 >> |1efd0000| powerup iobase=1420 st=50 >> |1efd0000| ata_detect ata0-0: sc=55 sn=aa dh=a0 >> >> The drive/controller is stating that the drive is not busy, but then >> the drive does not respond to register reads/writes. Thus SeaBIOS >> concludes that there is no drive present. Under normal circumstances, >> the drive will report busy until it is ready to respond to register >> accesses. >> >>> -- debug output from Coreboot has been disabled, as this increases >>> the overall boot time substantially. >> >> Can the failures be correlated to boot time? For example, if you >> enable/disable debugging in coreboot+seabios, can you get it to >> reliably fail or succeed? >> >> Also, what time of controller chip is this on? >> >> Another test - if you boot from another medium, does Linux detect your >> drive even when SeaBIOS doesn't? >> >> I'm not sure what can be done to handle a drive/controller that states >> it is ready but is not. I don't know how to distinguish that from a >> drive that isn't present. >> >> -Kevin > > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios

1 0

Re: [SeaBIOS] Issues with ASRock E350M1
by Kevin O'Connor 04 Jun '11

04 Jun '11

On Fri, Jun 03, 2011 at 11:55:47PM -0500, mbuschman(a)lucidmachines.com wrote: > Thanks for the reply. I've spent the last week getting Coreboot > under my control with help from CareBear. > I'm running a patched Coreboot (latest, as of 6/3/11), and SeaBIOS > master (as of 6/3/11). > > Coreboot is presenting the drives as IDE. > > I've attached the logs of a successful and an unsuccessful boot, as > well as my SeaBIOS configuration - the debug level has been set to 8 The key part of the log is: bad: |1efd0000| powerup iobase=1420 st=7f |1efd0000| powerup iobase=1420 st=7f |1efd0000| ata_detect ata0-0: sc=ff sn=ff dh=ff good: |1efd0000| powerup iobase=1420 st=50 |1efd0000| powerup iobase=1420 st=50 |1efd0000| ata_detect ata0-0: sc=55 sn=aa dh=a0 The drive/controller is stating that the drive is not busy, but then the drive does not respond to register reads/writes. Thus SeaBIOS concludes that there is no drive present. Under normal circumstances, the drive will report busy until it is ready to respond to register accesses. > -- debug output from Coreboot has been disabled, as this increases > the overall boot time substantially. Can the failures be correlated to boot time? For example, if you enable/disable debugging in coreboot+seabios, can you get it to reliably fail or succeed? Also, what time of controller chip is this on? Another test - if you boot from another medium, does Linux detect your drive even when SeaBIOS doesn't? I'm not sure what can be done to handle a drive/controller that states it is ready but is not. I don't know how to distinguish that from a drive that isn't present. -Kevin

2 2

Issues with ASRock E350M1
by Marshall Buschman 04 Jun '11

04 Jun '11

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

4 7

[RFC PATCH 00/13] AMD IOMMU emulation patches, another try
by Eduard - Gabriel Munteanu 02 Jun '11

02 Jun '11

Hi, Again, sorry for taking so long, but I just don't send stuff without looking through it. This is meant to go into Michael's PCI branch, if it does. Some of the changes include: - some fixes (one thanks to David Gibson) and cleanups - macro magic for exporting clones of the DMA interface (e.g. pci_memory_read()); I hope it isn't too much a stretch - we use pci_memory_*() in most places where PCI devices are involved now - luckily we don't need unaligned accesses anymore - some attempt at signaling target aborts, but it doesn't seem like that stuff is completely implemented in the PCI layer / devices - PCI ids are defined in hw/amd_iommu.c until they get merged into Linux Also, I can't answer every request that the API is extended for doing this and that more comfortably. I understand there may be corner cases, but may I suggest merging it (maybe into a separate branch related to mst's pci) so that everybody can deal with it? This is still labeled RFC, but if you think it's ready it can be merged. I hope most of the important issues have been dealt with. I'll post the SeaBIOS patches soon (though I think you can give it a spin with the old ones, if you need). I'll also take care of submitting PCI ids to be merged into Linux. In any case, let me know what you think. I hope I didn't forget to Cc someone. Cheers, Eduard Eduard - Gabriel Munteanu (13): Generic DMA memory access interface pci: add IOMMU support via the generic DMA layer AMD IOMMU emulation ide: use the DMA memory access interface for PCI IDE controllers rtl8139: use the DMA memory access interface eepro100: use the DMA memory access interface ac97: use the DMA memory access interface es1370: use the DMA memory access interface e1000: use the DMA memory access interface lsi53c895a: use the DMA memory access interface pcnet: use the DMA memory access interface usb-uhci: use the DMA memory access interface usb-ohci: use the DMA memory access interface Makefile.target | 2 +- dma-helpers.c | 23 ++- dma.h | 4 +- hw/ac97.c | 6 +- hw/amd_iommu.c | 712 ++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/dma_rw.c | 155 ++++++++++++ hw/dma_rw.h | 217 ++++++++++++++++ hw/e1000.c | 27 ++- hw/eepro100.c | 95 ++++---- hw/es1370.c | 4 +- hw/ide/ahci.c | 3 +- hw/ide/internal.h | 1 + hw/ide/macio.c | 4 +- hw/ide/pci.c | 18 +- hw/lsi53c895a.c | 24 +- hw/pc.c | 2 + hw/pci.c | 7 + hw/pci.h | 9 + hw/pci_internals.h | 1 + hw/pcnet-pci.c | 5 +- hw/rtl8139.c | 98 ++++---- hw/usb-ohci.c | 46 +++-- hw/usb-uhci.c | 26 +- 23 files changed, 1324 insertions(+), 165 deletions(-) create mode 100644 hw/amd_iommu.c create mode 100644 hw/dma_rw.c create mode 100644 hw/dma_rw.h -- 1.7.3.4

4 23

[RFC] [PATCH 0/2] Basic SeaBIOS support for Xen HVM
by Ian Campbell 01 Jun '11

01 Jun '11

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

6 19

Re: [SeaBIOS] [coreboot] Keyboard not working on Thinkpad X60/T60
by Sven Schnelle 31 May '11

31 May '11

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;

5 11

[PATCH] Support more than one vga card
by Glauber Costa 28 May '11

28 May '11

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

7 22

[coreboot] Add IDE_TO_AHCI config
by Chuang, Alex 28 May '11

28 May '11

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;

2 4

[PATCH] Consider a VGA to be active if it responds to either IO or memory access
by Ian Campbell 27 May '11

27 May '11

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

5 5

Re: [SeaBIOS] non-emulated AHCI hardware
by Scott Duplichan 27 May '11

27 May '11

17 Feb 15:28 2011 Jonathan Kollasch wrote: ]I have it (mostly) working now, just have to get it polished up a bit. ] ] Jonathan Kollasch Hello Jonathan, Right now I am trying to debug the same AHCI problem. The Host To Device FIS length change also gets me past the first polling loop in ahci_command, thanks for the tip. Do you have any fixes beyond that one I should try? Thanks, Scott

5 19

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS