* Brendan Trotter btrotter@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