[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

From: Jordan Justen
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Date: Fri, 31 May 2013 16:01:16 -0700

On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann <address@hidden> wrote:
>   Hi,
>> I guess -bios would load coreboot. Coreboot would siphon the data
>> necessary for ACPI table building through the current (same) fw_cfg
>> bottleneck, build the tables,
> Yes.

So, this is really about making coreboot+seabios the default QEMU
firmware, and making seabios depend on being a coreboot payload?

>> load the boot firmware (SeaBIOS or OVMF or
>> something else -- not sure how to configure that),

It wouldn't be loading OVMF. It would be loading CorebootPkg.

OVMF is a better sample platform for EDK II since it shows a more
realistic view of what an EDK II based platform looks like on real

Thus, if the ACPI tables are just being added to a new coreboot layer
with coreboot becoming the default QEMU firmware, then it doesn't help
OVMF (or other non-coreboot payloads).

Well, it could if the table code was BSD licensed, but only so we
could then merge them into OVMF. Then again, why not just provide a
set of suitably licensed ACPI source files within the QEMU tree that
firmware projects could use? QEMU doesn't necessarily need to
build/link them, or attempt to communicate them at runtime.


> The coreboot rom has named sections (this is called cbfs which stands
> for coreboot filesystem IIRC):
> rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print
> bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0
> alignment: 64 bytes
> Name                           Offset     Type         Size
> cmos_layout.bin                0x0        cmos_layout  1160
> fallback/romstage              0x4c0      stage        14419
> fallback/coreboot_ram          0x3d80     stage        37333
> config                         0xcfc0     raw          2493
> fallback/payload               0xd9c0     payload      56969
> vgabios/sgabios                0x1b8c0    raw          4096
> (empty)                        0x1c900    null         144216
> where "fallback/payload" is seabios.
>> and pass down the
>> tables to the firmware (through a now unspecified interface -- perhaps
>> the tables could even be installed at this point).
> As far I know coreboot can add more stuff such as acpi tables to cbfs at
> runtime and seabios able to access cbfs too and pull informations from
> coreboot that way.
> HTH,
>   Gerd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]