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

[Bensch, Alexander]

It's always fun to get in on a Monday morning and immediately realize I'm an 
idiot! Disregard the 'Sensitive / Proprietary'; that was just a complete goof 
by me when selecting the email sensitivity. Everything in my original question 
is alright to discuss.

Sorry for missing some of the details, as well. The CPU I'm currently trying to 
base my emulation off of the Cortex-M3, although I'm not actually sure whether 
the device I'm attempting to emulate is an M3 or M4. From what I've read the 
only real difference is some Thumb support and a DSP module, neither of which I 
need hopefully.

The register that I was referring to was control register 15, which in the docs 
I have is referred to simply as "CPU control register." My version of QEMU 
(which I will try updating as you suggested) refers to 'cp15.mvbar' and 
'cp15.vbar', which I have been investigating as the likely base address for 
execution.

You mention v8M. I haven't looked into that version of the arch, but could it 
be possible to execute v7M instructions on a v8M CPU? I'd like to avoid 
modifying QEMU as much as possible, so if there's any workarounds like that I'm 
receptive to them.

Thank you so much for the detailed response!

-----Original Message-----
From: Peter Maydell <address@hidden>
Sent: Monday, June 17, 2019 5:46 AM
To: Bensch, Alexander <address@hidden>
Cc: address@hidden
Subject: [EXTERNAL] Re: [Qemu-arm] Custom machine: Forcing initial boot address

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

NOTICE: This email message and all attachments transmitted with it may contain 
privileged and confidential information, and information that is protected by, 
and proprietary to, Parsons Corporation, and is intended solely for the use of 
the addressee for the specific purpose set forth in this communication. If the 
reader of this message is not the intended recipient, you are hereby notified 
that any reading, dissemination, distribution, copying, or other use of this 
message or its attachments is strictly prohibited, and you should delete this 
message and all copies and backups thereof. The recipient may not further 
distribute or use any of the information contained herein without the express 
written authorization of the sender. If you have received this message in 
error, or if you have any questions regarding the use of the proprietary 
information contained therein, please contact the sender of this message 
immediately, and the sender will provide you with further instructions.