Aims for BMC emulation in qemu

[Andrew Jeffery]

Hi Teddy,

On Sun, 2016-05-29 at 14:17 -0700, Teddy Reed wrote:
> 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?

Yeah, that's the plan.

> 
> 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.

This sounds good - I think we discussed this briefly on IRC in the
past. I was a bit hesitant on the former as upstream told me to pull
the machine definition out from the SoC file (fair enough), but as you
point out the vexpress machines do what you're suggesting.

A lot of the discussion was motivated by the lack of an ftgmac100 model
and whether we should integrate something like the Cadence GEM. This
has largely been resolved thanks to Cédric's latest efforts, but at
least we now have some approaches to handling approximations that we
can use in the future.

Cheers,

Andrew
-------------- 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/20160531/97ad2aed/attachment.sig>