Re: [Qemu-devel] [PATCH v1 1/1] target_arm: Make the reset rom_ptr a property

[Alistair Francis]

On Thu, Aug 21, 2014 at 10:22 PM, Peter Crosthwaite
<address@hidden> wrote:
> On Thu, Aug 21, 2014 at 10:09 PM, Alistair Francis <address@hidden> wrote:
>> On Thu, Aug 21, 2014 at 7:14 PM, Peter Maydell <address@hidden> wrote:
>>> On 21 August 2014 09:35, Alistair Francis <address@hidden> wrote:
>>>> On Thu, Aug 21, 2014 at 6:01 PM, Peter Maydell <address@hidden> wrote:
>>>>> On 21 August 2014 02:36, Alistair Francis <address@hidden> wrote:
>>>>>> This allows the board to set the reset address, which is required
>>>>>> for some boards (the Netduino Plus 2 for example)
>>>>>>
>>>>>> Signed-off-by: Alistair Francis <address@hidden>
>>>>>
>>>>> This looks a bit odd -- I'm pretty sure the hardware doesn't
>>>>> get only the reset address from an IMPDEF location.
>>>>> Are you sure this board doesn't actually have an IMPDEF
>>>>> reset value for the vector table offset register VTOR?
>>>>>
>>>>> Which CPU core is this, anyway? Googling suggests
>>>>> it's a Cortex-M4, and the M4 TRM suggests that VTOR
>>>>> always resets to 0.
>>>>
>>>> I'm not sure what you mean about the IMPDEF reset value
>>>> in the VTOR. The actual board is a Netduino Plus 2, with an
>>>> STM32F405RG (which is a Cortex-M4, but I'm making do with
>>>> the M3 for the moment).
>>>
>>> Well, the underlying question is, what is the hardware actually
>>> doing, because I'm 99% certain it's not "magically use a
>>> different address only for reading the reset SP and PC and
>>> nothing else". We need to identify what the h/w behaviour
>>> is that we're not getting right, and implement that.
>>>
>>> The suggestion I was making was that one way the CPU
>>> might be reading SP/PC from something other than 0
>>> was if it took the permitted IMPDEF behaviour of having
>>> VTOR reset to something non-zero, in which case that's
>>> the address that SP/PC get read from. (I don't think the
>>> M4 does this, though, so it's probably not the right answer.)
>>>
>>>> Not sure if this helps, but to quote the datasheet:
>>>> "The Cortex ® -M4 with FPU CPU always fetches the reset
>>>> vector on the ICode bus, which implies to have the boot space
>>>> available only in the code area (typically, Flash memory)."
>>>
>>> Yes, that's standard Cortex-M* behaviour. Are you saying
>>> that this board actually maps different devices at address
>>> zero on the icode and dcode buses (so that an instruction
>>> fetch from address 0 reads different data from a data load
>>> from address 0)? That would be awkward to model for us,
>>> we assume the system design is more conventional and
>>> doesn't show the iside and the dside different views of the
>>> world.
>>>
>>> (If it is doing this, then we have problems for instruction
>>> fetch, not just for reset SP and PC loading.)
>>>
>>>> The reason this is such a problem is that the Netduino Plus 2
>>>> maps memory to 0, but the memory that is mapped there can be changed.
>>>> The actual memory mappings are in different locations, the 0 address is 
>>>> more
>>>> of a pointer.
>>>
>>> This isn't making a great deal of sense to me. If you
>>> mean that the board design allows some sort of
>>> programmable or configurable remapping of the
>>> address space, we should implement that by
>>> mapping and remapping MemoryRegions into place
>>> as appropriate, not by messing with the CPU reset.
>>
>> This is the one that I mean.
>>
>> Either Main Flash, System Flash, FSMC Bank1 or SRAM
>> are mapped to address 0 based on the value of a register.
>>
>
> What's that register? Looking through docs now.

The register is: SYSCFG_MEMRMP

>
> Regards,
> Peter
>
>> This is checked after reset or when the device exits standby.
>>
>> If trying to run any code on QEMU, it will immediately error with
>> executing code out of memory at address 0 (if compiled without
>> this change). What do you think would be the best method to
>> implement this in QEMU?
>>
>> Thanks,
>>
>> Alistair
>>
>>>
>>> thanks
>>> -- PMM
>>