Extending runqemu/runqemu-internal with new machines

[Andrew Jeffery]

Hi all,

I'm interested in how to best extend the runqemu/runqemu-internal
scripts to add support for more specific machine types. The OpenBMC
project[1] (which uses Yocto) has been working on upstreaming support
for the Aspeed AST2400 and AST2500 SoCs[3] in the kernel and qemu, and
we'd like to run the same configuration in qemu as we do on hardware.

As it stands the qemuarm configuration runs a versatilepb machine, but
as we have more relevant machine types in upstream qemu (e.g. palmetto-
bmc) we'd like to invoke them instead.

In the OpenBMC repo we have Yocto as a subtree to which we apply
updates from upstream. Given that, it's best if we have no changes to
the subtree so that upstream patches apply without fuss. If we want to
provide additional machine types in runqemu/runqemu-internal it seems
that we cannot avoid carrying patches to the scripts, which will need
to be reworked when we apply the upstream patches.

Is there a better way to work that might avoid these issues?
Alternatively, should we start looking at reworking the
runqemu/runqemu-internal scripts such that we don't have to patch them
to support our use-case? If so, what sort of approach would the
community be happy with?

Cheers,

Andrew

[1] https://github.com/openbmc/docs#openbmc-goals
[2] https://github.com/openbmc/openbmc/
[3] http://www.aspeedtech.com/products.php?fPath=20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160517/c5ad7814/attachment.sig>