It seems that reading from QSPI could corrupt the data if the read_size is not aligned with 4.

Build the image for Musca-A with GCC and try to bootup. MCUBoot copies the image to SRAM in one go and validates there. It means that a huge amount of data, in my case 0x84afa bytes are read from flash and copied to SRAM directly. In my case the penultimate byte was corrupted during the copy and therefore the image validation failed. I have modified the code to read 0x84afc byte form the QSPI, which is 4 byte aligned and in this case the validation succeeded.

I attached two file:
sram.bin: The dumped memory from 0x1002000 till +0x84afa
tfm_signed.bin: The signed tfm binary which is the actual QSPI content, but it is padded up to 1MB. So the lot of 0xFF content can be ignored.

Binary comparing the two file it reveals that the byte at 0x84af8 address are different.

For me make the read_size aligned with 4 solved the problem, which might only Musca-A specific, but further investigation would be necessary and a fix to TF-M should be upstreamed.

Symptoms:

[INF] Starting bootloader
[INF] Primary slot: version=1.1.0+0
[INF] Secondary slot: Image not found
[INF] RAM loading to 0x10020000 is succeeded.
[ERR] Image in the primary slot is not valid!
[INF] Removing image from SRAM at address 0x10020000 [ERR] Unable to find bootable image