On 08/11/2016 12:14 PM, Peter Maydell wrote:
> On 2 August 2016 at 18:15, Cédric Le Goater <c...@kaod.org> wrote:
>> Let's define an object class for each Aspeed SoC we support. A
>> AspeedSoCInfo struct gathers the SoC specifications which can later be
>> used by an instance of the class or by a board using the SoC.
>>
>> Signed-off-by: Cédric Le Goater <c...@kaod.org>
>
>> diff --git a/hw/arm/palmetto-bmc.c b/hw/arm/palmetto-bmc.c
>> index 4d11905cfb18..531c266d9449 100644
>> --- a/hw/arm/palmetto-bmc.c
>> +++ b/hw/arm/palmetto-bmc.c
>> @@ -22,8 +22,6 @@
>> #include "sysemu/blockdev.h"
>>
>> static struct arm_boot_info palmetto_bmc_binfo = {
>> - .loader_start = AST2400_SDRAM_BASE,
>> - .board_id = 0,
>> .nb_cpus = 1,
>> };
>>
>> @@ -61,14 +59,17 @@ static void palmetto_bmc_init_flashes(AspeedSMCState *s,
>> const char *flashtype,
>> static void palmetto_bmc_init(MachineState *machine)
>> {
>> PalmettoBMCState *bmc;
>> + AspeedSoCClass *sc;
>>
>> bmc = g_new0(PalmettoBMCState, 1);
>> - object_initialize(&bmc->soc, (sizeof(bmc->soc)), TYPE_ASPEED_SOC);
>> + object_initialize(&bmc->soc, (sizeof(bmc->soc)), "ast2400-a0");
>> object_property_add_child(OBJECT(machine), "soc", OBJECT(&bmc->soc),
>> &error_abort);
>>
>> + sc = ASPEED_SOC_GET_CLASS(&bmc->soc);
>> +
>> memory_region_allocate_system_memory(&bmc->ram, NULL, "ram", ram_size);
>> - memory_region_add_subregion(get_system_memory(), AST2400_SDRAM_BASE,
>> + memory_region_add_subregion(get_system_memory(), sc->info->sdram_base,
>> &bmc->ram);
>> object_property_add_const_link(OBJECT(&bmc->soc), "ram",
>> OBJECT(&bmc->ram),
>> &error_abort);
>> @@ -84,6 +85,9 @@ static void palmetto_bmc_init(MachineState *machine)
>> palmetto_bmc_binfo.initrd_filename = machine->initrd_filename;
>> palmetto_bmc_binfo.kernel_cmdline = machine->kernel_cmdline;
>> palmetto_bmc_binfo.ram_size = ram_size;
>> + palmetto_bmc_binfo.board_id = sc->info->silicon_rev;
>> + palmetto_bmc_binfo.loader_start = sc->info->sdram_base;
>> +
>
> This changes the behaviour from passing in the board_id
> as 0 to passing in the silicon rev. Neither of those
> things is actually a valid board ID value, which must
> be one of:
> (a) for legacy pre-device-tree boards, a value listed in
> the official database at:
> http://www.arm.linux.org.uk/developer/machines/download.php
> (b) for device-tree-only boards, -1
>
> board_id 0 means "I am an EBSA110", which this isn't,
> and your silicon rev values are completely out of range.
OK. I was not aware of this. I will request new board ids for
the ast2400 and ast2500
Thanks,
C.
> thanks
> -- PMM
>
