[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