[coreboot] Hackaton in Prague 2011

Stefan Reinauer stefan.reinauer at coreboot.org
Tue May 10 06:32:38 CEST 2011


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.

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

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.

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


Stefan




More information about the coreboot mailing list