[coreboot] [U-Boot] U-Boot-x86 / coreboot Integration
wd at denx.de
Wed May 11 08:47:32 CEST 2011
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...
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
More information about the coreboot