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