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

[Peter Crosthwaite <peter.crosthwaite@xilinx.com>]

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