[coreboot] Hackaton in Prague 2011

Stefan Reinauer stefan.reinauer at coreboot.org
Tue May 10 06:46:45 CEST 2011


On 5/9/11 7:18 PM, Graeme Russ wrote:
> On Tue, May 10, 2011 at 11:15 AM, Peter Stuge<peter at stuge.se>  wrote:
>> Graeme Russ wrote:
>>>>> My point being that U-Boot needs to know about the arrangement of
>>>>> memory of the target board.
>>>> Yes. The information is published by coreboot in the "coreboot table"
>>>> AKA cbtable. libpayload already has code to find it.
>>> Hmm - I don't think linking U-Boot against libpayload is the right
>>> solution.
>> Why not?
> a) High probablility of impacting on the U-Boot build process (you mention
>     using lpgcc rather than gcc)
FILO uses libpayload without lpgcc (and in fact I think we should 
obsolete lpgcc)

> b) Breaks the ethos of U-Boot being a self-contained binary image
>     intended to be written directly to a boot Flash
No. It's just a static library. Unlike uboot, it does not do any run 
time relocation and linking ;-)

> c) The U-Boot maintainer (Wolfgang Denk) won't allow patches that result
>     in U-Boot relying on code external to the U-Boot git tree. All that
>     should ever be required to build U-Boot is a pull from the U-Boot git
>     tree and standard set of build tools (compiler and linker)
Ok, I am sure politics will get in the way at some point, but that is 
something that should not limit our initial design.

If you build uboot for coreboot, you will have libpayload checked out 
anyways. So that would not be too ugly.

However, unless we start using large portions (e.g. more than 3-4 files 
from libpayload) we should just copy them over and not worry. Worst case 
we have another target we have to fix if something in libpayload changes.

>> This is decided at (coreboot payload) build time.
> The in-RAM location of U-Boot is dynamically determined after RAM is
> initialised so as to place U-Boot as high in memory as possible to allow
> for the maximum amount of contiuous RAM below U-Boot
What's the practical use case of this? While I see a point in having 
stand alone applications return, a (Linux) kernel will most likely not. 
At least not on x86.


> This is only viable if coreboot can:
>    - Load U-Boot to an arbitrary memory address based on total available
>      system RAM
>    - Perform the relocation fixups (which are fairly trival to imeplement -
>      Look in u-boot's arch/x86/lib/board.c for details)
>    - Does not require U-Boot to be linked against libpayload (which is
>      possibly negotiable ;)
I would rather want to renegotiate adding a linker to coreboot and do 
that at compile time rather than runtime. The x86 CPU provides excellent 
features that make such a relinking unnecessary.

> Hmm, can we wrap u-boot.bin in a 'payload'

Preferably I would not add additional layers/wrappers around uboot. Boot 
time is precious.

>> My point was that coreboot has no drivers of that sort. :)
> But it does have more code for hardware that U-Boot :) Typically U-Boot
> drivers are derived from Linux, so maybe coreboot's codebase is not
> going to be as helpful as I might have thought. The question is, does
> coreboot knows about any hardware that Linux does not?

Yes, lots of it. But Linux does not need that knowledge (and neither 
should uboot)

I think the code in uboot might be fine except for the lack of support 
for PC specific components (IDE, VGA output, PS2 input, XHCI/USB3 boot, ...)

That stuff traditionally lives in libpayload (or the payload) for us, 
not in coreboot. Coreboot takes care of RAM controllers, HT links, PCIe 
links, DMI links, etc. By the time uboot runs it can assume that all 
necessary devices already live on what looks like a PCI bus.


> OK, so I think there are three things to really look into:
>    - Giving coreboot to ability to load a relocatable ELF image to an
>      arbitrary RAM location and performing the necessary relocation fixups

Can I bribe?

>    - libpayload
I'd be fine with just ripping what we need for now, like this:

>    - Console I/O in U-Boot (porting support available in libpayload into
>      U-Boot?)








More information about the coreboot mailing list