Limiting options in a BSP to some BSPs but not others

General
1

Okay, getting more facile with the BSP system and the current challenge is options that show up for one BSP but not another.

So I puzzled out that assigning options to grp and having the option YAML file appear in grp.yml would cause the option to show up in ./waf bspdefaults. But what I would like is for one grp.yml but to have options that only show up on BSPs that need that option. (For example, I’d like the OCTOSPI option to continue to show up for arm/stm32u5-grisp-nano but NOT show up for the arm/stm32u5-discovery BSP. It seems like the enable: true could be removed or switched to false but then having a line that enabled it for a specific BSP.

2

And a small update here, I did figure out that I could put the option files in the BSP YAML under links and then the grp.yml file could only have those options that were common to all flavors of STM32U5 BSPs. This might be a reasonable workaround. That said, I’d still like to figure out how to write a build option whose value depended on which BSP it was being attached too.

3

There are some examples of YAML files being included in a shared grp.yml, but only being enabled for some combination of options. spec/build/cpukit/objsmp.yml does this and is enabled only when RTEMS_SMP is defined.

1 Like
4

Yeah, still trying to track down whats going on. Another confounding factor is that when I configure the BSP I get this:

GCC build key                            : 2026.03.04 
GCC build key is too old (see GCC_BUILD_KEY_POLICY option), expected at least : 2026.06.12 
'configure' finished successfully (0.427s)

Which I don’t understand. I’ve re-built tools and it fetches and builds the March 4th gcc

5

The enabled-by: section should somehow do the trick. Just I cannot find an example for disabling an option in some case. Try grep -F -r "enabled-by:" spec/build/bsps/arm/*/opt* to find an example (those files where enabled-by: is not immediately followed by true).

6

I just pulled latest RSB and rebuilt AArch64 tooling and got 2026.06.12. This matches up with what RTEMS expects.

  1. Are you sure that RSB where you built tools is current?
  2. Are you certain that you’re using the tools you just built?
  3. Which build command did you use with sb-set-builder?
7

I thought I had just pulled it, I’ll go back an verify… and yeah I was on my own branch (in case I had to change things and wanted to revert :slight_smile:) and switched back to main and got an update. Well I’ll know in a couple of hours if that affects this weird BSP bug.

8

So going to close this one out as well. The rsb was behind and I am using rtems-current so that fixed the compiler message. The options issue ended up being subtle YAML syntax errors. I wrote a quick and dirty YAML validator with PyYAML and fixed those up and found you can have different results based on which BSP is being configured. So that works well. There is still the question that there are two ways to do this, with trigger conditions on enable: and with variant:. Not sure which is ideal, will make a note in my commit for whomever is merging it to consider that question. Thanks everyone, onward and upward.