Outdated list of BSPs in rtems-tools/config

[Joel Sherrill]

On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER <
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>> 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.


> >
> >
> > 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.


>
>  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
>
> 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.

--joel


>
> Best regards
>
> Christian
>
> >
> > --joel
> >
> >
> >     Best regards
> >
> >     Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230725/da9f1101/attachment.htm>