On Sun, May 31, 2015 at 3:59 PM, Liviu Ionescu <i...@livius.net> wrote: > >> On 01 Jun 2015, at 01:10, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> wrote: >> >> ... 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. > > 'this', 'it' are very confusing. > > you mean the cortex-m devices having ram and flash? > > I certainly don't know all existing Cortex-M devices, but I know many of > them. I did not yet encounter one without internal flash & ram. > > as for ARM docs, I don't know what you are looking for, but for me the > "System Address Map" chapter in "ARMv7-M Architecture Application Level > Reference Manual", ARM DDI 0405C, table Table B2-1 ARMv7-M Address map, is > clear enough: > > 0x00000000-0x1FFFFFFF | Code | flash or other code. Implementation can use > less, but must start this region at address 0x0. > 0x20000000-0x3FFFFFFF | SRAM | on-chip RAM. SRAM should be from base, other > kinds can be offset > ... etc > > >> 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. > > thank you for the hint, I'll check it > >> 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. > > yes, exactly this was the point, to identify the common characteristics of > various devices/boards, and define a framework to easily accommodate all of > them plus future entries, with minimal changes. > > in the first version, currently in the repository, I identified the > boards/devices of interest, and I implemented minimal inits for them, just to > see that emulation starts. > > now I started with a specific OLIMEX-H103 board and a STM32F103RB device and > I'm rewriting the inits, based on the object based framework used in the > existing devices (Stellaris and STM32F205). once I'm happy with the result, > I'll update all other devices/boards to use the new framework. >
I would stay away from Stellaris as much as possible for this framework type stuff as it is a legacy pre-qdev machine. Alistair straightened out many of the mistakes in Stellaris in the STM32F work which is a much better template for modern code. I have added your git branch to my to-review queue. I'll have a look over next few days. Regards, Peter > the core inits are in the cortexm.c file. > > for each vendor, there are two files, vendor_mcus.c and vendor_boards.c. > > the latest changes are in stm32_mcus.c (for the STM32F103RB) and > stm32_olimex.c, (for STM32-H103). > > please note that the device names match the CMSIS names. similarly for > boards, where available in CMSIS, otherwise I tried to match the names used > by the vendors. > > > regards, > > Liviu > > > >