On Thu, Aug 21, 2014 at 10:22 PM, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > On Thu, Aug 21, 2014 at 10:09 PM, Alistair Francis <alistai...@gmail.com> > wrote: >> On Thu, Aug 21, 2014 at 7:14 PM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> On 21 August 2014 09:35, Alistair Francis <alistai...@gmail.com> wrote: >>>> On Thu, Aug 21, 2014 at 6:01 PM, Peter Maydell <peter.mayd...@linaro.org> >>>> wrote: >>>>> On 21 August 2014 02:36, Alistair Francis <alistai...@gmail.com> 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 <alistai...@gmail.com> >>>>> >>>>> 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 >>
