This reverts commit bf35ef1ce7.
It has been noticed that there are scenarios where even though firmware is not enabled
with flash encryption config feature, it should be able to write to encrypted partitions.
This revert adds the feature back which was removed around v4.0 timelines, and same
change will be backported to all releases (upto v4.0) for consistency.
In commit 309376f51a, it seems like regression
was added to use ROM level API for disabling flash write protection. This
started random firmware crashes (on specific modules) with exception
`IllegalInstruction` during encrypted flash writes.
Fix here removes relevant ROM API call, since disabling flash write protection
is already ensured by caller of this API.
Closes https://github.com/espressif/esp-idf/issues/5467
The SPI bus lock on SPI1 introduces two side effects:
1. The device lock for the main flash requires the
`CONFIG_FREERTOS_SUPPORT_STATIC_ALLOCATION` to be selected, however this
option is disabled by default in earlier IDF versions. Some developers
may find their project cannot be built by their old sdkconfig files.
2. Usually we don't need the lock on the SPI1 bus, due to it's
restrictions. However the overhead still exists in this case, the IRAM
cost for static version of semaphore functions, and the time cost when
getting and releasing the lock.
This commit:
1. Add a CONFIG_SPI_FLASH_BYPASS_MAIN_LOCK option, which will forbid the
space cost, as well as the initialization of the main bus lock.
2. When the option is not selected, the bus lock is used, the
`CONFIG_FREERTOS_SUPPORT_STATIC_ALLOCATION` will be selected explicitly.
3. Revert default value of `CONFIG_FREERTOS_SUPPORT_STATIC_ALLOCATION`
to `n`.
introduced in 49a48644e4.
Closes https://github.com/espressif/esp-idf/issues/5046
We used to manually specify the CS id. However after the SPI bus lock is
introduced, the lock is responsible to assign the CS lines and provide
the CS id. The esp_flash driver now depends on the ID assigned by the
SPI bus lock, the configuration field is deprecated.
The issue is introduced in 571864e8ae. The
esp_flash API tries to clear the QE bit when the flash is not working in
quad modes.
However this introduces a regression, compared to earlier versions and
the legacy API. When the chip is not detected, the generic chip driver
is used, which cannot 100% handle the QE bit properly for all flash
vendors. There may be some flash chips (e.g. MXIC) that can be used in
dual modes by legacy API, but output wrong data when the esp_flash API
clears the QE bit in a wrong way.
This commit reverts the QE force clearing behavior, so that it's safer
for the generic chip driver to work under dual modes.
The default chip driver (chip_generic) use command 01H + 2 bytes to
clear the QE bit. However this will accidently change the configuration
register value of the MXIC chip.
MXIC chip driver is added to fix that.
Allocation of the temporary internal buffer will now repeat until a small enough buffer can be
allocated, and only fail if less than a 256 byte block of internal RAM is free.
Adds unit test for the same, and generic test utility for creating memory pressure.
Previously would try allocate buffer of minimum size 16KB not maximum size 16KB, causing
out of memory errors for any large reads, or if less than 16KB contiguous free heap.
Also, if using legacy API and internal allocation failed then implementation would abort()
instead of returning the error to the caller.
Added test for using large buffers in PSRAM.
Closes https://github.com/espressif/esp-idf/issues/4769
Also reported on forum: https://esp32.com/viewtopic.php?f=13&t=14304&p=55972
