On Sat, Jun 09, 2012 at 09:17:34PM +0200, Wolfgang Kamp - datakamp wrote:
> When execution of VGA option ROM is configured in seabios,
> seabios first scans all PCI devices and looks for a vga type device as you can see in my attached log.
> If seabios finds a pci vga device then it looks for a suitable VGA BIOS (Vendor id:Device id / 1002:9804) in CBFS.
> But if seabios does not find a vga device, it doesn't look for the VGA BIOS. That is what happens.
> In my issue seabios can only find the pci VGA device if I first enabled VGA ROM execution in coreboot.
> If seabios finds the vga device it will also find the correct VGA BIOS in CBFS and executes it.
> The log shows this. The issue is that the pci enumertion fails in seabios and it does not list all available devices.
> Why is it broken? It could be a coreboot or seabios problem.
Looks like a coreboot issue to me. The PCI device does not appear to
be present when SeaBIOS doesn't find it. As Ron indicated in another
email, it looks like coreboot needs an option to enable the vga but
not run the rom for your board.
Early versions of coreboot did not create an SMBIOS table (which Linux
needs in order to use the ACPI tables), so SeaBIOS had a hack to
generate an SMBIOS table. However, recent versions of coreboot can
generate an SMBIOS table, so there is no longer a reason to support
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
src/Kconfig | 4 +---
src/coreboot.c | 4 ----
2 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index 53fda9b..25b2b1b 100644
@@ -303,14 +303,13 @@ menu "BIOS interfaces"
menu "BIOS Tables"
+ depends on !COREBOOT
- depends on !COREBOOT
bool "PIR table"
Support generation of a PIR table in 0xf000 segment.
- depends on !COREBOOT
@@ -322,7 +321,6 @@ menu "BIOS Tables"
Support generation of SM BIOS tables. This is also
sometimes called DMI.
- depends on !COREBOOT
diff --git a/src/coreboot.c b/src/coreboot.c
index 9de99af..55590ce 100644
@@ -218,10 +218,6 @@ coreboot_copy_biostable(void)
if (m->type == CB_MEM_TABLE)
- // XXX - create a dummy smbios table for now.
- if (!SMBiosAddr)
On Thu, Jun 07, 2012 at 01:58:06PM -0600, Steve Goodrich wrote:
> This change adds support for multiple USB mass storage devices in the boot
> sequence. Previously, only one HDD device (which included both USB and SATA
> drives) was allowed in the boot sequence; USB drives were treated as HDDs.
> This code allows USB drives to be treated separately from SATA drives. Only
> one HDD is allowed to boot (0x80) as has always been the case. However,
> multiple USB drives can be tried in the order they are selected in the
I don't understand how this works. The problem with HD booting from
anything other than 0x80 is that boot loaders don't know which hard
drive to boot from, so they always try drive 0x80. Since USB images
use the same boot loaders as hard drives, I don't see how your patch
> @@ -655,11 +674,15 @@ do_boot(int seq_nr)
> case IPL_TYPE_HARDDISK:
> printf("Booting from Hard Disk...\n");
> - boot_disk(0x80, 1);
> + boot_disk(EXTSTART_HD, 1);
> case IPL_TYPE_CDROM:
In the above, CDROMs can boot from any drive because the CD booting
spec (El-Torito) clearly states the boot loader must use the drive
specified in the dl register.
> + case IPL_TYPE_USB:
> + printf("Booting from USB drive...\n");
> + boot_disk(EXTSTART_USB + USB_Drive_Number++, 1);
> + break;
This will set the 'dl' register to something (eg, 0xc0), but we can't
be sure the boot loader will honor it. So, as far as I understand,
this wont work. What images did you test with?
On Tue, Jun 05, 2012 at 10:58:43AM +0200, Fred . wrote:
> On Tue, Jun 5, 2012 at 5:21 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Mon, Jun 04, 2012 at 07:11:30PM -0700, Ralf A. Quint wrote:
> >> At 03:36 PM 6/4/2012, Kevin O'Connor wrote:
> >> >On Mon, Jun 04, 2012 at 03:33:05PM +0200, Fred . wrote:
> >> >> http://mjg59.dreamwidth.org/8035.html
> >> >>
> >> >> Does SeaBIOS support GPT disk labels?
> >> >> Does SeaBIOS understand GPT disk labels? Is it aware of GPT?
> >> >
> >> >This is a common misunderstanding of the BIOS. The BIOS doesn't do
> >> >anything with partition tables at all (at least according to the
> >> >available specs). Thus, the BIOS doesn't care if it's a legacy
> >> >partition table or a GPT partition table.
> >> Excuse me, but isn't it the BIOS that after POST is initiating the
> >> boot process from the active partition?
> > Not quite. The BIOS loads the first sector of the hard drive (ie, the
> > MBR) into memory and runs the code found there. It cares nothing
> > about the partition table. It's quite common for the executable code
> > in that first sector to analyze the partition table, load yet other
> > code, and then jump to that code - but that activity is outside the
> > BIOS and is easily upgradable.
> But does GPT disks even have a MBR?
> Isn't the GPT a replacement for MBR?
> If the disk doesn't have any MBR, does the BIOS load the first sector of GPT?
I'm not sure how I could be more clear on this. SeaBIOS cares nothing
about the partition table. No BIOS spec (that I'm aware of) requires
the BIOS to care anything about the partition table. The BIOS loads
the first sector of the hard drive into memory and executes the code
found there. GPT partitioned disks do arrange to be able to place
boot code in the first sector of the hard drive.
The only fundamental limit SeaBIOS has on drive size is a 64bit sector
count - this allows for up to 134 million terabytes of disk space
(assuming a 512 byte sector). But, even this isn't really a limit -
one just needs to be able to locate their bootloader in the first