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

[Peter Maydell]

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.

thanks
-- PMM