According to the application note in SD Card Physical Specification:
> The host shall set ACMD41 timeout more than 1 second to abort repeat
of issuing ACMD41 when the card does not indicate ready. The timeout
count starts from the first ACMD41 which is set voltage window
in the argument.
Previously, the timeout was exactly one second, and this caused
certain larger-capacity cards to "time out", because they couldn't
finish initialization process in time.
ACMD41 argument is different between SD mode and SPI mode.
In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD
mode, the bits reflecting the host's OCR should be zero.
Previously, we used to set these bits the same way as for the SD mode.
This has caused certain cards to fail initializing, apparently their
controllers have checked the ACMD41 argument more strictly and refused
to finish initialization, resulting in an error such as
sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107
(Note that this error may have other causes than the one fixed in
this commit. For example, if the card doesn't have a sufficient and
stable power supply, it may also fail to complete the internal
initialization process, and will never clear the busy flag in R1
response.)
Closes https://github.com/espressif/esp-idf/issues/6686
Closes https://github.com/espressif/esp-idf/issues/10542
This commit fixes a bug where if multiple concurrent USBH API calls trigger
multiple events on the same device, some events will be lost. As a result,
those lost events don't get processed by the subsequent usbh_process() call.
Secure version in the image header is only available for the application
image. However, for certain security workflows, bootloader verifies
itself (own image) and hence the secure version check during that must be
avoided.
Regression introduced in recent commit-id: 3305cb4d
Tested that both secure boot and flash-enc workflows work correctly
with the anti-rollback scenario.
Some additional checks related to secure version of the application in
anti-rollback case have been added to avoid any attempts to boot lower
security version but valid application (e.g., passive partition image).
- Read secure_version under sha256 protection
- First check has been added in the bootloader to ensure correct secure
version after application verification and loading stage. This check
happens before setting up the flash cache mapping and handling over
the final control to application. This check ensures that application
was not swapped (e.g., to lower security version but valid image) just
before the load stage in bootloader.
- Second check has been added in the application startup code to ensure
that currently booting app has higher security version than the one
programmed in the eFuse for anti-rollback scenario. This will ensure
that only the legit application boots-up on the device for
anti-rollback case.
