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. 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 >
