On Thu, 19 Feb 2026 at 17:18, Alex Bennée <[email protected]> wrote: > > All 68k chips should be able to follow the architectural behaviour on > reset which is to load the initial sp/pc from the first 8 bytes of the > address space. > > To avoid any potential issues with un-reset memory controllers we > punt the final setting of the register to the exit phase when > everything else is guaranteed to have been through the hold phase.
Unfortunately we can't guarantee that the exit-phase of a CPU's reset happens after everybody else's hold phase, because at the moment CPUs are still reset separately to the rest of the system: typically some bit of board code calls cpu_reset() on the CPU(s) out of a qemu_register_reset() hook. qemu_register_reset() hooks get called during the "hold" phase of system reset, and if they call cpu_reset() that causes all 3 phases of the CPU object reset to happen immediately, one after the other. This is why the Arm M-profile handling of "read the PC and SP from memory" is still being done with special case handling for "maybe there's a ROM blob here which hasn't yet been copied into guest RAM" -- look for "Load the initial SP and PC" in target/arm/cpu.c. I keep meaning to have another look at this for the Arm case, but haven't got round to it yet. This could be done without opening the entire reset can of worms by switching the arm use of qemu_register_reset() to qemu_register_resettable(), which would let you get called back separately for each phase so you could invoke exactly the right CPU object reset phase. (It might be sufficient to pass the CPU object itself to qemu_register_resettable() before calling qemu_register_reset() and rely on resettables being invoked in order.) thanks -- PMM
