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