Hi All,
This is more of an architecture/idiomatic question about the “right” way to define a BSP for waf. Sorry if it is wordy but I’d like to set the context correctly.
I am creating a BSP for the STM32U5G9-Discovery board, I started from the excellent work that @c-mauderer had done for the Grisp Nano board. I added one file in the spec directory named bspstm32u5-discovery.yml. It was basically just a copy of the Grisp Nano one with a new name so not much work there. I got the samples to run on my discovery board doing just that, but in the process uncovered some stuff I’d like to change. The first thing, and the thing I’m going to focus on here, are an ld(1) script aka “linkercmds” that is designed for the stm32u5-discovery board.
So there are lots of SKUs for this family of parts, and I’d like to define the RAM and ROM (FLASH) location and sizes accurately for the specific part that I need. It is pretty trivial to define 12 different versions of the linkercmdsmemory file, one for each SKU, but of course in the future they may add another one. Further, I would need the top-level BSP definition file to some how ‘inject’ that option for the given SKU that it needs. This is obviously a pretty common issue with all of the 32 bit Cortex SoCs as there are always different SKUs that have different RAM/FLASH options.
It feels kind of wrong to force the person to put a specific option in config.ini when they build the BSP, I mean if its the BSP for the STM32U5-Discovery board we know exactly what SKU that one uses and it doesn’t change. Similary for the Grisp Nano. But lets say someone comes along and wants a BSP for the STM32U545-Nucleo board. That’s using a different SKU, as is the U575ZI Nucleo board. Ideally someone wanting this could drop into the ../specs/bsps/arm/stm32u5 directory, create a bspmystm32u5board.yml and put a link in that file that says something like 'define BSP_CPU_SKU STM32U545` (and maybe a console pins define) which would be all they needed to be off to the races.
So is there an idiomatic way to set this up for waf to do? I’ve got a bunch of ugly code and overrides in configs which “work” but recognize that it is pretty cool for the Grisp Nano folks that you just build their BSP and poof you’re done. But some of the options they choose (like they have hooked RAM to the OCTOSPI) isn’t a correct setting for other boards.
Open to ideas here, trying to learn the zen of this stuff.
–Chuck
I believe I cannot answer your questions but I may provide some links which may be useful … or not 
.
When you look into spec/build/bsps/arm/stm32u5/linkcmds.yml:
───────┬────────────────────────────────────────────────────────────────────────
│ File: spec/build/bsps/arm/stm32u5/linkcmds.yml
───────┼────────────────────────────────────────────────────────────────────────
1 │ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
2 │ build-type: config-file
3 │ content: |
4 │ INCLUDE ${STM32U5_DEFAULT_LINKCMDS}
5 │ copyrights:
6 │ - Copyright (C) 2024 embedded brains GmbH & Co. KG
7 │ enabled-by: true
8 │ install-path: ${BSP_LIBDIR}
9 │ links: []
10 │ target: linkcmds
11 │ type: build
───────┴────────────────────────────────────────────────────────────────────────
The type: build is documented here. That section says the YAML structure depends on build-type: config-file which in turn is documented here.
Options in config.ini are defined in YAML files like spec/build/bsps/arm/stm32u5/optusart1gpiopins.yml (which defines STM32U5_USART1_GPIO_PINS to be enabled by default and its default value is ( GPIO_PIN_9 | GPIO_PIN_10 )). The build-type: option is documented here. With enabled-by you can enable an option only under specific condition like for a specific board. Note that the YAML files must be listed in the grp.yml file in the respective directory.
If you need to define some thing at compile/link time, the config-#defines could be used but I never saw them be used for selecting hardware variants.
1 Like
Hello @ChuckMcM,
I hope that I understood your question correctly: You basically have the problem that you need more than the BSP variant in the config.ini when adding a new BSP variant, right?
Like Frank already mentioned, you can handle that with default values for the options. For a BSP family that supports a lot of boards and therefore has different defaults for different BSPs, take a look at (for example) the STM32H7. Just as one option: The QSPI memory size is board specific:
https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml?ref_type=heads
Also note that a lot of BSPs completely generate the entire linkercmds using the yml files. I decided to write some parts by hand in the STM32U5 BSP because it just was simpler in that case. Only the memory sizes are generated (the linkercmds.memory). But if a new BSP changes that and generates the whole file, that’s OK too.
Best regards
Christian
As Christian mentioned, optmemquadspisz.yml is a configuration option that is automatically selected based on the particular BSP variant that has been selected in config.ini. You can use these to change values in the linker script generator, but you can also theoretically generate (either as a one-off static definition or dynamically via YAML) multiple linker script subtypes and then select one using a configuration option that contains a default value based on the BSP in use.
For example, you could use a chain of YAML like this:
optlinkerlayout.yml - This selects either nand or qspinor based on BSP, but is also overrideable by the userlinkercmds_base.yml - This contains a linker script generator with some common linker pieces and an include directive pointing to linkercmds_${linkerlayout}linkercmds_nand.yml - This controls the layout for devices operating from NAND flashlinkercmds_qspinor.yml - This controls the layout for devices operating from QSPI NOR flash
Since the NAND and QSPINOR specific linker scripts are generated, they can be templated with additional variables as necessary.
Thank you Frank! I had not found this bit of documentation. It looks to have at least 90% of what I need here.
–Chuck