[Qemu-devel] [RFC] extensions to the -m memory option

[Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

for more flexibility, in the new Cortex-M implementation I'm working on, I can overwrite the vendor defined MCU internal SRAM size by using: 

	-m sizeK

I'm trying to find a way to also overwrite the internal flash size and the first idea I had was to extend the "-m" command like:

	-m sizeK,flash=sizeK

would this be ok? 

for more readability I would prefer something like:

	--memory ram=sizeK,flash=sizeK

any other suggestions?


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Igor Mammedov]

On Fri, 29 May 2015 01:11:30 +0300
Liviu Ionescu <ilg@livius.net> wrote:

> for more flexibility, in the new Cortex-M implementation I'm working on, I can overwrite the vendor defined MCU internal SRAM size by using: 
> 
> 	-m sizeK
> 
> I'm trying to find a way to also overwrite the internal flash size and the first idea I had was to extend the "-m" command like:
> 
> 	-m sizeK,flash=sizeK
> 
> would this be ok? 
> 
> for more readability I would prefer something like:
> 
> 	--memory ram=sizeK,flash=sizeK
> 
> any other suggestions?
it looks to me like -machine option

> 
> 
> regards,
> 
> Liviu
> 
> 
> 
> 
> 

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 29/05/2015 00:11, Liviu Ionescu wrote:
> for more flexibility, in the new Cortex-M implementation I'm working on, I can overwrite the vendor defined MCU internal SRAM size by using: 
> 
> 	-m sizeK
> 
> I'm trying to find a way to also overwrite the internal flash size and the first idea I had was to extend the "-m" command like:
> 
> 	-m sizeK,flash=sizeK
> 
> would this be ok? 
> 
> for more readability I would prefer something like:
> 
> 	--memory ram=sizeK,flash=sizeK
> 
> any other suggestions?

If the flash is persistent, it should be tied to either "-pflash" (NOR)
or "-mtd" (NAND).  Just using a different image then results in resizing
the flash.

Paolo

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 29 May 2015, at 12:11, Igor Mammedov <imammedo@redhat.com> wrote:
> 
> On Fri, 29 May 2015 01:11:30 +0300
> Liviu Ionescu <ilg@livius.net> wrote:
> 
>> for more flexibility, in the new Cortex-M implementation I'm working on, I can overwrite the vendor defined MCU internal SRAM size by using: 
>> 
>> 	-m sizeK
>> 
>> I'm trying to find a way to also overwrite the internal flash size and the first idea I had was to extend the "-m" command like:
>> 
>> 	-m sizeK,flash=sizeK
>> 
>> would this be ok? 
>> 
>> for more readability I would prefer something like:
>> 
>> 	--memory ram=sizeK,flash=sizeK
>> 
>> any other suggestions?
> it looks to me like -machine option

-machine? in other words board? the ram-size is not a characteristic of the board, Cortex-M MCUs have both RAM & flash internally, so if --memory is not ok, probably ram & flash should be an extensions of --cpu?

regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 29 May 2015, at 14:08, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> 
> 
> On 29/05/2015 00:11, Liviu Ionescu wrote:
>> for more flexibility, in the new Cortex-M implementation I'm working on, I can overwrite the vendor defined MCU internal SRAM size by using: 
>> 
>> 	-m sizeK
>> 
>> I'm trying to find a way to also overwrite the internal flash size and the first idea I had was to extend the "-m" command like:
>> 
>> 	-m sizeK,flash=sizeK
>> 
>> would this be ok? 
>> 
>> for more readability I would prefer something like:
>> 
>> 	--memory ram=sizeK,flash=sizeK
>> 
>> any other suggestions?
> 
> If the flash is persistent, it should be tied to either "-pflash" (NOR)
> or "-mtd" (NAND).  Just using a different image then results in resizing
> the flash.

I did not try the resizing mechanism, but I don't think it is appropriate, one of my use cases is to start QEMU as GDB server, without any image specified on the command line, and in this case the flash size needs to be known in advance, I doubt the it can resize when the image is loaded by the GDB client.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Maydell]

On 29 May 2015 at 20:22, Liviu Ionescu <ilg@livius.net> wrote:
> -machine? in other words board? the ram-size is not a characteristic
> of the board, Cortex-M MCUs have both RAM & flash internally, so if
> --memory is not ok, probably ram & flash should be an extensions
> of --cpu?

RAM and flash size is not a property of the CPU -- the M3 itself
has no builtin memory. RAM and flash are external to the CPU and
are part of the SoC, so the CPU would be the wrong place to specify
their sizes.

-- PMM

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 29/05/2015 21:27, Liviu Ionescu wrote:
>> If the flash is persistent, it should be tied to either "-pflash"
>> (NOR) or "-mtd" (NAND).  Just using a different image then
>> results in resizing the flash.
>
> I did not try the resizing mechanism, but I don't think it is
> appropriate, one of my use cases is to start QEMU as GDB server,
> without any image specified on the command line, and in this case the
> flash size needs to be known in advance, I doubt the it can resize
> when the image is loaded by the GDB client.

You can use -drive if=mtd,snapshot=on,file=null-co://,file.size=128K to
start QEMU with a zero 128K NOR flash.

Paolo

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 29 May 2015, at 22:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 29/05/2015 21:27, Liviu Ionescu wrote:
>>> If the flash is persistent, it should be tied to either "-pflash"
>>> (NOR) or "-mtd" (NAND).  Just using a different image then
>>> results in resizing the flash.
>> 
>> I did not try the resizing mechanism, but I don't think it is
>> appropriate, one of my use cases is to start QEMU as GDB server,
>> without any image specified on the command line, and in this case the
>> flash size needs to be known in advance, I doubt the it can resize
>> when the image is loaded by the GDB client.
> 
> You can use -drive if=mtd,snapshot=on,file=null-co://,file.size=128K to
> start QEMU with a zero 128K NOR flash.

did someone else have a faint thought that:

- the above syntax might be a bit too complicated or non intuitive?

- specifying NOR flash might not be appropriate for defining the internal flash for all Cortex-M MCUs?

I know that this is mainly a linux shop, using large application processors, but perhaps we can find a simpler way to accommodate the slightly different MCU world.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 29/05/2015 22:13, Liviu Ionescu wrote:
>>> You can use -drive
>>> if=mtd,snapshot=on,file=null-co://,file.size=128K to start QEMU
>>> with a zero 128K NOR flash.
> did someone else have a faint thought that:
> 
> - the above syntax might be a bit too complicated or non intuitive?

Sure, this can be a problem.  But then in the common case I suspect you
want your flash to be non-zero at startup?

> - specifying NOR flash might not be appropriate for defining the
> internal flash for all Cortex-M MCUs?

In what sense?  Are there other kinds of flash than just NOR and NAND?
(By the way, NOR would be if=pflash; mtd is NAND.  I just picked a
random one).

Paolo

> I know that this is mainly a linux shop, using large application
> processors, but perhaps we can find a simpler way to accommodate the
> slightly different MCU world.

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 29 May 2015, at 22:32, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On 29 May 2015 at 20:22, Liviu Ionescu <ilg@livius.net> wrote:
>> -machine? in other words board? the ram-size is not a characteristic
>> of the board, Cortex-M MCUs have both RAM & flash internally, so if
>> --memory is not ok, probably ram & flash should be an extensions
>> of --cpu?
> 
> RAM and flash size is not a property of the CPU -- the M3 itself
> has no builtin memory. RAM and flash are external to the CPU and
> are part of the SoC, so the CPU would be the wrong place to specify
> their sizes.

ok, probably according to the dictionary you are right.

however, in the microcontroller world, it is usual to abuse the terms and use CPU for MCU. 

also, from a pure linguistic point of view, although microcontrollers (having plenty of memory and countless peripherals) can be considered "SoC", my understanding is that usually SoC is more appropriate for 'systems' running an operating system (most of the time linux), than to MCUs running a simple scheduler.

so for Cortex-M devices I prefer MCU to SoC; but English is not my first language, and I might be wrong.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 29 May 2015, at 23:15, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> ...  But then in the common case I suspect you want your flash to be non-zero at startup?

nope. I just want a method to adjust the size of the internal ram & flash, existing inside the MCU, sizes currently hard-wired in the QEMU definitions of a given MCU.

