Different comments from Peter Maydell regarding this issue: - https://www.mail-archive.com/qemu-devel@nongnu.org/msg683768.html
"We should be able to do this with the new 3-phase reset API : the rom loader reset should happen in phase 2, and the Arm CPU should only load the new PC and SP in phase 3." - https://www.mail-archive.com/qemu-devel@nongnu.org/msg686480.html "The expectation at the moment is that the board code should register a reset function with qemu_register_reset() which calls cpu_reset(). Relying on doing a reset in realize won't work for the case where there's a QEMU system reset, because we don't re-init/realize everything, we just call all the reset hooks. If m68k reads pc/sp from memory on reset you'll probably run into the same reset-ordering vs hw/cpu/loader.c that Arm M-profile has; we currently work around that in the arm reset function." - https://www.mail-archive.com/qemu-devel@nongnu.org/msg683856.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1881249 Title: CPU fetch from unpopulated ROM on reset Status in QEMU: New Bug description: Some architectures fetch the $PC/$SP register as vectors in memory, usually ROM. The CPU reset() handler is called before the ROM code is populated, resulting in fetching incorrect PC/SP. Architectures affected: - M68K - RX - ARM M-profile To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1881249/+subscriptions
