Hi Peter and Philip, Thanks for your insight on this matter.
I am okay as long as this issue is going to be eventually fixed in one way or another; the three-phase reset scheme you mentioned does sound like a more manageable approach for this purpose; though, I still believe having the option to specify the invocation priority for reset handlers would come in handy in the future for various purposes. On 2/27/20 10:31 PM, Philippe Mathieu-Daudé wrote: > I think Alistair and myself use the 'loader' device with Cortex-M boards and > never hit this problem. I tried both `-kernel [ELF IMAGE]` and `-device loader,file=[ELF IMAGE]` without any success; in both cases, without this patch, QEMU hard-faults during start-up due to the unavailability of the vector table content at the time of CPU reset. Maybe your firmware image has a load address of 0x0 instead of 0x8000000? The following is the MAP file for the firmware image I am testing with: https://gist.github.com/stephanosio/97d1f47f962844479a76e0e909a3b8cf Regards, Stephanos
