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

[Peter Crosthwaite]

On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu <address@hidden> wrote:
>
>> On 30 May 2015, at 12:39, Peter Crosthwaite <address@hidden> wrote:
>>
>> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <address@hidden> 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
>
>