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