[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: |
Wed, 26 Jun 2019 17:57:13 +0000 |
I finally located some device specific documentation. It turns out the SoC I am
targeting has its own bootrom header format that looks deceptively similar to
ARMv7-M. The device is actually using a Cortex-A9, and has some headers and
execution Thumb code at address 0x0 in the binary that are processed and
executed in place on ROM. I am currently working under the assumption that the
main bootrom code that gets loaded into DRAM at 0x0 is called by this Thumb
code.
There's pretty much no question that I'll need to do a custom board for this,
but I haven't been able to find any boards that bypass the built-in
mini-bootloader that QEMU uses (defined as `ArmInsnFixup bootloader[]` in
qemu-src/hw/arm/boot.c). Also, because I am unsure if this bootrom addresses
statically, I may need to find a way to execute code in place without loading
it into memory so that the execution header Thumb code can load at address 0x0
without interfering with the primary bootrom segment loading into DRAM at 0x0.
My questions, given that the previous vector issue has been resolved, are the
following:
- Is there a clean way for me to bypass the QEMU simple bootloader that loads
at address 0x0 without messing with the core ARM files? In other words, can I
do such a thing from a board class?
- Do I need to specify an MVBAR for QEMU if it appears that the device I'm
emulating does not expect that component to be loaded into memory? I believe it
may be defined in hardware, but so far documentation has not been clear.
- Can I execute code in-place in QEMU? i.e. can I provide QEMU with a Thumb
code segment and have it execute that code as if it were present on ROM?
I've tried finding answers to these questions in the QEMU source but haven’t
had much luck. Thank you again for your patience, this is all still pretty new
to me! Let me know if anything is unclear and hopefully I can clarify.
Alex Bensch
-----Original Message-----
From: Peter Maydell <address@hidden>
Sent: Monday, June 17, 2019 10:41 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 15:37, Bensch, Alexander <address@hidden> wrote:
> 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.
No, I'm afraid we don't have documentation for creating new boards.
The best advice is to look at one of the more recently added existing boards,
and follow the kinds of things that it does.
Older board models and device models tend to use styles or APIs that are
deprecated or have better approaches nowadays.
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.