No subject

>> =A0- Can we add relocation support to the coreboot ELF loader?
>
> ELF payloads are parsed at build time, simplified into a
> coreboot-internal format. Run time relocation is not so attractive.
>
>
>> =A0- Does coreboot relocate into RAM? If so, what is the target address?
>
> Determined at build time.
>
>> =A0 =A0What guarantee is there that the target address is valid?
>
> It's low enough in RAM.
>
>
>> =A0- Could coreboot benefit from U-Boot's 'load to top of RAM' philosoph=
y?
>
> I doubt it, but maybe?
>
>
>> =A0- Is it worth playing around with segment registers to 'relocate' U-B=
oot
>
> Maybe?

On further though, probably not. The Linux protected mode entry point
requires a very specific segment setup - Using segments to 'relocate'
U-Boot is only going to make things very ugly, very quickly

>> =A0- What hardware should be initialised in coreboot and what should be
>> =A0 =A0initialised in U-Boot? (political question ;)
>
> Actually this is well defined. coreboot in general does not touch
> peripherals with VGA being the exception.

Agree - Have coreboot do the bare minimum to launch an arbitrary payload
and leave the rest up to U-Boot

>> =A0- What about Chipset Microcode (CMC)
>> =A0- What about System Management Mode (SMM)
>
> coreboot does provide the bare minimum for chipsets which need it,
> but preference is to not go beyond the busses.

Yes, I think CMC and SMM should be loaded by U-Boot. It may be
necessary for some boards to have CMC loaded by coreboot in order to
bring SDRAM controllers up

>> We can start with U-Boot linked to a fixed location in RAM and skip
>> relocations then work on either extending coreboot to perform
>> relocation fixups or have U-Boot perform the fixups based on RAM
>> information read from cbtable
>
> The latter sounds better to me. :)

But involves a double memcpy - A decision for later

>> From there, we can start to add device support (USB, video, PCI,
>> IDE/SATA etc)
>
> libpayload covers most of these. :) Take a look at a couple different
> libpayload users. FILO would probably be the closest to what U-Boot
> does.

Hmm, I'm thinking these should be implemented in U-Boot. I'm keeping
embedded x86 solutions in mind - I want to maintain the idea of U-Boot
being a primary bootloader for these systems and not rely on coreboot /
libpayload / SeaBIOS etc

Regards,

Graeme