[PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board

[Andrew Jeffery]

On Tue, 2016-06-07 at 09:32 -0700, Teddy Reed wrote:
> On Mon, Jun 6, 2016 at 12:52 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
> > 
> > Hey Teddy,
> > 
> > On Sun, 2016-06-05 at 21:25 -0700, Teddy Reed wrote:
> > > 
> > > The Yosemite BMC board is very similar to the Palmetto BMC. They both configure
> > > an AST2400 SoC and have rather simple device sets.
> > > 
> > > The Yosemite uses dual SPI flashes but the AST2400's memory controller, via
> > > hardware strapping, makes either a NAND, NOR, or SPI available at boot at
> > > 0x0 and 0x2000:0000. For the board emulation included here the SPIs are replaced
> > > with CFI flash to allow simple pflash configuration via the caller.
> > Have you had a look at Cédric's recent series which adds FMC/SPI flash
> > support[1]? The caller can pass two -mtdblock args, the first
> > specifying the BMC flash and the second the host. It would be handy if
> > you could cast your eyes over it in any case, and it may make sense to
> > integrate with that work rather than just get by with the pflash
> > infrastructure.
> > 
> > [1] https://lists.ozlabs.org/pipermail/openbmc/2016-May/003316.html
> I've followed them loosely, but I'll take a look and see if they work
> for my tests. If so then we don't need this new model. ;)

Well, that'll tidy things up nicely!

> +
> > > +    /* Map flash0 to FBYOSEMITE_TEXT_BASE */
> > > +    pflash0mem = sysbus_mmio_get_region(SYS_BUS_DEVICE(pflash0), 0);
> > > +    memory_region_set_readonly(pflash0mem, true);
> > > +    memory_region_init_alias(&bmc->flash0_alias, NULL,
> > > +                             "flash0.alias", pflash0mem, FBYOSEMITE_TEXT_BASE,
> > > +                             FBYOSEMITE_FLASH0_SIZE);
> > > +    memory_region_add_subregion(get_system_memory(), FBYOSEMITE_TEXT_BASE,
> > > +                                &bmc->flash0_alias);
> > > +    memory_region_set_readonly(&bmc->flash0_alias, true);
> > So having tinkered with memory aliasing in the openbmc/qemu repo and
> > likely done the wrong thing: From memory the sdk u-boot re-maps RAM to
> > 0 during boot, so is it right to fix the mapping this way? I'm not
> > across what the side-effects are if we have the wrong data here after
> > remap, but we should probably do the right thing. As an aside Cédric's
> > series is using rom_add_blob_fixed() to copy the entire mtdblock device
> > content down to zero, but to my knowledge isn't dealing with remapping
> > either. How much does it matter?
> Having the alias does matter for my tests. But I have not been testing
> the remap via the SCU. I don't mind either way, but if it's possible
> to model the remap request within the QEMU AST2400 SCU that's awesome
> and absolutely preferred.

I'll look into this shortly to see if we can dynamically remap within
the SCU. Looks like I'll need to send the patch upstream in the near
future to make it into the next release.

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/20160608/b0d47352/attachment.sig>