On flash program operation (either erase or write), if corresponding address has
cache mapping present then cache is explicitly flushed (for both pro and app cpu)
Closes https://github.com/espressif/esp-idf/issues/2146
* Writing >4 bytes to unaligned offsets would fail
* Writiing data from flash would fail (wrong buffer was used)
* Writing >8192 bytes from RAM would over-write data multiple times
Adds test cases for the above.
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
* Erase range operations allow preemption after each block or sector.
* Write operations allow preemption every 8KB of data.
* Reado operations allow preemption every 16KB of data.
spi_flash_unlock was missing spi_flash_guard_start, which caused cache
to be enabled during unlock operation, causing hard-to-trace crashes
and cache data corruption.
Without this, it's possible for stale information to be read from
cache via mmap, even if the MMU table entry had been invalidated
prior to writing flash (if the same MMU table entry was re-used after
writing flash.)
These functions are marked as inline and are called from functions which are in IRAM.
In release (-Os) builds, the compiler may decide not to inline these functions.
Placing these functions into IRAM explicitly works around this.
The following issues mentioned during MR!341 review were fixed:
1) Core dump test application description
2) Usage of CONFIG_ESP32_ENABLE_COREDUMP_TO_FLASH and CONFIG_ESP32_ENABLE_COREDUMP_TO_UART
3) FLASH_GUARD_START macro usage is fixed in flash API
4) Core dump module logging facility
5) cache util functions doc updated
6) interactive delay before print core dump to uart
7) core dump partion support in build system
1) PS is fixed up to allow GDB backtrace to work properly
2) MR!341 discussion: in core dump module: esp_panicPutXXX was replaced by ets_printf.
3) MR!341 discussion: core dump flash magic number was changed.
4) MR!341 discussion: SPI flash access API was redesigned to allow flexible critical section management.
5) test app for core dump feature was added
6) fixed base64 file reading issues on Windows platform
7) now raw bin core file is deleted upon core loader failure by epscoredump.py
Complimentary changes:
1) Partition table definitions files with core dump partition
2) Special sub-type for core dump partition
3) Special version of spi_flash_xxx
4) espcoredump.py is script to get core dump from flash and print useful info
5) FreeRTOS API was extended to get tasks snapshots
Flash encryption support
Flash encryption support in build system, tooling
To come in future MR:
* On-device key generation on first boot (for production devices), need to finalise testing of bootloader entropy seeding.
* spi_flash_encrypted_write to support non-32-byte block writes (at least optionally.)
* I think a lot of the bootloader_support component can possibly be rolled into "spiflash" and other components, to use a common API.
See merge request !240
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
SPI flash hardware sends 52h command, which is a 32KB erase.
There is a matching bug in the ROM SPIEraseArea code, unless
flashchip->block_size is modified first.
ROM SPIWrite routine can work with unaligned sources, so this check is unnecessary.
Furthermore, it breaks nvs_set_str and nvs_get_blob when data pointer is unaligned.
Also fix stray backslash in COUNTER_STOP macro
spi_flash_read and spi_flash_write currently have a limitation that source and destination must be word-aligned.
This can be fixed by adding code paths for various unaligned scenarios, but function signatures also need to be adjusted.
As a first step (since we are pre-1.0 and can still change function signatures) alignment checks are added, and pointer types are relaxed to uint8_t.
Later we will add handling of unaligned operations.
This change also introduces spi_flash_erase_range and spi_flash_get_chip_size functions.
We probably need something like spi_flash_chip_size_detect which will detect actual chip size.
This is to allow single application binary to be used on a variety of boards and modules.
