Aims for BMC emulation in qemu

[Andrew Jeffery <andrew@aj.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hey all,

There's some divide as to whether our qemu machine types should
accurately describe the hardware, or whether compromises can be made.
We've been at one extreme with the poky vexpress-based qemuarm system,
but are progressing towards machine types that are a better reflection
of the Aspeed SoCs.

Cédric, Teddy, Joel and myself have been working on modelling the SoCs'
devices but some are more complex than others. For example getting
network up and running is desirable, but the the ftgmac100 code that
exists[1] has critical bugs and isn't upstream (though we've started
fixing it[2][3]). We could use a different NIC (e.g. the Cadence GEM),
but this doesn't reflect the hardware.

So, do we compromise or not, or can we avoid the problem altogether?

Accuracy of the models is useful for kernel and u-boot development,
where you can iterate quickly on your own machine to gain confidence
before deploying to hardware (but obviously requires the models to
exist).

Alternatively, compromising on the models can allow us to accelerate
userspace development, where some of the hardware details are
abstracted. For example, it would be useful to add a network device so
the robotframework tests[4] can be run. Depending on what you are
testing, you might not care for any hardware details.

At the moment we have a palmetto-bmc machine type in upstream qemu
(2.6.0) which describes the core devices. Maybe the solution is to keep
such machine types as an accurate reflection of the hardware, and
define others that have relaxed accuracy constraints for different
circumstances. I expect we'd be maintaining a fork if we did so, but it
would evaporate over time as more models were developed.

What are your thoughts?

Andrew


[1] https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02601.html
[2] https://github.com/shenki/qemu/tree/ftgmac100
[3] https://github.com/amboar/qemu/tree/ast2400-net-ftgmac100
[4] https://github.com/mkumatag/openbmc-automation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]