On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER < christian.maude...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel