SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] Issue booting to Linux Live DVD image using coreboot, SeaBIOS and QEMU
by Kevin O'Connor 13 Aug '15

13 Aug '15

On Wed, Aug 12, 2015 at 10:23:00AM -0700, Dustin Brazeau wrote: > I'm attempting to use QEMU, coreboot and SeaBIOS to boot a live Fedora > image. I have built a coreboot image with SeaBIOS as the payload. I can get > QEMU to boot all the way to the SeaBIOS's boot menu, but pressing F12 > doesn't not take me to the boot menu list and then SeaBIOS continually > prints out handle_02. > > Here is my qemu command line: > qemu-system-i386 -M q35 -bios build/coreboot.rom -serial stdio -hda > images/linux_hd.img -cdrom images/Fedora-Live-Workstation-x86_64-22-3.iso > -m 512 At first glance this looks like a coreboot issue, so I would ask on the coreboot mailing list. Also, you may wish to retry without the q35 machine type as I'm not sure how well coreboot supports it. If you think it is a SeaBIOS issue, then please retry with native SeaBIOS (ie, remove the -bios part of the command line). -Kevin

2 1

Issue booting to Linux Live DVD image using coreboot, SeaBIOS and QEMU
by Dustin Brazeau 12 Aug '15

12 Aug '15

I'm attempting to use QEMU, coreboot and SeaBIOS to boot a live Fedora image. I have built a coreboot image with SeaBIOS as the payload. I can get QEMU to boot all the way to the SeaBIOS's boot menu, but pressing F12 doesn't not take me to the boot menu list and then SeaBIOS continually prints out handle_02. Here is my qemu command line: qemu-system-i386 -M q35 -bios build/coreboot.rom -serial stdio -hda images/linux_hd.img -cdrom images/Fedora-Live-Workstation-x86_64-22-3.iso -m 512 I have also tried substituting -nographic for -serial stdio, but that doesn't seem to help. I'm trying to get it to boot off the QEMU DVD drive that is linked to the Fedora Live image, but I can't get into the boot menu to select it. I have also tried adding a boot order file to my coreboot.rom using the steps listed in http://www.coreboot.org/SeaBIOS#Configuring_boot_order, but that didn't seem to change the behavior. mybootlist.txt example: /pci@i0cf8/*@1f,2/drive@2/disk@0 /pci@i0cf8/*@1f,2/drive@0/disk@0 /pci@i0cf8/*@2 coreboot.rom print: # ./build/cbfstool build/coreboot.rom print coreboot.rom: 8192 kB, bootblocksize 864, romsize 8388608, offset 0x0 alignment: 64 bytes, architecture: x86 Name Offset Type Size fallback/dsdt.aml 0x0 raw 6952 fallback/romstage 0x1b80 stage 11656 fallback/ramstage 0x4940 stage 46224 fallback/payload 0xfe40 payload 55831 config 0x1d8c0 raw 3286 revision 0x1e5c0 raw 621 bootorder 0x1e880 raw 81 (empty) 0x1e900 null 8262488 I'm sure there is something basic I'm missing, but I have no idea what it could be. Here is the console dump: # qemu-system-i386 -M q35 -bios build/coreboot.rom -serial stdio -hda images/linux_hd.img -cdrom images/Fedora-Live-Workstation-x86_64-22-3.iso -m 512 WARNING: Image format was not specified for 'images/linux_hd.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. VNC server running on `127.0.0.1:5901' coreboot-4.1-6cb3a59fd5e754c3627b79db21c5bcc284bfd721 Wed Aug 12 16:06:51 UTC 2015 romstage starting... CBMEM: IMD: root @ 1ffff000 254 entries. IMD: root @ 1fffec00 62 entries. CBFS provider active. CBFS @ 0 size 7ffc80 CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 4940 size b490 'fallback/ramstage' located at offset: 4978 size: b490 coreboot-4.1-6cb3a59fd5e754c3627b79db21c5bcc284bfd721 Wed Aug 12 16:06:51 UTC 2015 ramstage starting... Moving GDT to 1fffe9c0...ok Initializing i82801ix southbridge... Enumerating buses... Show all devs... Before device enumeration. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: 0000: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:1f.0: enabled 1 PCI: 00:1f.2: enabled 1 PCI: 00:1f.3: enabled 1 PCI: 00:1a.0: enabled 1 PCI: 00:1a.1: enabled 1 PCI: 00:1a.2: enabled 1 PCI: 00:1a.7: enabled 1 PCI: 00:1b.0: enabled 1 PCI: 00:1c.0: enabled 1 PCI: 00:1c.1: enabled 1 PCI: 00:1c.2: enabled 1 PCI: 00:1c.3: enabled 1 PCI: 00:1c.4: enabled 1 PCI: 00:1c.5: enabled 1 PCI: 00:1d.0: enabled 1 PCI: 00:1d.1: enabled 1 PCI: 00:1d.2: enabled 1 PCI: 00:1d.7: enabled 1 PCI: 00:19.0: enabled 0 PCI: 00:1f.5: enabled 0 PCI: 00:1f.6: enabled 0 Compare with tree... Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: 0000: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:1f.0: enabled 1 PCI: 00:1f.2: enabled 1 PCI: 00:1f.3: enabled 1 PCI: 00:1a.0: enabled 1 PCI: 00:1a.1: enabled 1 PCI: 00:1a.2: enabled 1 PCI: 00:1a.7: enabled 1 PCI: 00:1b.0: enabled 1 PCI: 00:1c.0: enabled 1 PCI: 00:1c.1: enabled 1 PCI: 00:1c.2: enabled 1 PCI: 00:1c.3: enabled 1 PCI: 00:1c.4: enabled 1 PCI: 00:1c.5: enabled 1 PCI: 00:1d.0: enabled 1 PCI: 00:1d.1: enabled 1 PCI: 00:1d.2: enabled 1 PCI: 00:1d.7: enabled 1 PCI: 00:19.0: enabled 0 PCI: 00:1f.5: enabled 0 PCI: 00:1f.6: enabled 0 Root Device scanning... root_dev_scan_bus for Root Device CPU_CLUSTER: 0 enabled DOMAIN: 0000 enabled CPU_CLUSTER: 0 scanning... QEMU: firmware config interface detected QEMU: max_cpus is 1 CPU: APIC: 00 enabled DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/29c0] ops PCI: 00:00.0 [8086/29c0] enabled PCI: 00:01.0 [1234/1111] ops PCI: 00:01.0 [1234/1111] enabled PCI: 00:02.0 [8086/100e] enabled PCI: Static device PCI: 00:1a.0 not found, disabling it. PCI: Static device PCI: 00:1a.1 not found, disabling it. PCI: Static device PCI: 00:1a.2 not found, disabling it. PCI: Static device PCI: 00:1a.7 not found, disabling it. PCI: Static device PCI: 00:1b.0 not found, disabling it. PCI: Static device PCI: 00:1c.0 not found, disabling it. PCI: Static device PCI: 00:1c.1 not found, disabling it. PCI: Static device PCI: 00:1c.2 not found, disabling it. PCI: Static device PCI: 00:1c.3 not found, disabling it. PCI: Static device PCI: 00:1c.4 not found, disabling it. PCI: Static device PCI: 00:1c.5 not found, disabling it. PCI: Static device PCI: 00:1d.0 not found, disabling it. PCI: Static device PCI: 00:1d.1 not found, disabling it. PCI: Static device PCI: 00:1d.2 not found, disabling it. PCI: Static device PCI: 00:1d.7 not found, disabling it. PCI: 00:1f.0 [8086/0000] bus ops PCI: 00:1f.0 [8086/2918] enabled PCI: 00:1f.2 [8086/0000] ops PCI: 00:1f.2 [8086/2922] enabled PCI: 00:1f.3 [8086/0000] bus ops PCI: 00:1f.3 [8086/2930] enabled PCI: 00:1f.0 scanning... scan_lpc_bus for PCI: 00:1f.0 scan_lpc_bus for PCI: 00:1f.0 done PCI: 00:1f.3 scanning... scan_smbus for PCI: 00:1f.3 scan_smbus for PCI: 00:1f.3 done root_dev_scan_bus for Root Device done done found VGA at PCI: 00:01.0 Setting up VGA for PCI: 00:01.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 CPU_CLUSTER: 0 read_resources bus 0 link: 0 APIC: 00 missing read_resources CPU_CLUSTER: 0 read_resources bus 0 link: 0 done QEMU: 11 files in fw_cfg QEMU: etc/boot-fail-wait [size=4] QEMU: etc/smbios/smbios-tables [size=308] QEMU: etc/smbios/smbios-anchor [size=31] QEMU: etc/e820 [size=20] QEMU: genroms/kvmvapic.bin [size=9216] QEMU: etc/system-states [size=6] QEMU: etc/acpi/tables [size=131072] QEMU: etc/table-loader [size=4096] QEMU: etc/tpm/log [size=0] QEMU: etc/acpi/rsdp [size=36] QEMU: bootorder [size=0] QEMU: e820/ram: 0x00000000 +0x20000000 QEMU: reserve ioports 0x0510-0x0511 [firmware-config] QEMU: reserve ioports 0x5658-0x5658 [vmware-port] DOMAIN: 0000 read_resources bus 0 link: 0 DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device child on link 0 CPU_CLUSTER: 0 CPU_CLUSTER: 0 child on link 0 APIC: 00 APIC: 00 DOMAIN: 0000 child on link 0 PCI: 00:00.0 DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000 DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100 DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index a DOMAIN: 0000 resource base c0000 size 1ff40000 align 0 gran 0 limit 0 flags e0004200 index b DOMAIN: 0000 resource base 510 size 2 align 0 gran 0 limit ffff flags e0000100 index c DOMAIN: 0000 resource base 5658 size 1 align 0 gran 0 limit ffff flags e0000100 index d DOMAIN: 0000 resource base 20000000 size 90000000 align 0 gran 0 limit ffffffff flags e0000200 index e DOMAIN: 0000 resource base fee00000 size 10000 align 0 gran 0 limit ffffffff flags e0000200 index 3 PCI: 00:00.0 PCI: 00:00.0 resource base b0000000 size 10000000 align 0 gran 0 limit 0 flags f0000200 index 2 PCI: 00:01.0 PCI: 00:01.0 resource base 0 size 1000000 align 24 gran 24 limit ffffffff flags 1200 index 10 PCI: 00:01.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 18 PCI: 00:01.0 resource base 0 size 10000 align 16 gran 16 limit ffffffff flags 2200 index 30 PCI: 00:02.0 PCI: 00:02.0 resource base 0 size 20000 align 17 gran 17 limit ffffffff flags 200 index 10 PCI: 00:02.0 resource base 0 size 40 align 6 gran 6 limit ffff flags 100 index 14 PCI: 00:02.0 resource base 0 size 40000 align 18 gran 18 limit ffffffff flags 2200 index 30 PCI: 00:19.0 PCI: 00:1a.0 PCI: 00:1a.1 PCI: 00:1a.2 PCI: 00:1a.7 PCI: 00:1b.0 PCI: 00:1c.0 PCI: 00:1c.1 PCI: 00:1c.2 PCI: 00:1c.3 PCI: 00:1c.4 PCI: 00:1c.5 PCI: 00:1d.0 PCI: 00:1d.1 PCI: 00:1d.2 PCI: 00:1d.7 PCI: 00:1f.0 PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000 PCI: 00:1f.0 resource base ff800000 size 800000 align 0 gran 0 limit 0 flags c0040200 index 10000100 PCI: 00:1f.0 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3 PCI: 00:1f.2 PCI: 00:1f.2 resource base 0 size 20 align 5 gran 5 limit ffff flags 100 index 20 PCI: 00:1f.2 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 24 PCI: 00:1f.3 PCI: 00:1f.3 resource base 400 size 20 align 0 gran 0 limit 41f flags f0000100 index 20 PCI: 00:1f.3 resource base 0 size 0 align 0 gran 0 limit 0 flags 0 index 10 PCI: 00:1f.5 PCI: 00:1f.6 DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff PCI: 00:02.0 14 * [0x0 - 0x3f] io PCI: 00:1f.2 20 * [0x40 - 0x5f] io DOMAIN: 0000 io: base: 60 size: 60 align: 6 gran: 0 limit: ffff done DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffff PCI: 00:01.0 10 * [0x0 - 0xffffff] prefmem PCI: 00:02.0 30 * [0x1000000 - 0x103ffff] mem PCI: 00:02.0 10 * [0x1040000 - 0x105ffff] mem PCI: 00:01.0 30 * [0x1060000 - 0x106ffff] mem PCI: 00:01.0 18 * [0x1070000 - 0x1070fff] mem PCI: 00:1f.2 24 * [0x1071000 - 0x1071fff] mem DOMAIN: 0000 mem: base: 1072000 size: 1072000 align: 24 gran: 0 limit: ffffffff done avoid_fixed_resources: DOMAIN: 0000 avoid_fixed_resources:@DOMAIN: 0000 10000000 limit 0000ffff avoid_fixed_resources:@DOMAIN: 0000 10000100 limit ffffffff constrain_resources: DOMAIN: 0000 0a base 00000000 limit 0009ffff mem (fixed) constrain_resources: DOMAIN: 0000 0b base 000c0000 limit 1fffffff mem (fixed) constrain_resources: DOMAIN: 0000 0c base 00000510 limit 00000511 io (fixed) constrain_resources: DOMAIN: 0000 0d base 00005658 limit 00005658 io (fixed) constrain_resources: DOMAIN: 0000 0e base 20000000 limit afffffff mem (fixed) constrain_resources: DOMAIN: 0000 03 base fee00000 limit fee0ffff mem (fixed) constrain_resources: PCI: 00:00.0 02 base b0000000 limit bfffffff mem (fixed) constrain_resources: PCI: 00:1f.0 03 base fec00000 limit fec00fff mem (fixed) avoid_fixed_resources:@DOMAIN: 0000 10000000 base 00005659 limit 0000ffff avoid_fixed_resources:@DOMAIN: 0000 10000100 base fd000000 limit febfffff Setting resources... DOMAIN: 0000 io: base:5659 size:60 align:6 gran:0 limit:ffff PCI: 00:02.0 14 * [0x5800 - 0x583f] io PCI: 00:1f.2 20 * [0x5840 - 0x585f] io DOMAIN: 0000 io: next_base: 5860 size: 60 align: 6 gran: 0 done DOMAIN: 0000 mem: base:fd000000 size:1072000 align:24 gran:0 limit:febfffff PCI: 00:01.0 10 * [0xfd000000 - 0xfdffffff] prefmem PCI: 00:02.0 30 * [0xfe000000 - 0xfe03ffff] mem PCI: 00:02.0 10 * [0xfe040000 - 0xfe05ffff] mem PCI: 00:01.0 30 * [0xfe060000 - 0xfe06ffff] mem PCI: 00:01.0 18 * [0xfe070000 - 0xfe070fff] mem PCI: 00:1f.2 24 * [0xfe071000 - 0xfe071fff] mem DOMAIN: 0000 mem: next_base: fe072000 size: 1072000 align: 24 gran: 0 done Root Device assign_resources, bus 0 link: 0 DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:01.0 10 <- [0x00fd000000 - 0x00fdffffff] size 0x01000000 gran 0x18 prefmem PCI: 00:01.0 18 <- [0x00fe070000 - 0x00fe070fff] size 0x00001000 gran 0x0c mem PCI: 00:01.0 30 <- [0x00fe060000 - 0x00fe06ffff] size 0x00010000 gran 0x10 romem PCI: 00:02.0 10 <- [0x00fe040000 - 0x00fe05ffff] size 0x00020000 gran 0x11 mem PCI: 00:02.0 14 <- [0x0000005800 - 0x000000583f] size 0x00000040 gran 0x06 io PCI: 00:02.0 30 <- [0x00fe000000 - 0x00fe03ffff] size 0x00040000 gran 0x12 romem PCI: 00:1f.2 20 <- [0x0000005840 - 0x000000585f] size 0x00000020 gran 0x05 io PCI: 00:1f.2 24 <- [0x00fe071000 - 0x00fe071fff] size 0x00001000 gran 0x0c mem ERROR: PCI: 00:1f.3 10 unused size: 0x0000000000 not assigned DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Show resources in subtree (Root Device)...After assigning values. Root Device child on link 0 CPU_CLUSTER: 0 CPU_CLUSTER: 0 child on link 0 APIC: 00 APIC: 00 DOMAIN: 0000 child on link 0 PCI: 00:00.0 DOMAIN: 0000 resource base 5659 size 60 align 6 gran 0 limit ffff flags 40040100 index 10000000 DOMAIN: 0000 resource base fd000000 size 1072000 align 24 gran 0 limit febfffff flags 40040200 index 10000100 DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index a DOMAIN: 0000 resource base c0000 size 1ff40000 align 0 gran 0 limit 0 flags e0004200 index b DOMAIN: 0000 resource base 510 size 2 align 0 gran 0 limit ffff flags e0000100 index c DOMAIN: 0000 resource base 5658 size 1 align 0 gran 0 limit ffff flags e0000100 index d DOMAIN: 0000 resource base 20000000 size 90000000 align 0 gran 0 limit ffffffff flags e0000200 index e DOMAIN: 0000 resource base fee00000 size 10000 align 0 gran 0 limit ffffffff flags e0000200 index 3 PCI: 00:00.0 PCI: 00:00.0 resource base b0000000 size 10000000 align 0 gran 0 limit 0 flags f0000200 index 2 PCI: 00:01.0 PCI: 00:01.0 resource base fd000000 size 1000000 align 24 gran 24 limit fdffffff flags 60001200 index 10 PCI: 00:01.0 resource base fe070000 size 1000 align 12 gran 12 limit fe070fff flags 60000200 index 18 PCI: 00:01.0 resource base fe060000 size 10000 align 16 gran 16 limit fe06ffff flags 60002200 index 30 PCI: 00:02.0 PCI: 00:02.0 resource base fe040000 size 20000 align 17 gran 17 limit fe05ffff flags 60000200 index 10 PCI: 00:02.0 resource base 5800 size 40 align 6 gran 6 limit 583f flags 60000100 index 14 PCI: 00:02.0 resource base fe000000 size 40000 align 18 gran 18 limit fe03ffff flags 60002200 index 30 PCI: 00:19.0 PCI: 00:1a.0 PCI: 00:1a.1 PCI: 00:1a.2 PCI: 00:1a.7 PCI: 00:1b.0 PCI: 00:1c.0 PCI: 00:1c.1 PCI: 00:1c.2 PCI: 00:1c.3 PCI: 00:1c.4 PCI: 00:1c.5 PCI: 00:1d.0 PCI: 00:1d.1 PCI: 00:1d.2 PCI: 00:1d.7 PCI: 00:1f.0 PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000 PCI: 00:1f.0 resource base ff800000 size 800000 align 0 gran 0 limit 0 flags c0040200 index 10000100 PCI: 00:1f.0 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3 PCI: 00:1f.2 PCI: 00:1f.2 resource base 5840 size 20 align 5 gran 5 limit 585f flags 60000100 index 20 PCI: 00:1f.2 resource base fe071000 size 1000 align 12 gran 12 limit fe071fff flags 60000200 index 24 PCI: 00:1f.3 PCI: 00:1f.3 resource base 400 size 20 align 0 gran 0 limit 41f flags f0000100 index 20 PCI: 00:1f.3 resource base 0 size 0 align 0 gran 0 limit 0 flags 0 index 10 PCI: 00:1f.5 PCI: 00:1f.6 Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 00 PCI: 00:01.0 cmd <- 03 PCI: 00:02.0 cmd <- 03 PCI: 00:1f.0 subsystem <- 0000/0000 PCI: 00:1f.0 cmd <- 100 PCI: 00:1f.2 subsystem <- 0000/0000 PCI: 00:1f.2 cmd <- 103 PCI: 00:1f.3 subsystem <- 0000/0000 PCI: 00:1f.3 cmd <- 100 done. Initializing devices... Root Device init ... CPU_CLUSTER: 0 init ... Initializing SMM handler... ... pmbase = 0x0600 SMI_STS: PM1_STS: TMROF GPE0_STS: ALT_GP_SMI_STS: TCO_STS: ... raise SMI# Initializing CPU #0 CPU: vendor Intel device 663 CPU: family 06, model 06, stepping 03 CPU #0 initialized PCI: 00:00.0 init ... Keyboard init... Assigning IRQ 11 to 0:2.0 Assigning IRQ 10 to 0:1f.2 Assigning IRQ 10 to 0:1f.3 PCI: 00:01.0 init ... PCI: 00:02.0 init ... PCI: 00:1f.0 init ... i82801ix: lpc_init IOAPIC: Initializing IOAPIC at 0xfec00000 IOAPIC: Bootstrap Processor Local APIC = 0x00 IOAPIC: ID = 0x02 IOAPIC: Dumping registers reg 0x0000: 0x02000000 reg 0x0001: 0x00170011 reg 0x0002: 0x00000000 IOAPIC: 24 interrupts IOAPIC: Enabling interrupts on APIC serial bus IOAPIC: reg 0x00000000 value 0x00000000 0x00000700 IOAPIC: reg 0x00000001 value 0x00000000 0x00010000 IOAPIC: reg 0x00000002 value 0x00000000 0x00010000 IOAPIC: reg 0x00000003 value 0x00000000 0x00010000 IOAPIC: reg 0x00000004 value 0x00000000 0x00010000 IOAPIC: reg 0x00000005 value 0x00000000 0x00010000 IOAPIC: reg 0x00000006 value 0x00000000 0x00010000 IOAPIC: reg 0x00000007 value 0x00000000 0x00010000 IOAPIC: reg 0x00000008 value 0x00000000 0x00010000 IOAPIC: reg 0x00000009 value 0x00000000 0x00010000 IOAPIC: reg 0x0000000a value 0x00000000 0x00010000 IOAPIC: reg 0x0000000b value 0x00000000 0x00010000 IOAPIC: reg 0x0000000c value 0x00000000 0x00010000 IOAPIC: reg 0x0000000d value 0x00000000 0x00010000 IOAPIC: reg 0x0000000e value 0x00000000 0x00010000 IOAPIC: reg 0x0000000f value 0x00000000 0x00010000 IOAPIC: reg 0x00000010 value 0x00000000 0x00010000 IOAPIC: reg 0x00000011 value 0x00000000 0x00010000 IOAPIC: reg 0x00000012 value 0x00000000 0x00010000 IOAPIC: reg 0x00000013 value 0x00000000 0x00010000 IOAPIC: reg 0x00000014 value 0x00000000 0x00010000 IOAPIC: reg 0x00000015 value 0x00000000 0x00010000 IOAPIC: reg 0x00000016 value 0x00000000 0x00010000 IOAPIC: reg 0x00000017 value 0x00000000 0x00010000 Set power on after power failure. NMI sources disabled. rtc_failed = 0x0 RTC Init Disabling ACPI via APMC: done. Locking SMM. PCI: 00:1f.2 init ... i82801ix_sata: initializing... SATA controller in AHCI mode. ABAR: fe071000 PCI: 00:1f.3 init ... Devices initialized Show all devs... After init. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: 0000: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:1f.0: enabled 1 PCI: 00:1f.2: enabled 1 PCI: 00:1f.3: enabled 1 PCI: 00:1a.0: enabled 0 PCI: 00:1a.1: enabled 0 PCI: 00:1a.2: enabled 0 PCI: 00:1a.7: enabled 0 PCI: 00:1b.0: enabled 0 PCI: 00:1c.0: enabled 0 PCI: 00:1c.1: enabled 0 PCI: 00:1c.2: enabled 0 PCI: 00:1c.3: enabled 0 PCI: 00:1c.4: enabled 0 PCI: 00:1c.5: enabled 0 PCI: 00:1d.0: enabled 0 PCI: 00:1d.1: enabled 0 PCI: 00:1d.2: enabled 0 PCI: 00:1d.7: enabled 0 PCI: 00:19.0: enabled 0 PCI: 00:1f.5: enabled 0 PCI: 00:1f.6: enabled 0 PCI: 00:01.0: enabled 1 PCI: 00:02.0: enabled 1 Finalize devices... Devices finalized QEMU: found acpi tables in fw_cfg. QEMU: loading "etc/acpi/rsdp" to 0x1ffda000 (len 36) QEMU: loading "etc/acpi/tables" to 0x1ffda040 (len 131072) QEMU: loaded acpi tables from fw_cfg. ACPI tables: 131136 bytes. smbios_write_tables: 1ffd9000 Root Device (Emulation QEMU x86 q35/ich9) CPU_CLUSTER: 0 (QEMU Northbridge q35) APIC: 00 (unknown) DOMAIN: 0000 (QEMU Northbridge q35) QEMU: found smbios tables in fw_cfg (len 308). QEMU: coreboot type0 table found at 0x1ffd9020. QEMU: loading smbios tables to 0x1ffd907a PCI: 00:00.0 (QEMU Northbridge q35) PCI: 00:1f.0 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1f.2 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1f.3 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1a.0 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1a.1 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1a.2 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1a.7 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1b.0 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1c.0 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1c.1 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1c.2 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1c.3 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1c.4 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1c.5 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1d.0 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1d.1 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1d.2 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1d.7 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:19.0 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1f.5 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:1f.6 (Intel ICH9/ICH9-M (82801Ix) Series Southbridge) PCI: 00:01.0 (unknown) PCI: 00:02.0 (unknown) SMBIOS tables: 430 bytes. Writing table forward entry at 0x00000500 Wrote coreboot table at: 00000500, 0x10 bytes, checksum cfe1 Table forward entry ends at 0x00000528. ... aligned to 0x00001000 Writing coreboot table at 0x1ffd1000 rom_table_end = 0x1ffd1000 ... aligned to 0x1ffe0000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-000000001ffd0fff: RAM 3. 000000001ffd1000-000000001fffffff: CONFIGURATION TABLES 4. 00000000b0000000-00000000bfffffff: RESERVED Wrote coreboot table at: 1ffd1000, 0x144 bytes, checksum 485a coreboot table: 348 bytes. IMD ROOT 0. 1ffff000 00001000 IMD SMALL 1. 1fffe000 00001000 ACPI 2. 1ffda000 00024000 SMBIOS 3. 1ffd9000 00000800 COREBOOT 4. 1ffd1000 00008000 IMD small region: IMD ROOT 0. 1fffec00 00000400 CAR GLOBALS 1. 1fffebe0 00000004 ROMSTAGE 2. 1fffebc0 00000004 GDT 3. 1fffe9c0 00000200 CBFS provider active. CBFS @ 0 size 7ffc80 CBFS: Locating 'fallback/payload' CBFS: Found @ offset fe40 size da17 'fallback/payload' located at offset: fe78 size: da17 Loading segment from rom address 0xff80fe78 code (compression=1) New segment dstaddr 0xe64c4 memsize 0x19b3c srcaddr 0xff80feb0 filesize 0xd9df Loading segment from rom address 0xff80fe94 Entry Point 0x000fd4ce Bounce Buffer at 1ff7e000, 336152 bytes Loading Segment: addr: 0x00000000000e64c4 memsz: 0x0000000000019b3c filesz: 0x000000000000d9df lb: [0x0000000000100000, 0x000000000012908c) Post relocation: addr: 0x00000000000e64c4 memsz: 0x0000000000019b3c filesz: 0x000000000000d9df using LZMA [ 0x000e64c4, 00100000, 0x00100000) <- ff80feb0 dest 000e64c4, end 00100000, bouncebuffer 1ff7e000 Loaded segments ICH7 watchdog disabled Jumping to boot code at 000fd4ce(1ffd1000) CPU0: stack: 00120000 - 00121000, lowest used address 00120c3c, stack used: 964 bytes entry = 0x000fd4ce lb_start = 0x00100000 lb_size = 0x0002908c buffer = 0x1ff7e000 SeaBIOS (version unknown) Found mainboard Emulation QEMU x86 q35/ich9 Relocating init from 0x000e76e0 to 0x1ff86c90 (size 41648) Found CBFS header at 0xfffffc80 CPU Mhz=3206 Found 6 PCI devices (max PCI bus is 00) Copying SMBIOS entry point from 0x1ffd9000 to 0x000f1970 Copying ACPI RSDP from 0x1ffda000 to 0x000f1950 Using pmtimer, ioport 0x608 Scan for VGA option rom Running option rom at c000:0003 pmm call arg1=0 Turning on vga text mode console SeaBIOS (version unknown) All threads complete. Found 1 lpt ports Found 1 serial ports AHCI controller at 1f.2, iobase fe071000, irq 10 Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0 AHCI/0: registering: "AHCI/0: QEMU HARDDISK ATA-7 Hard-Disk (5120 MiBytes)" Searching bootorder for: /pci@i0cf8/*@1f,2/drive@2/disk@0 AHCI/2: registering: "DVD/CD [AHCI/2: QEMU DVD-ROM ATAPI-4 DVD/CD]" PS2 keyboard initialized All threads complete. Scan for option roms Running option rom at c980:0003 pmm call arg1=1 pmm call arg1=0 pmm call arg1=1 pmm call arg1=0 Searching bootorder for: /pci@i0cf8/*@2 Press F12 for boot menu. handle_02 handle_02 handle_02 handle_02 handle_02 handle_02 handle_02 handle_02 handle_02 handle_02 handle_02 handle_02

