1. separate rom include files and linkscript to esp_rom
2. modefiy "include rom/xxx.h" to "include esp32/rom/xxx.h"
3. Forward compatible
4. update mqtt
In the situation when bootloader was compiled for 240MHz, and app was
compiled for 160MHz, and the chip is a revision 0 chip, the
bootloader will assume that the application has also been running at
240MHz. This will cause the chip to lock up later. Modify this to use
a run time check of DPORT_CPUPERIOD_SEL, which indicates which of the
PLL frequencies was used.
Closes https://github.com/espressif/esp-idf/issues/2731.
Added:
* set a secure version in app/bootloader.
* description anti-rollback to ota part
* emulate the secure_version write and read operations
* efuse_em partition.
* a description about a rollback for native_ota_example.
Closes: TW26335
Bootloader used to calculate the number of cache pages assuming that
load address was aligned, while in reality load address for DROM and
IROM was offset by 0x20 bytes from the start of 64kB page. This
caused the bootloader to map one less page if the size of the image
was 0x4..0x1c less than a multiple of 64kB.
Reported in https://esp32.com/viewtopic.php?f=13&t=6952.
Added a new structure esp_app_desc_t. It has info about firmware:
version, secure_version, project_name, time/date build and IDF version.
Added the ability to add a custom structure with a description of the firmware.
The esp_app_desc_t is located in fixed place in start of ROM secotor. It is located after structures esp_image_header_t and esp_image_segment_header_t.
app_version is filed from PROJECT_VER variable (if set in custom make file) or PROJECT_PATH/version.txt or git repo (git describe).
Add API to get app_desc from partition.
If zero-overhead loop buffer is enabled, under certain rare conditions
when executing a zero-overhead loop, the CPU may attempt to execute an invalid instruction. Work around by disabling the buffer.
ROM definition of `abort` was removed in 9240bbb. The old definition
resulted in a panic due to a jump to a null pointer (abort member in
ROM stub table was zero). The new definition triggers a debug
exception if JTAG is connected, or goes into an infinite loop to be
reset by the WDT.
When CONFIG_ESP32_RTCDATA_IN_FAST_MEM is enabled, RTC data is placed
into RTC_FAST memory region, viewed from the data bus. However the
bootloader was missing a check that this region should not be
overwritten after deep sleep, which caused .rtc.bss segment to loose
its contents after wakeup.
Allows OTA updates to be secured via signature checks, without requiring the overhead or complexity
of a full secure boot implementation.
Uses same signing mechanisms (build system and/or espsecure.py as Secure Boot).
Requires:
* [ ] More testing
* [ ] Documentation
Added bootloader_common_get_sha256_of_partition() and esp_partition_get_sha256() - get or calculate SHA-256
digest for app and data partitions.
Added bootloader_sha256_hex_to_str() - helps to print SHA-256 digest
Added esp_partition_check_identity() - compares two partitions by SHA-256 digest
Refactoring a function esp_image_load() in bootloader space to esp_image_verify() and
bootloader_load_image(). Old name function esp_image_load is deprecated
and will remove in V4.0 version.
spi_flash/sim: Fix error test_host. Add stub for bootloader_common_get_sha256_of_partition in sim/stubs
If we have the partition table without any ota_apps but in ota_data have
valide entry, in this case we get an error(hang). This commit fix this
case. If bs->app_count is zero when selecting the factory app.
Closes https://github.com/espressif/esp-idf/issues/2218
* Fixes some "noreturn" functions in bootloader utils which did return (causing fatal CPU
exceptions).
* Marks bootloader entry as "noreturn", preventing "user code done" from stalling boot
Partial fix for https://github.com/espressif/esp-idf/issues/1814 TW20016
(Comprehensive fix for this issue will be enabling WDT during bootloader, coming shortly.)
Because address space is mapped in 64KB pages, it was possible for unauthenticated data after the
app .bin to become mapped into the flash cache address space.
This problem is solved by 2 changes:
* "esptool elf2image --secure-pad" will pad the image so that the signature block ends close to the
64KB boundary. Due to alignment constraints it will be 12 bytes too short after signing (but
with flash encryption, these 12 bytes are still encrypted as part of the last block and can't be
arbitrarily changed).
* By default, secure boot now requires all app partitions to be a multiple of 64KB in size.
components/spi_flash/partition.c: In function 'load_partitions':
components/spi_flash/partition.c:179:66: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
strncpy(item->info.label, (const char*) it->label, sizeof(it->label));
^
Moved useful functions from wrapped assert functions, because option `CONFIG_OPTIMIZATION_ASSERTIONS_DISABLED=y` will remove this functions.
Closes https://github.com/espressif/esp-idf/issues/2068
IDF had two defines ESP_PARTITION_TABLE_OFFSET and ESP_PARTITION_TABLE_ADDR. They were the same and equal by 0x8000.
A define ESP_PARTITION_TABLE_ADDR was removed from IDF.
A define ESP_PARTITION_TABLE_OFFSET depends on option CONFIG_PARTITION_TABLE_OFFSET in Kconfig.
Now using only #define ESP_PARTITION_TABLE_OFFSET CONFIG_PARTITION_TABLE_OFFSET
Allows you to move the partition table, it gives more space for the bootloader.
Added a new utility - parttool.py. This utility can search for the offset and/or size of the partitions by name and type/subtype. Use for getting APP_OFFSET and PHY_DATA_OFFSET.
The linker(esp32.bootloader.ld) made changes that allow you to write a custom bootloader code more.
TW14125
Added feature:
- reset firmware to Factory app.(by long pressing of the button)
- boot Test app. (by long pressing of the button)
- Added feature erase data partitions from factory reset.
TW10281
TW10280
The following mbedTLS APIs have been deprecated and replaced with the
new ones which return error codes:
mbedtls_shaX_starts -> mbedtls_shaX_starts_ret
mbedtls_shaX_update -> mbedtls_shaX_update_ret
mbedtls_shaX_finish -> mbedtls_shaX_finish_ret
mbedtls_shaX_process -> mbedtls_shaX_internal_process
Update hardware implementations of SHA functions, and other IDF
components which used above functions, to use new versions.
* Philosophical: "explicit is better than implicit".
* Practical: Allows useful errors if invalid directories given in components as the defaults aren't
always used. Also trims the -I path from a number of components that have no actual include
directory.
* Simplifies knowing which components will be header-only and which won't
Disables app image integrity checks when running under OpenOCD control.
Allows setting breakpoints in flash before application start (just after reset).
1. Bootloader reads SPI configuration from bin header, so that the burning configuration can be different with compiling configuration.
2. Psram mode init will overwrite original flash speed mode, so that users can change psram and flash speed after OTA. 3. Flash read mode(QIO/DIO…) will not be changed in app bin. It is decided by bootloader, OTA can not change this mode.
4. Add read flash ID function, and save flash ID in g_rom_flashchip
5. Set drive ability for all related GPIOs
6. Check raise VDDSDIO voltage in 80Mhz mode
7. Add check flash ID and update settings in bootloader
8. Read flash ID once and keep in global variable
9. Read flash image header once and reuse the result
Tested cases:
1. Test new and old version of bootloader
boot Flash 20M —> app Flash 80M + Psram 80M
boot Flash 40M —> app Flash 80M + Psram 80M
boot Flash 80M —> app Flash 80M + Psram 80M
boot Flash 20M —> app Flash 80M + Psram 40M
boot Flash 40M —> app Flash 80M + Psram 40M
boot Flash 80M —> app Flash 80M + Psram 40M
boot Flash 20M —> app Flash 40M + Psram 40M
boot Flash 40M —> app Flash 40M + Psram 40M
boot Flash 80M —> app Flash 40M + Psram 40M 2. Working after esp_restart reboot.
Need to make the bootloader modular so that users can redefine its functional part.
- refactoring and moving functions to the bootloader_support component
- Changed function to `void` bootloader_utility_load_image(...);
TW19596
1. External 32kHz crystal is started for too long or it may not start at all. It is often observed at the first start.
2. At the first start, it is possible that the crystal did not start. And the recorded period was recorded as 0. Which led to a division error by zero during the transition to the deep sleep mode (Maybe somewhere else).
3. Added a unit test to test a new method of oscillation an external crystal.
4. Added a new method of oscillating of an external crystal. The legs of the crystal are fed with a 32 kHz frequency.
The new method eliminates these errors.
Added unit test: `\esp-idf\components\soc\esp32\test\test_rtc_clk.c`: `make TEST_COMPONENTS=soc`
- 8 Test starting external RTC crystal. Will pass.
`Bootstrap cycles for external 32kHz crystal` - is specified in the file Kconfig by default 100.
QA tested a new method of oscillation the crystal on 25 boards. The supply of square waves on the crystal showed a 100% result in contrast to the previous method of launching the crystal. After the tests, the old method was deleted.
Closes TW19143
Makes app image booting more reliable (256-bit rather than 8-bit verification.)
Some measurements, time to boot a 655KB app.bin file and run to app_main() execution.
(All for rev 1 silicon, ie no 340ms spurious WDT delay.)
80MHz QIO mode:
before = 300ms
after = 140ms
40MHz DIO mode:
before = 712ms
after = 577ms
40MHz DIO mode, secure boot enabled
before = 1380ms
after = 934ms
(Secure boot involves two ECC signature verifications (partition table, app) that take approx 300ms each with 80MHz CPU.)
1. When dual core cpu run access DPORT register, must do protection.
2. If access DPORT register, must use DPORT_REG_READ/DPORT_REG_WRITE and DPORT_XXX register operation macro.
1) fixed SPI_read_status: added check for flash busy flag in matrix mode
2) fixed SPI_page_program: enable write before writing data to SPI FIFO
3) SPI flash ROM funcs replacement is controlled via menuconfig option