[coreboot] Hackaton in Prague 2011

Graeme Russ graeme.russ at gmail.com
Tue May 10 06:47:28 CEST 2011


Stefan,

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
> 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




More information about the coreboot mailing list