qemu-devel
[Top][All Lists]
Advanced

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

Re: QEMU Compatibility for Cortex-A55 AArch32 Firmware


From: Peter Maydell
Subject: Re: QEMU Compatibility for Cortex-A55 AArch32 Firmware
Date: Wed, 6 Mar 2024 15:24:43 +0000

On Wed, 6 Mar 2024 at 14:33, yb liu <liuyb845@gmail.com> wrote:
>
>
> Dear QEMU developers
>
> I hope this email finds you well. We are currently facing an issue related to 
> QEMU and the Cortex-A55 architecture. Specifically, we have compiled a 
> firmware for Cortex-A55 and would like it to run smoothly on QEMU A55 in 
> AArch32 mode.
>
> Despite our numerous attempts, we continue to encounter an "undefined 
> instruction" error when running the firmware in QEMU. Our question is whether 
> QEMU supports this particular use case—specifically, whether it can handle 
> A55 running AArch32 firmware.

We have Cortex-A55 emulation, but you may be running into one
of a few problems:
 * we might have a bug
 * firmware sometimes does very low level stuff that no other guest
   code does, so it might run into something we didn't get round
   to implementing (eg it is trying to touch one of the implementation
   specific system registers: we tend to implement these as "does
   nothing" stubs, but it looks like we didn't bother for the A55,
   presumably because Linux didn't care)
 * your guest code might be doing something that works on the
   real A55 hardware but which is architecturally UNPREDICTABLE:
   QEMU doesn't try to exactly match device-specific IMPDEF
   and UNPREDICTABLE things
 * your guest code might be assuming the presence of some feature
   that your real A55 has but which QEMU doesn't implement
   (for instance we implement only the absolute minimum RAS
   support required by the architecture, not the full RAS
   that hardware implements)

The thing you'd need to do is look at exactly what the UNDEF
instruction is (and what the guest code that causes it is
trying to do) to figure out which of these is the problem.
Some of these might be easy to fix; some would be harder.
If you're in a position to be able to modify the firmware
image then that would also allow you to work around missing
QEMU functionality if necessary.

The more usual reason guest firmware not working in QEMU is
not the CPU emulation itself but lack of a model of the
device/SoC/etc hardware that the firmware assumes it's
running on.

-- PMM



reply via email to

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