Outdated list of BSPs in rtems-tools/config

[Christian MAUDERER]

Hello Joel,

On 2023-07-25 15:46, Joel Sherrill wrote:
> 
> 
> On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER 
> <christian.mauderer at embedded-brains.de 
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> 
>     Hello,
> 
>     I noted that some BSPs are missing in the config files in the
>     rtems-tools repo. If I didn't miss one it's:
> 
>           - aarch64, raspberrypi4b
>           - aarch64, xilinx_zynqmp_lp64_cfc400x
>           - arm, imxrt1166-cm7-saltshaker
>           - arm, stm32h750b-dk
>           - powerpc, mvme2700
>           - powerpc, phycore_mpc5554
>           - riscv, kendrytek210
>           - x86_64, amd64efi
> 
>     One of the BSPs is from me. I don't know of the other ones.
> 
>     I noted the configuration files in that repo just now more or less by
>     chance when playing around with rtems-bsp-builder. I wasn't aware that
>     we have a second list beneath the one printed by the `rtems-bsps`
>     script
>     or `waf bsp-list` in the RTEMS repo.
> 
> 
> Yep. The list of bsps in the ini files for rtems-bsp-builder get out of 
> date.
> I was probably the last one to try to sync them back in March.
> 
> We need some scripting to check them both ways -- additions from rtems
> and deletions from RTEMS need to be reflected.
> 
> If we had some tool which checked this, I'd be happy to run it to the
> cron jobs that do build sweeps and Coverity runs.
> 

Wouldn't it be better to try to integrate the information from the ini 
files into the yml files of the new build system? That way they can't go 
out of sync. Or is there a special reason that they have to be separate?

 From a quick glance, every BSP would need an additional "exclude-smp" 
and "tier" parameter for that.

> 
>     Did I miss that I should have updated rtems-tools (and with that the
>     rtems-source-builder) every time I have added a BSP in the past? Or
>     would it only make problems if I would update these files manually
>     because they are usually created by some script during the release
>     process?
> 
> 
> Yes. And we all forget to do it.

To be honest: I haven't known these files or completely erased that I 
ever knew them from my memory till a few hours ago. I'll try to remember 
that I have to adapt them if I add a new BSP from now on.

> 
> I don't know if it is documented at all. It should be. I don't know where it
> would go. Tooling to check consistency would help.
> 
> The other part of this is the forgotten concept of BSP tiers. Tier 1 is for
> BSPs with test results reported on real hardware. We don't see that 
> regularly.
> 
> Tier 2 is simulator testing. We do a lot of that. Speaking for Chris, 
> he'd like
> to see the tests annotated for those not passing.
> 
> Tier 3 is "it builds" and we do a good job of keeping that going. I'm 
> not sure
> we have been on a warning search and destroy lately though.
> 
> Tier 4 is "does not build". These tend to be transient or precursors to the
> architecture losing tooling and us dropping it.

Yes, these are documented: 
https://docs.rtems.org/branches/master/user/hardware/tiers.html

I think the Tiers might start to live again as soon as we have a CI/CD 
system and the checks for the tiers are automated with that. Till then, 
the tires will most likely only be checked sporadically.

Best regards

Christian

> 
> --joel
> 
> 
>     Best regards
> 
>     Christian