[U-Boot] U-Boot / Coreboot integration

[Simon Glass]

Hi Graeme,

On Mon, Oct 22, 2012 at 11:41 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> 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 believe it does. Perhaps I should turn it on to make sure...

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

OK. Also from my point of view, while omitting a copy is nice and
clean, it isn't a huge deal in terms of boot time.

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

Only that if there are any red flags I would like to know before continuing.

Regards,
Simon

>
> Regards,
>
> Graeme