CMake: QSPIFBlockDevice: Guard unit test directory ...

In the QSPIFBlockDevice component we checked if BUILD_TESTING was
enabled before adding the QSPIFBlockDevice/UNITTESTS subdirectory. In
the parent blockdevice/CMakeLists.txt we added the QSPIFBlockDevice
subdirectory to the build under two separate conditions:

* when "QSPIF" is present in MBED_TARGET_LABELS
* when building only unit tests

This wasn't quite enough, as when we build greentea tests for some
targets QSPIF is enabled in MBED_TARGET_LABELS, causing the
QSPIFBlockDevice subdirectory and its unit tests to be added when
building greentea tests. This caused a test failure on targets which
enable QSPIF:

```
The following tests FAILED:
	 40 - qspif-unittest_NOT_BUILT (Not Run)
```

To fix this we need to specifically check that we're not building
greentea tests before adding the QSPIFBlockDevice/UNITTESTS directory to
the project.

Part of this issue is our reliance on MBED_TARGET_LABELS to pull
features in to the build. We should refactor our usage of
MBED_TARGET_LABELS and use CMake target dependencies where possible.
Then we wouldn't need to add subdirectories under various, often
conflicting, scenarios. Instead the targets would always be available
and we would just choose which ones to actually build in different cases
using CMake target linking.

Merge pull request #15050 from rwalton-arm/TF-Mv1.4.0 ...

Update to TF-M v1.4.0

TFM: MUSCA: Import partition maps from upstream ...

Import the latest partition headers from upstream. We no longer need to
patch the headers to define the BL2 macro as we now define it in the
scatter files for the MUSCA targets.

TFM: Remove BL2 macro workaround for mbed-cli1/ARMClang ...

We worked around an issue with mbed-cli1 not recognising the BL2 macro
from targets.json by adding patched versions of region_defs.h and
flash_layout.h for ARM_MUSCA targets. In the patched headers we defined
the BL2 macro to ensure it can be picked up by the ARM scatter files
that include the headers.

The current solution is not robust, because it means that the
aforementioned headers easily become out of date. A workaround of
defining the macros in the scatter files which need them was suggested
in https://github.com/ARMmbed/mbed-os/issues/14762

This commit applies the suggested changes to the ARM_MUSCA scatter
files.

PSA: Reinstate deprecated macro ...

PSA_ALG_AEAD_WITH_TAG_LENGTH has been replaced with
PSA_ALG_AEAD_WITH_SHORTENED_TAG upstream. We could just update
psa_util.h to use the new macro, but we still have some targets that
only support older versions of PSA, so we reinstate the removed macro.

psa: Include mbedtls_svc_key_id.h for TF-M ...

We have added definitions that are needed by Mbed TLS's PSK key exchange
but missing from TF-M's PSA to `mbedtls_svc_key_id.h`. To pick up those
definitions, TF-M's `psa/crypto_values.h' needs to include
`mbedtls_svc_key_id.h`.

tfm: Add mbedtls_ecc_group_to_psa.h to crypto_extra.h ...

Include mbedtls_ecc_group_to_psa.h from crypto_extra.h so that clients
of PSA within Mbed OS do not need to behave differently depending on
which PSA implementation they are using.

This solution is not ideal as it makes it more difficult to update the
TF-M-provided psa/crypto_extra.h. We'll have to see what other options
we have for including additional headers based on the Mbed OS
configuration.

targets: ARM_MUSCA: Update tfm_target_names ...

The directory structure upstream has changed. Now ARM_MUSCA board
support has been moved under an "arm" subdirectory. Update targets.json
with the new locations.

tfm: Move tfm_ns_interface.c ...

tfm_ns_interface.c is intended to be overriden by clients to support
different targets. We copy this file from upstream into the mbed-os
platform library. We also have a specific "strong" overridden version
for the NU_M2354 target, which is located in its target library.
Previously the implementations in the platform library were decorated
with __attribute__(weak), and we provided a strong definition for the
NU_M2354 target. This worked fine because of weak linking, the linker
will pick the first "strong" definition and use that, avoiding any ODR
violations. However, upstream have removed __attribute__(weak) from the
function definitions, which caused multiply defined symbol errors when
trying to build the NU_M2354 target.

To work around the above issue, we remove the common definition in the
platform library; instead we copy the file to the Musca B1 and Musca S1
target libaries. This means the appropriate tfm_ns_interface.c is only
included in the build when compiling for the specific target which uses
it.

tools: tfm: Update bin_utils

"Update secure binaries for [('NU_M2354', 'GNUARM')]"

"Update secure binaries for [('ARM_MUSCA_S1', 'ARMCLANG')]"

"Update secure binaries for [('ARM_MUSCA_B1', 'ARMCLANG')]"

"Update directory platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST"

Merge pull request #15067 from ARMmbed/fix_flash_overflow_callback_big_test ...

Greentea: Fix flash overflown issue in callback_big test

Greentea: Fix flash overflown issue in callback_big test ...

