Move the stm32l1 sources, headers and boards into arch/arm/src/stm32l1,
arch/arm/include/stm32l1 and boards/arm/stm32l1, then finalize the split:
source each split family directly in arch/arm/Kconfig and boards/Kconfig and
remove the now-empty combined arch/arm/src/stm32 and boards/arm/stm32 trees.
BREAKING CHANGE: The legacy STM32 architecture and board paths were split into
stm32f1, stm32l1, stm32f2, stm32f3, stm32f4, and stm32g4 directories.
Out-of-tree boards must move from stm32 to the matching split family.
Signed-off-by: raiden00pl <raiden00@railab.me>
For boards b-g431b-esc1/nsh, nucleo-g431kb/nsh and nucleo-g431rb/nsh,
the `.data` section of nuttx.elf overflows the 128 KB flash region by a
few hundred bytes on default GNU EABI builds:
arm-none-eabi-ld: nuttx section `.data' will not fit in region `flash'
arm-none-eabi-ld: region `flash' overflowed by 296 bytes
Enabling CONFIG_LTO_FULL=y in the corresponding defconfigs brings flash
usage back below the 128 KB limit (~93%).
Additionally, fix arch/arm/src/cmake/gcc.cmake so that when LTO is
enabled it always uses the gcc-ar / gcc-nm / gcc-ranlib wrappers, not
just when CONFIG_ARM_TOOLCHAIN_GNU_EABI is also set. CI tooling (via
tools/testbuild.sh) configures cmake first, then flips the toolchain
choice in .config with kconfig-tweak before running `cmake --build`.
With the previous "ARM_TOOLCHAIN_GNU_EABI && !LTO_NONE" guard the
regen step would switch to plain `ar` for the .a files, even though the
linker driver picked at configure time is still arm-none-eabi-g++ and
the object files contain GCC LTO IR. The result was a flood of
"undefined reference to `printf' / `free' / `puts' ..." link errors
when running tools/testbuild.sh -A -N -R on the *_CLANG variants.
Now that we are inside gcc.cmake the toolchain is unambiguously GCC,
so dropping the redundant CONFIG_ARM_TOOLCHAIN_GNU_EABI conjunct keeps
the LTO-aware ar wrappers in place across kconfig-tweak toolchain
switches.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Split nucleo-f4x1re into nucleo-f401re and nucleo-f411re.
These are separate boards and should be in separate directories as it's
done for all other nucleo boards in NuttX
CI Build Job `arm-05` (runtime 2 hours) has become the Performance Bottleneck for CI Workflow. That's because `arm-05` builds too many targets for nRF, RP2040, SAM 3, SAM A and SAM D. This PR splits `arm-05` into multiple smaller jobs, to reduce the CI Build Duration.
Before the PR: `arm-05` is overloaded, build requires 2 hours
- `arm-05` (2 hours): nRF, RP2040, SAM 3, SAM A, SAM D
- `arm-06` (56 mins): STM32 [a-m]*
After the PR: `arm-05` is offloaded (to `arm-06` and `arm-07`), completes within 1 hour
- `arm-05` (47 mins): nRF
- `arm-06` (1 hour): Reserve for RP2040 exclusively
- `arm-07` (1 hour 15 mins): SAM 3, SAM A, SAM D, STM32 [a-m]*
Build Jobs are sorted by Target Name. So we cascade the changes and rename the Build Jobs: `arm-07` becomes `arm-08`, `arm-08` becomes `arm-09` etc. Then `arm-13` becomes a new job `arm-14`. (Which we added to `build.yml`)
Performance of `arm-05` is discussed in https://github.com/apache/nuttx/issues/13775 and https://github.com/apache/nuttx/issues/12773
