[U-Boot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

Hi Wolfgang

On Wed, May 11, 2011 at 4:03 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <4DC94CD4.2050904 at gmail.com> you wrote:
>>
>> So coreboot and U-Boot are a good complement to each other so bringing
>> U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the
>> politics ;)
>>  - The U-Boot source 'must' be self contained - No external libraries.
>>    Incorporating license compatible source is OK
>
> The same is probably true for coreboot.
>
>>  - coreboot payloads should be in ELF (linked to libpayload)
>
> Is this really necessary, assuming we have a self-contained payload
> that does not request any services from the tool that was used to
> start it?

Question for the coreboot guys. I think the linkage to libpayload can be
omitted, but include enough of libpayload to get to the coreboot data
structures which can tell U-Boot vital information regarding the hardware.

Also see below - If it's loading an ELF image, can't it just pass a
parameter which points to the tables?

>>  - How much of libpayload would we need to bring into U-Boot to provide
>>    bare minimal payload delivery? U-Boot already contains it's own minimal
>>    libc routines.
>
> Right.  See above - eventually such linking is not really necessary if
> the U-Boot ELF image is really self-contained.

Yes

>>  - How do we get VGA and USB keyboard support working? Do other U-Boot
>>    boards implement console on anything other than serial?
>
> Yes, we do support output on LCD and other video adapters, and we
> support input from USB keyboard (not to mentione netconsole, or
> netconsole over ethernet  over USB and similar fancy stuff).

Nice :)

>>  - Can we add relocation support to the coreboot ELF loader?
>
> Do we have to?

If we want U-Boot at top-of RAM and avoid a second memcpy then yes,
but as we know, it is not as simple as that. U-Boot relocates after it
has determined how much upper memory to reserve which isn't known until
U-Boot has enumerated it's hardware environment. Hence the reason U-Boot
will always have to suffer the penalty of the extra memcpy (the bootstrap
loader does not have enough information to reserve this memory for U-Boot)

>>  - Does coreboot relocate into RAM? If so, what is the target address? What
>>    guarantee is there that the target address is valid?
>
> Do we have to care?  I would expect that we consider both coreboot and
> U-Boot as isolated entities, each performing it's own task. Coreboot
> will initialize the RAM and load and start U-Boot, similar to what a
> first stage loader does on systems that boot from NAND.  Once U-Bootis
> running, it does so completely on its own.
>
>>  - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
>
> Is there any need for this?  Don't make things more complex than
> needed.

No, I don't think there is

>>  - Is it worth playing around with segment registers to 'relocate' U-Boot
>
> That's a U-Boot question, right?  Let's solve this independently.

Not really - If we want coreboot to place U-Boot at top-of-RAM then
coreboot would have to figure this out. But I think this is now a moot
point (see my other email)

>>  - What hardware should be initialised in coreboot and what should be
>>    initialised in U-Boot? (political question ;)
>
> No, that's a very practical; question. Coreboot should do as many of
> the x86 specific stuff as it can, and as it already does to load and
> start other payloads.  And probably not more, at least not for now.

Yes - As I mentioned in my other post, coreboot should do as much as it
needs to (and not more) to load (arbitrary) payloads. The rest should
be up to U-Boot using the U-Boot principle of initialising only what
needs to be initialised.

> I think the best way to make this undertaking a success is to make it
> as unintrusive to both involved projects as possible.

Agree

>> I think a good start would be to create a new U-Boot target which includes
>> a stripped down libpayload in the U-Boot source. This target can exclude
>
> Why would we need that?  I can understand that this may make initial
> porting and debugging easier ("early console output" etc.), but we
> should try to do without this.

Even more stripped than that - Just enough to get access to the coreboot
tables. Actually, if coreboot is launching an ELF payload, surely it
could pass a pointer to the tables as a argument to main()

>> We can start with U-Boot linked to a fixed location in RAM and skip
>> relocations then work on either extending coreboot to perform relocation
>> fixups or have U-Boot perform the fixups based on RAM information read from
>> cbtable
>
> I strongly recommend not to request changes to coreboot, and not to
> deviate from standard U-Boot methods.

Agree and Agree

> We are not re-inventing the wheel here.  We have many similar
> situations where some ROM boot loader or xload or nand_spl code or
> onenand_ipl code is loading an U-Boot image into a halfway initialized
> system, and U-Boot starts there.  I see no need to make coreboot use a
> different method.

Except the coreboot can load ELF images and if we can avoid a memcpy by
having coreboot do the relocation, we eek out that little bit more boot
speed ;)

>> P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you
>> are not on the coreboot ml, you emails will get bounced to a moderator :(
>
> I hope he is tolerant enough...

Regards,

Graeme