- Mar 22, 2022
-
-
Rob Walton authored
Update to the version of MDH_ARM containing the latest HAL submodule. Signed-off-by:Robert Walton <rob.walton@arm.com>
-
Signed-off-by:Evelyne Donnaes <evelyne.donnaes@arm.com>
-
- Mar 21, 2022
-
-
Docker registry will be moved to a different location when CI is available for public GitLab. Use a variable defined in CI settings to resolve Docker registry so that CI works in both public and private GitLab instances. Signed-off-by:Saheer Babu <saheer.babu@arm.com>
-
Fix a bug that prevents the LwIP stack from posting empty messages. This isn't correct because parts of LwIP stack send and receive empty messages as a mean of synchronization. Fixes: 6f243443aee7 ("Add lwIP and its CMSIS port as components") Signed-off-by:Vincent Coubard <vincent.coubard@arm.com>
-
Add timestamps to pigweed logging with MCU-Driver-HAL's lp ticker. Signed-off-by: -
Signed-off-by: -
Add an example to demonstrate logging with pigweed for both bare metal and CMSIS-RTOS. Signed-off-by: -
Add a pigweed backend that uses a serial port to output logs. Protection of the serial port against concurrent access can be enabled by linking to the `pw_log_mdh_cmsis_rtos_lock` library. Signed-off-by: -
Pigweed is a collection of library and tools useful for embedded development. We intend to use it in this SDK for logging and RPC support. Applications can additionally take advantage of other modules. Signed-off-by: -
Signed-off-by:Paul Szczepanek <paul.szczepanek@arm.com>
-
The EMAC interface is provided by a factory function defined by the library iotsdk-emac-factory. Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
LwIP CMake build files require the presence of Doxygen to generate documentation. If Doxygen isn't available on the build machine, CMake doesn't finish the configuration. To solve that issue, the SDK creates an empty lwipdocs target if Doxygen isn't found. Signed-off-by: -
The TODO in the comment has been fulfilled Signed-off-by: -
Limitation: The cmsis-startup-cortex-m target defines compile definitions based on the CMAKE_SYSTEM_PROCESSOR variable that is not able to identify the presence of extensions such as floating point or MVE. Signed-off-by:Wilfried Chauveau <wilfried.chauveau@arm.com>
-
Using Arm Developer report security vulnerabilities Signed-off-by:
Martin Kojtal <martin.kojtal@arm.com> -
Upgrade TF-M to pull in its latest bug fixes as well as the latest target support, including Corstone-310. Signed-off-by:Jaeden Amero <jaeden.amero@arm.com>
-
Upgrade CMSIS_5 to pull in a version of RTX that initializes floating-point for the standard (non-microlib) Arm C Library, along with other bug fixes and enhancements since the previous version. Signed-off-by: -
Upgrade the version of the HAL used to obtain support for Corstone-310 and MPS2 Cortex-M4. Signed-off-by: -
With versions of the HAL newer than 8957b9cd5077, the C library defaults to the standard C library. This aligns the C library used between HAL and RTX, which avoids a linker error with versions of RTX newer than 28d54ba19edd, where _fp_init() is used, but only included when using the standard C library. With Armclang, the TF-M and littlefs examples hang when using the standard C library, due to freopen() being called from __rt_lib_init_atexit_1(), which eventually calls _sys_open() which contains an unhandled BKPT 0x00AB that when executed, leads to a HardFault. With GCC, we don't yet have enough stack space to switch to running the TF-M examples with the standard C library. Until we have an appropriate fix to enable using these examples with the standard C library, in the interest of upgrading to the new versions of HAL and RTX sooner, we keep the C library being used as the "small" type as it was before the HAL upgrade. We should prefer avoiding forcing the affected examples to always use a small C library. We do this at application level rather than library level, to leave application developers able to address this limitation on their own by e.g. providing retargeting support from their application; we don't want to force application developers to follow unnecessary restrictions. Signed-off-by: -
The CMSIS RTOS API example needs additional stack to be able to use serial_printf() with the standard C library (non-MicroLib). Allocate threads with enough stack for printing. Versions of the HAL since 8957b9cd5077 switch from using the small MicroLib C library to the standard C library. As such, our stack usage per thread goes up for any threads that print, as serial_printf() uses snprintf() from the C library. The standard C library's implementation of snprintf() uses more stack than the MicroLib C library. Signed-off-by: -
Save some stack space by allocating read-only mutex attributes in static memory. Signed-off-by: -
Make the thread_B() match thread_A() in style. Signed-off-by: -
Update the version of the FVP we state that we've tested with. We've moved to testing with version 11.16 of the FVP. Signed-off-by: -
This version of the HAL includes updates to the serial API, so update our use of the HAL Serial API at the same time. The new serial API doesn't provide a generic initialization function. As such, we add a new platform-specific "give me a serial instance" function, get_example_serial(), for use by examples needing a single serial port. This allows examples to be portable across targets that have an implementation of get_example_serial(). Only the mdh-arm-an552-mps3 target provides an implementation of get_example_serial() so far. Signed-off-by: -
Signed-off-by:Lingkai Dong <lingkai.dong@arm.com>
-
The variadic function `serial_printf()` retrieves arguments by calling `va_start()`. After processing arguments, `va_end()` should be called before the variadic function returns. Signed-off-by: -
Signed-off-by: -
Some of the section links in `docs/Prerequisites.md`'s table of contents are broken. Other files in `docs` do not contain tables of contents. Rather fixing and adding tables, we remove the existing one to reduce maintenance effort. Many Markdown viewers (such as the repository viewers of GitLab and GitHub) and documentation webpage generators (e.g. MkDocs) automatically show each page's table of content. Signed-off-by: -
The trusted-firmware-m repository provides an NS (non-secure) startup file and linker script for each platform. We switch the TF-M example to use those. The revision of TF-M has been bumped to a newer version with the fixes we need: * 61483155 platform: Fix missing PSP initial value and limit * a1352287 build: Make ARMClang maximum version check a warning Signed-off-by: -
The CMSIS_5 repository provides a reference startup file and for each Cortex-M core. We add a library `cmsis-startup-cortex-m` which pulls in a startup file from CMSIS_5 based on `CMAKE_SYSTEM_PROCESSOR`. Currently only Cortex-M55 has been added as we have only one platform at the time of writing. While a startup file is generic to the Cortex core, a linker script is specific to the memory layout of the hardware and the application. We add to each non-TF-M example `an552_armclang.sct` for ARMClang and `an552_gcc.ld` for GCC. Both files are based on the ones from `Device/ARM/ARMCM55/Source` inside CMSIS_5 (git tag: 5.8.0) with memory layout edited to match AN552. Having linker scripts inside each example reflects what an actual user project would do. Note that the TF-M examples need linker scripts from the trusted-firmware-m repository and will be handled by a subsequent commit. By pointing each executable's `LINK_DEPENDS` property to its linker script, we instruct CMake to redo linking upon modification of the linker script. Signed-off-by: -
Now TF-M is fetched using CMake `FetchContent` at configuration stage, so we can use `requirements.txt` from the TF-M source tree before build stage. This avoids relying on a web link with a hardcoded TF-M version. Signed-off-by: -
Previously, we used `ExternalProject` to both fetch and build TF-M, and fetching happened at build time. Now we switch to `FetchContent` for the fetching step, because * it fetches code during configuration instead of build, and no time is wasted contacting the git server on every rebuild * a local copy of a component can be used, saving time and disk space and allowing a modified version to be used To use a local copy of TF-M, pass -D FETCHCONTENT_SOURCE_DIR_TF-M=<path-to-local-TF-M> This has been added to the documentation. Signed-off-by: -
The suffix `-fvp` of the presets is inaccurate, because what gets built can run on both FVP and actual hardware/FPGA if they are the same device model. There also exist FVP models that emulate different devices, and this suffix doesn't allow any destinction. So we rename the suffix to `-an552` which is more precise. Similarly, "Fetch ... and MCU-Driver-Reference-Platforms-for-Arm" is not precise enough because support for more device models will be added to the HAL implementation repository, and we will need different presets in order to build examples for different devices. Instead, we explictly mention what device we build examples for, e.g. "Build ... for Corstone-300 AN552". Signed-off-by: -
Following some changes in registers and memory layout, a new Corstone- 300 implementation AN552 becomes available and supercedes AN547. Having recently added AN552 support to the HAL, we switch all examples to use AN552 instead of AN547. No examples or CMake presets are provided for AN547 anymore, because it requires one of the old FVPs none of which has both TF-M and EMAC working. TF-M has been bumped to an unreleased SHA1 which is the same revision from which AN552 support in the HAL was imported. This is because AN552 support is not available in any TF-M releases yet. The signing script has been modified due to a change in where secure image and bootloader builds are located. Now the CI uses FVP 11.16 whose model is AN552 and has working TF-M and EMAC. Signed-off-by: -
The littlefs example stores the status of closing a file in `close_ret`. If an error happens before a file is even opened, no closing is performed and `close_ret` is not set. To avoid problems when we check its value near the end of the `main()` and decide the application's return value, initialize `close_ret` (and `unmount_ret` to be extra safe in case we make further code changes in the future) to zero. This issue was warned by the compiler. Signed-off-by: -
MCU-Driver-HAL's flash API has been updated to a new programming model based on a vtable. The instantiation and initialization of flash are now platform-specific, but once it's done subsequent API calls on the vtable object are fully generic. This commit updates the flash API usage in the littlefs example. To allow the littlefs example to potentially be built and run on different platforms, we separate the main application (`main.c`) and Corstone-300 flash initialization (`platforms/flash_cs300.c`). Signed-off-by: -
The CMake keyword `EXCLUDE_FROM_ALL` can be applied to either a target (library or executable) or a subdirectory. To avoid building libraries that are not used by any applications in order to save time and space and avoid errors due to missing but unused dependencies, we exclude libraries from CMake's `all` target. Only libraries that are required by executables get built. The use of `EXCLUDE_FROM_ALL` is inconsistent among different libraries inside `components`. To fix this and improve maintainability, this commit removes `EXCLUDE_FROM_ALL` from individual libraries and applies the keyword globally to `components`. Signed-off-by: -
After some refactoring in MCU-Driver-HAL, it is no longer necessary to depend on any non-API code from the HAL. In particular, `RTE_Components.h` which is CMSIS components' configuration header is no longer provided by the HAL. Now we add one `RTE_Components.h` to each example that needs CMSIS, which is the standard approach. CMSIS components also require the macro `CMSIS_device_header` to be set to a file containing architecture-specific definitions. The HAL internally sets it to its own `cmsis.h`, but to avoid dependency on that we make CMSIS's built-in headers such as `ARMCM55.h` available in `cmsis-core`'s include paths and set `CMSIS_device_header="ARMCM55.h" in our examples. Note that uses of headers like `ARMCM55.h` are optional and a user project can provide its own customized architecture header. Note: RTX needs different configurations depending on whether TF-M is enabled or not. Because CMake can only produce one copy of each static library per build, TF-M and non-TF-M examples need to be built in separately if a user wants to try all of them. Signed-off-by:
-
