Outdated list of BSPs in rtems-tools/config

Tue Jul 25 14:30:18 UTC 2023

Hello Joel,

On 2023-07-25 16:14, Joel Sherrill wrote:
> 
> 
> On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER 
> <christian.mauderer at embedded-brains.de 
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> 
>     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>
>      > <mailto: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.
> 
> 
> Most of those are recent and from a lot of different people. GSoC, Kinsey,
> you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I
> think it has been around a LONG time.
> 
>      >
>      >     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.
> 
> 
> I would hope they are related under the hood. But rtems-bsps already can
> produce the bsp list in a lot of formats. Perhaps just having it product the
> ini file would help.
> 

Could be useful as a first step, yes. If I find some time, I'll take a 
look at that.

>      >
>      >
>      > 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?
> 
> 
> Chris would have to answer this. At this point, I don't think the tools 
> know
> about the RTEMS repo. But rtems-bsp-builder is special so it could ask
> rtems to generate that ini file. That might be easy.
> 

I tried it with rtems-bsp-builder and that one should know the sources. 
Otherwise, it can't build the BSPs. But it's possible that the ini files 
are used in other tools too.

I'll wait for a day or two whether Chris has an answer.

> 
>       From a quick glance, every BSP would need an additional "exclude-smp"
>     and "tier" parameter for that.
> 
> 
> Long term, that would be good information to have anyway.
> 
> 
>      >
>      >     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 only randomly trip across them myself.
> 
> 
>      >
>      > 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
>     <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.
> 
> 
> Chris and I sometimes poke at people with hardware to produce reports
> but it doesn't happen enough.

Yes, I know. I'm one of the people you poke now and then. And I usually 
don't find the time to generate reports and always feel guilty about it. 
It's one of the reasons why I would be really happy about an automatism 
in an official CI/CD that could generate the reports so that I don't 
have to feel guilty about it anymore.

Best regards

Christian

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