Aims for BMC emulation in qemu

[Teddy Reed]

Wow, sorry for lagging behind in the discussion! But I love all the suggestions!

This 'hybrid' approach definitely fits my need for boot testing and
enabling rapid development for the more-dynamic userland and
non-driver tweaks of U-Boot/Linux.

If possible, and I think this is the current MO, can we use the
openbmc/qemu as staging for changes to be up-streamed?

On Tue, May 24, 2016 at 5:19 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> On Mon, 2016-05-23 at 17:21 +0200, Cédric Le Goater wrote:
>> > Any work-arounds included in the fork should have an obvious immediate
>> > benefit and a plan to phase them out, and if that's not the case then
>> > they should be rejected. If it's more work to maintain the hack than to
>> > implement an accurate model, then we should do the latter.
>>

To fit the hybrid-approach, the development board models for the SoCs
can be the machine targets for the non-accurate models. Then you have
an ast2400 target that may include some work-arounds or devices that
allow for more-rapid prototyping, as is common with devboards. This
fits with several other qemu ARM development boards too-- like the
vexpress suite.

The board-specific models, like palmetto-bmc, can be held to as
absolute of model representation as possible. For these boards, no
work-arounds should be managed/merged, IMO. This makes for healthier
and more-manageable up-streaming.

>> Are we planning to use travis to boot the generated flash image with qemu ?
>> and eventually run some tests in the guest ?
>
> That's certainly something we should be aiming for, in addition to
> something we can use to smoke test u-boot/linux as part of the hack-
> compile-test cycle. With a view of using qemu as part of CI I had a
> pull-request open against openbmc/openbmc that patched the runqemu
> scripts to integrate the palmetto-bmc machine, but Patrick had concerns
> about my approach there so the pull-request has been closed for the
> moment.
>
> I plan on taking a quick look at integration again shortly as some
> relevant patches turned up on the openembedded-core mailing list.
>

-- 
Teddy Reed V