CI should build the real cross-toolchain, driven by Kconfig/hal_config module selection #16

New issue

Closed

opened 2026-07-21 20:21:01 +00:00 by hoogv · 0 comments

hoogv commented

2026-07-21 20:21:01 +00:00

(Migrated from codeberg.org)

Description

.forgejo/workflows/tests.yml only ran the host-native Catch2/fff suite (testing/CMakeLists.txt) on the ccstudio runner — it never exercised the actual cross-compilation toolchain files added under issue #1 (toolchain/R4F-toolchain.cmake, toolchain/GCC-R4F-toolchain.cmake, toolchain/C6000-toolchain.cmake). So "CI validates the toolchain build" wasn't true yet even though a CI workflow existed: it validated the host-side unit tests only, never that hal/ actually cross-compiles for the real MSS (Cortex-R4F) / DSS (C6000) targets.

Separately, the Kconfig integration (zephyr/Kconfig, zephyr/CMakeLists.txt, kconfig-ext/cmake-ext in zephyr/module.yml) and the non-Zephyr module-selection headers (hal/util/hal_config_mss.h, hal/util/hal_config_dss.h, with their template/hal_config_{mss,dss}_template.h templates) existed locally but weren't committed, and CI didn't exercise any of it.

Use Case / Rationale

As a developer, I need CI to actually compile hal/ for the real R4F/C6000 targets, not just run host-side tests, so a change that breaks the real cross-compile (but happens to still pass the host-native fakes-based suite) gets caught automatically instead of at flash time.

As a developer choosing modules via Kconfig or a hand-written hal_config_mss.h/hal_config_dss.h, I need at least one such combination built by CI, so a module that's wired into the config system but doesn't actually compile is caught before merge.

User Stories

As a developer, I want a CI job that configures and builds against toolchain/R4F-toolchain.cmake (MSS) and toolchain/C6000-toolchain.cmake (DSS), so real cross-compilation is part of the automated check, not just host tests.
As a developer, I want zephyr/Kconfig, zephyr/CMakeLists.txt, hal/util/hal_config_mss.h, hal/util/hal_config_dss.h, and their templates committed, so this module-selection system actually exists in the repo's history.
As a reviewer, I want CI to build at least one non-trivial module-selection combination (every optional module enabled) through the real toolchain, so a module that compiles fine standalone but breaks when enabled alongside others is caught.

Acceptance Criteria

CI adds a job that configures/builds hal/ for the real MSS target via toolchain/R4F-toolchain.cmake (and GCC-R4F-toolchain.cmake) and the DSS target via toolchain/C6000-toolchain.cmake, alongside the existing host-native testing/ suite
zephyr/Kconfig, zephyr/CMakeLists.txt, hal/util/hal_config_mss.h, hal/util/hal_config_dss.h, and template/hal_config_{mss,dss}_template.h are committed
CI builds a real module-selection combination (every optional Kconfig/hal_config module enabled) through the real toolchain
The stale, empty hal/util/hal_config.h is removed (already gone, superseded by the mss/dss split)

Functional Impact

None — CI/build-tooling only, no product/driver code behavior changes (two real bugs were fixed in toolchain/R4F-toolchain.cmake while validating this, both build-system-only: a missing include_guard(GLOBAL) causing duplicate-target errors, and a multi-line embedded bash script that broke the Unix Makefiles generator).

Regulatory Impact

None

QMS Impact

None

Risk Impact

No — existing risk coverage sufficient.

Relates to #1

### Description `.forgejo/workflows/tests.yml` only ran the host-native Catch2/fff suite (`testing/CMakeLists.txt`) on the ccstudio runner — it never exercised the actual cross-compilation toolchain files added under issue #1 (`toolchain/R4F-toolchain.cmake`, `toolchain/GCC-R4F-toolchain.cmake`, `toolchain/C6000-toolchain.cmake`). So "CI validates the toolchain build" wasn't true yet even though a CI workflow existed: it validated the host-side unit tests only, never that `hal/` actually cross-compiles for the real MSS (Cortex-R4F) / DSS (C6000) targets. Separately, the Kconfig integration (`zephyr/Kconfig`, `zephyr/CMakeLists.txt`, `kconfig-ext`/`cmake-ext` in `zephyr/module.yml`) and the non-Zephyr module-selection headers (`hal/util/hal_config_mss.h`, `hal/util/hal_config_dss.h`, with their `template/hal_config_{mss,dss}_template.h` templates) existed locally but weren't committed, and CI didn't exercise any of it. ### Use Case / Rationale As a developer, I need CI to actually compile `hal/` for the real R4F/C6000 targets, not just run host-side tests, so a change that breaks the real cross-compile (but happens to still pass the host-native fakes-based suite) gets caught automatically instead of at flash time. As a developer choosing modules via Kconfig or a hand-written `hal_config_mss.h`/`hal_config_dss.h`, I need at least one such combination built by CI, so a module that's wired into the config system but doesn't actually compile is caught before merge. ### User Stories - As a developer, I want a CI job that configures and builds against `toolchain/R4F-toolchain.cmake` (MSS) and `toolchain/C6000-toolchain.cmake` (DSS), so real cross-compilation is part of the automated check, not just host tests. - As a developer, I want `zephyr/Kconfig`, `zephyr/CMakeLists.txt`, `hal/util/hal_config_mss.h`, `hal/util/hal_config_dss.h`, and their templates committed, so this module-selection system actually exists in the repo's history. - As a reviewer, I want CI to build at least one non-trivial module-selection combination (every optional module enabled) through the real toolchain, so a module that compiles fine standalone but breaks when enabled alongside others is caught. ### Acceptance Criteria - [x] CI adds a job that configures/builds `hal/` for the real MSS target via `toolchain/R4F-toolchain.cmake` (and `GCC-R4F-toolchain.cmake`) and the DSS target via `toolchain/C6000-toolchain.cmake`, alongside the existing host-native `testing/` suite - [x] `zephyr/Kconfig`, `zephyr/CMakeLists.txt`, `hal/util/hal_config_mss.h`, `hal/util/hal_config_dss.h`, and `template/hal_config_{mss,dss}_template.h` are committed - [x] CI builds a real module-selection combination (every optional Kconfig/hal_config module enabled) through the real toolchain - [x] The stale, empty `hal/util/hal_config.h` is removed (already gone, superseded by the mss/dss split) ### Functional Impact None — CI/build-tooling only, no product/driver code behavior changes (two real bugs were fixed in `toolchain/R4F-toolchain.cmake` while validating this, both build-system-only: a missing `include_guard(GLOBAL)` causing duplicate-target errors, and a multi-line embedded bash script that broke the Unix Makefiles generator). ### Regulatory Impact None ### QMS Impact None ### Risk Impact No — existing risk coverage sufficient. ### Related Issues / PRs Relates to #1

hoogv added the

Rows
Columns