Hi,
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.
Which would be more or less cosmetic in the qemu case, there are no size constrains, we can make the (virtual) flash as big as needed.
Look for src/arch/x86/init/bootblock_normal.c, which switches between a "fallback" and a "normal" codepath by parsing some CMOS variable.
Ah, I see. I could probably even drop a src/arch/x86/init/bootblock_qemu.c file there which does the qemu-specific detection.
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?),
That is only half true. Initializing processor and northbridge is very qemu-specific indeed. qemu doesn't even use northbridge/intel/something.
Southbridge initialization largely works like it does on real hardware though. Thats why the attempt to simply compile two southbridge drivers into the image ...
cheers, Gerd