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

[Wolfgang Denk]

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?

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

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

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

Do we have to?

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

>  - Is it worth playing around with segment registers to 'relocate' U-Boot

That's a U-Boot question, right?  Let's solve this independently.

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

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

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

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

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.

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...all the  good  computer  designs  are  bootlegged;  the  formally
planned  products,  if  they  are built at all, are dogs!" - David E.
Lundstrom, "A Few Good Men From Univac", MIT Press, 1987