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

[Wolfgang Denk]

Dear Graeme Russ,

In message <BANLkTi=P=H+3u+03+zyVfoUkzNFC2EPY2g at mail.gmail.com> you wrote:
>
> >>  - Is it worth playing around with segment registers to 'relocate' U-Boot
> >
> > That's a U-Boot question, right?  Let's solve this independently.
>
> Not really - If we want coreboot to place U-Boot at top-of-RAM then
> coreboot would have to figure this out. But I think this is now a moot
> point (see my other email)

I think we should start simple, like we do for example with NAND
booting systems.  Here we agree on a fixed load address for U-Boot,
too, so we can certainly do the same for Coreboot.

At least initially.  If somebody finds time and ressources this could
be added as an optimization later.

> >>  - 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.
>
> Yes - As I mentioned in my other post, coreboot should do as much as it
> needs to (and not more) to load (arbitrary) payloads. The rest should
> be up to U-Boot using the U-Boot principle of initialising only what
> needs to be initialised.

Yes, but we also should try to avoid duplication of code - if coreboot
already includes code to initialize things that need to be
initialized, we should use this, and not duplicate the function in
U-Boot without need.

> > 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.
>
> Except the coreboot can load ELF images and if we can avoid a memcpy by
> having coreboot do the relocation, we eek out that little bit more boot
> speed ;)

Keep things simple first, and add optimization later, when we have
everything running.  Early optimization is...

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
God runs electromagnetics by wave theory on  Monday,  Wednesday,  and
Friday,  and the Devil runs them by quantum theory on Tuesday, Thurs-
day, and Saturday.                                   -- William Bragg