On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu <i...@livius.net> wrote: > >> On 30 May 2015, at 12:39, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> wrote: >> >> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu <i...@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 > >
