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

reply via email to

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