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

[Peter Crosthwaite]

On Sun, May 31, 2015 at 3:59 PM, Liviu Ionescu <address@hidden> wrote:
>
>> On 01 Jun 2015, at 01:10, Peter Crosthwaite <address@hidden> 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
>
>
>
>