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

[Peter Crosthwaite]

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.

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
>