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