Lines Matching full:boot
230 signature verification, the hardware-assisted Secure Boot and Flash Encryption were made available
297 ## [Secure Boot](#secure-boot)
299 The Secure Boot implementation is based on
300 [IDF's Secure Boot V2](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-…
308 ### [Building bootloader with Secure Boot](#building-bootloader-with-secure-boot) argument
369 *Once the device makes its first full boot, these configurations cannot be reverted*
391 *Once the bootloader is flashed and the device resets, the **first boot will enable Secure Boot**
404 ### [Secure Boot Process](#secure-boot-process) argument
406 Secure boot uses a signature block appended to the bootloader image in order to verify the
410 On its **first boot** the Secure Boot is not enabled on the device eFuses yet, neither the key nor
411 digests. So the first boot will have the following process:
413 1. 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
418 4. Bootloader burns eFuse to enable Secure Boot V2.
421 After that the Secure Boot feature is permanently enabled and on every next boot the ROM bootloader
422 will verify the MCUboot bootloader image. The process of an usual boot:
424 1. 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.
427 Interrupt boot if it fails.
428 3. ROM bootloader verifies the bootloader image, interrupt boot if any step fails:
437 6. Proceeds to boot the Primary image.
494 *Once the bootloader is flashed and the device resets, the __first boot will enable Flash
500 *In the same way as Secure Boot feature, you can disable UART Download Mode by adding the following
517 *These configurations cannot be reverted after the device's first boot*
545 On the **first boot**, the bootloader will:
591 The **first boot** will encrypt the flash content using the host key burned in the eFuse instead
604 On the **first boot**, the bootloader will:
640 Using the 3 features, Secure Boot, Image signature verification and Flash Encryption, a Security
663 The Espressif port bootloader handles the boot in two different approaches:
693 ### [Multi boot](#multi-boot)
695 In the multi boot approach the bootloader is responsible for booting two different images in two
697 CPU (current CPU), it is also responsible for update both images as well. Thus multi boot will be
717 # Enables multi image boot on independent processors
772 # GPIO used to boot on Serial Recovery
816 # GPIO used to boot on Serial Recovery
857 interrupted the image may be corrupted and unable to boot*
866 unavailable, it is reclaimable by the OS after boot as heap.
883 `boot/espressif/port/<TARGET>/ld/bootloader.ld`:
899 * | | iram_loader_seg | *Region usable as iram_loader_seg during boot
921 * | | dram_seg | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
943 #### ESP32 Multi Processor Boot
946 ([Multi boot](#multi-boot)) since APP CPU Cache region cannot be used for `iram_loader_seg` region
977 * | | dram_seg | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
982 * | | iram_loader_seg | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1033 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1040 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1075 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1082 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1125 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1132 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1169 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1176 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1206 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1213 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1243 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***
1250 * | | | *** OS CAN RECLAIM IT AFTER BOOT LATER AS HEAP ***