Re: [Qemu-arm] Custom machine: Forcing initial boot address

[Peter Maydell]

On Sat, 15 Jun 2019 at 02:17, Bensch, Alexander
<address@hidden> wrote:
>
> Sensitive / Proprietary

Er, you just sent this to a public mailing list...

> I am currently trying to modify the MPS2 board to emulate an ARMv7m device I 
> am working on, as none of the included machines provide an environment close 
> enough to what I’m working on to be sufficient. I am running into an issue in 
> which I cannot get the machine to execute the bootROM from address 
> 0xFFFF0000. The specs for the specific device I have (cannot share the device 
> model, unfortunately) state that there is a control register that I assume is 
> present in all v7m chips that selects whether to boot at 0x0 or 0xFFFF0000. I 
> can also see evidence of this register being emulated in QEMU in 
> ‘target/arm/cpu.c’.

It would help if you said what the register name was! "ARMv7M" is an
architecture family, which covers some things which must
be implemented, and allows some other things to be implementation
defined. There are various CPUs that implement ARMv7M, like the
Cortex-M3. Then these CPUs can be found in SoCs (like the
stm32f205, for example), which add extra memory mapped devices
with their own registers.

>However, since there is little API documentation I have been able to find, 
>I’ve effectively been reverse-engineering QEMU to figure out what needs to be 
>set. So far, all of my attempts to modify control registers and addresses 
>directly have resulted in unexpected behavior and partial implementation of my 
>goals. I have had success in forcing the ROM to load at the desired address, 
>and with GDB I can force the PC and SP to where I want, but the IVT must be at 
>0x0 by default. I was hoping someone knew how to enable the control register 
>that sets the boot address so that the IVT can be loaded from a different 
>address.

Architecturally the vector table starts at the address
specified by the CPU's VTOR register ("Vector Table
Offset Register"). QEMU does implement this, but we
don't currently provide a mechanism for allowing an
SoC model or board model to specify a reset value for
it other than zero (because for all the boards we model
they use a zero reset value, so we didn't need it).
We do provide this mechanism for the v8M secure-banked VTOR --
this is exposed to the rest of QEMU via the "init-svtor" qdev
property, which the board can then set. So for a v7M CPU
you would need to add something similar for "init-vtor"
to set the non-secure VTOR reset value. Then the CPU
would come out of reset by loading the PC and SP from the
vector table at that address.

> I am running QEMU version 2.11.

If you're modifying QEMU you should start with a much
newer version than that. There have been a lot of M-profile
related bugfixes since then. Generally for development
of QEMU we recommend working with the head of git.

thanks
-- PMM