Where did host ipmi go on qemu and EVB?

[Brad Bishop]

A number of people have asked where host IPMI went on the QEMU/EVB platforms.  If this is of interest to you, read on….

Background:

- One of the goals for OpenBMC is meet the needs of a broad range of applications, where applications are servers, switches, routers, raid appliances…etc.
- Yocto provides a concept of MACHINE_FEATURES, where features somewhat abstract declarations of the hardware features supported by a board.

For a real board, like the OpenPOWER Witherspoon server, the concepts are easy to apply.  Witherspoon is a server, and it has a BT interface on it.  So it isn’t much of a leap conceptually to have this in Witherspoon.conf:

MACHINE_FEATURES += “obmc-host-ipmi-hw”

The EVBs and QEMU models are different.  Most of us (if not everyone) are working on servers, and initially it was easy to just put the same line in those board config files, so we could prototype applications like host-ipmi on those boards.

Thats fine, and you can still do so, but this is no longer the default behavior.  If you want to prototype something on one of these boards, enable the feature in your local.conf, and build images and SDKs with those features enabled.

I opted to do this because I didn’t want to show any favortism towards servers.  For something with general applicability like a Raspberry Pi or a QEMU model my view is:

1 - A machine feature that really does exist in a QEMU model or on an EVB should still be enabled by default.  For example, it makes sense that a ‘led’ machine feature could exist and be enabled by default on a Raspberry Pi, since a Raspberry Pi, regardless of the application, could have leds hooked up to it. 

2 - Machine features, like a BT interface, that don’t exist in a QEMU model or EVB should not enabled by default.  Despite this, we should strive to make feature implementations work on all the EVBs and QEMU models, as they can be enabled manually via local.conf.

-brad bishop