[coreboot] EFI strategy

ron minnich rminnich at gmail.com
Sun Feb 10 16:51:00 CET 2008

On Feb 10, 2008 5:02 AM, Brendan Trotter <btrotter at gmail.com> wrote:

> 100 KB RAM initialization (and hyper-transport initialization?)
>  50 KB decompression code
> 200 KB (compressed) remaining chipset/motherboard initialization


geodelx today: 25k. For all this.

We had K8 setup in about 64K on many platforms I built for. I used to
easily fit a linux kernel and lb in 1 MB flash.

The flash size limit problem has always been a linux problem.

oh yeah, filo is 40K.

> Of course you'd eventually want other ways to update the payload (e.g.
> from CD, from floppy, from USB flash, etc) where one (or more?) of
> these methods may be enabled as a coreboot compile-time option. Things
> like file systems (for floppy, USB flash, etc) aren't really necessary
> - just let the end-user do "cat update > /dev/device" and reformat the
> device after the payload update is installed, so the payload update
> utility only needs to worry about reading contiguous sectors from the
> device.

nope. That's not what coreboot does. flash update should never be supported
by coreboot anyway. That's for the OS to manage. We're not an OS.

> I asked if coreboot was a viable option for me, and the indirect
> answer was mostly "no".
> Please note, I'm talking about software (including OS and
> applications) that boots directly from ROM; like SplashTop and the QNX
> demo I mention above, and firmware for embedded systems
> (broadband/ADSL modems, routers, firewalls, DVD players, etc). All of
> these things have one thing in common - there's no need for any
> additional storage device (application configuration can be stored in
> the flash ROM or perhaps in CMOS, and an additional storage device
> just increases manufacturing costs and boot times).

I've been booting OSes from ROM for 8 years now. What's so special
about this idea? I've booted 2 different OSes from ROM, routinely, for years.

> There's also one thing the current payloads have in common - they're
> all designed to boot something from an additional storage device;

That's pretty much not correct. It is how people have used coreboot
in many cases, but not all. You are confusing usage with capability.

> why it'd be good to ensure that different versions of each different
> payload don't have compatibility problems with different versions of
> coreboot.

There is no interface. That decision is very deliberate. That's why we support
something like a dozen different payloads, including at last count 3 OSes.

> "In general the payload must comply with the Tool Interface Standard
> (TIS) Executable and Linking Format (ELF) Specification (which can be
> downloaded at http://x86.ddj.com/ftp/manuals/tools/elf.pdf). However,
> coreboot only supports a subset of the ELF specification.
> Specifically, coreboot may not support:"


"Any standalone ELF file will do. Examples include Linux, GRUB2,
Plan 9, Tiano Core, and FILO. There is no support for BIOS callbacks.
". If People have trouble undertanding that they're in the wrong


> Then you list things that coreboot's ELF loader may not support, for
> example, PIC, dynamic linking, etc. Then add something about the
> permitted ELF file load addresses, the behaviour if the payload's
> "main()" returns, etc.

How can coreboot not support PIC?

And how could any firmware usefully claim to support dynamic linking?

If the payload main returns, what behaviour do you plan to implement?

"We'll recompile the payload if main() returns?" I mean, what can
firmware do at that

> This doesn't mean that a future version of coreboot couldn't implement
> support for something like PIC (position independant code), but it
> does mean that it's optional and a payload can't assume it's
> supported. Of course a future version of the "coreboot payload
> specification" could make PIC support (for e.g.) a requirement, but
> that doesn't break backward compatability.

You need to explain what is so special about PIC that it impacts firmware.

> Without any specification, coreboot developers will end up supporting
> specifications from other projects (instead of other projects
> supporting coreboot's specification). This is already happening -
> efforts have already been made by coreboot developers to support
> multi-boot, EFI, the (de facto) PC BIOS, FILO, etc, but I've been
> unable to find any other project writing code that supports coreboot
> directly.

I think you don't completely understand what coreboot is and is not. v3
actually supports a form of multipboot -- a payload can have many segments.
You could easily, for example, have a Xen hypervisor, kernel, and initram
in the payload directory in LAR.

> For example, (IMHO) the motherboard vendor and product ID should be
> required (and should match the equivelent strings provided by the
> original firmware where possible). Obviously the physical memory map
> should also be required (and the "memory area types" should match the
> data returned by "int 0x15, eax = 0xE820" as specified by ACPI, where
> possible).

You do realize that in many cases the "original strings in firmware"
can be wrong?

E820 map is not a hard one ... IIRC it has been supported in v2 in
some cases for some time.

it's ACPI that's the hard one. If you could extend our ACPI table
writing code, we'd be grateful.

> For an example, coreboot could have an optional cbtable entry that
> tells the payload where the ACPI tables are (so that payload doesn't
> need to search for them at 16-byte boundaries, which is a silly
> cache-thrashing idea IMHO).

That's not cache thrashing by definition, but if you want to call it
that, ok. That kind of "cache thrashing" occurs precisely *once*, all
OSes do it anyway, it simply does not matter in the broad scheme of
things. You're wasting your mind worrying about it.

Just having an ACPI table matters much, much more.

> Another example would be a cboot table entry that tells the payload/OS
> which PCI configuration space access mechanism the chipset uses (e.g.
> "mechanism #1", "mechanism #2", or "mechanism #1 with PCI-Express
> extensions"). If it isn't present the payload/OS can use probing.

Why? The OSes are all built to make this test, it's an utterly trivial
test, why complicate things? This idea makes no sense to me at all.

> Another idea could be a "payload area" cbtable entry, which tells the
> payload which address range (in the flash ROM) it came from, so that
> it can replace/update itself (although I prefer my original idea of
> building the "payload update" functionality into coreboot itself, to
> prevent "payload vendor lock-in").

Just use LAR. This idea is completely un-needed.

I don't like any of these ideas, sorry.



More information about the coreboot mailing list