[coreboot] EFI strategy

[Stefan Reinauer]

* Brendan Trotter <btrotter at gmail.com> [080210 14:02]:
> 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.
 
That's Normal + Fallback image. Most of the space is actually occupied
by filesystem drivers. :-)

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

2MB is plenty of space (16MBit) and unfortunately not the reality on
today's x86 systems. 

> 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

Because the hardware vendor added an incredible amount of flash memory
on those boards. 

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

You forgot Linux and Plan9. QNX should work just fine, given you have
2MB (a.k.a 16 MBit) of flash. Large flashes are still yet only 8MBit
today (except the Splashtop stuff which is NAND flash in addition to the
NOR flash, ie. an "external storage medium" in your sense). And most of
the community does not get their full application in 1MB these days. See
Alan Carvalho de Asis' impressive work on this topic.

If you have an application / use case that fits in this space, please
let us know. We're always glad to find new uses of coreboot. Maybe
booting BCOS directly out of flash?

> 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.
 
But they don't. Has there been a single such case you are referring to?
Or is this just a theoretical assumption? In this case I can reassure
you. At least we have not heard of such problems.

> 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.
 
PIC code is well supported. Dynamically linked code is obviously not,
because there are no libraries. System calls are neither. "Self
contained ELF" pretty much describes it completely

> Without any specification, coreboot developers will end up supporting
> specifications from other projects (instead of other projects
> supporting coreboot's specification).

Not at all! Our specifications are so simple that there is not much to
say.

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

Because that is not required. See how simple it is? You don't need any
of that stuff in between to boot Linux or Plan9 or any other OS that
does not require PC BIOS, for example, for the simple reason that PC
BIOS was there 20ys earlier. We're not going to change the world in a
single day, obviously. But we are going to change it.

Indeed, if you look at ADLO, FILO, TianoCore, and all the others: These
projects adapt to coreboot, not at all the other way round. It is true,
however, that a lot of the development in those projects happens in the
orbit of coreboot and the coreboot community. Just like the gcc
developers sometimes talk to the glibc developers and the Linux kernel
developers to find out how to make the projects interact in the best
possible way. And of course, the communities are overlapping. That is no
surprise in any sufficiently sized open source community.

Your lines read as if you are saying Linux is bad because it started
supporting C as a programming language, the POSIX standards and ELF as a
binary format. I can't agree with you here.

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

I don't think any one time executed micro-optimizations should really
become part of the coreboot concept. As you said: We are setting up our
own standards, and in v3, ACPI will at some point be nothing but a
compatibility layer for "old" "legacy" operating systems.

BTW ACPI is slowly dying: Intel decided to put power management much
more out of the software scope anyways for the upcoming chipsets.

Yes, we can offer that standard, but if we start forcing people into
reading ACPI relevant information from the coreboot table, we can as
well just do it without ACPI, and make sure we don't get dictated by
external projects don't you think.

Best wishes, 

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866