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: Bensch, Alexander
Subject: Re: [Qemu-arm] [EXTERNAL] Re: Custom machine: Forcing initial boot address
Date: Mon, 17 Jun 2019 14:36:47 +0000

Sounds like I need to look over the documentation again. I may have 
misidentified which CPU the target device is using if cp15 is only present on 
the A series. As a side note, is there an overview for implementing a new board 
in QEMU? I've searched for a week but haven't been able to turn up anything 
comprehensive, and none of the currently existing boards seem to have followed 
any clear structure for implementation. Reference material for creating a 
device would really help me out.

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

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

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.

reply via email to

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