Lines Matching full:bootloader

10 Documentation about the MCUboot bootloader design, operation and features can be found in the
23 the bootloader own memory layout to avoid overlapping. More information on the section
69     from NuttX RTOS environments also can be used for the bootloader standalone build, however as
81 ## [Building the bootloader itself](#building-the-bootloader-itself)
83 The MCUboot Espressif port bootloader is built using the toolchain and tools provided by Espressif.
85 `port/<TARGET>/bootloader.conf` file or passing a custom config file using the
236 ED25519. In order to enable the feature, the **bootloader** must be compiled with the following
282 Notice that the public key will be embedded in the bootloader code, since the hardware key storage
303 bootloader signature checking by the ROM bootloader.
305 ***Note***: ROM bootloader is the First Stage Bootloader, while the Espressif MCUboot port is the
306 Second Stage Bootloader.
308 ### [Building bootloader with Secure Boot](#building-bootloader-with-secure-boot)
310 In order to build the bootloader with the feature on, the following configurations must be enabled:
373 Once the **bootloader image** is built, the resulting binary file is required to be signed with
382 Then sign the bootloader image:
391 *Once the bootloader is flashed and the device resets, the **first boot will enable Secure Boot**
392 and the bootloader and key **no longer can be modified**. So **ENSURE** that both bootloader and
397 Flash the bootloader as following, with `--after no_reset` flag, so you can reset the device only
406 Secure boot uses a signature block appended to the bootloader image in order to verify the
413 1. On startup, since it is the first boot, the ROM bootloader will not verify the bootloader image
415    bootloader port).
416 2. Bootloader calculates the SHA-256 hash digest of the public key and writes the result to eFuse.
417 3. Bootloader validates the application images and prepare the booting process (MCUboot phase).
418 4. Bootloader burns eFuse to enable Secure Boot V2.
419 5. Bootloader proceeds to load the Primary image.
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,
426 2. ROM bootloader verifies the bootloader's signature block integrity (magic number and CRC).
428 3. 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
433     3. Use the public key to verify the signature of the bootloader image, using RSA-PSS with the
435 4. ROM bootloader executes the bootloader image.
436 5. Bootloader does the usual verification (MCUboot phase).
453 ### [Building bootloader with Flash Encryption](#building-bootloader-with-flash-encryption)
455 In order to build the bootloader with the feature on, the following configurations must be enabled:
494 *Once the bootloader is flashed and the device resets, the __first boot will enable Flash
495 Encryption, encrypt the flash content including bootloader and image slots, burn the eFuses that no
535 the SPI Flash. Flash the bootloader and application normally:
545 On the **first boot**, the bootloader will:
548 2. Encrypt flash in-place including bootloader, image primary/secondary slot and scratch.
590 Now, similar as the Device generated key, the bootloader and application can be flashed plaintext.
594 Flashing the bootloader and application:
604 On the **first boot**, the bootloader will:
606 1. Encrypt flash in-place including bootloader, image primary/secondary slot and scratch using the
646 1. ROM bootloader validates the MCUboot bootloader using RSA signature verification.
647 2. MCUboot bootloader validates the image using the chosen algorithm EC256/RSA/ED25519. It also
653 When all 3 features are enable at same time, the bootloader size may exceed the fixed limit for
654 the ROM bootloader checking on the Espressif chips **depending on which algorithm** was chosen for
663 The Espressif port bootloader handles the boot in two different approaches:
668 bootloader is aware of the second image regions and can update it, however it does not load
671 Configuration example (`bootloader.conf`):
695 In the multi boot approach the bootloader is responsible for booting two different images in two
788 When enabled, the bootloader checks the if the GPIO `<CONFIG_ESP_SERIAL_BOOT_GPIO_DETECT>`
865 `iram_loader_seg` and `dram_seg` bootloader RAM regions. Although part of the RAM becomes initially
868 Therefore, the application must be designed aware of the bootloader memory usage.
881 The following diagrams illustrate a memory organization from the bootloader point of view (notice
883 `boot/espressif/port/<TARGET>/ld/bootloader.ld`:
947 as there would be conflict when the bootloader starts the APP CPU before jump to the main