On Sun, May 31, 2015 at 1:59 PM, Liviu Ionescu <i...@livius.net> wrote: > >> On 31 May 2015, at 21:45, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> wrote: >> >> 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? > > 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 > > >
