[coreboot] Hackaton in Prague 2011

[Graeme Russ]

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)
b) Breaks the ethos of U-Boot being a self-contained binary image
   intended to be written directly to a boot Flash
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)

>
>> U-Boot is designed to be the primary bootloader much like coreboot
>> is - It is not a 'payload'.
>
> If coreboot is participating then yes, U-Boot is the (coreboot)
> payload. The idea is to leverage the shell and bootloading features
> of U-Boot, after the platform initialization in coreboot has run.
>
>
>> There is a rather special case with NAND booting where a bootstrap
>> loader loads U-Boot into RAM, but even in this case U-Boot is
>> treated like a binary blob exectuted in RAM with no real concept of
>> how it got there (i.e. no link-backs to the 'loader')
>
> Make no mistake, coreboot payloads have no link-back to the 'loader'.

I guess I need to understand what, exactly, libpayload is all about. I
get the impression that, while not a link-back to coreboot, it does
provide a set of low-level APIs (some of which provide access to data
structures created by coreboot and some to access hardware features)

> I guess this is getting a little confusing because both projects use
> the term payload to mean different things.

U-Boot does not have a 'payload' - It has a 'standalone application' which
can be invoked with control returning back to U-Boot and an OS 'image'
which, when invoked, typically results in U-Boot being 'blown away'

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

Already exists - It is the very first byte of u-boot.bin (which is a dozen
or so bytes before the entry point used by the x86 cold-reset vector code

I mentioned in an unrelated email that the U-Boot linker script needs to
be adjusted to fix the ELF entry point

>
>> 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.
>
>
>> So what would be really neat is if coreboot calculated where the final
>> in-RAM location of U-Boot needs to be,
>
> 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

>
>> copy U-Boot there,
>
> Sure thing.
>
>> do the relocation fixups
>
> But possibly not this one.
>
>> and jumps into the in-RAM copy of U-Boot.
>
> Yep.
>
>> U-Boot would then skip all it's own relocation code.
>
> ELF is the way to happiness in coreboot land. coreboot would like a
> U-Boot ELF binary and will copy it to given address in RAM and run
> it.

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

>> The other option is to not use coreboot's ELF loader and simply
>> have coreboot jump to the U-Boot binary image in Flash.
>
> Does not fit the coreboot model so well. Something could be hacked of
> course, but that's not so nice..

Hmm, can we wrap u-boot.bin in a 'payload' - In U-Boot, you create an
'image' using the mkimage tool. U-Boot images support a range of formats
including compressed/uncompress, raw/ELF etc. I suppose it is as close
to a coreboot 'payload' as you can get, but does not carry any API for
the contents of the image to use. The image content is always stand-alone
with U-Boot providing the API. Correct me if I am wrong, but it would
seem with coreboot that once the 'payload' is launched, coreboot is
gone and the only API available is what is in libpayload

>
>> This is a far simpler method, and all the code already exists in
>> U-Boot anyway - all we need to do is tell U-Boot the highest
>> available memory address.
>
> That can be read from the cbtable.

Which is only available via libpayload? - Can a link to cbtable be
provided via a reserved register (perhaps a reseved segment even)

>> > coreboot does not generally have drivers. coreboot knows how to do
>> > the init, but the payload is responsible for driving any hardware
>> > that needs to be driven.
>> >
>> > One could argue that coreboot is only a collection of CPU and chipset
>> > drivers, which so far have very few if any knobs.
>>
>> U-Boot is similar, but having a command line and shell which can
>> run scripts means that it can do a bit more with the hardware (set
>> Ethernet MAC addresses, intialise devices on I2C busses, display a
>> bitmap splash screen, toggle LEDs etc)
>
> 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?

>> > Besides using libpayload, U-Boot would also use libflashrom, to take
>> > advantage of the rich boot flash writing code that is flashrom also
>> > at boot time.
>>
>> 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.
>
>
>> With regard to VGA and keyboard support, how can we make them
>> usable in U-Boot (i.e. so the command prompt is displayed on a
>> monitor and the user can use the keyboard to enter commands?)
>
> 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. Or it can use
> libpayload, which already has console support for a few hardware
> types.

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
  - libpayload
  - Console I/O in U-Boot (porting support available in libpayload into
    U-Boot?)

Regards,

Graeme