1# [Building and using MCUboot with Espressif's chips](#building-and-using-mcuboot-with-espressifs-chips) 2 3The MCUBoot Espressif's port depends on HAL (Hardware Abstraction Layer) sources based on ESP-IDF 4or 3rd party frameworks as such as Zephyr-RTOS (`zephyrproject-rtos/hal_espressif/`) or NuttX RTOS 5(`espressif/esp-hal-3rdparty`). Building the MCUboot Espressif's port and its features is platform 6dependent, therefore, the system environment including toolchains, must be set accordingly. A 7standalone build version means that ESP-IDF and its toolchain are used as source. For 3rd parties 8framework, HAL path and toolchain must be set. 9 10Documentation about the MCUboot bootloader design, operation and features can be found in the 11[design document](design.md). 12 13## [SoC support availability](#soc-support-availability) 14 15The current port is available for use in the following SoCs within the OSes: 16 17| | ESP32 | ESP32-S2 | ESP32-C3 | ESP32-S3 | ESP32-C2 | ESP32-C6 | ESP32-H2 | 18| :----: | :-----: | :-----: | :-----: | :-----: | :---------: | :-----: | :-----: | 19| Zephyr | Supported | Supported | Supported | Supported | In progress | In progress | In progress | 20| NuttX | Supported | Supported | Supported | Supported | In progress | In progress | In progress | 21 22Notice that any customization in the memory layout from the OS application must be done aware of 23the bootloader own memory layout to avoid overlapping. More information on the section 24[Memory map organization for OS compatibility](#memory-map-organization-for-os-compatibility). 25 26## [Installing requirements and dependencies](#installing-requirements-and-dependencies) 27 28The following instructions considers a MCUboot Espressif port standalone build. 29 301. Install additional packages required for development with MCUboot: 31 32 ```bash 33 cd ~/mcuboot # or to your directory where MCUboot is cloned 34 ``` 35 36 ```bash 37 pip3 install --user -r scripts/requirements.txt 38 ``` 39 402. Update the Mbed TLS submodule required by MCUboot: 41 42 ```bash 43 git submodule update --init --recursive ext/mbedtls 44 ``` 45 463. If ESP-IDF is the chosen option for use as HAL layer and the system already have ESP-IDF 47 installed, ensure that the environment is set: 48 49 ```bash 50 <IDF_PATH>/install.sh 51 ``` 52 53 ```bash 54 . <IDF_PATH>/export.sh 55 ``` 56 57 --- 58 ***Note*** 59 60 *If desirable, instructions for ESP-IDF installation can be found 61 [here](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/index.html#manual-installation)* 62 63 --- 64 65 --- 66 ***Note*** 67 68 *The other HALs mentioned above like `hal_espressif` from Zephyr RTOS or `esp-hal-3rdparty` 69 from NuttX RTOS environments also can be used for the bootloader standalone build, however as 70 eventually code revision may differ from what is currently expected, it is recommended using 71 them only within their RTOS build system.* 72 73 --- 74 754. If ESP-IDF is not installed and will not be used, install `esptool`: 76 77 ```bash 78 pip3 install esptool 79 ``` 80 81## [Building the bootloader itself](#building-the-bootloader-itself) 82 83The MCUboot Espressif port bootloader is built using the toolchain and tools provided by Espressif. 84Additional configuration related to MCUboot features and slot partitioning may be made using the 85`port/<TARGET>/bootloader.conf` file or passing a custom config file using the 86`-DMCUBOOT_CONFIG_FILE` argument on the first step below. 87 88--- 89***Note*** 90 91*Replace `<TARGET>` with the target ESP32 family (like `esp32`, `esp32s2` and others).* 92 93--- 94 951. Compile and generate the BIN: 96 97 ```bash 98 cmake -DCMAKE_TOOLCHAIN_FILE=tools/toolchain-<TARGET>.cmake -DMCUBOOT_TARGET=<TARGET> -DESP_HAL_PATH=<ESP_HAL_PATH> -DMCUBOOT_FLASH_PORT=<PORT> -B build -GNinja 99 ``` 100 101 ```bash 102 ninja -C build/ 103 ``` 104 105 --- 106 ***Note*** 107 108 *If using ESP-IDF as HAL layer source, `ESP_HAL_PATH` can be ommited.* 109 110 *If desirable, `<TOOLCHAIN_BIN_DIR>` can be defined with the path for a different compatible 111 toolchain, however it is recommended to actually create a CMake toolchain file and 112 pass it through `<CMAKE_TOOLCHAIN_FILE>` variable since it may require a distinct set of 113 compilation flags.* 114 115 --- 116 1172. Flash MCUboot in your device: 118 119 ```bash 120 ninja -C build/ flash 121 ``` 122 123 If `MCUBOOT_FLASH_PORT` arg was not passed to `cmake`, the default `PORT` for flashing will be 124 `/dev/ttyUSB0`. 125 126 Alternatively: 127 128 ```bash 129 esptool.py -p <PORT> -b <BAUD> --before default_reset --after no_reset --chip <TARGET> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <BOOTLOADER_FLASH_OFFSET> build/mcuboot_<TARGET>.bin 130 ``` 131 132 --- 133 ***Note*** 134 135 You may adjust the port `<PORT>` (like `/dev/ttyUSB0`) and baud rate `<BAUD>` (like `2000000`) 136 according to the connection with your board. You can also skip `<PORT>` and `<BAUD>` parameters 137 so that esptool tries to automatically detect it. 138 139 *`<FLASH_SIZE>` can be found using the command below:* 140 141 ```bash 142 esptool.py -p <PORT> -b <BAUD> flash_id 143 ``` 144 145 The output contains device information and its flash size: 146 147 ``` 148 Detected flash size: 4MB 149 ``` 150 151 *`<BOOTLOADER_FLASH_OFFSET>` value must follow one of the addresses below:* 152 153 | ESP32 | ESP32-S2 | ESP32-C3 | ESP32-S3 | ESP32-C2 | ESP32-C6 | ESP32-H2 | 154 | :-----: | :-----: | :-----: | :-----: | :-----: | :-----: | :-----: | 155 | 0x1000 | 0x1000 | 0x0000 | 0x0000 | 0x0000 | 0x0000 | 0x0000 | 156 157 --- 158 1593. Reset your device 160 161## [Signing and flashing an application](#signing-and-flashing-an-application) 162 1631. Images can be regularly signed with the `scripts/imgtool.py` script: 164 165 ```bash 166 imgtool.py sign --align 4 -v 0 -H 32 --pad-header -S <SLOT_SIZE> <BIN_IN> <SIGNED_BIN> 167 ``` 168 169 --- 170 171 ***Note*** 172 173 `<SLOT_SIZE>` is the size of the slot to be used. 174 Default slot0 size is `0x100000`, but it can change as per application flash partitions. 175 176 For Zephyr images, `--pad-header` is not needed as it already has the padding for MCUboot 177 header. 178 179 --- 180 181 :warning: ***ATTENTION*** 182 183 *This is the basic signing needed for adding MCUboot headers and trailers. 184 For signing with a crypto key and guarantee the authenticity of the image being booted, see the 185 section [MCUboot image signature verification](#mcuboot-image-signature-verification) below.* 186 187 --- 188 1892. Flash the signed application: 190 191 ```bash 192 esptool.py -p <PORT> -b <BAUD> --before default_reset --after hard_reset --chip <TARGET> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <SLOT_OFFSET> <SIGNED_BIN> 193 ``` 194 195# [Downgrade prevention](#downgrade-prevention) 196 197Downgrade prevention (avoid updating of images to an older version) can be enabled using the 198following configuration: 199 200``` 201CONFIG_ESP_DOWNGRADE_PREVENTION=y 202``` 203 204MCUboot will then verify and compare the new image version number with the current one before 205perform an update swap. 206 207Version number is added to the image when signing it with `imgtool` (`-v` parameter, e.g. 208`-v 1.0.0`). 209 210### [Downgrade prevention with security counter](#downgrade-prevention-with-security-counter) 211 212It is also possible to rely on a security counter, also added to the image when signing with 213`imgtool` (`-s` parameter), apart from version number. This allows image downgrade at some extent, 214since any update must have greater or equal security counter value. Enable using the following 215configuration: 216 217``` 218CONFIG_ESP_DOWNGRADE_PREVENTION_SECURITY_COUNTER=y 219``` 220 221E.g.: if the current image was signed using `-s 1` parameter, an eventual update image must have 222been signed using security counter `-s 1` or greater. 223 224# [Security Chain on Espressif port](#security-chain-on-espressif-port) 225 226[MCUboot encrypted images](encrypted_images.md) do not provide full code confidentiality when only 227external storage is available (see [Threat model](encrypted_images.md#threat-model)) since by 228MCUboot design the image in Primary Slot, from where the image is executed, is stored plaintext. 229Espressif chips have off-chip flash memory, so to ensure a security chain along with MCUboot image 230signature verification, the hardware-assisted Secure Boot and Flash Encryption were made available 231on the MCUboot Espressif port. 232 233## [MCUboot image signature verification](#mcuboot-image-signature-verification) 234 235The image that MCUboot is booting can be signed with 4 types of keys: RSA-2048, RSA-3072, EC256 and 236ED25519. In order to enable the feature, the **bootloader** must be compiled with the following 237configurations: 238 239--- 240***Note*** 241 242*It is strongly recommended to generate a new signing key using `imgtool` instead of use the 243existent samples.* 244 245--- 246 247#### For EC256 algorithm use 248 249``` 250CONFIG_ESP_SIGN_EC256=y 251 252# Use Tinycrypt lib for EC256 or ED25519 signing 253CONFIG_ESP_USE_TINYCRYPT=y 254 255CONFIG_ESP_SIGN_KEY_FILE=<YOUR_SIGNING_KEY.pem> 256``` 257 258#### For ED25519 algorithm use 259 260``` 261CONFIG_ESP_SIGN_ED25519=y 262 263# Use Tinycrypt lib for EC256 or ED25519 signing 264CONFIG_ESP_USE_TINYCRYPT=y 265 266CONFIG_ESP_SIGN_KEY_FILE=<YOUR_SIGNING_KEY.pem> 267``` 268 269#### For RSA (2048 or 3072) algorithm use 270 271``` 272CONFIG_ESP_SIGN_RSA=y 273# RSA_LEN is 2048 or 3072 274CONFIG_ESP_SIGN_RSA_LEN=<RSA_LEN> 275 276# Use Mbed TLS lib for RSA image signing 277CONFIG_ESP_USE_MBEDTLS=y 278 279CONFIG_ESP_SIGN_KEY_FILE=<YOUR_SIGNING_KEY.pem> 280``` 281 282Notice that the public key will be embedded in the bootloader code, since the hardware key storage 283is not supported by Espressif port. 284 285### [Signing the image](#signing-the-image) 286 287Now you need to sign the **image binary**, use the `imgtool` with `-k` parameter: 288 289```bash 290imgtool.py sign -k <YOUR_SIGNING_KEY.pem> --pad --pad-sig --align 4 -v 0 -H 32 --pad-header -S 0x00100000 <BIN_IN> <BIN_OUT> 291``` 292 293If signing a Zephyr image, the `--pad-header` is not needed, as it already have the padding for 294MCUboot header. 295 296 297## [Secure Boot](#secure-boot) 298 299The Secure Boot implementation is based on 300[IDF's Secure Boot V2](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v2.html), 301is hardware-assisted and RSA based - except ESP32-C2 that uses ECDSA signing scheme - and has the 302role for ensuring that only authorized code will be executed on the device. This is done through 303bootloader signature checking by the ROM bootloader. 304 305***Note***: ROM bootloader is the First Stage Bootloader, while the Espressif MCUboot port is the 306Second Stage Bootloader. 307 308### [Building bootloader with Secure Boot](#building-bootloader-with-secure-boot) 309 310In order to build the bootloader with the feature on, the following configurations must be enabled: 311 312``` 313CONFIG_SECURE_BOOT=1 314CONFIG_SECURE_BOOT_V2_ENABLED=1 315CONFIG_SECURE_SIGNED_ON_BOOT=1 316``` 317 318For the currently supported chips, with exception of ESP32-C2, enable RSA signing scheme: 319 320``` 321CONFIG_SECURE_SIGNED_APPS_RSA_SCHEME=1 322CONFIG_SECURE_BOOT_SUPPORTS_RSA=1 323``` 324 325For ESP32-C2, enable ECDSA signing scheme and, if working with Flash Encryption too, enable the 326configuration to burn keys to efuse together: 327 328``` 329CONFIG_SECURE_SIGNED_APPS_ECDSA_V2_SCHEME=1 330 331CONFIG_SECURE_BOOT_FLASH_ENC_KEYS_BURN_TOGETHER=1 332``` 333 334--- 335:warning: ***ATTENTION*** 336 337*On development phase is recommended add the following configuration in order to keep the debugging 338enabled and also to avoid any unrecoverable/permanent state change:* 339 340``` 341CONFIG_SECURE_BOOT_ALLOW_JTAG=1 342CONFIG_SECURE_FLASH_UART_BOOTLOADER_ALLOW_CACHE=1 343 344# Options for enabling eFuse emulation in Flash 345CONFIG_EFUSE_VIRTUAL=1 346CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH=1 347``` 348--- 349 350--- 351:warning: ***ATTENTION*** 352 353*You can disable UART Download Mode by adding the following configuration:* 354 355``` 356CONFIG_SECURE_DISABLE_ROM_DL_MODE=1 357``` 358 359*This may be suitable for __production__ builds. __After disabling UART Download Mode you will not 360be able to flash other images through UART.__* 361 362*Otherwise, you can switch the UART ROM Download Mode to the Secure Download Mode. It will limit 363the use of Download Mode functions to simple flash read, write and erase operations.* 364 365``` 366CONFIG_SECURE_ENABLE_SECURE_ROM_DL_MODE=1 367``` 368 369*Once the device makes its first full boot, these configurations cannot be reverted* 370 371--- 372 373Once the **bootloader image** is built, the resulting binary file is required to be signed with 374`espsecure.py` tool. 375 376First create a signing key: 377 378```bash 379espsecure.py generate_signing_key --version 2 <BOOTLOADER_SIGNING_KEY.pem> 380``` 381 382Then sign the bootloader image: 383 384```bash 385espsecure.py sign_data --version 2 --keyfile <BOOTLOADER_SIGNING_KEY.pem> -o <BOOTLOADER_BIN_OUT> <BOOTLOADER_BIN_IN> 386``` 387 388--- 389:warning: ***ATTENTION*** 390 391*Once the bootloader is flashed and the device resets, the **first boot will enable Secure Boot** 392and the bootloader and key **no longer can be modified**. So **ENSURE** that both bootloader and 393key are correct and you did not forget anything before flashing.* 394 395--- 396 397Flash the bootloader as following, with `--after no_reset` flag, so you can reset the device only 398when assured: 399 400```bash 401esptool.py -p <PORT> -b 2000000 --after no_reset --chip <ESP_CHIP> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <BOOTLOADER_FLASH_OFFSET> <SIGNED_BOOTLOADER_BIN> 402``` 403 404### [Secure Boot Process](#secure-boot-process) 405 406Secure boot uses a signature block appended to the bootloader image in order to verify the 407authenticity. The signature block contains the RSA-3072 signature of that image and the RSA-3072 408public key. 409 410On its **first boot** the Secure Boot is not enabled on the device eFuses yet, neither the key nor 411digests. So the first boot will have the following process: 412 4131. On startup, since it is the first boot, the ROM bootloader will not verify the bootloader image 414 (the Secure Boot bit in the eFuse is disabled) yet, so it proceeds to execute it (our MCUboot 415 bootloader port). 4162. Bootloader calculates the SHA-256 hash digest of the public key and writes the result to eFuse. 4173. Bootloader validates the application images and prepare the booting process (MCUboot phase). 4184. Bootloader burns eFuse to enable Secure Boot V2. 4195. Bootloader proceeds to load the Primary image. 420 421After that the Secure Boot feature is permanently enabled and on every next boot the ROM bootloader 422will verify the MCUboot bootloader image. The process of an usual boot: 423 4241. On startup, the ROM bootloader checks the Secure Boot enable bit in the eFuse. If it is enabled, 425 the boot will proceed as following. 4262. ROM bootloader verifies the bootloader's signature block integrity (magic number and CRC). 427 Interrupt boot if it fails. 4283. ROM bootloader verifies the bootloader image, interrupt boot if any step fails: 429 1. Compare the SHA-256 hash digest of the public key embedded in the bootloader’s signature 430 block with the digest saved in the eFuses. 431 2. Generate the application image digest and match it with the image digest in the signature 432 block. 433 3. Use the public key to verify the signature of the bootloader image, using RSA-PSS with the 434 image digest calculated from previous step for comparison. 4354. ROM bootloader executes the bootloader image. 4365. Bootloader does the usual verification (MCUboot phase). 4376. Proceeds to boot the Primary image. 438 439## [Flash Encryption](#flash-encryption) 440 441The Espressif Flash Encryption is hardware-assisted, transparent to the MCUboot process and is an 442additional security measure beyond MCUboot existent features. 443The Flash Encryption implementation is also based on 444[IDF](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/flash-encryption.html) 445and is intended for encrypting off-chip flash memory contents, so it is protected against physical 446reading. 447 448When enabling the Flash Encryption, the user can encrypt the content either using a **device 449generated key** (remains unknown and unreadable) or a **host generated key** (owner is responsible 450for keeping the key private and safe). After the flash encryption gets enabled through eFuse 451burning on the device, all read and write operations are decrypted/encrypted in runtime. 452 453### [Building bootloader with Flash Encryption](#building-bootloader-with-flash-encryption) 454 455In order to build the bootloader with the feature on, the following configurations must be enabled: 456 457For **release mode**: 458 459``` 460CONFIG_SECURE_FLASH_ENC_ENABLED=1 461CONFIG_SECURE_FLASH_ENCRYPTION_MODE_RELEASE=1 462``` 463 464For **development mode**: 465 466``` 467CONFIG_SECURE_FLASH_ENC_ENABLED=1 468CONFIG_SECURE_FLASH_ENCRYPTION_MODE_DEVELOPMENT=1 469``` 470 471--- 472:warning: ***ATTENTION*** 473 474*On development phase is strongly recommended adding the following configuration in order to keep 475the debugging enabled and also to avoid any unrecoverable/permanent state change:* 476 477``` 478CONFIG_SECURE_FLASH_UART_BOOTLOADER_ALLOW_ENC=1 479CONFIG_SECURE_FLASH_UART_BOOTLOADER_ALLOW_DEC=1 480CONFIG_SECURE_FLASH_UART_BOOTLOADER_ALLOW_CACHE=1 481CONFIG_SECURE_BOOT_ALLOW_JTAG=1 482 483# Options for enabling eFuse emulation in Flash 484CONFIG_EFUSE_VIRTUAL=1 485CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH=1 486``` 487--- 488 489--- 490:warning: ***ATTENTION*** 491 492*Unless the recommended flags for __DEVELOPMENT MODE__ were enabled, the actions made by Flash 493Encryption process are __PERMANENT__.* \ 494*Once the bootloader is flashed and the device resets, the __first boot will enable Flash 495Encryption, encrypt the flash content including bootloader and image slots, burn the eFuses that no 496longer can be modified__ and if device generated the key __it will not be recoverable__.* \ 497*When on __RELEASE MODE__, __ENSURE__ that the application with an update agent is flashed before 498reset the device.* 499 500*In the same way as Secure Boot feature, you can disable UART Download Mode by adding the following 501configuration:* 502 503``` 504CONFIG_SECURE_DISABLE_ROM_DL_MODE=1 505``` 506 507*This may be suitable for __production__ builds. __After disabling UART Download Mode you will not 508be able to flash other images through UART.__* 509 510*Otherwise, you can switch the UART Download Mode to the Secure Download Mode. It will limit the 511use of Download Mode functions to simple flash read, write and erase operations.* 512 513``` 514CONFIG_SECURE_ENABLE_SECURE_ROM_DL_MODE=1 515``` 516 517*These configurations cannot be reverted after the device's first boot* 518 519--- 520 521### [Signing the image when working with Flash Encryption](#signing-the-image-when-working-with-flash-encryption) 522 523When enabling flash encryption, it is required to signed the image using 32-byte alignment: 524`--align 32 --max-align 32`. 525 526Command example: 527 528```bash 529imgtool.py sign -k <YOUR_SIGNING_KEY.pem> --pad --pad-sig --align 32 --max-align 32 -v 0 -H 32 --pad-header -S <SLOT_SIZE> <BIN_IN> <BIN_OUT> 530``` 531 532### [Device generated key](#device-generated-key) 533 534First ensure that the application image is able to perform encrypted read and write operations to 535the SPI Flash. Flash the bootloader and application normally: 536 537```bash 538esptool.py -p <PORT> -b 2000000 --after no_reset --chip <ESP_CHIP> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <BOOTLOADER_FLASH_OFFSET> <BOOTLOADER_BIN> 539``` 540 541```bash 542esptool.py -p <PORT> -b 2000000 --after no_reset --chip <ESP_CHIP> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <PRIMARY_SLOT_FLASH_OFFSET> <APPLICATION_BIN> 543``` 544 545On the **first boot**, the bootloader will: 546 5471. Generate Flash Encryption key and write to eFuse. 5482. Encrypt flash in-place including bootloader, image primary/secondary slot and scratch. 5493. Burn eFuse to enable Flash Encryption. 5504. Reset system to ensure Flash Encryption cache resets properly. 551 552### [Host generated key](#host-generated-key) 553 554First ensure that the application image is able to perform encrypted read and write operations to 555the SPI Flash. Also ensure that the **UART ROM Download Mode is not disabled** - or that the 556**Secure Download Mode is enabled**. Before flashing, generate the encryption key using 557`espsecure.py` tool: 558 559```bash 560espsecure.py generate_flash_encryption_key <FLASH_ENCRYPTION_KEY.bin> 561``` 562 563Burn the key into the device's eFuse (keep a copy on the host), this action can be done **only 564once**: 565 566--- 567:warning: ***ATTENTION*** 568 569*eFuse emulation in Flash configuration options do not have any effect, so if the key burning 570command below is used, it will actually burn the physical eFuse.* 571 572--- 573 574- ESP32 575 576```bash 577espefuse.py --port PORT burn_key flash_encryption <FLASH_ENCRYPTION_KEY.bin> 578``` 579 580- ESP32S2, ESP32C3 and ESP32S3 581 582```bash 583espefuse.py --port PORT burn_key BLOCK <FLASH_ENCRYPTION_KEY.bin> <KEYPURPOSE> 584``` 585 586`BLOCK` is a free keyblock between `BLOCK_KEY0` and `BLOCK_KEY5`. And `KEYPURPOSE` is either 587`XTS_AES_128_KEY`, `XTS_AES_256_KEY_1`, `XTS_AES_256_KEY_2` (AES XTS 256 is available only in 588ESP32S2). 589 590Now, similar as the Device generated key, the bootloader and application can be flashed plaintext. 591The **first boot** will encrypt the flash content using the host key burned in the eFuse instead 592of generate a new one. 593 594Flashing the bootloader and application: 595 596```bash 597esptool.py -p <PORT> -b 2000000 --after no_reset --chip <ESP_CHIP> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <BOOTLOADER_FLASH_OFFSET> <BOOTLOADER_BIN> 598``` 599 600```bash 601esptool.py -p <PORT> -b 2000000 --after no_reset --chip <ESP_CHIP> write_flash --flash_mode dio --flash_size <FLASH_SIZE> --flash_freq 40m <PRIMARY_SLOT_FLASH_OFFSET> <APPLICATION_BIN> 602``` 603 604On the **first boot**, the bootloader will: 605 6061. Encrypt flash in-place including bootloader, image primary/secondary slot and scratch using the 607 written key. 6082. Burn eFuse to enable Flash Encryption. 6093. Reset system to ensure Flash Encryption cache resets properly. 610 611Encrypting data on the host: 612 613- ESP32 614 615```bash 616espsecure.py encrypt_flash_data --keyfile <FLASH_ENCRYPTION_KEY.bin> --address <FLASH_OFFSET> --output <OUTPUT_DATA> <INPUT_DATA> 617``` 618 619- ESP32-S2, ESP32-C3 and ESP32-S3 620 621```bash 622espsecure.py encrypt_flash_data --aes_xts --keyfile <FLASH_ENCRYPTION_KEY.bin> --address <FLASH_OFFSET> --output <OUTPUT_DATA> <INPUT_DATA> 623``` 624 625--- 626***Note*** 627 628OTA updates are required to be sent plaintext. The reason is that, as said before, after the Flash 629Encryption is enabled all read/write operations are decrypted/encrypted in runtime, so as e.g. if 630pre-encrypted data is sent for an OTA update, it would be wrongly double-encrypted when the update 631agent writes to the flash. 632 633For updating with an image encrypted on the host, flash it through serial using `esptool.py` as 634above. **UART ROM Download Mode must not be disabled**. 635 636--- 637 638## [Security Chain scheme](#security-chain-scheme) 639 640Using the 3 features, Secure Boot, Image signature verification and Flash Encryption, a Security 641Chain can be established so only trusted code is executed, and also the code and content residing 642in the off-chip flash are protected against undesirable reading. 643 644The overall final process when all features are enabled: 645 6461. ROM bootloader validates the MCUboot bootloader using RSA signature verification. 6472. MCUboot bootloader validates the image using the chosen algorithm EC256/RSA/ED25519. It also 648 validates an upcoming image when updating. 6493. Flash Encryption guarantees that code and data are not exposed. 650 651### [Size Limitation](#size-limitation) 652 653When all 3 features are enable at same time, the bootloader size may exceed the fixed limit for 654the ROM bootloader checking on the Espressif chips **depending on which algorithm** was chosen for 655MCUboot image signing. The issue <https://github.com/mcu-tools/mcuboot/issues/1262> was created to 656track this limitation. 657 658## [Multi image](#multi-image) 659 660The multi image feature (currently limited to 2 images) allows the images to be updated separately 661(each one has its own primary and secondary slot) by MCUboot. 662 663The Espressif port bootloader handles the boot in two different approaches: 664 665### [Host OS boots second image](#host-os-boots-second-image) 666 667Host OS from the *first image* is responsible for booting the *second image*, therefore the 668bootloader is aware of the second image regions and can update it, however it does not load 669neither boots it. 670 671Configuration example (`bootloader.conf`): 672 673``` 674CONFIG_ESP_BOOTLOADER_SIZE=0xF000 675CONFIG_ESP_MCUBOOT_WDT_ENABLE=y 676 677# Enables multi image, if it is not defined, its assumed 678# only one updatable image 679CONFIG_ESP_IMAGE_NUMBER=2 680 681# Example of values to be used when multi image is enabled 682# Notice that the OS layer and update agent must be aware 683# of these regions 684CONFIG_ESP_APPLICATION_SIZE=0x50000 685CONFIG_ESP_IMAGE0_PRIMARY_START_ADDRESS=0x10000 686CONFIG_ESP_IMAGE0_SECONDARY_START_ADDRESS=0x60000 687CONFIG_ESP_IMAGE1_PRIMARY_START_ADDRESS=0xB0000 688CONFIG_ESP_IMAGE1_SECONDARY_START_ADDRESS=0x100000 689CONFIG_ESP_SCRATCH_OFFSET=0x150000 690CONFIG_ESP_SCRATCH_SIZE=0x40000 691``` 692 693### [Multi boot](#multi-boot) 694 695In the multi boot approach the bootloader is responsible for booting two different images in two 696different CPUs, firstly the *second image* on the APP CPU and then the *first image* on the PRO 697CPU (current CPU), it is also responsible for update both images as well. Thus multi boot will be 698only supported by Espressif multi core chips - currently only ESP32 is implemented. 699 700--- 701***Note*** 702 703*The host OSes in each CPU must handle how the resources are divided/controlled between then.* 704 705--- 706 707Configuration example: 708 709``` 710CONFIG_ESP_BOOTLOADER_SIZE=0xF000 711CONFIG_ESP_MCUBOOT_WDT_ENABLE=y 712 713# Enables multi image, if it is not defined, its assumed 714# only one updatable image 715CONFIG_ESP_IMAGE_NUMBER=2 716 717# Enables multi image boot on independent processors 718# (main host OS is not responsible for booting the second image) 719# Use only with CONFIG_ESP_IMAGE_NUMBER=2 720CONFIG_ESP_MULTI_PROCESSOR_BOOT=y 721 722# Example of values to be used when multi image is enabled 723# Notice that the OS layer and update agent must be aware 724# of these regions 725CONFIG_ESP_APPLICATION_SIZE=0x50000 726CONFIG_ESP_IMAGE0_PRIMARY_START_ADDRESS=0x10000 727CONFIG_ESP_IMAGE0_SECONDARY_START_ADDRESS=0x60000 728CONFIG_ESP_IMAGE1_PRIMARY_START_ADDRESS=0xB0000 729CONFIG_ESP_IMAGE1_SECONDARY_START_ADDRESS=0x100000 730CONFIG_ESP_SCRATCH_OFFSET=0x150000 731CONFIG_ESP_SCRATCH_SIZE=0x40000 732``` 733 734### [Image version dependency](#image-version-dependency) 735 736MCUboot allows version dependency check between the images when updating them. As `imgtool.py` 737allows a version assigment when signing an image, it is also possible to add the version 738dependency constraint: 739 740```bash 741imgtool.py sign --align 4 -v <VERSION> -d "(<IMAGE_INDEX>, <VERSION_DEPENDENCY>)" -H 32 --pad-header -S <SLOT_SIZE> <BIN_IN> <SIGNED_BIN> 742``` 743 744- `<VERSION>` defines the version of the image being signed. 745- `"(<IMAGE_INDEX>, <VERSION_DEPENDENCY>)"` defines the minimum version and from which image is 746 needed to satisfy the dependency. 747 748--- 749Example: 750 751```bash 752imgtool.py sign --align 4 -v 1.0.0 -d "(1, 0.0.1+0)" -H 32 --pad-header -S 0x100000 image0.bin image0-signed.bin 753``` 754 755Supposing that the image 0 is being signed, its version is 1.0.0 and it depends on image 1 with 756version at least 0.0.1+0. 757 758--- 759 760## [Serial recovery mode](#serial-recovery-mode) 761 762Serial recovery mode allows management through MCUMGR (more information and how to install it: 763<https://github.com/apache/mynewt-mcumgr-cli>) for communicating and uploading a firmware to the 764device. 765 766Configuration example: 767 768``` 769# Enables the MCUboot Serial Recovery, that allows the use of 770# MCUMGR to upload a firmware through the serial port 771CONFIG_ESP_MCUBOOT_SERIAL=y 772# GPIO used to boot on Serial Recovery 773CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT=32 774# GPIO input type (0 for Pull-down, 1 for Pull-up) 775CONFIG_ESP_SERIAL_BOOT_GPIO_INPUT_TYPE=0 776# GPIO signal value 777CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT_VAL=1 778# Delay time for identify the GPIO signal 779CONFIG_ESP_SERIAL_BOOT_DETECT_DELAY_S=5 780# UART port used for serial communication 781CONFIG_ESP_SERIAL_BOOT_UART_NUM=1 782# GPIO for Serial RX signal 783CONFIG_ESP_SERIAL_BOOT_GPIO_RX=25 784# GPIO for Serial TX signal 785CONFIG_ESP_SERIAL_BOOT_GPIO_TX=26 786``` 787 788When enabled, the bootloader checks the if the GPIO `<CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT>` 789configured has the signal value `<CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT_VAL>` for approximately 790`<CONFIG_ESP_SERIAL_BOOT_DETECT_DELAY_S>` seconds for entering the Serial recovery mode. Example: 791a button configured on GPIO 32 pressed for 5 seconds. 792 793Serial mode then uses the UART port configured for communication 794(`<CONFIG_ESP_SERIAL_BOOT_UART_NUM>`, pins `<CONFIG_ESP_SERIAL_BOOT_GPIO_RX>`, 795`<CONFIG_ESP_SERIAL_BOOT_GPIO_RX>`). 796 797### [Serial Recovery through USB JTAG Serial port](#serial-recovery-through-usb-jtag-serial-port) 798 799Some chips, like ESP32-C3 and ESP32-S3 have an integrated USB JTAG Serial Controller that 800implements a serial port (CDC) that can also be used for handling MCUboot Serial Recovery. 801More information about the USB pins and hardware configuration: 802 803- ESP32-C3: <https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/usb-serial-jtag-console.html> 804- ESP32-S3: <https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/usb-serial-jtag-console.html> 805- ESP32-C6: <https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/api-guides/usb-serial-jtag-console.html> 806- ESP32-H2: <https://docs.espressif.com/projects/esp-idf/en/latest/esp32h2/api-guides/usb-serial-jtag-console.html> 807 808Configuration example: 809 810``` 811# Use Serial through USB JTAG Serial port for Serial Recovery 812CONFIG_ESP_MCUBOOT_SERIAL_USB_SERIAL_JTAG=y 813# Use sector erasing (recommended) instead of entire image size 814# erasing when uploading through Serial Recovery 815CONFIG_ESP_MCUBOOT_ERASE_PROGRESSIVELY=y 816# GPIO used to boot on Serial Recovery 817CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT=5 818# GPIO input type (0 for Pull-down, 1 for Pull-up) 819CONFIG_ESP_SERIAL_BOOT_GPIO_INPUT_TYPE=0 820# GPIO signal value 821CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT_VAL=1 822# Delay time for identify the GPIO signal 823CONFIG_ESP_SERIAL_BOOT_DETECT_DELAY_S=5 824``` 825 826--- 827:warning: ***ATTENTION*** 828 829*When working with Flash Encryption enabled, `CONFIG_ESP_MCUBOOT_ERASE_PROGRESSIVELY` must be 830__disabled__, although it is recommended for common Serial Recovery usage* 831 832--- 833 834### [MCUMGR image upload example](#mcumgr-image-upload-example) 835 836After entering the Serial recovery mode on the device, MCUMGR can be used as following: 837 838Configure the connection: 839```bash 840mcumgr conn add esp type="serial" connstring="dev=<PORT>,baud=115200,mtu=256" 841``` 842 843Upload the image (the process may take some time): 844```bash 845mcumgr -c esp image upload <IMAGE_BIN> 846``` 847 848Reset the device: 849```bash 850mcumgr -c esp reset 851``` 852 853--- 854:warning: ***ATTENTION*** 855 856*Serial recovery mode uploads the image to the PRIMARY_SLOT, therefore if the upload process gets 857interrupted the image may be corrupted and unable to boot* 858 859--- 860 861## [Memory map organization for OS compatibility](#memory-map-organization-for-os-compatibility) 862 863When adding support for this MCUboot port to an OS or even customizing an already supported 864application memory layout, it is mandatory for the OS linker script to avoid overlaping on 865`iram_loader_seg` and `dram_seg` bootloader RAM regions. Although part of the RAM becomes initially 866unavailable, it is reclaimable by the OS after boot as heap. 867 868Therefore, the application must be designed aware of the bootloader memory usage. 869 870--- 871***Note*** 872 873*Mostly of the Espressif chips have a separation on the address space for the same physical memory 874ammount: IRAM (accessed by the instruction bus) and DRAM (accessed by the data bus), which means 875that they need to be accessed by different addresses ranges depending on type, but refer to the 876same region. More information on the 877[Espressif TRMs](https://www.espressif.com/en/support/documents/technical-documents?keys=&field_download_document_type_tid%5B%5D=963).* 878 879--- 880 881The following diagrams illustrate a memory organization from the bootloader point of view (notice 882that the addresses and sizes may vary depending on the chip), they reflect the linker script 883`boot/espressif/port/<TARGET>/ld/bootloader.ld`: 884 885### ESP32 886 887#### ESP32 standard 888 889``` 890 SRAM0 891 IRAM ADDR / DRAM ADDR 892 * +--------+--------------+------+ 0x40070000 / --------- - SRAM0 START 893 * | ^ | 894 * | | PRO CPU Cache | *NOT CLAIMABLE BY OS RAM 895 * | v | 896 * +--------+--------------+------+ 0x40078000 / ---------- 897 * | ^ | 898 * | | | *NOT CLAIMABLE BY OS RAM 899 * | | iram_loader_seg | *Region usable as iram_loader_seg during boot 900 * | | (APP CPU Cache) | as APP CPU is not initialized yet 901 * | | | 902 * | v | 903 * +--------+--------------+------+ 0x40080000 / ---------- 904 * | ^ | 905 * | | FREE | *CLAIMABLE BY OS RAM 906 * | v | 907 * +------------------------------+ 0x40090000 / ---------- 908 * | ^ | 909 * | | iram_seg | *CLAIMABLE BY OS RAM 910 * | | | 911 * | v | 912 * +--------+--------------+------+ 0x40099000 / ---------- 913 * | | FREE | *CLAIMABLE BY OS RAM 914 * +------------------------------+ 0x4009FFFF / ---------- - SRAM0 END 915 916 SRAM1 917 IRAM ADDR / DRAM ADDR 918 * +------------------------------+ 0x400A0000 / 0x3FFFFFFF - SRAM1 START 919 * | ^ | 920 * | | | *** SHOULD NOT BE OVERLAPPED *** 921 * | | dram_seg | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 922 * | v | 923 * +--------+--------------+------+ 0x400AB900 / 0x3FFF4700 924 * | ^ | 925 * | | | 926 * | | | 927 * | | FREE | *CLAIMABLE BY OS RAM 928 * | | | 929 * | | | 930 * | v | 931 * +--------+--------------+------+ 0x400BFFFF / 0x3FFE0000 - SRAM1 END 932 Note: On ESP32 the SRAM1 addresses are accessed in reverse order comparing Instruction 933 bus (IRAM) and Data bus (DRAM), but refer to the same location. See the TRM for more 934 information. 935 936 SRAM2 937 IRAM ADDR / DRAM ADDR 938 * +--------+--------------+------+ ---------- / 0x3FFAE000 - SRAM2 START 939 * | | FREE | *CLAIMABLE BY OS RAM 940 * +--------+--------------+------+ ---------- / 0x3FFDFFFF - SRAM2 END 941``` 942 943#### ESP32 Multi Processor Boot 944 945This is the linker script mapping when the `CONFIG_ESP_MULTI_PROCESSOR_BOOT` is enabled 946([Multi boot](#multi-boot)) since APP CPU Cache region cannot be used for `iram_loader_seg` region 947as there would be conflict when the bootloader starts the APP CPU before jump to the main 948application. 949 950``` 951 SRAM0 952 IRAM ADDR / DRAM ADDR 953 * +--------+--------------+------+ 0x40070000 / --------- - SRAM0 START 954 * | ^ | 955 * | | | 956 * | | Cache | *Used by PRO CPU and APP CPU as Cache 957 * | | | 958 * | v | 959 * +--------+--------------+------+ 0x40080000 / ---------- 960 * | ^ | 961 * | | FREE | *CLAIMABLE BY OS RAM 962 * | v | 963 * +------------------------------+ 0x40090000 / ---------- 964 * | ^ | 965 * | | iram_seg | *CLAIMABLE BY OS RAM 966 * | | | 967 * | v | 968 * +--------+--------------+------+ 0x40099000 / ---------- 969 * | | FREE | *CLAIMABLE BY OS RAM 970 * +------------------------------+ 0x4009FFFF / ---------- - SRAM0 END 971 972 SRAM1 973 IRAM ADDR / DRAM ADDR 974 * +------------------------------+ 0x400A0000 / 0x3FFFFFFF - SRAM1 START 975 * | ^ | 976 * | | | *** SHOULD NOT BE OVERLAPPED *** 977 * | | dram_seg | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 978 * | v | 979 * +--------+--------------+------+ 0x400AB900 / 0x3FFF4700 980 * | ^ | 981 * | | | *** SHOULD NOT BE OVERLAPPED *** 982 * | | iram_loader_seg | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 983 * | | | 984 * | v | 985 * +------------------------------+ 0x400B1E00 / 0x3FFEE200 986 * | ^ | 987 * | | | 988 * | | FREE | *CLAIMABLE BY OS RAM 989 * | | | 990 * | v | 991 * +--------+--------------+------+ 0x400BFFFF / 0x3FFE0000 - SRAM1 END 992 Note: On ESP32 the SRAM1 addresses are accessed in reverse order comparing Instruction 993 bus (IRAM) and Data bus (DRAM), but refer to the same location. See the TRM for more 994 information. 995 996 SRAM2 997 IRAM ADDR / DRAM ADDR 998 * +--------+--------------+------+ ---------- / 0x3FFAE000 - SRAM2 START 999 * | | FREE | *CLAIMABLE BY OS RAM 1000 * +--------+--------------+------+ ---------- / 0x3FFDFFFF - SRAM2 END 1001``` 1002 1003### ESP32-S2 1004 1005``` 1006 SRAM0 1007 IRAM ADDR / DRAM ADDR 1008 * +--------+--------------+------+ 0x40020000 / 0x3FFB0000 - SRAM0 START 1009 * | | FREE | *CLAIMABLE BY OS RAM 1010 * +--------+--------------+------+ 0x40027FFF / 0x3FFB7FFF - SRAM0 END 1011 1012 SRAM1 1013 IRAM ADDR / DRAM ADDR 1014 * +--------+--------------+------+ 0x40028000 / 0x3FFB8000 - SRAM1 START 1015 * | ^ | 1016 * | | | 1017 * | | FREE | *CLAIMABLE BY OS RAM 1018 * | | | 1019 * | v | 1020 * +--------+--------------+------+ 0x40047000 / 0x3FFD7000 1021 * | ^ | 1022 * | | | 1023 * | | | 1024 * | | iram_seg | *CLAIMABLE BY OS RAM 1025 * | | | 1026 * | | | 1027 * | v | 1028 * +------------------------------+ 0x40050000 / 0x3FFE0000 1029 * | ^ | 1030 * | | | 1031 * | | | 1032 * | | iram_loader_seg | *** SHOULD NOT BE OVERLAPPED *** 1033 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1034 * | | | 1035 * | v | 1036 * +------------------------------+ 0x40056000 / 0x3FFE6000 1037 * | ^ | 1038 * | | | 1039 * | | dram_seg | *** SHOULD NOT BE OVERLAPPED *** 1040 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1041 * | v | 1042 * +--------+--------------+------+ 0x4006FFFF / 0x3FFFFFFF - SRAM1 END 1043``` 1044 1045### ESP32-S3 1046 1047``` 1048 SRAM0 1049 IRAM ADDR / DRAM ADDR 1050 * +--------+--------------+------+ 0x40370000 / ---------- - SRAM0 START 1051 * | | FREE | *CLAIMABLE BY OS RAM 1052 * +--------+--------------+------+ 0x40377FFF / ---------- - SRAM0 END 1053 1054 SRAM1 1055 IRAM ADDR / DRAM ADDR 1056 * +--------+--------------+------+ 0x40378000 / 0x3FC88000 - SRAM1 START 1057 * | ^ | 1058 * | | | 1059 * | | FREE | *CLAIMABLE BY OS RAM 1060 * | | | 1061 * | v | 1062 * +--------+--------------+------+ 0x403B0000 / 0x3FCC0000 1063 * | ^ | 1064 * | | | 1065 * | | | 1066 * | | iram_seg | *CLAIMABLE BY OS RAM 1067 * | | | 1068 * | | | 1069 * | v | 1070 * +------------------------------+ 0x403BA000 / 0x3FCCA000 1071 * | ^ | 1072 * | | | 1073 * | | | 1074 * | | iram_loader_seg | *** SHOULD NOT BE OVERLAPPED *** 1075 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1076 * | | | 1077 * | v | 1078 * +------------------------------+ 0x403C0000 / 0x3FCD0000 1079 * | ^ | 1080 * | | | 1081 * | | dram_seg | *** SHOULD NOT BE OVERLAPPED *** 1082 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1083 * | v | 1084 * +--------+--------------+------+ 0x403DFFFF / 0x3FCEFFFF - SRAM1 END 1085 1086 SRAM2 1087 IRAM ADDR / DRAM ADDR 1088 * +--------+--------------+------+ ---------- / 0x3FCF0000 - SRAM2 START 1089 * | | FREE | *CLAIMABLE BY OS RAM 1090 * +--------+--------------+------+ ---------- / 0x3FCFFFFF - SRAM2 END 1091``` 1092 1093### ESP32-C2 1094 1095``` 1096 SRAM0 1097 IRAM ADDR / DRAM ADDR 1098 * +--------+--------------+------+ 0x4037C000 / ---------- - SRAM0 START 1099 * | | FREE | *CLAIMABLE BY OS RAM 1100 * +--------+--------------+------+ 0x4037FFFF / ---------- - SRAM0 END 1101 1102 SRAM1 1103 IRAM ADDR / DRAM ADDR 1104 * +--------+--------------+------+ 0x40380000 / 0x3FCA0000 - SRAM1 START 1105 * | ^ | 1106 * | | | 1107 * | | | 1108 * | | FREE | *CLAIMABLE BY OS RAM 1109 * | | | 1110 * | | | 1111 * | v | 1112 * +--------+--------------+------+ 0x403A1370 / 0x3FCC1370 1113 * | ^ | 1114 * | | | 1115 * | | | 1116 * | | iram_seg | *CLAIMABLE BY OS RAM 1117 * | | | 1118 * | | | 1119 * | v | 1120 * +------------------------------+ 0x403A9B70 / 0x3FCC9B70 1121 * | ^ | 1122 * | | | 1123 * | | | 1124 * | | iram_loader_seg | *** SHOULD NOT BE OVERLAPPED *** 1125 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1126 * | | | 1127 * | v | 1128 * +------------------------------+ 0x403B0B70 / 0x3FCD0B70 1129 * | ^ | 1130 * | | | 1131 * | | dram_seg | *** SHOULD NOT BE OVERLAPPED *** 1132 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1133 * | v | 1134 * +--------+--------------+------+ 0x403BFFFF / 0x3FCDFFFF - SRAM1 END 1135``` 1136 1137### ESP32-C3 1138 1139``` 1140 SRAM0 1141 IRAM ADDR / DRAM ADDR 1142 * +--------+--------------+------+ 0x4037C000 / ---------- - SRAM0 START 1143 * | | FREE | *CLAIMABLE BY OS RAM 1144 * +--------+--------------+------+ 0x4037FFFF / ---------- - SRAM0 END 1145 1146 SRAM1 1147 IRAM ADDR / DRAM ADDR 1148 * +--------+--------------+------+ 0x40380000 / 0x3FC80000 - SRAM1 START 1149 * | ^ | 1150 * | | | 1151 * | | | 1152 * | | FREE | *CLAIMABLE BY OS RAM 1153 * | | | 1154 * | | | 1155 * | v | 1156 * +--------+--------------+------+ 0x403C7000 / 0x3FCC7000 1157 * | ^ | 1158 * | | | 1159 * | | | 1160 * | | iram_seg | *CLAIMABLE BY OS RAM 1161 * | | | 1162 * | | | 1163 * | v | 1164 * +------------------------------+ 0x403D0000 / 0x3FCD0000 1165 * | ^ | 1166 * | | | 1167 * | | | 1168 * | | iram_loader_seg | *** SHOULD NOT BE OVERLAPPED *** 1169 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1170 * | | | 1171 * | v | 1172 * +------------------------------+ 0x403D5400 / 0x3FCD5400 1173 * | ^ | 1174 * | | | 1175 * | | dram_seg | *** SHOULD NOT BE OVERLAPPED *** 1176 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1177 * | v | 1178 * +--------+--------------+------+ 0x403DFFFF / 0x3FCDFFFF - SRAM1 END 1179``` 1180 1181### ESP32-C6 1182 1183``` 1184 IRAM ADDR / DRAM ADDR 1185 * +--------+--------------+------+ 0x40800000 / 0x40800000 - HP SRAM START 1186 * | ^ | 1187 * | | | 1188 * | | | 1189 * | | FREE | *CLAIMABLE BY OS RAM 1190 * | | | 1191 * | | | 1192 * | v | 1193 * +--------+--------------+------+ 0x40860610 / 0x40860610 1194 * | ^ | 1195 * | | | 1196 * | | | 1197 * | | iram_seg | *CLAIMABLE BY OS RAM 1198 * | | | 1199 * | | | 1200 * | v | 1201 * +------------------------------+ 0x40869610 / 0x40869610 1202 * | ^ | 1203 * | | | 1204 * | | | 1205 * | | iram_loader_seg | *** SHOULD NOT BE OVERLAPPED *** 1206 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1207 * | | | 1208 * | v | 1209 * +------------------------------+ 0x40870610 / 0x40870610 1210 * | ^ | 1211 * | | | 1212 * | | dram_seg | *** SHOULD NOT BE OVERLAPPED *** 1213 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1214 * | v | 1215 * +--------+--------------+------+ 0x4087FFFF / 0x4087FFFF - HP SRAM END 1216``` 1217 1218### ESP32-H2 1219 1220``` 1221 IRAM ADDR / DRAM ADDR 1222 * +--------+--------------+------+ 0x40800000 / 0x40800000 - HP SRAM START 1223 * | ^ | 1224 * | | | 1225 * | | | 1226 * | | FREE | *CLAIMABLE BY OS RAM 1227 * | | | 1228 * | | | 1229 * | v | 1230 * +--------+--------------+------+ 0x408317D0 / 0x408317D0 1231 * | ^ | 1232 * | | | 1233 * | | | 1234 * | | iram_seg | *CLAIMABLE BY OS RAM 1235 * | | | 1236 * | | | 1237 * | v | 1238 * +------------------------------+ 0x40839FD0 / 0x40839FD0 1239 * | ^ | 1240 * | | | 1241 * | | | 1242 * | | iram_loader_seg | *** SHOULD NOT BE OVERLAPPED *** 1243 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1244 * | | | 1245 * | v | 1246 * +------------------------------+ 0x40840FD0 / 0x40840FD0 1247 * | ^ | 1248 * | | | 1249 * | | dram_seg | *** SHOULD NOT BE OVERLAPPED *** 1250 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP *** 1251 * | v | 1252 * +--------+--------------+------+ 0x4084FFFF / 0x4084FFFF - HP SRAM END 1253``` 1254
