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

[Alistair Francis]

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.

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