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
* 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>
We fixed some flash bugs in bootloader, but for the users used the old
vrsion bootloader, they can not fix these bugs via OTA, the solution is
add these updates in app startup.
These updates include:
1. SPI flash gpio matrix and drive strength configuration
2. SPI flash clock configuration
3. SPI flash read dummy configuration
4. SPI flash cs timing configuration
5. Update flash id of g_rom_flashchip
Made MMU pages available check in `esp_image_format.c`
This now makes it possible to map and process bootoader image as well in chunks when image doesn't fit completely into available free pages.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
This MR improves existing flash encryption document to provide simplified steps
Adds two new modes for user: Development & Release
Adds a simple example
Supports encrypted write through make command
Still using ESP32_xxx prefix on all chips: CORE_DUMP, APP_TRACE
Still using the same config prefix and duplicate names in esp32 & esp32s2beta: SPIRAM, PM
For example, if a renamed option CONFIG_NEW is a bool with value "n", kconfiglib will not generate a define for it in the Kconfig file. The define (#define CONFIG_NEW 1) will only be generated if the option is "y" or "m".
However the compatibility definition was always generated: #define CONFIG_OLD CONFIG_NEW. This broke the #ifdef checks which depended on the old option names.
Using xxx_periph.h in whole IDF instead of xxx_reg.h, xxx_struct.h, xxx_channel.h ... .
Cleaned up header files from unnecessary headers (releated to soc/... headers).
When flash work in DIO Mode, in order to ensure the fast read mode of flash
is a fixed value, we merged the mode bits into address part, and the fast
read mode value is 0 (the default value).
Fixed the case when the first part of log was missed
this was happened when:
* CONFIG_CONSOLE_UART_CUSTOM option is selected (UART1)
* The selected CONSOLE_UART port is used also for the console component
* in code esp_restart() or abort() functions were called.
This MR removes the common dependency from every IDF components to the SOC component.
Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components.
But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components.
In CMAKE, we have two kinds of header visibilities (set by include path visibility):
(Assume component A --(depends on)--> B, B is the current component)
1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B)
2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only)
and we have two kinds of depending ways:
(Assume component A --(depends on)--> B --(depends on)--> C, B is the current component)
1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B)
2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B)
1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default.
2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it.
3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers
4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link)
This is a breaking change. Previous code may depends on the long include chain.
You may need to include the following headers for some files after this commit:
- soc/soc.h
- soc/soc_memory_layout.h
- driver/gpio.h
- esp_sleep.h
The major broken include chain includes:
1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h.
2. ets_sys.h no longer includes soc/soc.h
3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h
some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h
BREAKING CHANGE
This prevents a device from being bricked in case when both secure boot & flash encryption are enabled and encryption gets interrupted during first boot. After interruption, all partitions on the device need to be reflashed (including the bootloader).
List of changes:
* Secure boot key generation and bootloader digest generation logic, implemented inside function esp_secure_boot_permanently_enable(), has been pulled out into new API esp_secure_boot_generate_digest(). The enabling of R/W protection of secure boot key on EFUSE still happens inside esp_secure_boot_permanently_enable()
* Now esp_secure_boot_permanently_enable() is called only after flash encryption process completes
* esp_secure_boot_generate_digest() is called before flash encryption process starts
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
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.
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
