[U-Boot] U-Boot / Coreboot integration

[U-Boot] U-Boot / Coreboot integration

[Graeme Russ]

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)

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

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.

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

Regards,

Graeme

[U-Boot] U-Boot / Coreboot integration

[Simon Glass]

Hi Graeme,

On Mon, Oct 22, 2012 at 10:16 PM, Graeme Russ <graeme.russ@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

[U-Boot] U-Boot / Coreboot integration

[Graeme Russ]

Hi Simon

On Oct 23, 2012 4:50 PM, "Simon Glass" <sjg@chromium.org> wrote:
>
> Hi Graeme,
>
> On Mon, Oct 22, 2012 at 10:16 PM, Graeme Russ <graeme.russ@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

[U-Boot] U-Boot / Coreboot integration

[Simon Glass]

Hi Graeme,

On Mon, Oct 22, 2012 at 11:41 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Simon
>
> On Oct 23, 2012 4:50 PM, "Simon Glass" <sjg@chromium.org> wrote:
>>
>> Hi Graeme,
>>
>> On Mon, Oct 22, 2012 at 10:16 PM, Graeme Russ <graeme.russ@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

[U-Boot] U-Boot / Coreboot integration

[Graeme Russ]

Hi Simon,

On Wed, Oct 24, 2012 at 12:48 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Graeme,
>
> On Mon, Oct 22, 2012 at 11:41 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
>> Hi Simon

[snip]

>> 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 quick Google seems to confirm, but I really don't know what the
Linux kernel pulls out of the device tree for x86. For example, does
it pull out PCI Memory, I/O, and IRQ assignments?

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

Every ms counts :) And for me, life is generally easier if things
aren't jumping all over the 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.
>
> Only that if there are any red flags I would like to know before continuing.

No red flags so far. With x86 being so small (coreboot being the only
active platform) you pretty much have carte blanch over x86 :)

But as has been seen by others, be careful about breaking non-x86 builds.

Regards,

Graeme