the point is that there are thousand of different Cortex-M MCUs, and unless we define a mechanism for QEMU to read the CMSIS xml definitions and auto-magically provide emulated devices with exactly the vendor specifications, there will always be some users in need of a MCU that is not present in QEMU, but might have a close relative already implemented, the difference between the two being in ram and/or flash size.

---

so, for such cases, where would be more appropriate to define the ram/flash sizes? -machine is definitely not the right place, -cpu seems also not appropriate, what else do we have left?


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Maydell]

On 29 May 2015 at 21:26, Liviu Ionescu <ilg@livius.net> wrote:
>> On 29 May 2015, at 22:32, Peter Maydell <peter.maydell@linaro.org> wrote:
>> RAM and flash size is not a property of the CPU -- the M3 itself
>> has no builtin memory. RAM and flash are external to the CPU and
>> are part of the SoC, so the CPU would be the wrong place to specify
>> their sizes.
>
> ok, probably according to the dictionary you are right.
>
> however, in the microcontroller world, it is usual to abuse the terms
> and use CPU for MCU.
>
> also, from a pure linguistic point of view, although microcontrollers
> (having plenty of memory and countless peripherals) can be considered
> "SoC", my understanding is that usually SoC is more appropriate for
> 'systems' running an operating system (most of the time linux), than
> to MCUs running a simple scheduler.

The important distinction is not linguistic but in how we model things.
There is a set of layers:

1) the CPU is the set of things in a Cortex-M3 (in this case),
   as defined by the technical reference manual for the processor;
   that has the registers and the MPU and so on in it
2) what I call the "SoC" and which in the microcontroller world
   is called the MCU is the bit of silicon which contains:
    * a CPU
    * various devices like a UART and others
    * probably flash, maybe RAM
3) a "board", which has the SoC/MCU chip on it, and likely
   some other chips, but perhaps none; if the RAM isn't
   built into the SoC then it's on the board

QEMU models these in layers because the hardware is in layers.
The RAM and flash are not in the Cortex-M3 in our model, because
they're not in the M3 in real life either.

"SoC" just means "system on chip", ie "one chip, with a CPU
and enough devices on it to be a more-or-less complete system".
(You don't need an SoC for a system in theory, you could build
one with a separate CPU and devices all on their own chips, but
in practice ARM CPUs tend to come in SoCs.) Whether you call it
an SoC or an MCU, the key point is that there's a level of
abstraction, a container, between the CPU itself and the board.
That's where the RAM and flash usually live and that's where
the properties to control their size probably belong.

-- PMM

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 30 May 2015, at 00:40, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> ... Whether you call it
> an SoC or an MCU, the key point is that there's a level of
> abstraction, a container, between the CPU itself and the board.
> That's where the RAM and flash usually live and that's where
> the properties to control their size probably belong.

ok, great, thank you for clarifying things.

however the question remains: in this nicely layered model, what command line options would be more appropriate to overwrite the MCU hard-wired ram/flash sizes?

as I already mentioned in the original post, right now my implementation uses "-m sizeK", but this configures only the ram size, and I would need something for the flash size too.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 30 May 2015, at 00:40, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> ... Whether you call it
>> an SoC or an MCU, the key point is that there's a level of
>> abstraction, a container, between the CPU itself and the board.
>> That's where the RAM and flash usually live and that's where
>> the properties to control their size probably belong.
>
> ok, great, thank you for clarifying things.
>
> however the question remains: in this nicely layered model, what command line options would be more appropriate to overwrite the MCU hard-wired ram/flash sizes?
>

Make it a property of the SoC container and then just use -global?

Regards,
Peter

> as I already mentioned in the original post, right now my implementation uses "-m sizeK", but this configures only the ram size, and I would need something for the flash size too.
>
>
> regards,
>
> Liviu
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Fri, May 29, 2015 at 4:08 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 29/05/2015 00:11, Liviu Ionescu wrote:
>> for more flexibility, in the new Cortex-M implementation I'm working on, I can overwrite the vendor defined MCU internal SRAM size by using:
>>
>>       -m sizeK
>>
>> I'm trying to find a way to also overwrite the internal flash size and the first idea I had was to extend the "-m" command like:
>>
>>       -m sizeK,flash=sizeK
>>
>> would this be ok?
>>
>> for more readability I would prefer something like:
>>
>>       --memory ram=sizeK,flash=sizeK
>>
>> any other suggestions?
>
> If the flash is persistent, it should be tied to either "-pflash" (NOR)
> or "-mtd" (NAND).  Just using a different image then results in resizing
> the flash.
>

Does it? From what I can see the NAND model inits a specific part as
instructed by the board with a fixed size. As the part is self
identifying to the system via jedec code the guest is going to assume
this is a very specifically sized part regardless of what size block
image is really behind it. I think the same is true of NOR. I know
that SD cards do however change size to the guest the way you
describe.

Using -pflash or -mtd for persistance support is a good idea but I
dont think it works for this resizing problem in general. I think this
a property on the SoC layer. This flash seems to be heavily integrated
into the SoC and transparently has a memory mapped interface.

Regards,
Peter

> Paolo
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 30/05/2015 11:55, Peter Crosthwaite wrote:
> I think the same is true of NOR.

NOR is sized according to the capacity of its backing file, at least in
the PC case.

Paolo

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Sat, May 30, 2015 at 3:32 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 30/05/2015 11:55, Peter Crosthwaite wrote:
>> I think the same is true of NOR.
>
> NOR is sized according to the capacity of its backing file, at least in
> the PC case.
>

So that might be the exception to the rule. I assume that is this (pc_sysfw.c):

        snprintf(name, sizeof name, "system.flash%d", unit);
        system_flash = pflash_cfi01_register(phys_addr, NULL /* qdev */, name,
                                             size, blk, sector_size,
                                             size >> sector_bits,
                                             1      /* width */,
                                             0x0000 /* id0 */,
                                             0x0000 /* id1 */,
                                             0x0000 /* id2 */,
                                             0x0000 /* id3 */,
                                             0      /* be */);

This ID fields are 0'd out and a generic flash is created matching the
blk dev geometry. So this does what you says it does.

A bit of grepping around, there are a good number of embedded boards
(ARM is heavily represented) where the board specifies the flash
specifically. Here is one for versatilepb:

hw/arm/versatilepb.c:#define VERSATILE_FLASH_SIZE (64 * 1024 * 1024)

