[coreboot] EFI strategy

[Carl-Daniel Hailfinger]

On 10.02.2008 14:02, Brendan Trotter wrote:
>> 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
>   

Flashrom is 610 kB uncompressed and we're still missing loads of board
enable functions and support for quite a few flash chips. Even with lzma
this is not going to be smaller than 200kB.

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

See above. We don't include a flashing tool in the ROM.

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

And where is a mass-market board with 2 MB of flash ROM? Most of them
have 2 Mbit (256 kB). With your rough estimate above, RAMinit,
decompression and chipset init already don't fit into such a chip.

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

You're free to do that. Alan Carvalho de Assis has created a ROM with
coreboot and Linux and an X server in 2 MB.

>>> 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?
>   

See above. And a few more reasons I'll state after you solved the
problems above.

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

Ah, flashrom via serial. This absolutely fails your own criteria
("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).")

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

That is not "incredibly simple" at all.

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

Checking for that stuff will cost you enough time to cause a slowdown of
perhaps 50% or more when considering time from poweron to bootloader.

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

Right. Sorry.

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

Except the Linux-with-Xserver-in-ROM by Alan Carvalho de Assis.

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

And why should there be compatibility problems? There is no reason you
can't stuff an OS loader and an OS into ROM (except space problems).

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

Sorry, but it seems you are obsessed with specifications. I still don't see
- what you exactly want (except a specification with theoretical benefits)
- why you want that (please no hypothetical scenario, show us some code
which does not work because we have not yet written a spec)
- who will write the spec
- who will implement it
- who will make sure the spec doesn't limit our future design work.

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

See above.

>> 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!
>   

None of these points amount to the specification you want.

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

There is no such thing as draft specifications. Once the draft is
released, people start using it. If we ever want to fix up the draft, we
will get complaints from all people who developed code according to the
draft.

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

There is no reason why we can't solve the whole spec thing by using a
payload (OFW, Etherboot, ADLO, ...) which implements an existing spec
and have that payload load the final payload.


Regards,
Carl-Daniel