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.
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
