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