The "Callback_big" greentea test has six test cases that require
a minimum above 36kb ROM to build all test cases. LPC1114 target
has only 32KB ROM memory, so the limit 6th test case to include
or exclude based on the target minimum ROM size.

Note:
In LPC1114 target, callback_big test has ROM overflow build issue
for both Mbed CLI1 and CLI2.

Merge pull request #15066 from ARMmbed/fix_platform_wait_ns_test_cmake ...

CMake: Fix platform wait_ns greentea test Cmake

CMake: Fix platform wait_ns greentea test Cmake ...

Mbed CLI 2 generates TARGET_ARM_FM macro as a string in mbed_config.cmake
under the MBED_TARGET_DEFINITIONS list. Fix the "if defined" check for
TARGET_ARM_FM by searching for the TARGET_ARM_FM string in the
MBED_TARGET_DEFINITIONS list. This allows us to skip or include the test from CMake.

Merge pull request #14989 from LDong-Arm/sfdp_sector_maps_multi ...

SFDP: Add support for multiple configurations and sector maps

Merge pull request #15022 from jeromecoutant/PR_STM32U5 ...

STM32U5 new family introduction

CYW9P62S1_43012EVB_01: Enable QSPI and QSPIF ...

QSPIF was disabled on CYW9P62S1_43012EVB_01 because its S25FS512S
flash chip has multiple configurations but our SFDP parser did not
support this scenario. Now having added support for this, we can
enable QSPIF (the component label for QSPIFBlockDevice) and QSPI
(the label for Quad-SPI communication).

SFDP: Add support for multiple configurations and sector maps ...

A Sector Map Parameter Table contains a sequence of the following
descriptors:
* (Optional) configuration detection command descriptors, one for
each command to run to determine the current configuration. This
exists only if the flash layout is configurable.
* Sector map descriptors, one for each possible configuration. On
a flash device with a non-configurable layout, there is only one
such descriptor.

Previously we only supported the non-configurable case with a single
descriptor. This commit adds support for multiple configurations.

QSPIFBlockDevice: Add unit test for the S25FS512S quirk ...

Add a test case to verify that the quirk on `CR1NV` and `CR3NV`
registers get applied by `QSPIFBlockDevice` when the flash device
is S25FS512S.

`QSPIFBlockDevice` depends on the SFDP functions and the `QSPI` class,
but we can't use gMock on them because:
* SFDP functions are global functions, whereas gMock only supports
mocking class member functions.
* A mocked class is injected into the test subject, but passing a
preexisting `QSPI` instance into `QSPIFBlockDevice` is not possible
(unless we resort to pointers). For details, see comments in
test_QSPIFBlockDevice.cpp.

So fakes of the `QSPI` class and any SFDP functions involved are
defined in test_QSPIFBlockDevice.cpp.

QSPIFBlockDevice: Add quirk to ignore overlaying sectors on S25FS512S ...

The entire flash chip S25FS512S consists of uniform 256KB sectors.
Additionally, it has three configurations:
* 0x01: Eight 4KB sectors (32KB in total) overlaying the start of
the first 256KB sector
* 0x03: Eight 4KB sectors (32KB in total) overlaying the end of the
last 256KB sector
* 0x05: No overlaying sectors

The active configuration is determined from bit fields of two
registers, CR1NV and CR3NV.

Mbed OS does not currently support partially overlaying sectors,
meaning that with eight 4KB sectors overlay a 256KB sectors, the
remaining 224KB (== 256KB - 8 * 4KB) of the big sector can't be
correctly handled. Supporting such scenario would involve a large
amount of rewriting in Mbed OS's BlockDevice, SFDP and their tests,
and may increase the code size.

So, this commit applies a quirk to always report configuration 0x05
(no overlaying sectors). Even if 0x01 or 0x03 is the real configuration,
they are compatible with the 0x05 configuration because 256KB sectors
exist in all cases.

Note: This quirk does *not* change actual configurations on hardware,
because registers CR1NV and CR3NV are one-time configurable (OTP) -
each bit field has a factory value of 0 and can be changed to 1 by the
user but not back to 0. So QSPIFBlockDevice avoids changing them.

QSPIFBlockDevice: Add quirk for inconsistent CR3NV register value ...

Cypress S25FS512S's SFDP table suggests that bit-1 of the register
CR3NV on 25FS512S should equal 1. But it is a known issue that the
value is actually 0 on hardware. So if we query the value of CR3NV
during configuration detection, we can't find a configuration that
matches the SFDP data. This issue has been discussed in the Linux MTD
(Memory Technology Devices) mailing list:
https://linux-mtd.infradead.narkive.com/ylHK6CyT/spi-nor-fs512s-incorrect-cr3nv-1-value

This commit adds a quirk to report bit-1 of CR3NV as 1.

Note: In Mbed OS, vendor-specific quirks can only be handled in block
devices. The SFDP functions assume data from hardware to be correct.
So this quirk is in the block device.

STM32U5: README update

STM32U5: targets.json

STM32U5 : B_U585I_IOT02A introduction

STM32U5 : NUCLEO_U575ZI_Q introduction

STM32U5 : STM32U5xxxxx sub-families