qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Liviu Ionescu
Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option
Date: Mon, 1 Jun 2015 01:59:09 +0300

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

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]