[PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board
Teddy Reed
teddy.reed at gmail.com
Wed Jun 8 02:32:07 AEST 2016
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. ;)
>
>>
>> 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?
Not a nit! Good catch.
>
>> +#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?
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.
>
> Cheers,
>
> Andrew
--
Teddy Reed V
More information about the openbmc
mailing list