hw/arm/versatilepb.c:    if
(!pflash_cfi01_register(VERSATILE_FLASH_ADDR, NULL, "versatile.flash",
hw/arm/versatilepb.c-                          VERSATILE_FLASH_SIZE,
hw/arm/versatilepb.c-                          dinfo ?
blk_by_legacy_dinfo(dinfo) : NULL,
hw/arm/versatilepb.c-                          VERSATILE_FLASH_SECT_SIZE,
hw/arm/versatilepb.c-                          VERSATILE_FLASH_SIZE /
VERSATILE_FLASH_SECT_SIZE,
hw/arm/versatilepb.c-                          4, 0x0089, 0x0018,
0x0000, 0x0, 0)) {

Vexpress does something very similar but using QOM setters instead.
The IDs are set to something very specific indicating a chosen part
rather than a generic pflash.

Consequently we have the mixed semantic of blk sometimes dictating the
device size and other times not. For ARM, it is generally the not
case.

Regards,
Peter

> Paolo
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 30 May 2015, at 12:39, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <ilg@livius.net> wrote:
>> however the question remains: in this nicely layered model, what command line options would be more appropriate to overwrite the MCU hard-wired ram/flash sizes?
>> 
> 
> Make it a property of the SoC container and then just use -global?

I followed your advice and I ended up with the following:

- I added a new type "cortexm-mcu" that I use as parent for all Cortex-M MCU objects (like "STM32F103RB")

- I added the following properties to this type:

	cortexm-mcu.flash-sizeK=uint32
	cortexm-mcu.ram-sizeK=uint32
	cortexm-mcu.cpu-model=str
	cortexm-mcu.kernel-filename=str

I can set the memory sizes with --global:

	--global cortexm-mcu.flash-sizeK=123
	--global cortexm-mcu.ram-sizeK=45

and the result looks like:

	GNU ARM Eclipse 64-bits QEMU v2.3.50 (qemu-system-gnuarmeclipse).
	Board: 'STM32-H103' (Olimex Header Board for STM32F103RBT6 (Experimental)).
	Device: 'STM32F103RB' (Cortex-M3, MPU), Flash: 123 KB, RAM: 45 KB.

without the --global definitions, the result looks like:

	Device: 'STM32F103RB' (Cortex-M3, MPU), Flash: 128 KB, RAM: 20 KB.


so the configuration is effective and the result is as expected.


the only minor disadvantage is that the command line gets a bit too long, but, given the flexibility to add any properties, this shouldn't be a problem.


q: does this fit into the general qemu configuration mechanism?


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 30 May 2015, at 12:39, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>
>> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <ilg@livius.net> wrote:
>>> however the question remains: in this nicely layered model, what command line options would be more appropriate to overwrite the MCU hard-wired ram/flash sizes?
>>>
>>
>> Make it a property of the SoC container and then just use -global?
>
> I followed your advice and I ended up with the following:
>
> - I added a new type "cortexm-mcu" that I use as parent for all Cortex-M MCU objects (like "STM32F103RB")
>

Is this a documented abstraction common to all cortex-M
implementations (is it in ARM documentation?) or is it specific to
STMxxxxx. Or is it an undocumented common practice across multiple
vendors?

> - I added the following properties to this type:
>
>         cortexm-mcu.flash-sizeK=uint32
>         cortexm-mcu.ram-sizeK=uint32
>         cortexm-mcu.cpu-model=str
>         cortexm-mcu.kernel-filename=str
>
> I can set the memory sizes with --global:
>
>         --global cortexm-mcu.flash-sizeK=123
>         --global cortexm-mcu.ram-sizeK=45
>
> and the result looks like:
>
>         GNU ARM Eclipse 64-bits QEMU v2.3.50 (qemu-system-gnuarmeclipse).
>         Board: 'STM32-H103' (Olimex Header Board for STM32F103RBT6 (Experimental)).
>         Device: 'STM32F103RB' (Cortex-M3, MPU), Flash: 123 KB, RAM: 45 KB.
>
> without the --global definitions, the result looks like:
>
>         Device: 'STM32F103RB' (Cortex-M3, MPU), Flash: 128 KB, RAM: 20 KB.
>
>
> so the configuration is effective and the result is as expected.
>
>
> the only minor disadvantage is that the command line gets a bit too long, but, given the flexibility to add any properties, this shouldn't be a problem.
>
>
> q: does this fit into the general qemu configuration mechanism?
>

yes and no :).

RE the user interface, at least for ARM boards this generally not the
taken approach. QEMU is supposed to implement fixed boards using -M.
That is, the interface is:

qemu-system-arm -M some-board-name

Is "olimex" your board? That would mean:

qemu-system-arm -M olimex

And it should get everything right.

Now for the "yes" part :)

If there is a generic abstraction layer that defines this concept of
"there is a flash and ram in the SoC at this location" then the QOM
property can exist as a legitimate change without worrying bout UI or
-global. It will be needed for correct implementation of multiple
boards anyway. That is, rather than setting your props using -global,
the multiple boards will set them. You can always as a hack take a
know board (are you using Alistairs board?) and do -global to change
these particulars.

Regards,
Peter

>
> regards,
>
> Liviu
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 31 May 2015, at 21:45, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu <ilg@livius.net> wrote:
>> 
>>> On 30 May 2015, at 12:39, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>> 
>>> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <ilg@livius.net> wrote:
>>>> however the question remains: in this nicely layered model, what command line options would be more appropriate to overwrite the MCU hard-wired ram/flash sizes?
>>>> 
>>> 
>>> Make it a property of the SoC container and then just use -global?
>> 
>> I followed your advice and I ended up with the following:
>> 
>> - I added a new type "cortexm-mcu" that I use as parent for all Cortex-M MCU objects (like "STM32F103RB")
>> 
> 
> Is this a documented abstraction common to all cortex-M
> implementations (is it in ARM documentation?) or is it specific to
> STMxxxxx. Or is it an undocumented common practice across multiple
> vendors?

sorry, I don't understand your question.

yes, cortex-m devices have internal flash and ram, and this is not a STM only feature.

> ..., rather than setting your props using -global,
> the multiple boards will set them. You can always as a hack take a
> know board (are you using Alistairs board?) and do -global to change
> these particulars.

no, I'm not using Alistair's board, but I used it as a model.

in my branch I already have definitions for the following boards, and their MCUs:

Supported machines are:
EK-TM4C123GXL        TI Tiva C Series TM4C123GXL LaunchPad Evaluation Kit (Experimental)
FRDM-K20D50M         Freescale Freedom Development Platform for Kinetis K20 USB MCUs (Experimental)
FRDM-K22F            Freescale Freedom Development Platform for Kinetis K22 MCUs (Experimental)
FRDM-K64F            Freescale Freedom Development Platform for Kinetis K6[34] and K24 MCUs (Experimental)
FRDM-KL25Z           Freescale Freedom Development Platform for Kinetis KL[12][45] MCUs (Experimental)
FRDM-KL26Z           Freescale Freedom Development Platform for Kinetis KL[12]6 MCUs (Experimental)
FRDM-KL43Z           Freescale Freedom Development Platform for Kinetis KL[34]3, KL[12]7 MCUs (Experimental)
FRDM-KL46Z           Freescale Freedom Development Platform for Kinetis KL[34]x MCUs (Experimental)
LPCXpresso-LPC1769   Embedded Artists LPCXpresso LPC1769 Development Board (Experimental)
Mapple               LeafLab Arduino-style STM32 microcontroller board (Experimental)
NUCLEO-F103RB        ST Nucleo Development Board for STM32 F1 series (Experimental)
NUCLEO-F334R8        ST Nucleo Development Board for STM32 F3 series (Experimental)
NUCLEO-F411RE        ST Nucleo Development Board for STM32 F4 series (Experimental)
NUCLEO-L152RE        ST Nucleo Development Board with STM32L152RET6 (Experimental)
Netduino2            Netduino Development Board with STM32F2 (Experimental)
NetduinoGo           Netduino GoBus Development Board with STM32F4 (Experimental)
NetduinoPlus2        Netduino Development Board with STM32F4 (Experimental)
OLIMEXINO-STM32      Olimex Mapple (Arduino-like) Development Board (Experimental)
SAM3-H256            Olimex Header Board for ATSAM3S4BA (Experimental)
STM32-E407           Olimex Development Board for STM32F407ZGT6 (Experimental)
STM32-H103           Olimex Header Board for STM32F103RBT6 (Experimental)
STM32-P103           Olimex Prototype Board for STM32F103RBT6 (Experimental)
STM32-P107           Olimex Prototype Board for STM32F107VCT6 (Experimental)
STM32F0-Discovery    ST Discovery kit for STM32F051 line (Experimental)
STM32F3-Discovery    ST Discovery kit for STM32F303 line (Experimental)
STM32F4-Discovery    ST Discovery kit for STM32F407/417 lines (Experimental)
STM32F429I-Discovery ST Discovery kit for STM32F429/439 lines (Experimental)
STM32VL-Discovery    ST Discovery kit for STM32F100 Value Line (Experimental)
TWR-K60F120M         Freescale Kinetis K60 120 MHz Tower System Module (Experimental)
XMC 2Go              Infineon XMC 2Go Kit with XMC1100 (Experimental)
XMC1100 Boot Kit     Infineon CPU Card XMC1100 Boot Kit Entry Series (Experimental)
XMC1200 Boot Kit     Infineon CPU Card XMC1200 Boot Kit Feature Series (Experimental)
XMC1300 Boot Kit     Infineon CPU Card XMC1300 Boot Kit Control Series (Experimental)
XMC4200 Enterprise Kit Infineon CPU Board XMC4200 Actuator (Experimental)
XMC4400 Enterprise Kit Infineon CPU Board XMC4400 General Purpose (Experimental)
XMC4500 Enterprise Kit Infineon CPU Board XMC4500 General Purpose (Experimental)
XMC4500 Relax Kit    Infineon CPU Board XMC4500 Relax Kit (Experimental)
XMC4500 Relax Lite Kit Infineon CPU Board XMC4500 Relax Lite Kit (Experimental)

> ... QEMU is supposed to implement fixed boards using -M.

yes, I am aware of this, but in the cortex-m world this simply does not scale, there are too many different variants of the same mcu, and too many boards.

