qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-arm] [EXTERNAL] Re: Custom machine: Forcing initial boot address
Date: Mon, 17 Jun 2019 14:36:35 +0100

On Mon, 17 Jun 2019 at 14:15, Bensch, Alexander
<address@hidden> wrote:
> 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.

MVBAR and VBAR are registers for A-profile CPUs. M-profile is
significantly different. (In particular M-profile does not
have a "cp15".) QEMU supports both, but changing things
related to A-profile will either have no effect or bad
effects on emulating an M-profile CPU.

M-profile does have a register called "CONTROL", but this
doesn't have anything related to the vector table address in it.

Is it possible this register is not part of the CPU but is
in the SoC?

I would definitely recommend if you don't have them already
getting a copy of the v7M architecture reference manual
and the Cortex-M3/M4 technical reference manuals. Then
you can cross-reference against whatever docs you have so
you can see what's actually architectural and what's
specific to the thing you're trying to emulate, and you
can use the architecture's names for things that are
architectural, which will make this conversation less
confusing :-)

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

v8M is the next version that supports (among other things)
TrustZone for M profile. You would still want to deal with
the v7M CPUs though. I mention it just because the v8M
init-svtor implementation is a useful guide to implementing
the v7M init-vtor.

> I'd like to avoid modifying QEMU as much as possible, so if there's any 
> workarounds like that I'm receptive to them.

If you are trying to get QEMU to model a board/SoC that
it does not already model, then you are inherently
looking at modifying QEMU, I'm afraid. That is the only
way to add new board models.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]