1 0

[PATCH] xhci: Count new Max Scratchpad Bufs bits from XHCI 1.1
by Julius Werner 10 Aug '15

10 Aug '15

The 1.1 revision of the XHCI specification added an extra 5 bits to the Max Scratchpad Bufs field of HCSPARAMS2 that newer controllers make use of. Not honoring these bits means we're not allocating as many scratchpad buffers as the controller expects, which means it will interpret some uninitialized values from the end of the pointer array as scratchpad buffer pointers. We just fixed this in libpayload and it seems to apply the same way to SeaBIOS (I only compile-tested this, though... sorry). Signed-off-by: Julius Werner <jwerner(a)chromium.org> --- src/hw/usb-xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/usb-xhci.c b/src/hw/usb-xhci.c index d6caa77..0059f2e 100644 --- a/src/hw/usb-xhci.c +++ b/src/hw/usb-xhci.c @@ -465,7 +465,7 @@ configure_xhci(void *data) xhci->evts->cs = 1; reg = readl(&xhci->caps->hcsparams2); - u32 spb = reg >> 27; + u32 spb = (reg >> 21 & 0x1f) << 5 | reg >> 27; if (spb) { dprintf(3, "%s: setup %d scratch pad buffers\n", __func__, spb); u64 *spba = memalign_high(64, sizeof(*spba) * spb); -- 2.1.2

