[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option
Date: Sun, 31 May 2015 11:45:20 -0700

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

> - 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,
> Liviu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]