[U-Boot] U-Boot / Coreboot integration

[Simon Glass]

Hi Graeme,

On Mon, Oct 22, 2012 at 10:16 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> As I've mentioned in my comments to several patches related to
> coreboot support in U-Boot, I would like to discuss how to formally
> support the execution of U-Boot as a coreboot payload.
>
> Looking at the code in arch/x86/cpu/coreboot, I think the cleanest
> approach will be to move the coreboot code into arch/x86/lib/. We
> could either prefix coreboot related source files with cb_ or create a
> coreboot directory under arch/x86/lib (there would be no reason not to
> pull in the coreboot lib through the existing lib/Makefile)

Sounds good.

>
> Every x86 board would then have it's own board config file which
> define CONFIG_X86_COREBOOT. As discussed previously
> CONFIG_X86_COREBOOT should result in the exclusion of all 16-bit code

OK.

>
> The next item to discuss is the passing of data from coreboot to
> U-Boot (and ultimately to Linux) including:
>  - Physical memory map (E820)
>  - List of initialised devices
>  - Pointer to the coreboot filesystem (or multiple pointers if
> multiple such filesystems exist)
>  - etc.
>
> I know you have mentioned that coreboot has data structure used to
> maintain such data and that this will be preferred in future over FTD.
> Considering that U-Boot already has extensive FDT support, I'm loath
> to add yet another data passing mechanism. Add to this rumours I have
> heard that FDT support is 'coming to an x86 kernel near you', I think
> FDT is the most appropriate way forward.

Well I'm a bit of a fan of FDT so no argument there. It's just that we
don't really control Coreboot - they can do what they like and at the
moment they really don't see the point of FDT in Coreboot. It already
has a similar facility. I suppose if Coreboot boots the x86 kernel
directly, and the x86 kernel starts using FDT, then that would have to
change, but for now that is the state of things. But we can certainly
create an FDT in U-Boot (perhaps using the tables of info from
coreboot) and pass it to the kernel.

I certainly don't propose to pass coreboot tables to the kernel as is.

>
> Last but not least, we need to have a closer look at how coreboot
> loads and launches U-Boot. I can't say for sure, but I am assuming
> U-Boot is built to some fixed RAM address (0xfc0000) and U-Boot
> relocates based on memory information passed by U-Boot. What I would
> like to see is one of two possible approaches implemented:
>  1) Have coreboot load U-Boot to the final RAM location
>  2) If U-Boot is stored in cbfs as a single linear chunk, execute
> U-Boot in-place from cbfs
>
> Both of these will eliminate a redundant memory copy. If option 1) is
> chosen, we have two sub-options:
>  1) Tweak U-Boot's relocation code for x86 to allow relocation from an
> arbitrary load address (al-la how the Linux kernel works)
>  2) Have coreboot perform the relocation adjustments
>
> I think sub-option 1) is probably the way to go

We can certainly instruct Coreboot to load U-Boot wherever it likes.
But I believe we need to relocate U-Boot to the top of memory (isn't
that just a requirement of U-Boot on all archs?). Your plan makes
sense to me - I agree sub-option 1 is good.

On the patches side, I have another series ready to go, so will send
it soon. Does everything look reasonable so far?

Regards,
Simon

>
> Regards,
>
> Graeme