补充第二章 ESP32的启动过程
- 源码地址：https://github.com/HX-IoT/ESP32-Developer-Guide
- ESP32开发指南QQ群：824870185，内有pdf版，排版整洁。
目标
- 了解app_main之前ESP32干了什么
- 了解ESP32复位原因
ESP32启动总流程（原文）
ESP32开发程序中有且只能有一个app_main函数，该函数是用户程序的入口，相当于其它系统中的main函数。但在app_main之前，系统还有一段初始化的过程，其大致可以分为以下三个过程：
ROM中的第一级引导加载程序将闪存偏移0x1000的第二级引导加载程序映像加载到RAM（IRAM和DRAM）；
第二级引导程序从闪存加载分区表和主应用程序映像，主应用程序包含RAM段和通过闪存缓存映射的只读段；
主应用程序执行，此时可以启动第二个CPU和RTOS调度程序。
ESP32启动详细过程（可以不看了）
第一阶段
系统first-stage bootload启动，对于系统的first-stage bootloader，其主要任务是负责从Flash的地址0X1000开始加载bootloader镜像到RAM中。此工程源码在esp-idf的component目录下bootloader/subproject/main/bootloader_start.c。
在SoC复位后，PRO CPU将立即开始运行，执行复位向量代码，而APP CPU将保持复位。在启动过程中，PRO CPU执行所有初始化。call_start_cpu0应用程序启动代码功能中的APP CPU复位被取消置位。复位向量代码位于ESP32芯片掩码ROM中的地址0x40000400，不能修改。
从复位向量调用的启动代码通过检查GPIO_STRAP_REG(gpio_reg.h定义的)引导引脚 [GPIO0, GPIO2, GPIO4, MTDO, GPIO5]状态的寄存器来确定引导模式。
如果GPIO0和GPIO2同时为低电平，则会进入下载模式，等待串口通信信息。
如果GPIO0为高电平，则会进入Flash 运行模式，启动SPI 驱动，并加载Flash中的程序段。
本次启动ESP32可知道上次复位的原因，有以下几种可能。
从深度睡眠复位
如果RTC_CNTL_STORE6_REG值为非零，并且RTC存储器的CRC值RTC_CNTL_STORE7_REG有效，RTC_CNTL_STORE6_REG则将其用作入口点地址并立即跳转。如果RTC_CNTL_STORE6_REG为零，或RTC_CNTL_STORE7_REG包含无效的CRC，或者一旦调用通过RTC_CNTL_STORE6_REG返回的代码，继续进行启动，就好像是上电复位一样。注意，此时运行自定义代码，提供了一个深度睡眠存根机制。
对于上电复位，软件SOC复位和看门狗SOC复位
GPIO_STRAP_REG如果要求UART或SDIO下载模式，请检查寄存器。如果是这种情况，请配置UART或SDIO，并等待下载代码。否则，继续进行启动，就好像是由于软件CPU复位。
对于软件CPU复位和看门狗CPU复位
根据EFUSE值配置SPI闪存，并尝试从闪存加载代码。如果从闪存加载代码失败，将BASIC解释器解压缩到RAM中并启动它。当发生这种情况时，RTC看门狗仍然使能，因此除非解释器接收到任何输入，否则看门狗将在几百毫秒内重置SOC，重复整个过程。如果解释器从UART接收到任何输入，它将禁用看门狗。
ESP32复位源
第一阶段总结：可以看出，第一阶段主要是为了第二阶段做铺垫，应用程序二进制从地址0x1000开始从闪存加载。第一个4kB闪存扇区用于存储安全引导IV和应用程序映像的签名。
第二阶段
在ESP-IDF中，闪存中位于0x1000位置的二进制映像是第二级引导加载程序。ESP-IDF的组件bootloader目录中提供了第二阶段引导加载程序源代码。这种安排并不是ESP32芯片中唯一的可能，也可以编写一个功能齐全的应用程序，当闪存到0x1000时，该应用程序将工作，ESP-IDF中使用第二阶段引导加载程序来增加闪存布局的灵活性（使用分区表），并允许发生与闪存加密，安全引导和空中更新（OTA）相关的各种流程。
当第一阶段引导加载程序完成检查和加载第二阶段引导加载程序时，它跳转到二进制映像头中找到的第二阶段引导加载程序入口点。
第二阶段引导程序读取在偏移0x8000处找到的分区表。引导加载程序找到工厂和OTA分区，并根据在OTA信息分区中找到的数据来决定哪一个进行引导。
对于所选分区，第二级引导加载程序将映射到IRAM和DRAM的数据和代码段复制到其加载地址。对于在DROM和IROM区域中具有加载地址的部分，Flash MMU配置为提供正确的映射。第二阶段引导加载程序为PRO和APP CPU配置闪存MMU，但只能为PRO CPU启用闪存MMU。这样做的原因是第二阶段引导程序代码被加载到APP CPU缓存使用的内存区域中。启用APP CPU的缓存的功能被传递给应用程序。一旦加载了代码并且设置了闪存MMU，则第二级引导加载程序将跳转到二进制映像头中的应用程序入口点。
目前，官方并不支持加载程序添加应用程序定义来自己定义应用程序分区选择逻辑。
第三阶段
主函数镜像开始执行（即main_task，应用程序入口点是call_start_cpu0，可在components/esp32/cpu_start.c中找到），这个功能的两个主要作用是启用堆分配器并使APP CPU跳到其入口点call_start_cpu1。PRO CPU上的代码设置APP CPU的入口点，取消置位APP CPU复位，并等待由APP CPU上运行的代码设置的全局标志，表示已启动。一旦完成，PRO CPU跳转到start_cpu0功能，并且APP CPU将跳转到start_cpu1功能。
start_cpu0和start_cpu的功能并不是不可修改的，start_cpu0根据所做的选择启用或初始化组件默认实现，可以通过查看components/esp32/cpu_start.c观察最新的执行步骤列表，不过值得注意的是，此阶段将调用应用程序中存在的所有C++全局构造函数。一旦所有基本组件都被初始化，则创建主任务，并启动FreeRTOS调度程序。esp32是一个双核cpu，在这个过程中，当PRO CPU在start_cpu0功能中进行初始化时，APP CPU会自动start_cpu1运行功能，等待在PRO CPU上启动调度程序。一旦在PRO CPU上启动了调度程序，APP CPU上的代码也启动了调度程序。
main_task的任务是可以配置主任务堆栈大小和优先级，当然我们可以使用此任务进行初始的应用程序特定设置，例如启动其它任务。应用程序还可以使用事件循环和其它通用活动的主要任务。但是需要注意的是，如果app_main函数返回，main_task将被删除。
ESP32启动总结
- 再不需要修改boot结构的情况下就不用看了，了解有好几个阶段即可。
- 如果实在想搞清楚启动流程，就把源码好好阅读一遍。反正我没看。
- 源码：esp-idf/component/bootloader/subproject/main/bootloader_start.c