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