soc: xtensa: esp32_net:
Fixes boot sequence for esp32_net, also reflect the changes in the
esp32 ipm driver.
Signed-off-by: Felipe Neves <felipe.neves@linaro.org>
diff --git a/soc/xtensa/esp32/esp32-mp.c b/soc/xtensa/esp32/esp32-mp.c
index 4555948..ece3196 100644
--- a/soc/xtensa/esp32/esp32-mp.c
+++ b/soc/xtensa/esp32/esp32-mp.c
@@ -194,6 +194,26 @@
DPORT_APPCPU_CTRL_A |= DPORT_APPCPU_RESETTING;
DPORT_APPCPU_CTRL_A &= ~DPORT_APPCPU_RESETTING;
+
+ /* extracted from SMP LOG above, THIS IS REQUIRED FOR AMP RELIABLE
+ * OPERATION AS WELL, PLEASE DON'T touch on the dummy write below!
+ *
+ * Note that the logging done here is ACTUALLY REQUIRED FOR RELIABLE
+ * OPERATION! At least one particular board will experience spurious
+ * hangs during initialization (usually the APPCPU fails to start at
+ * all) without these calls present. It's not just time -- careful
+ * use of k_busy_wait() (and even hand-crafted timer loops using the
+ * Xtensa timer SRs directly) that duplicates the timing exactly still
+ * sees hangs. Something is happening inside the ROM UART code that
+ * magically makes the startup sequence reliable.
+ *
+ * Leave this in place until the sequence is understood better.
+ *
+ */
+ esp_rom_uart_tx_one_char('\r');
+ esp_rom_uart_tx_one_char('\r');
+ esp_rom_uart_tx_one_char('\n');
+
/* Seems weird that you set the boot address AFTER starting
* the CPU, but this is how they do it...
*/
