When two CPUs read the area of the DPORT and the area of the APB, the result is corrupted for the CPU that read the APB area.
And another CPU has valid data.
The method of eliminating this error.
Before reading the registers of the DPORT, make a preliminary reading of the APB register.
In this case, the joint access of the two CPUs to the registers of the APB and the DPORT is successful.
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.)
* 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. 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.
Confusion here is that original ROM has two functions:
* SPIReadModeCnfig() - sets mode, calls enable_qio_mode/disable_qio_mode
* SPIMasterReadModeCnfig() - As above, but doesn't set QIO mode in status register
However we never want to use the ROM method to set/clear QIO mode flag, as not all flash chips work this way. Instead we
do it in flash_qio_mode.c in bootloader.
So in both cases (ROM or "patched ROM") we now call SPIMasterReadModeCnfig(), which is now named
esp_rom_spiflash_config_readmode().
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
Flash operation complete flag was cleared by the core initiating flash
operation. If the other core was running an ISR, then IPC task could
be late to enter the loop to check s_flash_op_complete by the time next
flash operation started. If the flag is cleared on the CPU waiting on
this flag, then the race condition can not happen.
* 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.
The issue that cache entries are not invalidated correctly sometimes
can also be reproduced for non-encrypted flash as well.
This change updates the workaround to do Cache_Flush, enabling it for
non-encrypted flash, and adds a unit test.
Partition/SPI/OTA docs & OTA new functionality
* Update partition, SPI flash & OTA docs to reflect functionality changes
* Refactor OTA implementation to perform checks mentioned in API doc
* Add new functions to OTA API: esp_ota_get_running_partition() & esp_ota_get_next_update_partition() functions
* Add spi_flash_cache2phys() & spi_flash_phys2cache() functions to support esp_ota_get_running_partition()
See merge request !513
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.
