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.
- 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.
