The body of the bootloader_debug_buffer function was conditioned to
macros that were never defined, resulting in deactivated code.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
peripheral enable/disable usually should be managed by driver itself,
so make it as espressif private APIs, not recommended for user to use it
in application code.
However, if user want to re-write the driver or ports to other platform,
this is still possible by including the header in this way:
"esp_private/peripheral_ctrl.h"
This commit fixes issue where empty (unprogrammed) digest slot out of
multiple supported (e.g. 3 for ESP32-C3) could cause issue in
workflow enablement process.
Notes:
1. This issue was applicable for chips supporting "secure-boot-v2"
scheme with multiple digests slots
2. This issue was affecting only manual workflow, where digest of
public was pre-flashed in efuse
3. Change in "flash_encrypt.c" is only for additional safety purpose
By using IOMUX instead of GPIO Matrix for UART, it is now possible
on ESP32 boards to use the UART as a wake up source even if it is
not used as a console.
For other boards where this issue was not present, using IOMUX has
the advantage to be faster than using GPIO matrix, so a highest
baudrate can be used
Add .eh_frame and .eh_frame_hdr sections to the binary (can be
enabled/disabled within menuconfig). These sections are parsed
when a panic occurs. Their DWARF instructions are decoded and
executed at runtime, to retrieve the whole backtrace. This
parser has been tested on both RISC-V and x86 architectures.
This feature needs esptool's merge adjacent ELF sections feature.
- Add to docs & config descriptions
- Change to a "choice" to become self-documenting
- Keep the bootloader_common_check_long_hold_gpio() function for compatibility
Updates the following with changes from verification branches:
* esp_rom linker files
* rtc_cntl and system reg and struct headers
Also updates:
* GDMA driver with new register layout
* esptool submodule commit
Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
1. add some efuse api to get rtc & digital voltage
2. set dig_rtc voltage to a fix value storing in efuse no mater which cpu frequency
3. modify hardware code in bootloader to fit all c3 ECO3 version
bootloader_support: Fix bootloader_common_get_sha256_of_partition when CHECK_SIGNATURE is on
Closes IDFGH-5089
See merge request espressif/esp-idf!12795
And it fixed another case for bootloader_common_get_sha256_of_partition() when CHECK_SIGNATURE is on
- If RSA signature check is on in Kconfig then sha256 was 0xFFFFF...
because image_load gave image_len which pointed to the end of sign blocks.
And image_digest was filled from a wrong position.
Closes https://github.com/espressif/esp-idf/issues/6873
When `DIS_USB_JTAG` eFuse is NOT burned (`False`), it is not possible
to set pins 18 and 19 as GPIOs. This commit solves this by manually
disabling USB JTAG when using pins 18 or 19.
The functions shall use `gpio_hal_iomux_func_sel` instead of
`PIN_FUNC_SELELECT`.
1. deepsleep poweron reset bug in high temperature before ECO3;
2. brownout reset bug before ECO2;
3. bbpll voltage low bug before ECO3;
4. need xpd iph for xtal before ECO3;
As this mode uses the public keys attached to the existing app's signatures to
verify the next app, checking that a signature block is found on boot prevents
the possibility of deploying a non-updatable device from the factory.
ESP32 V1 and V2 - protection bits.
ESP32xx V2: revoke bits, protection bits
- refactor efuse component
- adds some APIs for esp32 chips as well as for esp32xx chips
- Cmake shows an error if the partition table has a test app.
- BOOTLOADER_APP_TEST depends on !BOOTLOADER_APP_ANTI_ROLLBACK.
- Bootloader does not boot the test app if secure version is low.
Closes: https://www.esp32.com/viewtopic.php?f=13&t=19164&p=71302#p71302
Since idf_monitor decodes anything that looks like a code address and
starts with 0x, bootloader logs often get annotated with function
names such as WindowOverflow and other random and scary looking things
unrelated to the issue the user is facing. Print the addresses without
0x to avoid confusion by decoded function names. Print hexadecimal
size with 'h' suffix to distinguish it from the decimal value that
follows.
* Target components pull in xtensa component directly
* Use CPU HAL where applicable
* Remove unnecessary xtensa headers
* Compilation changes necessary to support non-xtensa gcc types (ie int32_t/uint32_t is no
longer signed/unsigned int).
Changes come from internal branch commit a6723fc
During HAL layer refactoring and new chip bringup, we have several
caps.h for each part, to reduce the conflicts to minimum. But this is
The capabilities headers will be relataive stable once completely
written (maybe after the featues are supported by drivers).
Now ESP32 and ESP32-S2 drivers are relative stable, making it a good
time to combine all these caps.h into one soc_caps.h
This cleanup also move HAL config and pin config into separated files,
to make the responsibilities of these headers more clear. This is
helpful for the stabilities of soc_caps.h because we want to make it
public some day.
For getting secure_version field in anti rollback case, bootloader tries
to map whole firmware partition but fails for cases where partition size
is beyond available MMU free pages capacity.
Fix here insures to map only required length upto application descriptor
size in firmware partition.
Closes https://github.com/espressif/esp-idf/issues/5911
1. The 2nd bootloader always call `rom_spiflash_unlock()`, but never help to clear the WEL bit when exit. This may cause system unstability.
This commit helps to clear WEL when flash configuration is done.
**RISK:** When the app starts, it didn't have to clear the WEL before it actually write/erase. But now the very first write/erase operation should be done after a WEL clear. Though the risk is little (all the following write/erase also need to clear the WEL), we still have to test this carefully, especially for those functions used by the OTA.
2. The `rom_spiflash_unlock()` function in the patch of ESP32 may (1) trigger the QPI, (2) clear the QE or (3) fail to unlock the ISSI chips.
Status register bitmap of ISSI chip and GD chip:
| SR | ISSI | GD25LQ32C |
| -- | ---- | --------- |
| 0 | WIP | WIP |
| 1 | WEL | WEL |
| 2 | BP0 | BP0 |
| 3 | BP1 | BP1 |
| 4 | BP2 | BP2 |
| 5 | BP3 | BP3 |
| 6 | QE | BP4 |
| 7 | SRWD | SRP0 |
| 8 | | SRP1 |
| 9 | | QE |
| 10 | | SUS2 |
| 11 | | LB1 |
| 12 | | LB2 |
| 13 | | LB3 |
| 14 | | CMP |
| 15 | | SUS1 |
QE bit of other chips are at the bit 9 of the status register (i.e. bit 1 of SR2), which should be read by RDSR2 command.
However, the RDSR2 (35H, Read Status 2) command for chip of other vendors happens to be the QIOEN (Enter QPI mode) command of ISSI chips. When the `rom_spiflash_unlock()` function trys to read SR2, it may trigger the QPI of ISSI chips.
Moreover, when `rom_spiflash_unlock()` try to clear the BP4 bit in the status register, QE (bit 6) of ISSI chip may be cleared by accident. Or if the ISSI chip doesn't accept WRSR command with argument of two bytes (since it only have status register of one byte), it may fail to clear the other protect bits (BP0~BP3) as expected.
This commit makes the `rom_spiflash_unlock()` check whether the vendor is issi. if so, `rom_spiflash_unlock()` only send RDSR to read the status register, send WRSR with only 1 byte argument, and also avoid clearing the QE bit (bit 6).
3. `rom_spiflash_unlock()` always send WRSR command to clear protection bits even when there is no protection bit active. And the execution of clearing status registers, which takes about 700us, will also happen even when there's no bits cleared.
This commit skips the clearing of status register if there is no protection bits active.
Also move the execute_flash_command to be a bootloader API; move
implementation of spi_flash_wrap_set to the bootloader
Summary of changes:
- bootloader_clock split into *_clock_init and *_clock_loader.
Only esp_clk_apb_freq is in *_clock_loader.
- bootloader_common moved out of loader; functions needed in loader
(or, referenced from bootloader_utility) were moved into
bootloader_common_loader.c.
- assert and abort moved into bootloader_panic, made part of the
loader
- rtc_clk and rtc_time made part of loader
* changing dependencies from unity->cmock
* added component.mk and Makefile.projbuild
* ignore test dir in gen_esp_err_to_name.py
* added some brief introduction of CMock in IDF
Sometimes the flash size read from bootloader is not correct. This may
forbid SPI Flash driver from reading the the area larger than the size
in bootloader header.
When the new config option is enabled, the latest configured
ESPTOOLPY_FLAHSIZE in the app header will be used to override the value
read from bootloader header.
bootloader_support: Fix bootloader_common_get_sha256_of_partition(), can handle a long image
Closes IDFGH-3594
See merge request espressif/esp-idf!9509
Allows booting in QIO/QOUT mode or with PSRAM on ESP32-PICO-V3 and
ESP32-PICO-V3-O2 without any config changes.
Custom WP pins (needed for fully custom circuit boards) should still be compatible.
esp32/esp32s2: Reduce using ESP_EARLY_LOGx and move some code after the stdout initialization in startup code
Closes IDFGH-3367
See merge request espressif/esp-idf!8904
Reduces write cycles, and useful on ESP32 ECO3 as UART_DIS_DL is protected by
the same efuse.
Also fixes accidental macro definition introduced in 7635dce502
flash_encryption: modify additional efuses burning method to fix them are not being written
flass_encryption: burn efuse to disable boot from RAM space
flash_encryption: added better checking for key generation state plus set read and write protect for them
soc esp32s2: Add register-level bit definitions for read & wrote protect bits
esp32s2: Fixes for flash encryption
- Write efuses in a batch
- Fix some detection of whether existing efuse blocks are read/write protected
flash_enctryption: enabled flash encryption example on esp32s2
bootloader: raise WDT overflow value providing sufficient interval to encrypt app partition
flash_ encrypt: Fixed the TODOs on flash encryption key generation for esp32s2
flash_encryption: added secure boot features to flash enctryption for esp32s2
bootloader: leave only esp32s2 compatible potentially insecure options on menuconfig.
flash_encryption: removed secure boot version 1 from esp32s2 encryption code
flash_encryption: added CONFIG_SECURE_FLASH_REQUIRE_ALREADY_ENABLED option for esp32s2
flash_encryption: fixed the count of left plaintext flash
flash_encryption: disable dcache and icache download when using encryption in release mode
flash_encryption: add cache potentally insecure options for s2 chips
flash_encryption: fixed bug which bricked some chips in relase mode
If BLK2 is empty then it's OK to continue with a warning (otherwise it may spook users into thinking
something this is wrong, but this is the expected workflow.)
If BLK2 is not empty and doesn't match then we need to fail because it won't be possible to
trust the signature.
Previous method was to write-protect this efuse, however on ECO3
the write protect field also covers the UART_DOWNLOAD_DIS efuse.
Doing it this way keeps the possibility of disabling UART download
mode, later.
This commit updates the watchdog timers (MWDT and RWDT)
in the following ways:
- Add seprate LL for MWDT and RWDT.
- Add a combined WDT HAL for all Watchdog Timers
- Update int_wdt.c and task_wdt.c to use WDT HAL
- Remove most dependencies on LL or direct register access
in other components. They will now use the WDT HAL
- Update use of watchdogs (including RTC WDT) in bootloader and
startup code to use the HAL layer.
In commit 02d2903e39, mbedtls was
updated to release v2.16.5, where it was made mandatory to initialize
mbedtls_ctr_drbg_context before using same. It was fixed in wpa supplicant
but missed out in secure boot v2 verification code. This commit
fixes that.
Goal is that multiple faults would be required to bypass a boot-time signature check.
- Also strengthens some address range checks for safe app memory addresses
- Change pre-enable logic to also check the bootloader signature before enabling SBV2 on ESP32
Add some additional checks for invalid sections:
- Sections only partially in DRAM or IRAM are invalid
- If a section is in D/IRAM, allow the possibility only some is in D/IRAM
- Only pass sections that are entirely in the same type of RTC memory region
On the ESP32S2, rtc_clk_cal(RTC_CAL_RTC_MUX) measures the frequency
of the 90kHz RTC clock regardless of the selected slow clock
frequency. Keep track which clock is selected and pass the argument
to rtc_clk_cal accordingly.
fix clock choices
update rtc 32k xtal code for s2
missed api in rtc.h
bootloader_clock: update for S2
1. use spi functions in rom
2. remove unnecessary GPIO configurations.
3. remove unnecessary dummy settings.
4. enable dummy out function
5. flash and psram have independent timing setting registers.
6. no need to set 1.9v for LDO in 80Mhz
7. set IO driver ability to 1 by default.
8. no need to use GPIO matrix on esp32s2, IO MUX is recommended
9. enable spi clock mode and IO mode settings
1. Delete bootloader_clock_get_rated_freq_mhz, esp32s2 do not need it right now
2. Remove bootloader_flash_gpio_config () because it has the same function as bootloader_flash_dummy_config
DISABLED_FOR_TARGETS macros are used
Partly revert "ci: disable unavailable tests for esp32s2beta"
This partly reverts commit 76a3a5fb48.
Partly revert "ci: disable UTs for esp32s2beta without runners"
This partly reverts commit eb158e9a22.
Partly revert "fix unit test and examples for s2beta"
This partly reverts commit 9baa7826be.
Partly revert "efuse: Add support for esp32s2beta"
This partly reverts commit db84ba868c.
* Don't bother checking the chip revision if it looks like the partition
doesn't really contain an app
* Don't print the "info" level about the revision & min revision unless
we're in the bootloader (otherwise it gets printed at random times
during the OTA process)
bootloader_random_enable() and bootloader_random_disable() functions
can be used in app.
This MR added the protection for shared CLK_EN and RST_EN registers.
and all ECDSA to be disabled if secure boot is not enabled
Previously if ECDSA disabled in config then secure_boot_signatures.c would
fail to build (whether or not secure boot was enabled).
To avoid breaking apps that might be using the signature scheme with custom OTA
without enabling secure boot signatures in config, this change just disables
this functionality if unavailable in mbedTLS config.
Possible fix for root cause of https://github.com/espressif/esp-idf/pull/3703
Commit 8cd04c80 has added a dependency of efuse component on
esp_clk_apb_freq, however there was no definition of this function in
the bootloader context.
Reported at https://esp32.com/viewtopic.php?f=13&t=12035
This saves time when waking up from deep sleep, but potentially decreases
the security of the system. If the application able to modify itself
(especially areas that are loaded into RAM) in flash while running
without crashing or is modifies the cached bits of information about
what was last booted from the bootloader, this could cause security
issues if the user does a "deep sleep reset" since the full validation
is skipped.
Signed-off-by: Tim Nordell <tim.nordell@nimbelink.com>
No need to take this step if we are not doing image validation. The
obfuscation only buys us a tiny bit of "security" anyways since the
main parts of flash are memory mapped, too. This saves a little bit of
wake-up time when waking up from deep sleep when the
BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP option is set.
Signed-off-by: Tim Nordell <tim.nordell@nimbelink.com>