it is not realistic to imagine that all the mcu variants will ever be emulated as separate boards.

so, for some cases, referring to one existing board/mcu and slightly adjusting the flash/ram sizes might provide a temporary solution.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Sun, May 31, 2015 at 1:59 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 31 May 2015, at 21:45, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>
>> On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu <ilg@livius.net> wrote:
>>>
>>>> On 30 May 2015, at 12:39, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>>>
>>>> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <ilg@livius.net> wrote:
>>>>> however the question remains: in this nicely layered model, what command line options would be more appropriate to overwrite the MCU hard-wired ram/flash sizes?
>>>>>
>>>>
>>>> Make it a property of the SoC container and then just use -global?
>>>
>>> I followed your advice and I ended up with the following:
>>>
>>> - I added a new type "cortexm-mcu" that I use as parent for all Cortex-M MCU objects (like "STM32F103RB")
>>>
>>
>> Is this a documented abstraction common to all cortex-M
>> implementations (is it in ARM documentation?) or is it specific to
>> STMxxxxx. Or is it an undocumented common practice across multiple
>> vendors?
>
> sorry, I don't understand your question.
>
> yes, cortex-m devices have internal flash and ram, and this is not a STM only feature.
>

So based on PMMs earlier reply on this thread, this is not specced by
cortex-m profile. So an abstraction containing an M3 processor, flash
and ram is more of a "6 manfactures do it this way so lets make an
abstraction for it" rather than it being documented somewhere. If
there is an ARM doc specifying this (separate from ARM ARM M profile
doc) then let me know, cause this will very easily justify the change
you just made. That said, a critical mass of manufacturers doing the
same thing may also justify this in its own right.

>> ..., rather than setting your props using -global,
>> the multiple boards will set them. You can always as a hack take a
>> know board (are you using Alistairs board?) and do -global to change
>> these particulars.
>
> no, I'm not using Alistair's board, but I used it as a model.
>
> in my branch I already have definitions for the following boards, and their MCUs:
>
> Supported machines are:
> EK-TM4C123GXL        TI Tiva C Series TM4C123GXL LaunchPad Evaluation Kit (Experimental)
> FRDM-K20D50M         Freescale Freedom Development Platform for Kinetis K20 USB MCUs (Experimental)
> FRDM-K22F            Freescale Freedom Development Platform for Kinetis K22 MCUs (Experimental)
> FRDM-K64F            Freescale Freedom Development Platform for Kinetis K6[34] and K24 MCUs (Experimental)
> FRDM-KL25Z           Freescale Freedom Development Platform for Kinetis KL[12][45] MCUs (Experimental)
> FRDM-KL26Z           Freescale Freedom Development Platform for Kinetis KL[12]6 MCUs (Experimental)
> FRDM-KL43Z           Freescale Freedom Development Platform for Kinetis KL[34]3, KL[12]7 MCUs (Experimental)
> FRDM-KL46Z           Freescale Freedom Development Platform for Kinetis KL[34]x MCUs (Experimental)
> LPCXpresso-LPC1769   Embedded Artists LPCXpresso LPC1769 Development Board (Experimental)
> Mapple               LeafLab Arduino-style STM32 microcontroller board (Experimental)
> NUCLEO-F103RB        ST Nucleo Development Board for STM32 F1 series (Experimental)
> NUCLEO-F334R8        ST Nucleo Development Board for STM32 F3 series (Experimental)
> NUCLEO-F411RE        ST Nucleo Development Board for STM32 F4 series (Experimental)
> NUCLEO-L152RE        ST Nucleo Development Board with STM32L152RET6 (Experimental)
> Netduino2            Netduino Development Board with STM32F2 (Experimental)
> NetduinoGo           Netduino GoBus Development Board with STM32F4 (Experimental)
> NetduinoPlus2        Netduino Development Board with STM32F4 (Experimental)
> OLIMEXINO-STM32      Olimex Mapple (Arduino-like) Development Board (Experimental)
> SAM3-H256            Olimex Header Board for ATSAM3S4BA (Experimental)
> STM32-E407           Olimex Development Board for STM32F407ZGT6 (Experimental)
> STM32-H103           Olimex Header Board for STM32F103RBT6 (Experimental)
> STM32-P103           Olimex Prototype Board for STM32F103RBT6 (Experimental)
> STM32-P107           Olimex Prototype Board for STM32F107VCT6 (Experimental)
> STM32F0-Discovery    ST Discovery kit for STM32F051 line (Experimental)
> STM32F3-Discovery    ST Discovery kit for STM32F303 line (Experimental)
> STM32F4-Discovery    ST Discovery kit for STM32F407/417 lines (Experimental)
> STM32F429I-Discovery ST Discovery kit for STM32F429/439 lines (Experimental)
> STM32VL-Discovery    ST Discovery kit for STM32F100 Value Line (Experimental)
> TWR-K60F120M         Freescale Kinetis K60 120 MHz Tower System Module (Experimental)
> XMC 2Go              Infineon XMC 2Go Kit with XMC1100 (Experimental)
> XMC1100 Boot Kit     Infineon CPU Card XMC1100 Boot Kit Entry Series (Experimental)
> XMC1200 Boot Kit     Infineon CPU Card XMC1200 Boot Kit Feature Series (Experimental)
> XMC1300 Boot Kit     Infineon CPU Card XMC1300 Boot Kit Control Series (Experimental)
> XMC4200 Enterprise Kit Infineon CPU Board XMC4200 Actuator (Experimental)
> XMC4400 Enterprise Kit Infineon CPU Board XMC4400 General Purpose (Experimental)
> XMC4500 Enterprise Kit Infineon CPU Board XMC4500 General Purpose (Experimental)
> XMC4500 Relax Kit    Infineon CPU Board XMC4500 Relax Kit (Experimental)
> XMC4500 Relax Lite Kit Infineon CPU Board XMC4500 Relax Lite Kit (Experimental)
>
>> ... QEMU is supposed to implement fixed boards using -M.
>
> yes, I am aware of this, but in the cortex-m world this simply does not scale, there are too many different variants of the same mcu, and too many boards.
>
> it is not realistic to imagine that all the mcu variants will ever be emulated as separate boards.
>

With a bit of tabulation you may be able to pull this off. Check
hw/block/m25p80.c for an example of creating a large number for QOM
device models via tabular parameterisation. This is likely to work for
the MCU variation. As for the boards, there seems to be some families
with only minor variation. I assume the FRDMs are all similar to each
other and the NUCLEOs. So you can create one parameterisable machine
model for each major board familiy then have a data driven type
registration to do 5 or 6 at once.

> so, for some cases, referring to one existing board/mcu and slightly adjusting the flash/ram sizes might provide a temporary solution.
>

Yes. -global can do this for you once you have the RAM size parameterisation.

I think we are getting close to the point where we need to see some
WIP code to get a better idea. Want to send what you have so far as an
RFC patchset?

Regards,
Peter

>
> regards,
>
> Liviu
>
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> I think we are getting close to the point where we need to see some
> WIP code to get a better idea. Want to send what you have so far as an
> RFC patchset?

my branch is publicly available from SourceForge (https://sourceforge.net/p/gnuarmeclipse/qemu/ci/gnuarmeclipse-dev/tree/), but I'm still working/polishing the code structure, so I would prefer delaying sending patches for now.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

> -----Original Message-----
> From: Liviu Ionescu [mailto:ilg@livius.net]
> Sent: Sunday, May 31, 2015 3:24 PM
> To: Peter Crosthwaite
> Cc: Peter Maydell; Igor Mammedov; QEMU Developers; Alistair Francis
> Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option
>
>
> > On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> wrote:
> >
> > I think we are getting close to the point where we need to see some
> > WIP code to get a better idea. Want to send what you have so far as an
> > RFC patchset?
>
> my branch is publicly available from SourceForge
> (https://sourceforge.net/p/gnuarmeclipse/qemu/ci/gnuarmeclipse-dev/tree/),

I got 404d on that.

Do you have a github or a git url + branch name?

Regards,
Peter

> but I'm still working/polishing the code structure, so I would prefer delaying
> sending patches for now.
>
>
> regards,
>
> Liviu



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 01:27, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
>> my branch is publicly available from SourceForge
>> (https://sourceforge.net/p/gnuarmeclipse/qemu/ci/gnuarmeclipse-dev/tree/),
> 
> I got 404d on that.

hmmm... SourceForge is less and less reliable...

> Do you have a github or a git url + branch name?

git://git.code.sf.net/p/gnuarmeclipse/qemu

gnuarmeclipse-dev


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> ... If
> there is an ARM doc specifying this (separate from ARM ARM M profile
> doc) then let me know, cause this will very easily justify the change
> you just made. That said, a critical mass of manufacturers doing the
> same thing may also justify this in its own right.

'this', 'it' are very confusing.

you mean the cortex-m devices having ram and flash?

I certainly don't know all existing Cortex-M devices, but I know many of them. I did not yet encounter one without internal flash & ram.

as for ARM docs, I don't know what you are looking for, but for me the "System Address Map" chapter in "ARMv7-M Architecture Application Level Reference Manual", ARM DDI 0405C, table Table B2-1 ARMv7-M Address map, is clear enough:

0x00000000-0x1FFFFFFF | Code | flash or other code. Implementation can use less, but must start this region at address 0x0.
0x20000000-0x3FFFFFFF | SRAM | on-chip RAM. SRAM should be from base, other kinds can be offset
... etc


> With a bit of tabulation you may be able to pull this off. Check
> hw/block/m25p80.c for an example of creating a large number for QOM
> device models via tabular parameterisation.

thank you for the hint, I'll check it

> This is likely to work for
> the MCU variation. As for the boards, there seems to be some families
> with only minor variation. I assume the FRDMs are all similar to each
> other and the NUCLEOs. So you can create one parameterisable machine
> model for each major board familiy then have a data driven type
> registration to do 5 or 6 at once.

yes, exactly this was the point, to identify the common characteristics of various devices/boards, and define a framework to easily accommodate all of them plus future entries, with minimal changes.

in the first version, currently in the repository, I identified the boards/devices of interest, and I implemented minimal inits for them, just to see that emulation starts.

now I started with a specific OLIMEX-H103 board and a STM32F103RB device and I'm rewriting the inits, based on the object based framework used in the existing devices (Stellaris and STM32F205). once I'm happy with the result, I'll update all other devices/boards to use the new framework.

the core inits are in the cortexm.c file.

for each vendor, there are two files, vendor_mcus.c and vendor_boards.c.

the latest changes are in stm32_mcus.c (for the STM32F103RB) and stm32_olimex.c, (for STM32-H103).

please note that the device names match the CMSIS names. similarly for boards, where available in CMSIS, otherwise I tried to match the names used by the vendors.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Sun, May 31, 2015 at 3:59 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>
>> ... If
>> there is an ARM doc specifying this (separate from ARM ARM M profile
>> doc) then let me know, cause this will very easily justify the change
>> you just made. That said, a critical mass of manufacturers doing the
>> same thing may also justify this in its own right.
>
> 'this', 'it' are very confusing.
>
> you mean the cortex-m devices having ram and flash?
>
> I certainly don't know all existing Cortex-M devices, but I know many of them. I did not yet encounter one without internal flash & ram.
>
> as for ARM docs, I don't know what you are looking for, but for me the "System Address Map" chapter in "ARMv7-M Architecture Application Level Reference Manual", ARM DDI 0405C, table Table B2-1 ARMv7-M Address map, is clear enough:
>
> 0x00000000-0x1FFFFFFF | Code | flash or other code. Implementation can use less, but must start this region at address 0x0.
> 0x20000000-0x3FFFFFFF | SRAM | on-chip RAM. SRAM should be from base, other kinds can be offset
> ... etc
>
>
>> With a bit of tabulation you may be able to pull this off. Check
>> hw/block/m25p80.c for an example of creating a large number for QOM
>> device models via tabular parameterisation.
>
> thank you for the hint, I'll check it
>
>> This is likely to work for
>> the MCU variation. As for the boards, there seems to be some families
>> with only minor variation. I assume the FRDMs are all similar to each
>> other and the NUCLEOs. So you can create one parameterisable machine
>> model for each major board familiy then have a data driven type
>> registration to do 5 or 6 at once.
>
> yes, exactly this was the point, to identify the common characteristics of various devices/boards, and define a framework to easily accommodate all of them plus future entries, with minimal changes.
>
> in the first version, currently in the repository, I identified the boards/devices of interest, and I implemented minimal inits for them, just to see that emulation starts.
>
> now I started with a specific OLIMEX-H103 board and a STM32F103RB device and I'm rewriting the inits, based on the object based framework used in the existing devices (Stellaris and STM32F205). once I'm happy with the result, I'll update all other devices/boards to use the new framework.
>

I would stay away from Stellaris as much as possible for this
framework type stuff as it is a legacy pre-qdev machine. Alistair
straightened out many of the mistakes in Stellaris in the STM32F work
which is a much better template for modern code.

I have added your git branch to my to-review queue. I'll have a look
over next few days.

Regards,
Peter

> the core inits are in the cortexm.c file.
>
> for each vendor, there are two files, vendor_mcus.c and vendor_boards.c.
>
> the latest changes are in stm32_mcus.c (for the STM32F103RB) and stm32_olimex.c, (for STM32-H103).
>
> please note that the device names match the CMSIS names. similarly for boards, where available in CMSIS, otherwise I tried to match the names used by the vendors.
>
>
> regards,
>
> Liviu
>
>
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 02:44, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> ... I would stay away from Stellaris as much as possible for this
> framework type stuff as it is a legacy pre-qdev machine.

ok

> Alistair
> straightened out many of the mistakes in Stellaris in the STM32F work
> which is a much better template for modern code.

yes, I noticed that, my current work is transitioning to this template.

> I have added your git branch to my to-review queue. I'll have a look
> over next few days.

thank you, any comments/suggestions are highly appreciated, but, again, as it is now, it is preliminary work, only STM32-H103 and STM32F103RB were partly updated.

I'll let you know in a few days when a more polished version will be available.


regards,

Liviu


p.s. my repository also includes a relatively up-to-date copy of the official master branch, so if you have a graphical tool (I use SourceTree on my Mac), you can easily compare the gnuarmeclipse-dev branch with master and spot the differences.

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Sun, May 31, 2015 at 5:14 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 01 Jun 2015, at 02:44, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>
>> ... I would stay away from Stellaris as much as possible for this
>> framework type stuff as it is a legacy pre-qdev machine.
>
> ok
>
>> Alistair
>> straightened out many of the mistakes in Stellaris in the STM32F work
>> which is a much better template for modern code.
>
> yes, I noticed that, my current work is transitioning to this template.
>
>> I have added your git branch to my to-review queue. I'll have a look
>> over next few days.
>
> thank you, any comments/suggestions are highly appreciated, but, again, as it is now, it is preliminary work, only STM32-H103 and STM32F103RB were partly updated.
>
> I'll let you know in a few days when a more polished version will be available.
>
>
> regards,
>
> Liviu
>
>
> p.s. my repository also includes a relatively up-to-date copy of the official master branch, so if you have a graphical tool (I use SourceTree on my Mac), you can easily compare the gnuarmeclipse-dev branch with master and spot the differences.
>

So FWIW, to see a developers' changes relative to whatever fork-point
they used, do this (bash):

git diff $(git merge-base target-branch master) target-branch

Where master is mainline and target-branch is what you are reviewing
(could be a branch, SHA1 or tag etc).

It will also work with difftool if you have that configured for a
differ of preference (such as this SourceTree tool?).

Regards,
Peter

>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 05:26, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> .... to see a developers' changes ... do this (bash):
> 
> git diff $(git merge-base target-branch master) target-branch

:-)

I was a 'unix typist' for more than 25 years, now I'm getting old and getting lazy. in 2009 I switched to Macs and since then I prefer the nice OS X graphical tools. SourceTree (by Atlassian, https://www.sourcetreeapp.com) is one of them (highly recommended). otherwise I use Eclipse (for which I started to write plug-ins, like the GNU ARM Eclipse plug-ins).

anyway, thank you for the hint. 

Liviu


p.s. just curious, anyone else using graphical IDEs for QEMU development? if so, which one? 

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 31/05/2015 16:05, Liviu Ionescu wrote:
> I followed your advice and I ended up with the following:
> 
> - I added a new type "cortexm-mcu" that I use as parent for all Cortex-M MCU objects (like "STM32F103RB")
> 
> - I added the following properties to this type:
> 
> 	cortexm-mcu.flash-sizeK=uint32

This should be okay, though more on this below.

> 	cortexm-mcu.ram-sizeK=uint32

This is the same as "-m", thus probably unnecessary, but I understand
that the megabyte default unit in -m can be a bit annoying for you.
However, there were patches on the list to set a different default for
each machine.

> 	cortexm-mcu.cpu-model=str

This is the same as "-cpu"

> 	cortexm-mcu.kernel-filename=str

This is the same as "-kernel" i.e. "-machine kernel=str".

Regarding flash, I'm still curious about some questions I have...

1) who initializes flash contents?

2) can the running program modify flash at run-time?  if so, how?  and
if so, are the writes supposed to stick around from one QEMU invocation
to the next?

