Dear Graeme Russ,
In message BANLkTi=P=H+3u+03+zyVfoUkzNFC2EPY2g@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