Hi Patrick
On Tue, May 10, 2011 at 3:14 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 09.05.2011 14:18, schrieb Graeme Russ:
- Formalising the u-boot payload API. For example ELF/binary, compressed/raw, passing memory size, temporary stack location, relocation, transition from u-boot back to coreboot
compressed/raw is nothing the payload needs to concern itself with with coreboot.
Transitioning back to coreboot doesn't happen (what for?), though we have bayou which allows handling multiple payloads with proper exit semantics.
Well, I do not know the semantic architecture of coreboot :) In addition to 'boot OS and die', U-Boot has a 'standalone application' API which allows a 'payload' to be run with control returning to U-Boot. If coreboot does not have any such concept then you are right, no need to worry about returning back to coreboot
memory size is in cbtable, payloads are ELF by convention (worst case would be to objcopy a binary uboot image into ELF to use that), stack location and relocation are payload matters (ie. nothing coreboot cares about), though optional relocation support might be provided by libpayload in the not too far future.
My point being that U-Boot needs to know about the arrangement of memory of the target board. As the primary bootloader, U-Boot figures this out during SDRAM initialisation (in addition to some hard-coded board level defines in some cases). If coreboot is doing all the memory init, we need a way of telling U-Boot about the memory on the board.
The idea of adding support for relocatable ELF images to libpayload is interesting. If coreboot can load U-Boot at an appropriate target address than we can skip a memcpy and relocation fixup loop in U-Boot. Need to have a closer look at the impact of some post-relocation code such as reloading of the GDT (although off the top of my head, I don't think this will be a problem at all)
- Can u-boot piggy-back on SeaBIOS loaded by coreboot?
In the context of coreboot: why?
Again, probably a missunderstanding of coreboot on my behalf - U-Boot has a REALLY primative BIOS implementation (just enough to trick Linux into booting in an embedded environment). It is basically just some empty VGA stubs and simple e820 support. If coreboot can load SeaBIOS, U-Boot could transition to it and I could ditch all of the real-mode support from U-Boot. This could allow U-Boot to support booting of OSs that require a BIOS. For Linux, I can implement a protected mode transition from U-Boot for which we would not need to load SeaBIOS at all.
- Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
- VGA & Keyboard support - U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
How will these work in practice? Where are they initiated from?
Regards,
Graeme