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: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option
Date: Tue, 2 Jun 2015 03:32:07 -0700

On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu <address@hidden> wrote:
>
>> On 01 Jun 2015, at 01:59, 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
>
> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM 
> DDI 0403D, "ARMv7-M Architecture Reference Manual".
>
> 0x00000000-0x1FFFFFFF | Code | Typically ROM or flash memory. Memory required 
> from address 0x0 to support the vector table for system boot code on reset.
> 0x20000000-0x3FFFFFFF | SRAM | SRAM region typically used for on-chip RAM.
>

The Devil is in the "typically" which means it's not actually specced
on the processor layer. I think the case is reasonable for your
intermediate layer though with a critical mass of vendors opting into
this "typical" case.

>
> does this answer your question?
>

yes.

Regards,
Peter

> regards,
>
> Liviu
>
>



reply via email to

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