Issue is that when users creates a custom bootloader from
$IDF_PATH/components/bootloader. Parent project build uses the copy but
bootloader subproject build uses the original still. The issue is solved
by passing the custom bootloader as extra component directory so
bootloader build knows to use the new copy (itself) in the build.
In some cases, linker could choose to use ROM functions instead of the
ones defined in IDF.
For functions used in ROM stub table, this would lead to infinite
recursion when the corresponding function was called from ROM.
For crypto functions, some of these were modified in IDF, and
incompatible with ROM counterparts.
It is possible to utilize some of the routines related to otadata
partition validation, after firmware image is downloaded to RAM. Hence
these routines should be part of app cpu cache, so that they do not
get overwritten by firmware.
Signed-off-by: Mahavir Jain <mahavir@espressif.com>
* 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.)
When 2nd stage bootloader loads the ROM bootloader, it prints a
message similar to "entry 0x40080xxx", which idf_monitor decodes
(using application ELF file) as one of the reset vectors (xxx is <
400h). This moves the iram_seg of bootloader 1k up to prevent overlap
of bootloader .text and application vectors, making the output look
nicer. There is still a chance that the entry point decodes as some
symbol in application ELF file, but at least it won't have
"Exception" in its name.
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
Refactor IDF "project" functionality under a wrapping of the default
"project" command, so we can tweak it a bit...
Will need more testing in other environments.
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
This commit adds support for CPU max freqeuency rating
bits in CPU. Bootloader will now print an error if attempting
to 160MHz rated ESP32 at 240MHz.
EFUSE_CHIP_VER_RESERVE has been replaced by the
frequency rating bits. Dependancies on EFUSE_CHIP_VER_RESERVE
have been changed to use EFUSE_CHIP_VER_PKG
Since 9a8c0392, XTAL frequency is set to 40MHz by default, and users
of 26MHz boards need to select 26MHz manually. Most users are not aware
of this change, and existing getting started guides do not mention that
XTAL frequency needs to be set for some boards. So users are left with
garbage output from UART without any clue what to check.
This change adds a warning in case specific XTAL frequency was set, and
it does not match automatically detected one. This should help users
fix the issue.
Regression introduced in 43e231c.
Thanks to @yanbe for pointing out issue in https://github.com/espressif/esp-idf/pull/955
This is a different fix, tries to keep the behaviour that 43e231c was aiming to correct (unnecessarily testing an
invalid slot more than once.)
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.)
