While building with ARM toolchain relocation warnings appears
This commit will fix it for MAX32625/30 targets.
The system interrupt function is defined as weak in startup file
and its overvides in other files, Becuase of the functions is overrites
while calling it in startup modile by B XXXXX probably compiler give
info purpose warnings... By using using . instead function name it says
go existing point to the compiler.
Warning detail:
https://www.keil.com/support/man/docs/armerr/armerr_dom1365073159742.htm
Signed-off-by: Sadik.Ozer <Sadik.Ozer@maximintegrated.com>
Add
- STM32G050K8Tx for all STM32G050x8 targets
- STM32G051K8Tx for all STM32G051x8 targets
- STM32G061K8Tx for all STM32G061x8 targets
- STM32G0B0RETx for all STM32G0B0xE targets
- STM32G0B1RETx for all STM32G0B1xE targets
Greentea tests run on microcontrollers, so any required drivers need
to be available and built.
Note: Even though unit tests do not require drivers, for ease of
maintenance there's no need to exclude those drivers when building unit
tests because a driver only gets enabled when the Mbed target matches.
When unit tests or unit test stubs get added as CMake targets, they
becomes part of the "all" target and get compiled when building the
whole project. When building greentea tests we need to disable unit
tests and stubs to avoid unnecessary compilation and errors.
The most common extension for static libraries is .a and CMake generates
it with both GCC and Arm toolchains. Mbed CLI 1 generates .ar files with
the Arm Compiler, but since Mbed CLI 2 uses memap.py to generate map
files too, both extensions should be permitted.
This fixes a warning when building greentea tests:
Malformed input found when parsing ARMCC map: _deps/greentea-client-build/libclient_userio.a(greentea_test_env.o)
Malformed input found when parsing ARMCC map: _deps/greentea-client-build/libclient_userio.a(greentea_test_env.o)
Malformed input found when parsing ARMCC map: _deps/greentea-client-build/libclient_userio.a(greentea_test_env.o)
...
which repeats over 30 times per test.
The HAL can_api stores an array of IDs in order to dispatch interrupts
to the correct CAN object. The drivers level CAN Class casts a pointer
to itself to an uint32_t, which is stored as the ID and then cast back
to a CAN * in order to call the correct handler. This results in
compilation failure when the size of an object pointer is greater than
uint32_t, for example when building on a PC for unit testing.
In order to allow Unit Testing of the CAN Class, we replace the use of
uint32_t with uintptr_t (type capable of holding a pointer), which
allows portability and expresses intentions more clearly. In aid of this
latter goal, we also replace the use of the name "id" with "context",
to improve clarity. These are addresses of the context related to that
callback.
1. In TF-M, fix NSPE interrupt-disabled NSC call broken. Check:
https://developer.trustedfirmware.org/T966
2. In TF-M, enable mcuboot log enabled forcibly. This is to help check firmware update process.
3. Update readme and script
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.
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.
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_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.
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`.
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.