[coreboot] EFI strategy

[Brendan Trotter]

Hi,

> On Sat, Feb 09, 2008 at 09:34:55PM +0000, Brendan Trotter wrote:
> > There's only 2 things coreboot is missing. The first is an inbuilt
> > "update payload from <device>" utility

On 2/9/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> It is surprisingly hard to get this right with limited flash sizes of today.

On 2/10/08, Peter Stuge <peter at stuge.se> wrote:
> This is basically the problem of flash chips still being too small.

Some (rough) estimates:

100 KB RAM initialization (and hyper-transport initialization?)
 50 KB decompression code
200 KB (compressed) remaining chipset/motherboard initialization
 25 KB (compressed) "update" storage device driver
 25 KB (compressed) payload update utility
  ? KB misc

While I can guarantee these estimates are wrong, they can't be wrong
by too much as your own build tutorials (e.g.
http://www.coreboot.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) suggest
that coreboot v2 and FILO add up to about 512 KB.

For a 2 MB flash that leaves about 1.5 MB for the compressed payload.
That's plenty of space.

For an example, consider this (from
http://www.amd.com/epd/desiging/evalboards/all/21923/index.html):

"To showcase QNX's exceptionally small memory footprint, the QNX
In-Hand demo fits the following into just 4MB of ROM: POSIX RTOS,
full-featured windowing system, TCP/IP stack, desktop-caliber web
browser (HTML 3.2, JavaScript, frames, etc.), Internet dialer, email
client, spreadsheet, text editor, contact manager, personal scheduler,
several games, on-line help, PCMCIA support, and more."

That's a lot to fit into a 4 MB ROM - I only want about a quarter of
that in a 2 MB ROM.

> > There's only 2 things coreboot is missing. The first is an inbuilt
> > "update payload from <device>" utility to make installing (and
> > reinstalling) a payload after coreboot is installed incredibly simple
> > (e.g. something that can easily be used by end-users who have never
> > seen a compiler in their life and never will).

On 2/9/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> This is impossible in the general case and hard in some special cases.

Can you suggest anything that makes it difficult?

Code that attempts to download a file (the new payload) from a serial
port wouldn't be too hard, some sanity checks are simple (make sure
the payload will fit in the available space, has the right magic
number or header, and the right checksum, etc), some glue to copy
coreboot from ROM into RAM and replace the payload shouldn't be hard
either, and you've already got code to copy data from RAM into flash
(in an external utility called "flashrom").

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.

The general idea would be for coreboot to be able to use any of these
(optional) methods to attempt "payload update", and to boot normally
if no payload update is present.

> > The second thing that's missing is a "payload specification" (with
> > backward compatability) that allows payloads to be written by anyone
> > that always work reliably without any compatability problems. Without
> > this, coreboot is too volatile for any sane third party to rely on.

On 2/9/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Ah, the same point you already stated earlier and which was already
> answered.

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).

There's also one thing the current payloads have in common - they're
all designed to boot something from an additional storage device;
except memtest which doesn't boot anything, and including etherboot
(where the external storage device is a TFTP server on the network).

This makes all current payloads unsuitable for the purpose of "boot
everything from ROM", and with the limited flash sizes of today there
just isn't enough space for coreboot, a useless/unsuitable payload
*and* the OS and it's applications. The only sane solution (for the
purpose of "boot everything from ROM") is for the payload to include
the OS and it's applications and nothing else, which is why the
interface between the (potentially) many possible payloads (written by
lots of seperate third party groups) and coreboot is important; and
why it'd be good to ensure that different versions of each different
payload don't have compatibility problems with different versions of
coreboot.


> Any self-contained ELF file will naturally do.

Ok, so you start with something like this...

"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:"

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.

Basically, any differences between the full ELF specification and the
subset of ELF that coreboot must support would need to be found and
explicitly mentioned in the "coreboot payload specification".

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.

> The flexibility of the
> approach is the lack of a more restricting specification.

How flexible it is depends on how carefully worded the document is.

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 agree we should specify the coreboot table format in a formal
> document. And we should provide "libpayload.a" to provide
> functions such as coreboot table reading, cmos access, ram detection,
> console detection, ...

Yes!

> If we want to push coreboot on another level, we should make substantial
> changes to the coreboot table datastructure with the advent of v3.

Yes. I'd consider keeping the payload specification in "draft" status
and developing it in conjunction with coreboot V3, then releasing both
at the same time.

The first step would be to describe what's already present, and
indicate which entries are required and which entries are optional.

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).

Other things may be optional, such that coreboot may or may not supply
the information depending on the implementation and/or compile-time
options.

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). If the "ACPI pointer" cbtable entry isn't
be present the payload or OS can still search for them, and if the
"ACPI pointer" cbtable entry is present but contains the address
0xFFFFFFFF then the payload or OS knows there is no ACPI tables.

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.

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").


Cheers,

Brendan