Stefan,
On Tue, May 10, 2011 at 2:32 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
On 5/9/11 6:15 PM, Peter Stuge wrote:
Graeme Russ wrote:
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code.
Here there should probably be a second possible entry point, for when U-Boot is a coreboot payload.
Let's just add a compile time option and select that for a coreboot build. I don't think we need additional entry points.
KISS has always served us well.
The second entry point already exists - It is an extremely small overhead in the U-Boot source and I have been using it extensively to load new images for testing into RAM and bypassing the cold-reset vector and initial setup of a temporary GDT - It's value far outweighs the expense
It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
I guess this processing would remain, but the bytes it operates on would already be in RAM.
Please, no! Why would you do something at run time on every boot when you can do it at compile/build time?
Because U-Boot is designed to load itself into the highest possible memory address to provide a maximum RAM footprint to whatever image it loads. Also, there is no guarantee of a particular amount of RAM existing. This is not an x86 specific feature - This is a core U-Boot design principle
It's firmware, not an OS. (Even if popular belief claims there is no difference)
As I said earlier, I don't want to tie U-Boot to libpayload.
Again, why not? For the particular U-Boot build that runs as coreboot payload it should save a lot of development time.
I think copying over those one or two files from libpayload would allow to keep uboot without any build time dependencies, which sounds like a good thing and possibly worth the code duplication. Note that Rudolfs port already copies a small portion of libpayload code because he felt that the libpayload integration would make the code more complex than the code duplication. And I agree in this case.
Yes, I think small bits of libpayload could be easily integrated
If U-Boot will require SeaBIOS then some VGA option ROM will likely have been executed and all the standard BIOS services for console are there.
When U-Boot is the coreboot payload there are no BIOS services, and U-Boot needs to implement everything on it's own.
Not everything. It can rely on coreboot initializing video (and a framebuffer for example)
I think both above scenarios would make an excellent configuration choice in uboot, providing support for whatever the user wants.
On systems with SeaBIOS you probably don't care for uboot anyways as the additional benefit is rather small. On other systems where SeaBIOS is not the payload of choice uboot is much more interesting (for now)
Well I think the examination of use cases could get very interesting. For the time being, I think there are two options:
1) Load SeaBIOS and then launch U-Boot and have U-Boot use the BIOS routines provided by SeaBIOS for I/O 2) Incorporate parts of libpayload (and potentially bits of SeaBIOS implemented in 32-bit protected mode) into U-Boot and launch U-Boot directly
I think we could start with 1) and then transition to 2) over time. Note that for 2), U-Boot could also provide a very thin 'BIOS wrapper' which would translate 16-bit BIOS calls into the U-Boot core via for (optional) support of legacy applications
Regards,
Graeme