qemu: Question about including Facebook's Yosemite board

[Teddy Reed]

On Mon, May 2, 2016 at 12:13 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
> 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.
>

Perhaps the AST2400 can emit an EVM board configuration (QEMU machine target)?

Then we will not cause derivation for the Palmetto, it wont set
precedence for adding several other "slightly different" BMC
configurations, and should facility hacking/thrashing/"evaluation". ;)

The existing ./hw/arm/ast2400.c can both create the SoC model and emit
the board, that shouldn't affect the Palmetto and will only cause 1
additional ARM machine going forward.

If this sounds cool, let me know and I'd be happy to throw up a branch
on Github that can be pulled into the openbmc/qemu repo.

> 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


-- 
Teddy Reed V