Paolo

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 10:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> Regarding flash, I'm still curious about some questions I have...
> 
> 1) who initializes flash contents?

the flash region is created with 

memory_region_init_ram()
memory_region_set_readonly()

so it behaves like ram, but prevents writes.

if -kernel is present, the memory content is loaded from the external image (which is not at all a kernel, as the confusing option implies).

if -kernel is not used, but -gdb is used, memory content is loaded by the gdb client, as for any debug session using a jtag/swd.

> 2) can the running program modify flash at run-time?  if so, how?

sure, using vendor specific procedures; each mcu family has a flash control interface.

>  and
> if so, are the writes supposed to stick around from one QEMU invocation
> to the next?

that would be useful for testing bootloaders, but it is not yet implemented.

I guess a command line option to define the path to a file where the flash content will be saved to/loaded from would do the trick.


---

for those not familiar with Cortex-M devices, the major use cases for emulating them that I consider are:

1 - as target for debug sessions, replacing a physical board connected via jtag/swd; the 'flash' is written on each debug session, via gdb client commands, passed to qemu in gdb server mode. the 'GNU ARM Eclipse QEMU' plug-in does just that, behaving exactly like the J-Link plug-in or the OpenOCD plug-in. this is generally an interactive session, under user control.

the desired integration with GNU ARM Eclipse requires the QEMU emulation of Cortex-M devices to fully support the CMSIS startup code (generally setting the PLL clocks), and one GPIO port for blinking a LED. this will provide a convenient test environment for the projects generated by the GNU ARM Eclipse C/C++ wizards, which generate simple 'blinky' projects. for a nice feedback, the emulator should display a picture of the board, and the LED to turn on and off as a square saturated colour area in the actual LED location.

2 - as a convenient platform for running unit tests; in this case the .elf is loaded via -kernel, full semihosting is enabled, and argv[] are passed to the application; the result of the test is an exit code and an .xml with details about each test case. this is generally a scripted session, running under a continuous integration server, like Hudson/Jenkins, and requires a convenient way to pass semihosting arguments to the application. (the current implementation using the '-semihosting-config arg=' syntax is NOT designed with this kind of ease of use in mind, it is too complicated, it requires a wrapper to pack the arguments, and encourages inconsistent use for arm/mips targets).

3 - as you noticed, there are other use cases, like testing bootloaders, but they are less frequent.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 01/06/2015 10:30, Liviu Ionescu wrote:
> if -kernel is present, the memory content is loaded from the external image (which is not at all a kernel, as the confusing option implies).

In this case, you should use -pflash, not -kernel; it should be a binary
file, not ELF.  -pflash does not have a confusing option
name. :)

> if -kernel is not used, but -gdb is used, memory content is loaded by the gdb client, as for any debug session using a jtag/swd.

This can simply be the case where -pflash is not specified.  The flash
is then initialized with zeros.  This is the case where you need to
specify the size.

Assuming this is usually driven from an external program, I honestly do
not find file.size=128K,file=null-co://,snapshot=on too bad, but I
understand how you see that differently.

>> are the writes supposed to stick around from one QEMU invocation to the next?
> 
> that would be useful for testing bootloaders, but it is not yet implemented.

-pflash would give you this for free.

Paolo

> 1 - as target for debug sessions, replacing a physical board connected
> via jtag/swd; the 'flash' is written on each debug session, via gdb
> client commands, passed to qemu in gdb server mode. the 'GNU ARM Eclipse
> QEMU' plug-in does just that, behaving exactly like the J-Link plug-in
> or the OpenOCD plug-in. this is generally an interactive session, under
> user control.
> 
> the desired integration with GNU ARM Eclipse requires the QEMU
> emulation of Cortex-M devices to fully support the CMSIS startup code
> (generally setting the PLL clocks), and one GPIO port for blinking a
> LED. this will provide a convenient test environment for the projects
> generated by the GNU ARM Eclipse C/C++ wizards, which generate simple
> 'blinky' projects. for a nice feedback, the emulator should display a
> picture of the board, and the LED to turn on and off as a square
> saturated colour area in the actual LED location.
> 
> 2 - as a convenient platform for running unit tests; in this case the
> .elf is loaded via -kernel, full semihosting is enabled, and argv[] are
> passed to the application; the result of the test is an exit code and an
> .xml with details about each test case. this is generally a scripted
> session, running under a continuous integration server, like
> Hudson/Jenkins, and requires a convenient way to pass semihosting
> arguments to the application. (the current implementation using the
> '-semihosting-config arg=' syntax is NOT designed with this kind of ease
> of use in mind, it is too complicated, it requires a wrapper to pack the
> arguments, and encourages inconsistent use for arm/mips targets).
> 
> 3 - as you noticed, there are other use cases, like testing
> bootloaders, but they are less frequent.

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Mon, Jun 1, 2015 at 1:53 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 01/06/2015 10:30, Liviu Ionescu wrote:
>> if -kernel is present, the memory content is loaded from the external image (which is not at all a kernel, as the confusing option implies).
>
> In this case, you should use -pflash, not -kernel; it should be a binary
> file, not ELF.  -pflash does not have a confusing option
> name. :)
>

You still want to be able to use elf using a proper elf load process
even if the target memory is a persistent flash. These micros tend to
have small memory-mapped executable flashes so from a debug and
programming model that really look and feel like RAM and should be
usable by -kernel.

If all we are worried about the name of -kernel can we give it an alias?

>> if -kernel is not used, but -gdb is used, memory content is loaded by the gdb client, as for any debug session using a jtag/swd.
>
> This can simply be the case where -pflash is not specified.  The flash
> is then initialized with zeros.  This is the case where you need to
> specify the size.
>

You should define size to match the board and part with either an
error condition or padding policy. Truncating the flash to something
smaller than the part is trap for users. Perhaps something like:

"WARNING: block device /foo/bar/blah.bin is smaller than flash for STMXXXXX"

Semi-related, I have had problems in the past with users bringing
small SD card images to QEMU and falling over because the driver only
support SDHC (requiring 2GB+ block devices to activate over SDSC).

> Assuming this is usually driven from an external program, I honestly do
> not find file.size=128K,file=null-co://,snapshot=on too bad, but I
> understand how you see that differently.
>
>>> are the writes supposed to stick around from one QEMU invocation to the next?
>>
>> that would be useful for testing bootloaders, but it is not yet implemented.
>
> -pflash would give you this for free.
>

You could support both. -plfash and -kernel, the latter trumping the
former, to emulate a JTAG blobbing in an elf to persistent flash. All
with a unified interface for loading an elf in the first place.
arm_load_kernel doesn't (or shouldn't) really care where or what type
of memory it loads to, so if told to load to the flash this should be
ok.

Use cases:

-kernel alone can load software to either RAM or flash from elf or RAW
image. Handles all build-and-debug flows
-pflash can test realistic boot from raw flash image. Useful for late
stage development image testing
neither is used when using a pure gdb flow
both is used when developing apps that interact with flash data
(include apps that are hosted on the flash itself!).

Regards,
Peter

