[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trying to understand QOM object creation and property linking
From: |
Alex Bennée |
Subject: |
Re: Trying to understand QOM object creation and property linking |
Date: |
Wed, 05 Jan 2022 21:02:25 +0000 |
User-agent: |
mu4e 1.7.5; emacs 28.0.90 |
Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> Hi Alex,
>
> On 5/1/22 19:03, Alex Bennée wrote:
>> Hi,
>> I'm having a hell of a time trying to create a new SoC+Board model
>> from
>> scratch. The problem comes down to trying to expose some properties to
>> the underlying CPU from my board model. So I have:
<snip>
>> static void pipico_machine_init(MachineState *machine)
>> {
>> PiPicoMachineState *s = PIPICO_MACHINE(machine);
>> ...
>> MemoryRegion *system_memory = get_system_memory();
Hmm this memory is initialised by memory_region_init() so...
>> ...
>> /* initialize external Flash device */
>> memory_region_init_rom(&s->flash, NULL,
>> "pico.flash0", 256 * KiB, &error_fatal);
>> memory_region_add_subregion(system_memory, 0, &s->flash);
>> /* Setup the SOC */
>> object_initialize_child(OBJECT(machine), "soc", &s->soc, TYPE_RP2040);
>> /* link properties from machine the SoC needs */
>> object_property_set_link(OBJECT(&s->soc), "memory",
>> OBJECT(system_memory), &error_fatal);
>> sysbus_realize(SYS_BUS_DEVICE(&s->soc), &error_fatal);
>> The initialisation of the SoC is simple because I can't do much
>> until
>> things are realised:
>> static void rp2040_init(Object *obj)
>> {
>> RP2040State *s = RP2040(obj);
>> int n;
>> fprintf(stderr, "%s: %p\n", __func__, obj);
>> for (n = 0; n < RP2040_NCPUS; n++) {
>> object_initialize_child(obj, "cpu[*]", &s->armv7m[n], TYPE_ARMV7M);
>> qdev_prop_set_string(DEVICE(&s->armv7m[n]), "cpu-type",
>> ARM_CPU_TYPE_NAME("cortex-m0"));
>
> Here for each core you need to initialize a MemoryRegion container, ...
>
>> }
>> }
>> However when I get to realize the SoC itself:
>> static void rp2040_realize(DeviceState *dev, Error **errp)
>> {
>> RP2040State *s = RP2040(dev);
>> Object *obj = OBJECT(dev);
>> int n;
>> if (!s->board_memory) {
>> error_setg(errp, "%s: memory property was not set", __func__);
>> return;
>> }
>> /* initialize internal 16 KB internal ROM */
>> memory_region_init_rom(&s->rom, obj, "rp2040.rom0", 16 * KiB, errp);
>> memory_region_add_subregion(s->board_memory, 0, &s->rom);
>> /* SRAM (Main 256k bank + two 4k banks)*/
>> memory_region_init_ram(&s->sram03, obj, "rp2040.sram03", 256 * KiB,
>> errp);
>> memory_region_add_subregion(s->board_memory, RP2040_SRAM_BASE,
>> &s->sram03);
>> memory_region_init_ram(&s->sram4, obj, "rp2040.sram4", 4 * KiB,
>> errp);
>> memory_region_add_subregion(s->board_memory, RP2040_SRAM4_BASE,
>> &s->sram4);
>> memory_region_init_ram(&s->sram5, obj, "rp2040.sram5", 4 * KiB,
>> errp);
>> memory_region_add_subregion(s->board_memory, RP2040_SRAM5_BASE,
>> &s->sram5);
>> ...
>> for (n = 0; n < RP2040_NCPUS; n++) {
>> /* DeviceState *cpudev = DEVICE(&s->armv7m[i]); */
>> Object *cpuobj = OBJECT(&s->armv7m[n]);
>
> then you add the board_memory in the per-CPU container as subregion,
> ...
Can't be added as a subregion to the container...
qemu-system-arm: ../../softmmu/memory.c:2538:
memory_region_add_subregion_common: Assertion `!subregion->container' failed.
>
>> object_property_set_link(cpuobj, "memory",
>> OBJECT(&s->board_memory), errp);
>
> and finally each CPU links its container as its memory bus.
So something like:
object_property_set_link(cpuobj, "memory", OBJECT(s->cpu_mem[n]), errp);
so the CPU sees the container with whatever particular set of memory
regions you want to make visible to that CPU?
<snip>
>> Follow-up questions, does only creating the main memory aliases as
>> part
>> of the SoC make sense? My rational is most of the memory is part of the
>> SoC not the board. I assume later RP2040 based boards may have different
>> flash configs or even external memory.
>> The current (messy) state of my tree can be seen at:
>> https://gitlab.com/stsquad/qemu/-/commits/arm/picopi-rfc
>>
--
Alex Bennée
- Trying to understand QOM object creation and property linking, Alex Bennée, 2022/01/05
- Re: Trying to understand QOM object creation and property linking, Philippe Mathieu-Daudé, 2022/01/05
- Re: Trying to understand QOM object creation and property linking,
Alex Bennée <=
- Re: Trying to understand QOM object creation and property linking, Peter Maydell, 2022/01/06
- Re: Trying to understand QOM object creation and property linking, Alex Bennée, 2022/01/06
- Re: Trying to understand QOM object creation and property linking, Peter Maydell, 2022/01/06
- Re: Trying to understand QOM object creation and property linking, Alex Bennée, 2022/01/06
- Re: Trying to understand QOM object creation and property linking, Peter Maydell, 2022/01/06