[PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board

Andrew Jeffery andrew at aj.id.au
Mon Jun 6 17:52:14 AEST 2016


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

> 
> Additionally, to support an SPL boot where DRAM has not been calibrated, the
> board relocates global data and the stack into the small 32kB of SRAM.
> 
> Signed-off-by: Teddy Reed <teddy.reed at gmail.com>
> Cc: Joel

The tag is imcomplete or seems to have been truncated?

> ---
> 
> Changes in v2:
> - Base and size defines use FBYOSEMTIE prefix
> - Use correct pointer style
> 
>  hw/arm/Makefile.objs    |   2 +-
>  hw/arm/fbyosemite-bmc.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 116 insertions(+), 1 deletion(-)
>  create mode 100644 hw/arm/fbyosemite-bmc.c
> 
> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> index 2fcd33a..cbf5c3e 100644
> --- a/hw/arm/Makefile.objs
> +++ b/hw/arm/Makefile.objs
> @@ -16,4 +16,4 @@ obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
>  obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
>  obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
>  obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
> -obj-$(CONFIG_ASPEED_SOC) += ast2500.o ast2500-edk.o ast2400.o palmetto-bmc.o
> +obj-$(CONFIG_ASPEED_SOC) += ast2500.o ast2500-edk.o ast2400.o palmetto-bmc.o fbyosemite-bmc.o
> diff --git a/hw/arm/fbyosemite-bmc.c b/hw/arm/fbyosemite-bmc.c
> new file mode 100644
> index 0000000..f6bf738
> --- /dev/null
> +++ b/hw/arm/fbyosemite-bmc.c
> @@ -0,0 +1,115 @@
> +/*
> + * OpenCompute Facebook Yosemite BMC
> + *
> + * Teddy Reed <reed at fb.com>
> + *
> + * Copyright 2016-Present, Facebook, Inc.
> + *
> + * This code is licensed under the GPL version 2 or later.  See
> + * the COPYING file in the top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qemu-common.h"
> +#include "cpu.h"
> +#include "exec/address-spaces.h"
> +#include "hw/arm/arm.h"
> +#include "hw/arm/ast2400.h"
> +#include "hw/boards.h"
> +#include "hw/block/flash.h"
> +
> +#define FBYOSEMITE_FLASH0_BASE 0x20000000
> +#define FBYOSEMITE_FLASH0_SIZE 0x02000000 /* Max is 64k, but set 32kB */

Bit of a nit-pick, but MB not kB right?

> +#define FBYOSEMITE_FLASH1_BASE 0x24000000
> +#define FBYOSEMITE_FLASH1_SIZE 0x02000000
> +#define FBYOSEMITE_TEXT_BASE 0x0
> +
> +static struct arm_boot_info fbyosemite_bmc_binfo = {
> +    .loader_start = FBYOSEMITE_TEXT_BASE,
> +    .board_id = 0,
> +    .nb_cpus = 1,
> +};
> +
> +typedef struct FBYosemiteBMCState {
> +    AST2400State soc;
> +    MemoryRegion ram;
> +    MemoryRegion flash0_alias;
> +} FBYosemiteBMCState;
> +
> +static pflash_t *pflash_register(hwaddr base, hwaddr size, const char *name,
> +                            DriveInfo *info) {
> +    int sector_len = 128 * 1024;
> +    int be = 0;
> +    pflash_t *pf;
> +
> +    pf = pflash_cfi01_register(base, NULL, name, size,
> +                               info ? blk_by_legacy_dinfo(info) : NULL,
> +                               sector_len, size / sector_len,
> +                               2, 0, 0, 0, 0, be);
> +    if (pf == NULL) {
> +        fprintf(stderr, "qemu: Error registering flash memory.\n");
> +        exit(1);
> +    }
> +    return pf;
> +}
> +
> +static void fbyosemite_bmc_init(MachineState *machine)
> +{
> +    FBYosemiteBMCState *bmc;
> +    DriveInfo *dinfo;
> +    pflash_t *pflash0;
> +    MemoryRegion *pflash0mem;
> +
> +    bmc = g_new0(FBYosemiteBMCState, 1);
> +    object_initialize(&bmc->soc, (sizeof(bmc->soc)), TYPE_AST2400);
> +    object_property_add_child(OBJECT(machine), "soc", OBJECT(&bmc->soc),
> +                              &error_abort);
> +
> +    memory_region_allocate_system_memory(&bmc->ram, NULL, "ram", ram_size);
> +    memory_region_add_subregion(get_system_memory(), AST2400_SDRAM_BASE,
> +                                &bmc->ram);
> +    object_property_add_const_link(OBJECT(&bmc->soc), "ram", OBJECT(&bmc->ram),
> +                                   &error_abort);
> +    object_property_set_bool(OBJECT(&bmc->soc), true, "realized",
> +                             &error_abort);
> +
> +    /* Connect flash0 */
> +    dinfo = drive_get_next(IF_PFLASH);
> +    pflash0 = pflash_register(FBYOSEMITE_FLASH0_BASE, FBYOSEMITE_FLASH0_SIZE,
> +                              "fbyosemite.flash0", dinfo);
> +
> +    /* 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?

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/20160606/31c5dd37/attachment.sig>


More information about the openbmc mailing list