search

ARMmbed / mbed-os-tf-m-regression-tests

An Mbed OS application that runs the TF-M regression tests
2 stars 12 forks source link

WIP: Musca S1: Erase Protected Storage in QSPI flash #112

Closed LDong-Arm closed 3 years ago

LDong-Arm commented 3 years ago

PSA storages which include Protected Storage (PS) and Internal Trusted Storage (ITS) should be erased prior to tests to avoid residual data interfering with storage test cases. The .hex test images for Musca S1 generated by test_psa_target.py already erases the ITS on the MRAM (internal storage). But TF-M v1.3 has relocated the PS to the QSPI flash.

This commits adds the erase of the PS area at 0x200000 - 0x205000 but extended to 0x210000 bytes to match DAPLink's flash alignment. See https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/target/musca_s1/partition/flash_layout.h?h=TF-Mv1.3.0#n34

Note: According to experiments, flashing only succeeds if every byte is set to 0x00, and 0xFF results in FAIL.txt in the mount.

Patater commented 3 years ago

Any ideas why 0xFF doesn't work?

Patater commented 3 years ago

I verified the memory region and syntax in the script looks good.

LDong-Arm commented 3 years ago

Any ideas why 0xFF doesn't work?

I need to look into it. Also, images generated by this PR work on my local board but can't be flashed onto CI boards.

LDong-Arm commented 3 years ago

Any ideas why 0xFF doesn't work?

It looks like this PR doesn't work. Somehow Musca S1's DAPLink (at least the latest version on my board) always reports a success if a region is filled with 0x00, even if the address range is completely non-existent. So apparently the data isn't actually flashed. Filling an invalid region with any non-zero data results in a flash failure. I'm not sure this is a correct behaviour.

A different approach I'm going to try is let Mbed OS do the erase. We may be able to use https://github.com/ARMmbed/mbed-os/blob/mbed-os-6.10.0/targets/TARGET_ARM_SSG/TARGET_MUSCA_S1/flash_api_qspi.c

Closing this PR.

LDong-Arm commented 3 years ago

Okay, it turns out that the QSPI flash (mapped to 0x0200000) is only programmable by DAPLink when the BOOT switch is at QSPI. As we boot from the MRAM, we just can't erase the QSPI flash using a hex image.

LDong-Arm commented 3 years ago

We can add a "troubleshooting" section to README to ask users to temporarily switch to QSPI boot and flash an eraser hex image, but this won't work with our CI. Erasing it programmatically with an Mbed application is preferable.