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