All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board
@ 2016-06-06  4:25 Teddy Reed
  2016-06-06  7:52 ` Andrew Jeffery
  0 siblings, 1 reply; 4+ messages in thread
From: Teddy Reed @ 2016-06-06  4:25 UTC (permalink / raw)
  To: openbmc

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.

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@gmail.com>
Cc: Joel
---

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@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 */
+#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);
+
+    /* Connect flash1 */
+    dinfo = drive_get_next(IF_PFLASH);
+    pflash_register(FBYOSEMITE_FLASH1_BASE, FBYOSEMITE_FLASH1_SIZE,
+                   "fbyosemite.flash1", dinfo);
+
+    fbyosemite_bmc_binfo.kernel_filename = machine->kernel_filename;
+    fbyosemite_bmc_binfo.initrd_filename = machine->initrd_filename;
+    fbyosemite_bmc_binfo.kernel_cmdline = machine->kernel_cmdline;
+    fbyosemite_bmc_binfo.ram_size = ram_size;
+    arm_load_kernel(ARM_CPU(first_cpu), &fbyosemite_bmc_binfo);
+}
+
+static void fbyosemite_bmc_machine_init(MachineClass *mc)
+{
+    mc->desc = "OpenCompute Facebook Yosemite BMC";
+    mc->init = fbyosemite_bmc_init;
+    mc->max_cpus = 1;
+    mc->no_sdcard = 1;
+    mc->no_floppy = 1;
+    mc->no_cdrom = 1;
+    mc->no_parallel = 1;
+}
+
+DEFINE_MACHINE("fbyosemite-bmc", fbyosemite_bmc_machine_init);
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board
  2016-06-06  4:25 [PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board Teddy Reed
@ 2016-06-06  7:52 ` Andrew Jeffery
  2016-06-07 16:32   ` Teddy Reed
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Jeffery @ 2016-06-06  7:52 UTC (permalink / raw)
  To: Teddy Reed, openbmc

[-- Attachment #1: Type: text/plain, Size: 6918 bytes --]

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@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@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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board
  2016-06-06  7:52 ` Andrew Jeffery
@ 2016-06-07 16:32   ` Teddy Reed
  2016-06-08  0:24     ` Andrew Jeffery
  0 siblings, 1 reply; 4+ messages in thread
From: Teddy Reed @ 2016-06-07 16:32 UTC (permalink / raw)
  To: Andrew Jeffery; +Cc: OpenBMC Maillist

On Mon, Jun 6, 2016 at 12:52 AM, Andrew Jeffery <andrew@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@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@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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board
  2016-06-07 16:32   ` Teddy Reed
@ 2016-06-08  0:24     ` Andrew Jeffery
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Jeffery @ 2016-06-08  0:24 UTC (permalink / raw)
  To: Teddy Reed; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

On Tue, 2016-06-07 at 09:32 -0700, Teddy Reed wrote:
> On Mon, Jun 6, 2016 at 12:52 AM, Andrew Jeffery <andrew@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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-06-08  0:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-06  4:25 [PATCH qemu v2] Add OpenCompute Yosemite BMC ARM board Teddy Reed
2016-06-06  7:52 ` Andrew Jeffery
2016-06-07 16:32   ` Teddy Reed
2016-06-08  0:24     ` Andrew Jeffery

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.