Hi,
when promoting LinuxBIOS over the last few months I almost invariably got the response: "Why would anyone want to create a new BIOS? EFI is the future." EFI marketing seems to have successfully convinced many people by simple repetition of their "EFI is the future" campaign. Back when we had the dreaded "BIOS" in the project name it was almost impossible to get the message across that we had the most modern concept and codebase. Now is the time for change. CHANGE! Let's use EFI marketing for our own advantage and add some new marketing in EFI style to our public image. Suggestions: - "The EFI proponents are right. BIOS is a thing of the past." - "EFI has been superseded by Coreboot. Of course Coreboot has a backwards compatible EFI emulation for systems stuck with a solution from the 90s." - "Coreboot is able to run legacy code like EFI and BIOS, but who would want that?" To be fair to EFI, it was a good idea back in 1995, but we live in 2008 and have to be realistic about the "future" of EFI.
Regards, Carl-Daniel
The only fully open source implementation of EFI is based on coreboot. Coreboot + tiano core provides a full open source EFI.
No EFI-based BIOS can make that statement.
Coreboot can reduce the costs of the platform, because 1. no per-unit license 2. distributed support model (same model as Linux, Apache, etc. etc. etc.) 3. Demonstrated higher quality than closed-source BIOS --> lower support costs
There is also a real security issue with closed source BIOSes, particularly EFI. The question is simple: what's your computer doing? The answer is simple: with a proprietary, closed-source BIOS like EFI that reserves the right to continue running once you boot, you do not and can not and never will know. People are starting to figure this out, and it's worrying them.
EFI is part of the old model of closed, proprietary software. coreboot is part of the open future.
ron
Hi,
with that regard, the change to coreboot improved the perception of LinuxBIOS a lot. It's no longer a BIOS. :-)
You are right, EFI is not a completely new idea. It is roughly an attempt to write a C implementation of what was 1994 (not '95) standardized as Open Firmware (IEEE 1275-1994) and existed for about a decade before that.
EFI is really nothing we should be hostile about. EFI is just yet another bootloader, a payload in coreboot speak. It can be just one of the "personalities" of coreboot. Just like gPXE, OpenFirmware, ADLO, GRUB2, Linux-as-a-Bootloader, (FILO, OpenBIOS).
EFI is a problem that was solved quite a while ago: If you want coreboot to be your EFI, you can have that. If you want it to be Open Firmware, go ahead. coreboot _is_ whatever people _require_ it to be. An interesting interesting observation is that not a whole lot of people require coreboot to be EFI (or Open Firmware).
Today's OS landscape had to find a way around the Firmware mess of the 70's, 80's and 90's and started defining there requirements feature driven rather than standards driven almost a decade ago. This was when coreboot, called LinuxBIOS back then, started to be successful.
Our customers usually stop asking for (U)EFI once they understand it is just another bootloader. That is what it was designed as. coreboot really is, what Intel calls a "pre-EFI environment": PEI. This is the part where the interesting things happen (everything else except loading a kernel and bringing the graphics adapter to light.) But this is just what we experienced. I am sure there are parts of industry where EFI might become the solution of excellence - Just like there is such a market for Intel's Itanium® processors.
None the less, I think it is important that we offer this variation just as any other. This is one of the reasons coresystems became a member of UEFI. We were able to build up some remarkable contacts to Intel for supporting their hardware and we think it is in common interest to have Intel work with us in this community in the long run. There are guys from Intel on this mailing list, and I think we should welcome them heartly for their interest in our technology rather than cutting the rescue rope by prematurely sounding the trumpet for attack ;-)
Best regards,
Stefan
I think it would be interesting to have a buildrom option for 'build EFI'.
It could fetch tiano core and build an EFI from that. Somebody want to take this on as a project? It would really be valuable.
Then we could just say "oh, you want EFI? It's a simple config option to the coreboot buildrom tool".
ron
Hi,
Sorry for the interruption, but...
On 2/9/08, ron minnich rminnich@gmail.com wrote:
I think it would be interesting to have a buildrom option for 'build EFI'.
It'd be much more interesting to have no buildrom options for payloads at all. Let the user install their own payload *after* coreboot is installed.
Why? So motherboard manufactures for a wide range of hardware (e.g. embedded, desktop and server) can install coreboot as default on all motherboards.
It's better for the motherboard manufacturer, who would be freed from the hassle of deciding whether to use PC BIOS or EFI or GRUB or whatever.
It's also better for the end-user, who isn't stuck with the manufacturers choice of payload and doesn't need to get their hands dirty with compilers and compile-time configuration. If it's done right, a complete moron could safely install a pre-built payload of any description on top of pre-installed coreboot, without worrying about bricking their hardware (or stuffing up their warranty).
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).
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.
Cheers,
Brendan
On Feb 9, 2008 1:34 PM, Brendan Trotter btrotter@gmail.com wrote:
Hi,
Sorry for the interruption, but...
On 2/9/08, ron minnich rminnich@gmail.com wrote:
I think it would be interesting to have a buildrom option for 'build EFI'.
It'd be much more interesting to have no buildrom options for payloads at all. Let the user install their own payload *after* coreboot is installed.
brendan, you realize I'm talking about buildrom, not just coreboot, right?
ron
On 09.02.2008 22:34, Brendan Trotter wrote:
On 2/9/08, ron minnich rminnich@gmail.com wrote:
I think it would be interesting to have a buildrom option for 'build EFI'.
It'd be much more interesting to have no buildrom options for payloads at all. Let the user install their own payload *after* coreboot is installed.
I think you may be confusing buildrom with coreboot. Buildrom is there to create a ROM with payload. The normal coreboot build process doesn't really care about a payload.
Why? So motherboard manufactures for a wide range of hardware (e.g. embedded, desktop and server) can install coreboot as default on all motherboards.
It's better for the motherboard manufacturer, who would be freed from the hassle of deciding whether to use PC BIOS or EFI or GRUB or whatever.
It's also better for the end-user, who isn't stuck with the manufacturers choice of payload and doesn't need to get their hands dirty with compilers and compile-time configuration. If it's done right, a complete moron could safely install a pre-built payload of any description on top of pre-installed coreboot, without worrying about bricking their hardware (or stuffing up their warranty).
It is surprisingly hard to get this right with limited flash sizes of today.
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).
This is impossible in the general case and hard in some special cases.
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.
Ah, the same point you already stated earlier and which was already answered.
Regards, Carl-Daniel
On Sat, Feb 09, 2008 at 09:34:55PM +0000, Brendan Trotter wrote:
Sorry for the interruption, but...
All input is valuable!
On 2/9/08, ron minnich rminnich@gmail.com wrote: There's only 2 things coreboot is missing. The first is an inbuilt "update payload from <device>" utility
This is basically the problem of flash chips still being too small.
The second thing that's missing is a "payload specification"
This has come up before. We would very much appreciate help from anyone who has ideas about such a specification.
(with backward compatability) that allows payloads to be written by anyone that always work reliably without any compatability problems.
I don't think this is really possible though. Even the C programming language changes over time. I agree with you that specifications should be very stable, but I believe it is impossible to create one that "always" works. At some point this will become a re-invention of OpenFirmware. Please prove me wrong though! :)
//Peter
Peter Stuge wrote:
On Sat, Feb 09, 2008 at 09:34:55PM +0000, Brendan Trotter wrote:
Sorry for the interruption, but...
All input is valuable!
On 2/9/08, ron minnich rminnich@gmail.com wrote: There's only 2 things coreboot is missing. The first is an inbuilt "update payload from <device>" utility
This is basically the problem of flash chips still being too small.
The second thing that's missing is a "payload specification"
This has come up before. We would very much appreciate help from anyone who has ideas about such a specification.
Any self-contained ELF file will naturally do. The flexibility of the approach is the lack of a more restricting specification.
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, ...
I don't think this is really possible though. Even the C programming language changes over time. I agree with you that specifications should be very stable, but I believe it is impossible to create one that "always" works. At some point this will become a re-invention of OpenFirmware. Please prove me wrong though! :)
If we want to push coreboot on another level, we should make substantial changes to the coreboot table datastructure with the advent of v3. This includes exporting the device tree in the cbtable (or the other way round?) coreboot really should tell anyone reading the cbtable all that it knows about a given machine.
Stefan
//Peter
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@gmx.net wrote:
It is surprisingly hard to get this right with limited flash sizes of today.
On 2/10/08, Peter Stuge peter@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@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@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
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@gmx.net wrote:
It is surprisingly hard to get this right with limited flash sizes of today.
On 2/10/08, Peter Stuge peter@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@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@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
* 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
On Feb 10, 2008 5:02 AM, Brendan Trotter btrotter@gmail.com wrote:
100 KB RAM initialization (and hyper-transport initialization?) 50 KB decompression code 200 KB (compressed) remaining chipset/motherboard initialization
eh?
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:"
Why?
"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 place.
Done.
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 point?
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.
Thanks
ron
Jordan?
On 09.02.2008 19:21, ron minnich wrote:
I think it would be interesting to have a buildrom option for 'build EFI'.
It could fetch tiano core and build an EFI from that. Somebody want to take this on as a project? It would really be valuable.
Then we could just say "oh, you want EFI? It's a simple config option to the coreboot buildrom tool".
Maybe the GSoC results for Tianocore can be integrated into buildrom: http://code.google.com/p/google-summer-of-code-2007-coresystems/downloads/de...
Regards, Carl-Daniel
On 26/02/08 11:31 +0100, Carl-Daniel Hailfinger wrote:
Jordan?
Yes - this would be a reasonable thing to do.
Jordan
On 09.02.2008 19:21, ron minnich wrote:
I think it would be interesting to have a buildrom option for 'build EFI'.
It could fetch tiano core and build an EFI from that. Somebody want to take this on as a project? It would really be valuable.
Then we could just say "oh, you want EFI? It's a simple config option to the coreboot buildrom tool".
Maybe the GSoC results for Tianocore can be integrated into buildrom: http://code.google.com/p/google-summer-of-code-2007-coresystems/downloads/de...
Regards, Carl-Daniel
-
Brendan Trotter -
Carl-Daniel Hailfinger -
Jordan Crouse -
Peter Stuge -
ron minnich -
Stefan Reinauer