2 1

Re: [SeaBIOS] [PATCH 2/2] Boot Linux using QEMU fw_cfg DMA interface
by Marc Marí 07 Aug '15

07 Aug '15

On Thu, 6 Aug 2015 13:38:33 +0100 Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > On Thu, Aug 6, 2015 at 12:02 PM, Marc Marí <markmb(a)redhat.com> wrote: > > case IPL_TYPE_BEV: > > - boot_rom(ie->vector); > > + if (qemu_cfg_dma_enabled()) { > > + boot_linux_cfg_dma(); > > + } else { > > + boot_rom(ie->vector); > > + } > > break; > > I thought the fw_cfg DMA interface is equivalent to the PIO interface? > > Therefore, your Linux loading code completely replaces the > linuxboot.rom. Why would you want to keep using linuxboot.rom in the > PIO case if SeaBIOS now has to code to launch the kernel? > > By the way, I think this change is incorrect. We shouldn't hijack the > BEV. Instead fw_cfg should simply add a higher priority IPL entry > when the kernel file is present. That way we just don't execute the > option ROM. > linuxboot.rom is doing all the work of reading and copying the kernel to the correct position through the PIO interface, in assembly. If we want to speed up the kernel copying with DMA, it is necessary to change it, and implementing fw_cfg DMA in C is a lot easier. This new boot is independent of PIO or DMA, so now linuxboot.rom would not be necessary. I don't know if this is desirable. In any case, I agree with adding a new IPL. Thanks Marc

