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

[Peter Crosthwaite]

On Tue, Jun 2, 2015 at 4:01 AM, Liviu Ionescu <address@hidden> wrote:
>
>> On 02 Jun 2015, at 13:42, Peter Maydell <address@hidden> wrote:
>>
>> On 2 June 2015 at 11:32, Peter Crosthwaite <address@hidden> wrote:
>>> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu <address@hidden> wrote:
>>>> 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.
>>
>> Yep. The CPU itself (and the M profile architecture) are opinionated
>> about the memory map layout (much more so than A/R profile), but don't
>> actually insist on it, and the flash/ROM are outside the core proper.
>
> the  "ARMv7-M Architecture Reference Manual" does not mandate on a specific 
> memory type ("Typically ROM or flash memory"), but when it writes "Memory 
> required from address 0x0 to support the vector table for system boot code on 
> reset.", my understanding is that this is a mandatory requirement.
>

So translated loosely this is "Something memory mapped must be at
address 0". We shouldn't make any assumptions of what on the proc
layer. It could be an external bus, a hardcoded short rom section that
trampolines the vectors somewhere else or either RAM or ROM.

> anyway, my implementation includes a "cortexm-mcu" type, which is intended as 
> base type for specific vendor mcu objects, and as such it includes rom and 
> ram.
>

But practical reality seems different so this solution makes sense to me so far.

Regards,
Peter

> regards,
>
> Liviu
>
>