[coreboot] one rom image for two boards?

[Patrick Georgi]

Am 06.06.2013 16:44, schrieb Gerd Hoffmann:
> Is it possible to build a single rom which is able to run on two
> different boards?
 > [...]
> Drivers seem to be kicked by hardware detection (struct pci_driver), so
> it looks like simply compiling in two southbridges could work.  Tried,
> got duplicate symbols.  Hmm.
>
> There also is no obvious way to have two devicetrees and pick one of
> them at runtime.  Same with acpi tables.
We hardcode a whole lot of things in code (some, but not all of those 
things are a design decision).

I built such an image years ago, using the fallback/normal mechanism. 
fallback was one configuration, normal another.
Since then, the bootblock mechanism got refactored so in principle it's 
even easier to build such a crude multi-configuration coreboot image:

Downside: lots of duplication in the image.

Look for src/arch/x86/init/bootblock_normal.c, which switches between a 
"fallback" and a "normal" codepath by parsing some CMOS variable. You 
can adapt that to check for some hardware characteristics instead (eg. 
presence of some device on a bus that is available early - not that this 
should be an actual issue on qemu), and jump to i440fx/romstage or 
q35/romstage respectively.

Building would happen in multiple passes with multiple dotconfig files, 
of which all but the first have CONFIG_UPDATE_IMAGE enabled (so they 
work on the same coreboot.rom).

However, the question is if there's actually much configuration 
necessary that differs between the two qemu modes - the init sequence 
isn't well emulated by qemu (and why should it?), so things might just 
work with a single code path without too much fuss.


Regards,
Patrick