Re: QEMU Compatibility for Cortex-A55 AArch32 Firmware

[yb liu]

Thanks a lot for you respond me soon!

The exact instruction is mrc, and the exception happended in early boot process. I have no idea to how to debug this error because it happended in code_gen_prologue.

I need to comform that whether QEMU A55 fully supports aarch32 mode. If it need me to add addition instructions to support this function, I will suspend this task for now.

I hope to get your respond as soon as possible.

Best regards!

Peter Maydell <peter.maydell@linaro.org> 于 2024年3月6日周三 23:24写道：

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