On Wed, May 11, 2011 at 10:11:41AM +1000, Graeme Russ wrote: > On Wed, May 11, 2011 at 4:03 AM, Wolfgang Denk <w...@denx.de> wrote: > > In message <4dc94cd4.2050...@gmail.com> you wrote: > >> - coreboot payloads should be in ELF (linked to libpayload) > > > > Is this really necessary, assuming we have a self-contained payload > > that does not request any services from the tool that was used to > > start it? > > Question for the coreboot guys. I think the linkage to libpayload can be > omitted, but include enough of libpayload to get to the coreboot data > structures which can tell U-Boot vital information regarding the hardware. > > Also see below - If it's loading an ELF image, can't it just pass a > parameter which points to the tables?
Finding and parsing the coreboot tables is trivial - SeaBIOS does it in ~170 lines of code. See coreboot_fill_map(): http://code.coreboot.org/p/seabios/source/tree/master/src/coreboot.c#L126 Note, SeaBIOS is deployed as a coreboot payload, but it does not use libpayload. [...] > >> - Can we add relocation support to the coreboot ELF loader? > > > > Do we have to? > > If we want U-Boot at top-of RAM and avoid a second memcpy then yes, > but as we know, it is not as simple as that. U-Boot relocates after it > has determined how much upper memory to reserve which isn't known until > U-Boot has enumerated it's hardware environment. Hence the reason U-Boot > will always have to suffer the penalty of the extra memcpy (the bootstrap > loader does not have enough information to reserve this memory for U-Boot) If U-Boot can already relocate itself to top-of-ram, then I'd reuse that - it can always be optimized later. Note, SeaBIOS can also relocate part of itself to high memory. (Though, SeaBIOS is pretty small, so the memcpy costs are trivial.) -Kevin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
