qemu: Question about including Facebook's Yosemite board

[Andrew Jeffery]

On Mon, 2016-05-02 at 12:06 +0930, Joel Stanley wrote:
> On Sun, May 1, 2016 at 5:57 AM, Teddy Reed <teddy.reed at gmail.com> wrote:
> > 
> > I'd like to model the Facebook Yosemite board in QEMU, which from the
> > QEMU model perspective, is almost equivalent to the Palmetto. The only
> > requirement for the board, outside of the AST2400 capabilities, is the
> > inclusion of 2 flashes.
> > 
> > Here's an example of what I mean:
> > https://github.com/theopolis/qemu/blob/bc20ef6a7a17f8424571234d4429e7e6b67f17e8/hw/arm/fbyosemite-bmc.c#L78
> Great! This is really useful.
> 
> > 
> > If you don't mind including those flash definitions in the Palmetto
> > model I can save some QEMU complexity by not adding another board
> > definition, which IMO is ideal. If that's the case, I can also submit
> > a patch to add the flashes ASAP.
> I'm torn. Similar to Andrew's work to get the GEM ethernet device
> working in the palmetto board, I'm not sure we want to add hacks to
> that don't represent the physical system. OTOH, it's nice to be able
> to boot a flash image in Qemu.

I think we need to be a bit nuanced about it to avoid throwing the baby
out with the bath water. We haven't yet modelled the flash controller,
and the hack (almost*) gives us the ability to boot the bitbake flash
output file. Regarding the GEM NIC: we have a ftgmac100 QEMU model, but
it has issues; having networking is an advantage if you consider
running automated testing[0] as part of a CI setup. It's better if the
models reflect the hardware but since they are not ready to go I think
the benefit the hack is reasonable.

We're in the right place if we're making an up-front decision about
technical debt and having a plan for paying it down. With networking we
can resolve it by fixing up the bugs in the existing (but not upstream)
ftgmac100 model, and ripping out the Cadence GEM. In the case of the
flash controller we have to write it from scratch, but we need to do
that regardless. I think what we should push back against is bad code,
which we can do with code review.

Andrew

* Should, with the DRAM-training-SCU-bit-workaround

[0] https://github.com/mkumatag/openbmc-automation