- Mar 21, 2022
-
-
The pre-commit tool performs automated actions on user commits, as configured in `.pre-commit-config.yaml`. This project's pre-commit currently includes hooks for formatting code and license headers, which help an author ensure their contribution is compliant to some of the project's standards. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
Pass the option `--show-diff-on-failure` when running pre-commit in the pipeline, so the author can see what needs to be changed. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
As the printf() function has not been retargeted to use MCU-Driver-HAL's serial, we have a custom function in each example's main.c for printing to serial. To avoid duplicating this function in every example which makes it hard to maintain, move it into a new library and name the function serial_printf(). Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
When linking an executable target, the output binary name CMake passes to the linker is <target>${CMAKE_EXECUTABLE_SUFFIX}. CMake automatically sets CMAKE_EXECUTABLE_SUFFIX to .elf for the Arm Compiler but does not set it for GCC. We set it in the SDK so that image names do not depend on which compiler is used, making scripting simpler. The name of an image to use for htrun is simplified to <target>.${IOTSDK_HTRUN_IMAGE_FORMAT}. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
The baud rate used by all examples is 115200, which needs to be specified when running tests with htrun. As there is more than one common option to pass to htrun for all examples, add a new variable IOTSDK_HTRUN_COMMON_ARGUMENTS to store the list of options to avoid duplication. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
Prior to the addition of --sync=0, this issue was hidden because the example was executed twice due to htrun retrying after sync timed out. After sync is disabled, the example is run once only. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
The linkers' output format of executables is ELF which contains useful information such as section addresses and debug symbols. But sometimes raw binaries are needed, for example when a board's disk mount takes a raw binary image for flashing. We always generate a raw binary for each example so users and CTest can use it as needed. This was missing for the littlefs example. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
This version contains a useful update for the AN547 target and is base for TF-M branches that support floating point. Signed-off-by:
Vincent Coubard <vincent.coubard@arm.com>
-
This change allows an application to provide its own patch for TF-M. It can be used by an application to use experimental features such as floating point. Signed-off-by:
Vincent Coubard <vincent.coubard@arm.com>
-
While an application can provide its own startup file and linker script, it can instead use default ones from an `mcu-driver-<vendor>` repository by linking the corresponding `INTERFACE` target. In the examples that come with the SDK, we use the default target `mdh-arm-an547-mps3-startup` from `mcu-driver-reference-platforms-for-arm` for Corstone-300. The revisions of the `mcu-driver-reference-platforms-for-arm` repository have been bumped to bring in the aforementioned targets. Note: The `PRIVATE` keyword has been removed from `target_link_libraries` of `iotsdk-example-freertos`, because an executable is final and not linked by anything else anyway. This avoids the need for `PRIVATE` when subsequently linking the target for startup file and linker script, because CMake requires scope keywords to be used or not used consistently. Note: As before, TF-M and non-TF-M examples cannot be built together because * The CMSIS-RTX configuration depends on whether TrustZone is enabled or not, controlled by the macro `DOMAIN_NS`. It is not possible to have a single build of RTX that works in both cases. * For now, they use the same target `mdh-arm-an547-mps3-startup` for start up file and linker script but require different memory layouts (controlled by the macros `DOMAIN_NS` and `BL2`). This limitation would not exist if the TF-M example used the NS linker script from TF-M, but some pre-main functions in `mcu-driver-hal` (e.g. `mbed_boot()`) need special symbols (e.g. `__StackTop`) that are not provided by TF-M's NS linker script. In the future, wrapping of `main()` (and other "bootstrap" code) should be cleaned up from `mcu-driver-hal`. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
The toolchain repo has been updated to remove setting of fshort-enum and fshort-wchar for ArmClang. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
- Feb 07, 2022
-
-
Jaeden Amero authored
The TF-M example has been tested to run with version 11.14 of the Corstone-300 FVP. Version 11.15 of the FVP has a known issue preventing the example from working. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
The stack is not integrated with the rest of the SDK at this stage. It is only fetched. Signed-off-by:
Vincent Coubard <vincent.coubard@arm.com>
-
Jaeden Amero authored
Provide an overview of the components included in the SDK. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Ensure all components in the components folder are capitalized for consistency. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Reduce confusion over whether components should go into `3rdparty`, which includes a mix of Arm-managed projects alongside third-party-managed projects, or `components`, by moving all components into the `components` directory. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Run pre-commit from CI. This helps catch issues found by pre-commit in CI, and helps align the set of tests CI runs with the set of tests that is easy to run locally. Signed-off-by:
Saheer Babu <saheer.babu@arm.com>
-
Jaeden Amero authored
Teach the licenseheaders tool that CMake files are not only files named CMakeLists.txt, but additionally any files ending with the ".cmake" extension. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Use pre-commit to check for license headers in C and C++ files. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Use pre-commit to check for license headers. This makes it easier to check licenses on development machines, rather than just in GitLab CI. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Add clang-format to pre-commit to ensure C and C++ files are formatted with style. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Add a new configuration file for pre-commit, to enable running a few simple checks. This will check for trailing white space, too large files, and the lack of a newline at the end of files. Once pre-commit is installed, you can run `pre-commit run --all-files` to ensure all files are valid. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
json files were previously excluded from being checked for a license header. Yaml files are very similar and by the same reasoning we can exclude yaml files as well. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Jaeden Amero authored
Ensure all license headers follow a consistent template. This will help us automatically check the headers later. Signed-off-by:
Jaeden Amero <jaeden.amero@arm.com>
-
Update our copy of the Apache 2.0 license text to match https://www.apache.org/licenses/LICENSE-2.0.txt Signed-off-by:
Anna Bridge <anna.bridge@arm.com>
-
The documentation didn't mention that users need to set `CMAKE_SYSTEM_PROCESSOR` to successfully use our default toolchain files. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-
We only enable examples if the IoT SDK is the top level project. We can set the IOTSDK_EXAMPLES option to ON by default and remove it from CMakePresets.json. If a user is building the SDK as the top level project, they most likely want to always build the examples for their current configuration. This commit also updates the docs to explain how examples work. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-
Consuming projects will not want to build our examples. Add a check to only build examples if IoT SDK is the top level CMake project. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-
Previously we included MCU-Driver-HAL as the top level CMake project. This was to work around the the hard-coded inclusion of app.cmake to enable toolchains in the HAL. Because the HAL was technically the top level CMake project, we couldn't use the typical check to conditionally include CTest to enable testing. Instead we checked if the IOTSDK_HTRUN_ARGUMENTS variable was an empty string. The HAL has been reworked to use toolchain files passed on the command line. So we don't have to include it before the IOT SDK project is declared. Now IoT SDK is the actually the top level project. This means we can use the standard check to include CTest and enable testing. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-
Signed-off-by:
Marcelo Salazar <Marcelo.Salazar@arm.com>
-
In order for the Cortex-M Security Extension (CMSE) to work properly for TF-M, GNU Arm Embedded Toolchain 10.3 or Arm Compiler 6.16 is required. The documentation and CI Docker image have been updated. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
A merged image of bootloader, TF-M and application has the following benefits: * some microcontrollers do not support flashing different parts of memory with different images * the `htrun` tool for running Greentea tests does not support multiple images * a single image means a simpler workflow when running an application manually. To create a merged image, an executable's CMakeLists.txt needs to call `iotsdk_tf_m_merge_images()`, passing the executable's target name and addresses of the three images. The combined image is named `<cmake-target-name>_merged`, with `.bin`, `.hex` and `.elf` versions of it available in the build directory. Notes: * The commands bin2hex.py, hex2bin.py and hexmerge.py come from the intelhex python package, which is installed as a dependency of the imgtool package listed in TF-M's requirements.txt. The installation of dependencies for TF-M has been added to the SDK's documentation. * The Corstone-300 FVP requires an ELF image, and conversion from a raw binary or an Intel HEX image to an ELF image requires either arm-none-eabi-objcopy from the GNU Arm Embedded Toolchain or objcopy from the host's GNU Binutils. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
By default, htrun uses the Greentea protocol which involves sync packets. But when comparing a plain application with a log, no synchronization is involved and htrun should not send sync packets or expect any response from the device. So --sync=0 should be used. Note: If an application runs fast enough and matches the log before synchronization times out (when --sync is not set to 0), htrun treats it as a pass. But this is not reliable especially when TF-M (which takes time to boot) is used. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
The format specifier `%p` causes GCC to prepend `0x` and the Arm Compiler not to. To print consistently, use the standardized `PRIxPTR` from C99. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
The memory layout depends on whether TF-M is enabled or not. Currently MCU-Driver-HAL globally sets a linker script for all executables without letting executables override it, so we need to disable non-TF-M applications when TF-M is enabled. In the future, each executable should be able to specify its linker script rather inheriting it from the HAL. Signed-off-by:
Lingkai Dong <lingkai.dong@arm.com>
-
In the README, add instructions for configuring the IoT SDK using toolchain files for cross compilation. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-
Update the CI scripts to use our toolchain files. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-
We require CMAKE_SYSTEM_PROCESSOR to be set so CMake can discover our platform files. The platform files set architecture and ABI specific options per language and toolchain. The ARMClang toolchain support in CMake actually always required this variable: it was used to apply the `--cpu` option for the ARMClang compiler. Previously we set CMAKE_SYSTEM_PROCESSOR somewhere in MCU-Driver-HAL's toolchain files. Now our default toolchain files don't set this variable for simplicity and so they can remain generic for all cortex-m variants. Users may set CMAKE_SYSTEM_PROCESSOR in a custom toolchain file for their own convenience. We set CMAKE_SYSTEM_PROCESSOR with our supported core types in our CMake presets. This is for our own convenience when testing our current HAL implementations. Signed-off-by:
Robert Walton <rob.walton@arm.com>
-