3 3

Re: [SeaBIOS] [PATCH 1/2] Add QEMU fw_cfg DMA interface
by Laszlo Ersek 06 Aug '15

06 Aug '15

On 08/06/15 14:35, Stefan Hajnoczi wrote: > On Thu, Aug 6, 2015 at 12:02 PM, Marc Marí <markmb(a)redhat.com> wrote: >> + if (qemu_cfg_dma_enabled()) { >> + QemuCfgDmaAccess access; >> + >> + access.address = (u64)(u32)buf; >> + access.length = len; >> + access.control = QEMU_CFG_DMA_CTL_READ; >> + >> + /* >> + * The out is done before the write of the variables on memory. This >> + * causes misread on the QEMU side. >> + */ >> + barrier(); >> + >> + outl((u32)&access, PORT_QEMU_CFG_DMA_ADDR); > > I thought PORT_QEMU_CFG_DMA_ADDR is a 64-bit register according to the > spec you posted? > >> + while(access.length != 0 && !(access.control & QEMU_CFG_DMA_CTL_ERROR)); > > Either the field accesses need to be marked volatile, or a barrier is > needed to force the compiler to reload these register from memory each > iteration of the loop. Better yet, I would recommend declaring (and here, also defining) "access" as "volatile". volatile QemuCfgDmaAccess access; > I think the problem is that there are no "sequence points" (according > to the C language specification) in this loop, so the compiler may > assume that access.length and access.control will not change. > https://en.wikipedia.org/wiki/Sequence_point The loop does contain sequence points; three in total. Appendix C of the ISO C spec gives an informative summary on the sequence points (with references to the individual normative passages). Quoting from appendix C: 1 The following are the sequence points described in 5.1.2.3: [...] - The end of the first operand of the following operators: logical AND && (6.5.13); [...] [...] - The end of a full expression: [...] the expression in an expression statement (6.8.3); [...] the controlling expression of a while or do statement (6.8.5); [...] - Here we have the controlling expression of a while statement. - In that expression, we also have a logical AND operator. - And the null statement in the loop body is an expression statement. The lack of sequence points is not the problem (we do have sequence points). The problem is that without "volatile", the compiler might optimize out the accesses, because it deduces that the expressions produce no side effects. 5.1.2.3 Program execution [...] 2 Accessing a volatile object, [...] are all side effects, which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. [...] 3 In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object). [...] 5 The least requirements on a conforming implementation are: - At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred. [...] [...] 6.7.3 Type qualifiers [...] 6 An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. [footnote 116] What constitutes an access to an object that has volatile-qualified type is implementation- defined. Footnote 116 (informative): A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be "optimized out" by an implementation or reordered except as permitted by the rules for evaluating expressions. So, this covers both the initial population of "access", and the later reads. (If "access" is declared "volatile", then even the current barrier() can be removed, which is otherwise src/types.h:#define barrier() __asm__ __volatile__("": : :"memory") ie. a compiler barrier.) Thanks Laszlo

3 4

Re: [SeaBIOS] [PATCH 1/2] Add QEMU fw_cfg DMA interface
by Kevin O'Connor 06 Aug '15

06 Aug '15

On Thu, Aug 06, 2015 at 01:35:27PM +0100, Stefan Hajnoczi wrote: > On Thu, Aug 6, 2015 at 12:02 PM, Marc Marí <markmb(a)redhat.com> wrote: > > + if (qemu_cfg_dma_enabled()) { > > + QemuCfgDmaAccess access; > > + > > + access.address = (u64)(u32)buf; > > + access.length = len; > > + access.control = QEMU_CFG_DMA_CTL_READ; > > + > > + /* > > + * The out is done before the write of the variables on memory. This > > + * causes misread on the QEMU side. > > + */ > > + barrier(); > > + > > + outl((u32)&access, PORT_QEMU_CFG_DMA_ADDR); > > I thought PORT_QEMU_CFG_DMA_ADDR is a 64-bit register according to the > spec you posted? > > > + while(access.length != 0 && !(access.control & QEMU_CFG_DMA_CTL_ERROR)); > > Either the field accesses need to be marked volatile, or a barrier is > needed to force the compiler to reload these register from memory each > iteration of the loop. In seabios, one would use the yield() call. For example: while (access.control & QEMU_CFG_DMA_CTL_READ) yield(); -Kevin

1 0

QEMU fw_cfg DMA interface
by Marc Marí 06 Aug '15

06 Aug '15

Implementation of the FW CFG DMA interface. When running a Linux guest on top of QEMU, using the -kernel options, this is the timing improvement for x86: QEMU commit 2be4f242b50a8 and SeaBIOS commit 908a58c1d5ff QEMU startup time: .078 BIOS startup time: .060 Kernel setup time: .578 Total time: .716 QEMU with this patch series and SeaBIOS with this patch series QEMU startup time: .080 BIOS startup time: .039 Kernel setup time: .002 Total time: .121 QEMU startup time is the time between the start and the first kvm_entry. BIOS startup time is the time between the first kvm_entry and the start of function do_boot, in SeaBIOS. Kernel setup time is the time between the start of the function do_boot in SeaBIOS and the jump to the Linux kernel. As you can see, both the BIOS (because of ACPI tables and other configurations) and the Linux kernel boot (because of the copy to memory) are greatly improved with this new interface. Also, this new interface is an addon to the old interface. Both interfaces are compatible and interchangeable.

2 6

[PATCH 0/5] sdcard improvements
by Kevin O'Connor 05 Aug '15

05 Aug '15

This series expands the sdcard init sequence (as detailed in the SDHCI spec). It will probably still only work under QEMU, but it's further along. -Kevin Kevin O'Connor (5): sdcard: Check if card is present before sending commands to card sdcard: Implement controller frequency setting according to sdhci spec sdcard: Make sure controller support 3.3V before enabling it sdcard: Set timeout control register during init (to max allowed timeout) sdcard: Improve SD card initialization command sequence src/hw/sdcard.c | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 101 insertions(+), 9 deletions(-) -- 1.9.3

1 6

[PATCH] ata: Many CPUs cause seabios not to find boot disk
by Huaitong Han 05 Aug '15

05 Aug '15

When CPUs are 76, mptable_setup will alloc much fseg memory,and init_atadrive allocation fails. when CPUs are 86, mptable_setup allocation is too much to be met, and init_atadrive allocs success. So when CPUs are 76~85, seabios cannot find boot disk because init_atadrive allocation fails. Set a reserved area from fsegzone for atadrive allocation, and the fsegzone space also increases by the reserved area space. Signed-off-by: Huaitong Han <huaitong.han(a)intel.com> diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py index b976fb0..a7bc5b1 100755 --- a/scripts/layoutrom.py +++ b/scripts/layoutrom.py @@ -62,7 +62,7 @@ BUILD_BIOS_SIZE = 0x10000 BUILD_ROM_START = 0xc0000 BUILD_LOWRAM_END = 0xa0000 # Space to reserve in f-segment for dynamic allocations -BUILD_MIN_BIOSTABLE = 2048 +BUILD_MIN_BIOSTABLE = 2304 # Layout the 16bit code. This ensures sections with fixed offset # requirements are placed in the correct location. It also places the diff --git a/src/hw/ata.c b/src/hw/ata.c index fbbbbc1..12bd01f 100644 --- a/src/hw/ata.c +++ b/src/hw/ata.c @@ -710,7 +710,7 @@ ata_extract_model(char *model, u32 size, u16 *buffer) static struct atadrive_s * init_atadrive(struct atadrive_s *dummy, u16 *buffer) { - struct atadrive_s *adrive = malloc_fseg(sizeof(*adrive)); + struct atadrive_s *adrive = malloc_reserved_fseg(sizeof(*adrive)); if (!adrive) { warn_noalloc(); return NULL; @@ -920,7 +920,7 @@ init_controller(struct pci_device *pci, int chanid, int irq , u32 port1, u32 port2, u32 master) { static int ataid = 0; - struct ata_channel_s *chan_gf = malloc_fseg(sizeof(*chan_gf)); + struct ata_channel_s *chan_gf = malloc_reserved_fseg(sizeof(*chan_gf)); if (!chan_gf) { warn_noalloc(); return; diff --git a/src/malloc.c b/src/malloc.c index c4cb171..16114f5 100644 --- a/src/malloc.c +++ b/src/malloc.c @@ -296,6 +296,19 @@ malloc_getspace(struct zone_s *zone) return maxspace - reserve; } +u32 malloc_get_zone_space(struct zone_s *zone) +{ + // XXX - results not reliable when CONFIG_THREAD_OPTIONROMS + u32 totalspace = 0; + struct allocinfo_s *info; + hlist_for_each_entry(info, &zone->head, node) { + u32 space = info->allocend - info->dataend; + totalspace += space; + } + + return totalspace; +} + // Set a handle associated with an allocation. void malloc_sethandle(void *data, u32 handle) diff --git a/src/malloc.h b/src/malloc.h index 2bcb5bf..c70a468 100644 --- a/src/malloc.h +++ b/src/malloc.h @@ -20,6 +20,10 @@ int _free(void *data); u32 malloc_getspace(struct zone_s *zone); void malloc_sethandle(void *data, u32 handle); void *malloc_findhandle(u32 handle); +u32 malloc_get_zone_space(struct zone_s *zone); + +//Set a reserved zone to prevent key memory allocation failure +#define RESERVED_FSEG_ZONE 256 #define MALLOC_DEFAULT_HANDLE 0xFFFFFFFF // Minimum alignment of malloc'd memory @@ -32,6 +36,13 @@ static inline void *malloc_high(u32 size) { return _malloc(&ZoneHigh, size, MALLOC_MIN_ALIGN); } static inline void *malloc_fseg(u32 size) { + u32 allspace = malloc_get_zone_space(&ZoneFSeg); + if (allspace < (size + RESERVED_FSEG_ZONE)) + return NULL; + + return _malloc(&ZoneFSeg, size, MALLOC_MIN_ALIGN); +} +static inline void *malloc_reserved_fseg(u32 size){ return _malloc(&ZoneFSeg, size, MALLOC_MIN_ALIGN); } static inline void *malloc_tmplow(u32 size) { -- 1.9.1

3 5

Re: [SeaBIOS] Problems booting USB's on Chromebook Pixel 2015
by Kevin O'Connor 04 Aug '15

04 Aug '15

On Tue, Aug 04, 2015 at 12:31:35PM +0100, Paul Hurst wrote: > Hi there Kevin, > > Hope you are well. > > I am running a 2015 Chromebook Pixel LS and I'm wondering if you could > possibly help me as I'm at my whits end :-) > > I have enabled developer mode and legacy boot/usb boot using the commands > readily available on Google but whenever I try to boot from any USB stick > (I've tried USB 2 and 3), The screen just corrupts and the machine appears > to hang. It is odd that you are seeing screen corruption. Did you try different Linux distributions on your USB sticks? > I know its running SeaBios as it tells me after I have pressed CTRL+L and > it then offers me a boot menu with my devices correctly listed but its > after that where the corruption starts. > > Completely by fluke on one of my linux usb sticks, I removed it and > reinserted it while the corruption was on screen and that did actually > allow the boot but obviously this isnt good for my USB integrity. If you can get into Linux from SeaBIOS then that should be enough to obtain the SeaBIOS "cbmem" debug log. To do this, you'll need to download the coreboot source code (see http://coreboot.org/ ) and then build the tool in the 'util/cbmem/ directory. Then run "cbmem -c" under Linux (booted via SeaBIOS) and forward the full log to this mailing list. Getting the SeaBIOS debug log is the next key step to figuring out the problem. > I do hope you can help, I found your email via a google search as someone > else seems to have had the same issue but there where no fix instructions > that I could find. > > Finally, I've tried to see if its possible to update/re-install seaBios > but there's nothing i can see online for beginners such as me. It is possible to update seabios. I've done it on my acer c720 chromebook. I don't have a pixel, but I imagine the steps are similar. It's possible to build seabios directly from source, create a rom using coreboot's cbfstool, and install it using the flashrom tool that comes with chromeos. I also understand that there are some scripts that automate it (eg, http://johnlewis.ie/ ). -Kevin

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS