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
Previously, hardware SHA engine "locks" were mutex semaphores. This meant that the task which
started a particular SHA session (in hardware) needed to finalise that session, or an invalid
FreeRTOS state was created.
Replace with binary semaphore which can be shared between tasks.
Includes a unit test, but unit test doesn't crash even without this fix
(some other unknown condition is required).
This commit resolves a blocking in esp_aes_block function.
Introduce:
The problem was in the fact that AES is switched off at the moment when he should give out the processed data. But because of the disabled, the operation can not be completed successfully, there is an infinite hang. The reason for this behavior is that the registers for controlling the inclusion of AES, SHA, MPI have shared registers and they were not protected from sharing.
Fix some related issue with shared using of AES SHA RSA accelerators.
Closes: https://github.com/espressif/esp-idf/issues/2295#issuecomment-432898137
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.
If two different types of SHA hashes were active in the hardware
concurrently, a race condition meant the SHA unit could be incorrectly
reset leading to all-zero results.
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.
SHA hardware allows each of SHA1, SHA256, SHA384&SHA512 to calculate digests
concurrently.
Currently incompatible with AES acceleration due to a hardware reset problem.
Ref TW7111.
Should protect against concurrent use of hardware crypto primitives,
with good performance.
Not necessary to call esp_aes_acquire_hardware(),
esp_sha_acquire_hardware(), etc when using these APIs. These are
provided for external users calling the hardware crypto hardware
directly, to coexist with this implementation.
