On 5/9/11 7:18 PM, Graeme Russ wrote:
On Tue, May 10, 2011 at 11:15 AM, Peter Stugepeter@stuge.se wrote:
Graeme Russ wrote:
My point being that U-Boot needs to know about the arrangement of memory of the target board.
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution.
Why not?
a) High probablility of impacting on the U-Boot build process (you mention using lpgcc rather than gcc)
FILO uses libpayload without lpgcc (and in fact I think we should obsolete lpgcc)
b) Breaks the ethos of U-Boot being a self-contained binary image intended to be written directly to a boot Flash
No. It's just a static library. Unlike uboot, it does not do any run time relocation and linking ;-)
c) The U-Boot maintainer (Wolfgang Denk) won't allow patches that result in U-Boot relying on code external to the U-Boot git tree. All that should ever be required to build U-Boot is a pull from the U-Boot git tree and standard set of build tools (compiler and linker)
Ok, I am sure politics will get in the way at some point, but that is something that should not limit our initial design.
If you build uboot for coreboot, you will have libpayload checked out anyways. So that would not be too ugly.
However, unless we start using large portions (e.g. more than 3-4 files from libpayload) we should just copy them over and not worry. Worst case we have another target we have to fix if something in libpayload changes.
This is decided at (coreboot payload) build time.
The in-RAM location of U-Boot is dynamically determined after RAM is initialised so as to place U-Boot as high in memory as possible to allow for the maximum amount of contiuous RAM below U-Boot
What's the practical use case of this? While I see a point in having stand alone applications return, a (Linux) kernel will most likely not. At least not on x86.
This is only viable if coreboot can:
- Load U-Boot to an arbitrary memory address based on total available system RAM
- Perform the relocation fixups (which are fairly trival to imeplement - Look in u-boot's arch/x86/lib/board.c for details)
- Does not require U-Boot to be linked against libpayload (which is possibly negotiable ;)
I would rather want to renegotiate adding a linker to coreboot and do that at compile time rather than runtime. The x86 CPU provides excellent features that make such a relinking unnecessary.
Hmm, can we wrap u-boot.bin in a 'payload'
Preferably I would not add additional layers/wrappers around uboot. Boot time is precious.
My point was that coreboot has no drivers of that sort. :)
But it does have more code for hardware that U-Boot :) Typically U-Boot drivers are derived from Linux, so maybe coreboot's codebase is not going to be as helpful as I might have thought. The question is, does coreboot knows about any hardware that Linux does not?
Yes, lots of it. But Linux does not need that knowledge (and neither should uboot)
I think the code in uboot might be fine except for the lack of support for PC specific components (IDE, VGA output, PS2 input, XHCI/USB3 boot, ...)
That stuff traditionally lives in libpayload (or the payload) for us, not in coreboot. Coreboot takes care of RAM controllers, HT links, PCIe links, DMI links, etc. By the time uboot runs it can assume that all necessary devices already live on what looks like a PCI bus.
OK, so I think there are three things to really look into:
- Giving coreboot to ability to load a relocatable ELF image to an arbitrary RAM location and performing the necessary relocation fixups
Can I bribe?
- libpayload
I'd be fine with just ripping what we need for now, like this:
- Console I/O in U-Boot (porting support available in libpayload into U-Boot?)