> Paolo
>
>> 1 - as target for debug sessions, replacing a physical board connected
>> via jtag/swd; the 'flash' is written on each debug session, via gdb
>> client commands, passed to qemu in gdb server mode. the 'GNU ARM Eclipse
>> QEMU' plug-in does just that, behaving exactly like the J-Link plug-in
>> or the OpenOCD plug-in. this is generally an interactive session, under
>> user control.
>>
>> the desired integration with GNU ARM Eclipse requires the QEMU
>> emulation of Cortex-M devices to fully support the CMSIS startup code
>> (generally setting the PLL clocks), and one GPIO port for blinking a
>> LED. this will provide a convenient test environment for the projects
>> generated by the GNU ARM Eclipse C/C++ wizards, which generate simple
>> 'blinky' projects. for a nice feedback, the emulator should display a
>> picture of the board, and the LED to turn on and off as a square
>> saturated colour area in the actual LED location.
>>
>> 2 - as a convenient platform for running unit tests; in this case the
>> .elf is loaded via -kernel, full semihosting is enabled, and argv[] are
>> passed to the application; the result of the test is an exit code and an
>> .xml with details about each test case. this is generally a scripted
>> session, running under a continuous integration server, like
>> Hudson/Jenkins, and requires a convenient way to pass semihosting
>> arguments to the application. (the current implementation using the
>> '-semihosting-config arg=' syntax is NOT designed with this kind of ease
>> of use in mind, it is too complicated, it requires a wrapper to pack the
>> arguments, and encourages inconsistent use for arm/mips targets).
>>
>> 3 - as you noticed, there are other use cases, like testing
>> bootloaders, but they are less frequent.
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Maydell]

On 1 June 2015 at 10:16, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> You still want to be able to use elf using a proper elf load process
> even if the target memory is a persistent flash. These micros tend to
> have small memory-mapped executable flashes so from a debug and
> programming model that really look and feel like RAM and should be
> usable by -kernel.
>
> If all we are worried about the name of -kernel can we give it an alias?

Better still, an option that was consistently "load this ELF file"
regardless of target architecture would be nice. -kernel's semantics
vary wildly between archs and it doesn't do ELF loading on all of
them.

-- PMM

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 11:53, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> if -kernel is not used, but -gdb is used, memory content is loaded by the gdb client, as for any debug session using a jtag/swd.
> 
> This can simply be the case where -pflash is not specified.  The flash
> is then initialized with zeros.  This is the case where you need to
> specify the size.

the internal flash size is fixed and known from the device name (or explicitly overwritten by a command line option).

> Assuming this is usually driven from an external program, I honestly do
> not find file.size=128K,file=null-co://,snapshot=on too bad, but I
> understand how you see that differently.
> 
>>> are the writes supposed to stick around from one QEMU invocation to the next?
>> 
>> that would be useful for testing bootloaders, but it is not yet implemented.
> 
> -pflash would give you this for free.

ok, thank you, I'll consider it.

however, the desired behaviour is

- the -pflash specifies a file path, no need for size
- when emulation starts, if -pflash is used and the file exists, its content is loaded as initial flash content
- when emulation ends, if -pflash is used, the flash content is saved to this file
- if the gdb server is used, it must allow for some parts of the flash to be overwritten by GDB, for example the bootloader is located either in low or high memory, and the rest of the flash is reprogrammed by the debugger with each session, the bootloader (and the rest of the flash) remaining persistent between sessions.

does the existing -pflash implementation matches this expected use case? 


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Paolo Bonzini]

On 01/06/2015 11:23, Liviu Ionescu wrote:
> however, the desired behaviour is
> 
> - the -pflash specifies a file path, no need for size
> - when emulation starts, if -pflash is used and the file exists, its content is loaded as initial flash content
> - when emulation ends, if -pflash is used, the flash content is saved to this file
> - if the gdb server is used, it must allow for some parts of the flash to be overwritten by GDB, for example the bootloader is located either in low or high memory, and the rest of the flash is reprogrammed by the debugger with each session, the bootloader (and the rest of the flash) remaining persistent between sessions.
> 
> does the existing -pflash implementation matches this expected use case? 

Yes, entirely.  Saving flash content can be avoided by using "-drive
if=pflash,snapshot=on,file=...".

So it looks like you have a use for both -kernel (ELF) and -pflash (raw
image).

Paolo

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 12:16, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> If all we are worried about the name of -kernel can we give it an alias?

in my initial implementation I aliased it to --image, but I received a strong opposition on the list, for polluting the command line, and I did not insist.

I'd highly appreciate to get rid of all linux specifics for the cortex-m emulation, since they really do not apply here, and just increase the user confusion.

so I reiterate my suggestion to use "--image file".

> 
> You should define size to match the board and part with either an
> error condition or padding policy. Truncating the flash to something
> smaller than the part is trap for users. Perhaps something like:
> 
> "WARNING: block device /foo/bar/blah.bin is smaller than flash for STMXXXXX"

good point.

> You could support both. -plfash and -kernel, the latter trumping the
> former,

yes, in my view "-pflash file" must be an independent option, to provide initial content to the flash area, and to provide a persistent location where to save the memory area when emulation ends.

if, on top of it, -image (!) and/or -gdb are used to overwrite parts of the flash, this is completely unrelated.

btw, there are microcontrollers with battery backed ram areas, I guess these should be handled similarly (just that the name -pflash is no longer appropriate).

perhaps some -global properties like "device.flash_file=path", "device.persistent_ram_file=path", would be more appropriate for this.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 03:14, Liviu Ionescu <ilg@livius.net> wrote:
> 
>> I have added your git branch to my to-review queue. I'll have a look
>> over next few days.
> 
> thank you, any comments/suggestions are highly appreciated, but, again, as it is now, it is preliminary work, only STM32-H103 and STM32F103RB were partly updated.
> 
> I'll let you know in a few days when a more polished version will be available.

I just pushed a preliminary version where all STM32 MCUs and STM32 related boards use the new framework.

the STM32F103RB is functional, including SysTick.

files to check:
- hw/arm/cortexm.c
- hw/arm/stm32_mcus.c
- hw/arm/stm32_boards.c
- hw/arm/stm32_*_boards.c

- hw/arm/cortexm.h
- hw/arm/stm32.h

the boards from the other vendors (kinetis, lpc, netduino, sam, tiva, xmc) and their mcus, will be updated at a later moment.

---

my next priority is to check and extend the implementation of the System Control Space (SCS), available in armv7m_nvic.c.


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 01:59, Liviu Ionescu <ilg@livius.net> wrote:
> 
> 
>> On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> 
>> ... If
>> there is an ARM doc specifying this (separate from ARM ARM M profile
>> doc) then let me know, cause this will very easily justify the change
>> you just made. That said, a critical mass of manufacturers doing the
>> same thing may also justify this in its own right.
> 
> 'this', 'it' are very confusing.
> 
> you mean the cortex-m devices having ram and flash?
> 
> I certainly don't know all existing Cortex-M devices, but I know many of them. I did not yet encounter one without internal flash & ram.
> 
> as for ARM docs, I don't know what you are looking for, but for me the "System Address Map" chapter in "ARMv7-M Architecture Application Level Reference Manual", ARM DDI 0405C, table Table B2-1 ARMv7-M Address map, is clear enough:
> 
> 0x00000000-0x1FFFFFFF | Code | flash or other code. Implementation can use less, but must start this region at address 0x0.
> 0x20000000-0x3FFFFFFF | SRAM | on-chip RAM. SRAM should be from base, other kinds can be offset
> ... etc

similar content is also present in Table B3-1 "ARMv7-M address map", in ARM DDI 0403D, "ARMv7-M Architecture Reference Manual".

0x00000000-0x1FFFFFFF | Code | Typically ROM or flash memory. Memory required from address 0x0 to support the vector table for system boot code on reset.
0x20000000-0x3FFFFFFF | SRAM | SRAM region typically used for on-chip RAM.


does this answer your question?

regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 01 Jun 2015, at 01:59, Liviu Ionescu <ilg@livius.net> wrote:
>>
>>
>>> On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>>
>>> ... If
>>> there is an ARM doc specifying this (separate from ARM ARM M profile
>>> doc) then let me know, cause this will very easily justify the change
>>> you just made. That said, a critical mass of manufacturers doing the
>>> same thing may also justify this in its own right.
>>
>> 'this', 'it' are very confusing.
>>
>> you mean the cortex-m devices having ram and flash?
>>
>> I certainly don't know all existing Cortex-M devices, but I know many of them. I did not yet encounter one without internal flash & ram.
>>
>> as for ARM docs, I don't know what you are looking for, but for me the "System Address Map" chapter in "ARMv7-M Architecture Application Level Reference Manual", ARM DDI 0405C, table Table B2-1 ARMv7-M Address map, is clear enough:
>>
>> 0x00000000-0x1FFFFFFF | Code | flash or other code. Implementation can use less, but must start this region at address 0x0.
>> 0x20000000-0x3FFFFFFF | SRAM | on-chip RAM. SRAM should be from base, other kinds can be offset
>> ... etc
>
> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM DDI 0403D, "ARMv7-M Architecture Reference Manual".
>
> 0x00000000-0x1FFFFFFF | Code | Typically ROM or flash memory. Memory required from address 0x0 to support the vector table for system boot code on reset.
> 0x20000000-0x3FFFFFFF | SRAM | SRAM region typically used for on-chip RAM.
>

