Dear Graeme Russ, In message <BANLkTi=P=h+3u+03+zyvfoukznfc2ep...@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: w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
