[U-Boot] U-Boot / Coreboot integration

[Graeme Russ]

Hi Simon

On Oct 23, 2012 4:50 PM, "Simon Glass" <sjg at chromium.org> wrote:
>
> 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.

The x86 kernel doesn't yet support FDT as far as I am aware. I just want to
make sure we follow a path that won't lead to huge rework in the future. I
think I will raise it on LKML and see what is going on.

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

Ok. I'll have a look at what would be involved in implementing the.kernel
style 'relocate in place'

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

Yes, but I have not had a chance to have a close look at them (family
commitments). Let me know if you want some priority applied.

Regards,

Graeme