Lines Matching full:on
3 The MCUBoot Espressif's port depends on HAL (Hardware Abstraction Layer) sources based on ESP-IDF
23 the bootloader own memory layout to avoid overlapping. More information on the section
86 `-DMCUBOOT_CONFIG_FILE` argument on the first step below.
212 It is also possible to rely on a security counter, also added to the image when signing with
224 # [Security Chain on Espressif port](#security-chain-on-espressif-port)
231 on the MCUboot Espressif port.
299 The Secure Boot implementation is based on
302 role for ensuring that only authorized code will be executed on the device. This is done through
310 In order to build the bootloader with the feature on, the following configurations must be enabled:
337 *On development phase is recommended add the following configuration in order to keep the debugging
410 On its **first boot** the Secure Boot is not enabled on the device eFuses yet, neither the key nor
413 1. On startup, since it is the first boot, the ROM bootloader will not verify the bootloader image
421 After that the Secure Boot feature is permanently enabled and on every next boot the ROM bootloader
424 1. On startup, the ROM bootloader checks the Secure Boot enable bit in the eFuse. If it is enabled,
443 The Flash Encryption implementation is also based on
451 burning on the device, all read and write operations are decrypted/encrypted in runtime.
455 In order to build the bootloader with the feature on, the following configurations must be enabled:
474 *On development phase is strongly recommended adding the following configuration in order to keep
497 *When on __RELEASE MODE__, __ENSURE__ that the application with an update agent is flashed before
545 On the **first boot**, the bootloader will:
563 Burn the key into the device's eFuse (keep a copy on the host), this action can be done **only
604 On the **first boot**, the bootloader will:
611 Encrypting data on the host:
633 For updating with an image encrypted on the host, flash it through serial using `esptool.py` as
654 the ROM bootloader checking on the Espressif chips **depending on which algorithm** was chosen for
696 different CPUs, firstly the *second image* on the APP CPU and then the *first image* on the PRO
717 # Enables multi image boot on independent processors
755 Supposing that the image 0 is being signed, its version is 1.0.0 and it depends on image 1 with
772 # GPIO used to boot on Serial Recovery
791 a button configured on GPIO 32 pressed for 5 seconds.
816 # GPIO used to boot on Serial Recovery
836 After entering the Serial recovery mode on the device, MCUMGR can be used as following:
864 application memory layout, it is mandatory for the OS linker script to avoid overlaping on
873 *Mostly of the Espressif chips have a separation on the address space for the same physical memory
875 that they need to be accessed by different addresses ranges depending on type, but refer to the
876 same region. More information on the
882 that the addresses and sizes may vary depending on the chip), they reflect the linker script
932 Note: On ESP32 the SRAM1 addresses are accessed in reverse order comparing Instruction
992 Note: On ESP32 the SRAM1 addresses are accessed in reverse order comparing Instruction