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 于 2024年3月6日周三 23:24写道：
> On Wed, 6 Mar 2024 at 14:33, yb liu 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
>
