About ROM0/ROM1...

[Spritetm]

FYI, I see you only dump one version of the ROM with esptool. I'm not sure if it makes any difference in the emulation, but just fyi: the version of the ROM that the 2nd CPU sees is slightly different from the one the 1st CPU sees. I think the changes are all in the 1st 64K and entirely irrelevant if you're running an esp-idf app, but if you strive for 100% emulation, you may want to take that into account.

[Ebiroll]

Thanks for the info Sprite. I dont strive for 100% emulation. I only try to emulate what the esp-idf and esp32-arduino software expects. Its more fun that way rather then reading the (boring..) technical spec. and trying to implement that. (sorry)
However, I would really like to get dual core mode to work. It works fine unless I call nvs_flash_init();
I think it is related to timing and the spi_flash_op_block_func() . Emulation ends up in deadlock for both cpus in (cpu0) while (!s_flash_op_complete) {} and (cpu1) while (!dport_access_start[cpu_id]) {};
If you think this difference in ROMS can solve this issue then I will do it.
However I think is most likely becaause of,

1. Different timing in qemu, (flash operations are too fast or incorrectly emulated).
2. Faulty qemu implementation of DPORT_REG_WRITE(DPORT_CPU_INTR_FROM_CPU_3_REG, DPORT_CPU_INTR_FROM_CPU_3); and friends.
3. There is a race condition in the esp-idf drivers
4. Your guess (better than mine)
   Anyways. Hope all is well in Shanghai and that you come visit us in Stockholm someday. I will buy you a drink. :-)