[coreboot] Hackaton in Prague 2011
graeme.russ at gmail.com
Tue May 10 06:47:28 CEST 2011
On Tue, May 10, 2011 at 2:32 PM, Stefan Reinauer
<stefan.reinauer at 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
>>> 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
>> 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
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
More information about the coreboot