one rom image for two boards?

[Gerd Hoffmann]

Hi,

Is it possible to build a single rom which is able to run on two
different boards?

Background: qemu recently got an emulation for a more recent chipset.
Current seabios roms detect at runtime whenever runs on the old (i440fx
+ piix4) or the new (q35 + ich9) and initializes the hardware
accordingly.  I'd like to do the same with coreboot if possible.

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.

Comments?  Suggestions?

thanks,
  Gerd

[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

[Gerd Hoffmann]

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