SeaBIOS June 2011

seabios@seabios.org

22 participants
40 discussions

[PATCH] Correct fseg allocation for SMBIOS tables.
by Ian Campbell 15 Jun '11

15 Jun '11

Anthony Perard noticed that grub was unhappy because it sees no low memory and that his e820 table was missing the first entry. He then pointed out this rather glaring error in the allocation of space for the SMBIOS tables. I've no idea why I didn't see this failure. Signed-off-by: Ian Campbell <ian.campbell(a)citrix.com> Tested-by: Anthony Perard <anthony.perard(a)citrix.com> --- src/biostables.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/biostables.c b/src/biostables.c index 761b260..d8b5067 100644 --- a/src/biostables.c +++ b/src/biostables.c @@ -95,7 +95,7 @@ copy_smbios(void *pos) return; if (checksum(pos+0x10, p->length-0x10) != 0) return; - struct smbios_entry_point *newpos = malloc_fseg(sizeof(p->length)); + struct smbios_entry_point *newpos = malloc_fseg(p->length); if (!newpos) { warn_noalloc(); return; -- 1.7.2.5

2 1

[patch] Add IDE_TO_AHCI config
by Chuang, Alex 13 Jun '11

13 Jun '11

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

3 8

[RfC PATCH 0/2] pci: two pass initialization
by Gerd Hoffmann 07 Jun '11

07 Jun '11

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

12 43

Re: [SeaBIOS] Issues with ASRock E350M1
by Scott Duplichan 06 Jun '11

06 Jun '11

Marshall Buschman wrote: ]Or not! It's back. Same issue as before. ] ]Quoting mbuschman(a)lucidmachines.com: ] ]> 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. Hello Marshall, An SSD drive I bought for boot time testing also has the SandForce sf-1200 controller: http://www.mushkin.com/Digital-Storage/SSDs/MKNSSDCL40GB-DX.aspx I have not noticed any detection problem with it. Let me know if there is any experiment I could do with it. Thanks, Scott

2 2

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

04 Jun '11

Or not! It's back. Same issue as before. Quoting mbuschman(a)lucidmachines.com: > 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 > > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2011