[coreboot] Hackaton in Prague 2011

[Graeme Russ]

Hi Patrick

On Tue, May 10, 2011 at 3:14 AM, Patrick Georgi <patrick at 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