SeaBIOS June 2011

seabios@seabios.org

22 participants
40 discussions

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

14 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/… [View More]

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)… [View More]

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, … [View More]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 [View Less]

12 43

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

05 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. ]>> … [View More]

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 … [View More]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 [View Less]

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 … [View More]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 [View Less]

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 … [View More]

2 2

Issues with ASRock E350M1
by Marshall Buschman 03 Jun '11

03 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 … [View More]

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 … [View More]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 [View Less]

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 … [View More]

6 19

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2011