On 5/9/11 7:18 PM, Graeme Russ wrote:
On Tue, May 10, 2011 at 11:15 AM, Peter Stuge<pe...@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?)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