The Devil is in the "typically" which means it's not actually specced
on the processor layer. I think the case is reasonable for your
intermediate layer though with a critical mass of vendors opting into
this "typical" case.

>
> does this answer your question?
>

yes.

Regards,
Peter

> regards,
>
> Liviu
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Maydell]

On 2 June 2015 at 11:32, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu <ilg@livius.net> wrote:
>> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM DDI 0403D, "ARMv7-M Architecture Reference Manual".
>>
>> 0x00000000-0x1FFFFFFF | Code | Typically ROM or flash memory. Memory required from address 0x0 to support the vector table for system boot code on reset.
>> 0x20000000-0x3FFFFFFF | SRAM | SRAM region typically used for on-chip RAM.
>>
>
> The Devil is in the "typically" which means it's not actually specced
> on the processor layer. I think the case is reasonable for your
> intermediate layer though with a critical mass of vendors opting into
> this "typical" case.

Yep. The CPU itself (and the M profile architecture) are opinionated
about the memory map layout (much more so than A/R profile), but don't
actually insist on it, and the flash/ROM are outside the core proper.

-- PMM

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 02 Jun 2015, at 13:42, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On 2 June 2015 at 11:32, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu <ilg@livius.net> wrote:
>>> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM DDI 0403D, "ARMv7-M Architecture Reference Manual".
>>> 
>>> 0x00000000-0x1FFFFFFF | Code | Typically ROM or flash memory. Memory required from address 0x0 to support the vector table for system boot code on reset.
>>> 0x20000000-0x3FFFFFFF | SRAM | SRAM region typically used for on-chip RAM.
>>> 
>> 
>> The Devil is in the "typically" which means it's not actually specced
>> on the processor layer. I think the case is reasonable for your
>> intermediate layer though with a critical mass of vendors opting into
>> this "typical" case.
> 
> Yep. The CPU itself (and the M profile architecture) are opinionated
> about the memory map layout (much more so than A/R profile), but don't
> actually insist on it, and the flash/ROM are outside the core proper.

the  "ARMv7-M Architecture Reference Manual" does not mandate on a specific memory type ("Typically ROM or flash memory"), but when it writes "Memory required from address 0x0 to support the vector table for system boot code on reset.", my understanding is that this is a mandatory requirement.

anyway, my implementation includes a "cortexm-mcu" type, which is intended as base type for specific vendor mcu objects, and as such it includes rom and ram.

regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Tue, Jun 2, 2015 at 4:01 AM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 02 Jun 2015, at 13:42, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On 2 June 2015 at 11:32, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu <ilg@livius.net> wrote:
>>>> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM DDI 0403D, "ARMv7-M Architecture Reference Manual".
>>>>
>>>> 0x00000000-0x1FFFFFFF | Code | Typically ROM or flash memory. Memory required from address 0x0 to support the vector table for system boot code on reset.
>>>> 0x20000000-0x3FFFFFFF | SRAM | SRAM region typically used for on-chip RAM.
>>>>
>>>
>>> The Devil is in the "typically" which means it's not actually specced
>>> on the processor layer. I think the case is reasonable for your
>>> intermediate layer though with a critical mass of vendors opting into
>>> this "typical" case.
>>
>> Yep. The CPU itself (and the M profile architecture) are opinionated
>> about the memory map layout (much more so than A/R profile), but don't
>> actually insist on it, and the flash/ROM are outside the core proper.
>
> the  "ARMv7-M Architecture Reference Manual" does not mandate on a specific memory type ("Typically ROM or flash memory"), but when it writes "Memory required from address 0x0 to support the vector table for system boot code on reset.", my understanding is that this is a mandatory requirement.
>

So translated loosely this is "Something memory mapped must be at
address 0". We shouldn't make any assumptions of what on the proc
layer. It could be an external bus, a hardcoded short rom section that
trampolines the vectors somewhere else or either RAM or ROM.

> anyway, my implementation includes a "cortexm-mcu" type, which is intended as base type for specific vendor mcu objects, and as such it includes rom and ram.
>

But practical reality seems different so this solution makes sense to me so far.

Regards,
Peter

> regards,
>
> Liviu
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 23:36, Liviu Ionescu <ilg@livius.net> wrote:
> 
> ... I just pushed a preliminary version where all STM32 MCUs and STM32 related boards use the new framework.

please disregard the current version, I'm already re-working the code to be more compliant with the (quite complicated) object infrastructure.

btw, except from various other pieces of code, more or less up-to-date, is there any document explaining what is the recommended way of using these objects?

at least the confusing 'realize' mechanism is it explained somewhere?


regards,

Liviu

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Peter Crosthwaite]

On Wed, Jun 3, 2015 at 5:31 AM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 01 Jun 2015, at 23:36, Liviu Ionescu <ilg@livius.net> wrote:
>>
>> ... I just pushed a preliminary version where all STM32 MCUs and STM32 related boards use the new framework.
>
> please disregard the current version, I'm already re-working the code to be more compliant with the (quite complicated) object infrastructure.
>
> btw, except from various other pieces of code, more or less up-to-date, is there any document explaining what is the recommended way of using these objects?
>
> at least the confusing 'realize' mechanism is it explained somewhere?
>

http://wiki.qemu.org/QOMConventions

but that doesn't really cover your question.

Some of my rules of thumb.

1: For container objects, realize is often just a recursive call of
realize for the contained. It may set properties on the way. see
hw/arm/xlnx-zynqmp for a recent example.
2: Data structure creation should generally go in the init. If it
depends on a property (e.g. to size an array) then you can delay to
realize or do it in a property setter callback.
3: If it has a user visible failure path it goes in realize
4: When in doubt and if it is possible. do things in init, not realize.
5: External interface connection is usually realize (e.g. connecting a
uart or network)
6: Do not have any device state modifications in realize. A common
mistake is to put hardware reset behavior in realize (e.g. initing
registers to their reset value). Use the DeviceClass::reset callback
for this.
7: When I say init, I mean the object instance_init callback, do not
use the depracated SysBusDevice::init callback.

Regards,
Peter

>
> regards,
>
> Liviu
>
>

Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Markus Armbruster]

Copying Andreas in case he has further advice.

Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:

> On Wed, Jun 3, 2015 at 5:31 AM, Liviu Ionescu <ilg@livius.net> wrote:
>>
>>> On 01 Jun 2015, at 23:36, Liviu Ionescu <ilg@livius.net> wrote:
>>>
>>> ... I just pushed a preliminary version where all STM32 MCUs and
>>> STM32 related boards use the new framework.
>>
>> please disregard the current version, I'm already re-working the
>> code to be more compliant with the (quite complicated) object
>> infrastructure.
>>
>> btw, except from various other pieces of code, more or less
>> up-to-date, is there any document explaining what is the recommended
>> way of using these objects?
>>
>> at least the confusing 'realize' mechanism is it explained somewhere?
>>
>
> http://wiki.qemu.org/QOMConventions
>
> but that doesn't really cover your question.
>
> Some of my rules of thumb.
>
> 1: For container objects, realize is often just a recursive call of
> realize for the contained. It may set properties on the way. see
> hw/arm/xlnx-zynqmp for a recent example.
> 2: Data structure creation should generally go in the init. If it
> depends on a property (e.g. to size an array) then you can delay to
> realize or do it in a property setter callback.
> 3: If it has a user visible failure path it goes in realize
> 4: When in doubt and if it is possible. do things in init, not realize.
> 5: External interface connection is usually realize (e.g. connecting a
> uart or network)
> 6: Do not have any device state modifications in realize. A common
> mistake is to put hardware reset behavior in realize (e.g. initing
> registers to their reset value). Use the DeviceClass::reset callback
> for this.
> 7: When I say init, I mean the object instance_init callback, do not
> use the depracated SysBusDevice::init callback.