Re: Outdated list of BSPs in rtems-tools/config

2023-09-17 Thread oss 

Hello Peter, Thomas, Karel,

Am 14.09.23 um 22:15 schrieb Karel Gardas:


   Hello Thomas,

On 9/14/23 21:35, Thomas DOERFLER wrote:

Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the 
PowerPC architecture and favor ARM for automotive applications.


But the MPC5xxx controllers were developed in some sort of cooperation 
with ST microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)


indeed, but even ST Micro probably plans to migrate their customers 
slowly to their brand new ARM-based chips for automotive: Stellar 32-bit 
Automotive MCUs [1]. Although I must add that "Longetivity" is extended 
to 20 years for your mentioned SPC56x, whatever that means exactly...


Anyway, I'm afraid, sun is setting on PPC even in automotive business...



I don't really know a lot about the eTPU. But after reading a bit about 
it, I stumbled across a presentation from ST and a company called Hycon 
(Hybrid Controls) that describes a eTPU to GTM migration (see [1]). The 
presentation seems to be part of a Bosch event focused on that GTM (see 
[2]). There has been a second event a few years later (see [3]). That 
GTM seems to be an IP core that is licensed by multiple chip vendors.


I found it in a number of the PowerPC based chips from ST. But beneath 
that, I also found it in some ARM chips from ST that have a "proposal" 
status (for example [4]). One of the presentations from Bosch from 2022 
mentions that it is implemented by Infineon, ST, Renesas and NXP.


Like I said: I don't really know the eTPU. But if there is a migration 
guide, there is a good chance, that it at least works for some cases to 
replace the eTPU.


Best regards

Christian


[1] 
http://www.bosch-semiconductors.com/media/events/techday_presentations/12_stmicroelectronics.pdf
[2] 
https://www.bosch-semiconductors.com/ip-modules/gtm-platform/gtm-techday-2017/
[3] 
https://www.bosch-semiconductors.com/ip-modules/gtm-platform/gtm-techday-2022/

[4] https://www.st.com/en/automotive-microcontrollers/sr6g7c6.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-15 Thread Peter Dufault 


> On Sep 14, 2023, at 15:22 , o...@c-mauderer.de wrote:
> 
> At the moment a lot of chips start to provide two different ARM cores. One 
> bigger (often Cortex-A; sometimes multicore) and one smaller one (most of the 
> time Cortex-M). I haven't used both CPUs of these dual CPU systems yet. But 
> in theory they should allow some quite nice division of tasks: The small CPU 
> can handle the timing intensive application (maybe with some bare metal 
> code). The second CPU can handle higher level control and communication. It 
> would be interesting to implement something like that.

I have thought about this.  It's more hand-coding for the control loops, but 
it's traditional coding.  Not everyone thinks the eTPU/PowerPC architecture is 
as well-designed as I do - "Way too complicated!" is the feedback I get.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering





signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-15 Thread Peter Dufault 
It will be difficult to replace how well the PowerPC motor controllers work for 
motor control when the canned, pre-written eTPU code do what you need.  It's a 
great  architecture, the DMA chain is well thought out.

There is a Bosch "GTM" Generic Timer IP module that is intended to replace the 
eTPU.  I'll look at that to see how close it comes to providing the clean 
support for motor control coupled to a general purpose processor that the eTPU 
/ PowerPC has.

When I see "IP" in a "chip" description I get nervous - I assume Bosch is 
selling "IP" and the integration is up to the licensor. That said, ARM works 
well.

> On Sep 14, 2023, at 15:22 , o...@c-mauderer.de wrote:
> 
> Hello Peter,
> 
> Am 13.09.23 um 19:22 schrieb Peter Dufault:
>>> On Jul 25, 2023, at 10:14 , Joel Sherrill  wrote:
>>> 
>>> 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'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP 
>> in July.
>> I am the one who added the Phycore-mpc5554 as a minor refinement to the 
>> Freescale MPC55xx embedded board BSPs developed by "eb".
>> It *is* time to retire the Phytec board as that board is no longer available.
>> But, I hope we can keep it around for a while as I now need to work on a 
>> follow-up to that BSP.
> 
> That thread was not about retiring or deprecating BSPs. It was about some 
> missing BSPs in the rtems-tools/config files. So if it is still necessary, I 
> don't think the BSP should be removed.
> 
>> One of my clients uses the Phycore-MPC5554.  They missed the end-of life 
>> announcement for that board. They need to quickly update to something very 
>> compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F 
>> has all the functionality they require without software changes.
>> I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop 
>> equivalent MPC5674F support.
> 
> OK for me.
> 
>> A related question. I think "eb" has a "gwlcfm" target that uses this NXP 
>> architecture in one of their products.  "eb", are you planning another 
>> "gwlcfm", or are you done with that, and what platform would you move to?  
>> I'd like to learn about an architecture that works as well as the old 
>> Motorola architecture does without custom FPGA programming.
> 
> I think it's possible that a new batch of the gwlcfm hardware will be 
> manufactured in the next few years. But it's quite unlikely that the software 
> will get an upgrade.
> 
> The question about a good architecture is quite difficult because it's always 
> quite application specific.
> 
> For RTEMS work that I do, usually a customer already selected a chip (most of 
> the time some ARM). Therefore, I can't pick a platform that often. For 
> eb-projects, we usually use NXP or ST chips. On the NXP it would be i.MX or 
> now also i.MXRT and for ST it's one of the many STM32 chips.
> 
> Personally I would like to play a bit with Risc-V chips. But I haven't found 
> any time yet. Additionally, it seems that there are still not that many 
> manufacturers that produce Risc-V chips.
> 
> 
>> If I leave the old Motorola PowerPC's architecture targeted at engine 
>> control, I will miss how the ADC DMA chain works together with the eTPU and 
>> also schedules the output so cleanly do background motor control, and other 
>> timing intensive applications, so that the main CPU is free to e.g. run 
>> RTEMS (and in my case position servo control).
> 
> Difficult. Best bet is some NXP chip because they have quite some peripherals 
> that are still based on the Motorola chips. But I think you know these chips 
> already and it seems that they are not a good enough replacement. Otherwise, 
> you wouldn't ask.
> 
> At the moment a lot of chips start to provide two different ARM cores. One 
> bigger (often Cortex-A; sometimes multicore) and one smaller one (most of the 
> time Cortex-M). I haven't used both CPUs of these dual CPU systems yet. But 
> in theory they should allow some quite nice division of tasks: The small CPU 
> can handle the timing intensive application (maybe with some bare metal 
> code). The second CPU can handle higher level control and communication. It 
> would be interesting to implement something like that.
> 
> Best regards
> 
> Christian
> 
>> Peter
>> -
>> Peter Dufault
>> HD Associates, Inc.  Software and System Engineering
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering





signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread Karel Gardas 



  Hello Thomas,

On 9/14/23 21:35, Thomas DOERFLER wrote:

Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the PowerPC 
architecture and favor ARM for automotive applications.


But the MPC5xxx controllers were developed in some sort of cooperation 
with ST microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)


indeed, but even ST Micro probably plans to migrate their customers 
slowly to their brand new ARM-based chips for automotive: Stellar 32-bit 
Automotive MCUs [1]. Although I must add that "Longetivity" is extended 
to 20 years for your mentioned SPC56x, whatever that means exactly...


Anyway, I'm afraid, sun is setting on PPC even in automotive business...

Cheers,
Karel

[1]: 
https://www.st.com/en/automotive-microcontrollers/stellar-32-bit-automotive-mcus.html

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread Thomas DOERFLER 

Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the PowerPC 
architecture and favor ARM for automotive applications.


But the MPC5xxx controllers were developed in some sort of cooperation 
with ST microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)


wkr,

Thomas.

Am 14.09.23 um 21:22 schrieb o...@c-mauderer.de:

Hello Peter,

Am 13.09.23 um 19:22 schrieb Peter Dufault:




On Jul 25, 2023, at 10:14 , Joel Sherrill  wrote:

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'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 
BSP in July.


I am the one who added the Phycore-mpc5554 as a minor refinement to 
the Freescale MPC55xx embedded board BSPs developed by "eb".


It *is* time to retire the Phytec board as that board is no longer 
available.


But, I hope we can keep it around for a while as I now need to work on 
a follow-up to that BSP.


That thread was not about retiring or deprecating BSPs. It was about 
some missing BSPs in the rtems-tools/config files. So if it is still 
necessary, I don't think the BSP should be removed.




One of my clients uses the Phycore-MPC5554.  They missed the end-of 
life announcement for that board. They need to quickly update to 
something very compatible, and a BSP based on the PHYTEC MPC5674F will 
work, the MPC5674F has all the functionality they require without 
software changes.


I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I 
develop equivalent MPC5674F support.




OK for me.

A related question. I think "eb" has a "gwlcfm" target that uses this 
NXP architecture in one of their products.  "eb", are you planning 
another "gwlcfm", or are you done with that, and what platform would 
you move to?  I'd like to learn about an architecture that works as 
well as the old Motorola architecture does without custom FPGA 
programming.




I think it's possible that a new batch of the gwlcfm hardware will be 
manufactured in the next few years. But it's quite unlikely that the 
software will get an upgrade.


The question about a good architecture is quite difficult because it's 
always quite application specific.


For RTEMS work that I do, usually a customer already selected a chip 
(most of the time some ARM). Therefore, I can't pick a platform that 
often. For eb-projects, we usually use NXP or ST chips. On the NXP it 
would be i.MX or now also i.MXRT and for ST it's one of the many STM32 
chips.


Personally I would like to play a bit with Risc-V chips. But I haven't 
found any time yet. Additionally, it seems that there are still not that 
many manufacturers that produce Risc-V chips.



If I leave the old Motorola PowerPC's architecture targeted at engine 
control, I will miss how the ADC DMA chain works together with the 
eTPU and also schedules the output so cleanly do background motor 
control, and other timing intensive applications, so that the main CPU 
is free to e.g. run RTEMS (and in my case position servo control).


Difficult. Best bet is some NXP chip because they have quite some 
peripherals that are still based on the Motorola chips. But I think you 
know these chips already and it seems that they are not a good enough 
replacement. Otherwise, you wouldn't ask.


At the moment a lot of chips start to provide two different ARM cores. 
One bigger (often Cortex-A; sometimes multicore) and one smaller one 
(most of the time Cortex-M). I haven't used both CPUs of these dual CPU 
systems yet. But in theory they should allow some quite nice division of 
tasks: The small CPU can handle the timing intensive application (maybe 
with some bare metal code). The second CPU can handle higher level 
control and communication. It would be interesting to implement 
something like that.


Best regards

Christian



Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--
embedded brains GmbH & Co. KG
Herr Thomas DOERFLER
Dornierstr. 4
82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
phone: +49- 89-18 94 741 -12
mobil: +49-176-15 22 06 - 02

Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread oss 

Hello Peter,

Am 13.09.23 um 19:22 schrieb Peter Dufault:




On Jul 25, 2023, at 10:14 , Joel Sherrill  wrote:

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'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in 
July.

I am the one who added the Phycore-mpc5554 as a minor refinement to the Freescale MPC55xx 
embedded board BSPs developed by "eb".

It *is* time to retire the Phytec board as that board is no longer available.

But, I hope we can keep it around for a while as I now need to work on a 
follow-up to that BSP.


That thread was not about retiring or deprecating BSPs. It was about 
some missing BSPs in the rtems-tools/config files. So if it is still 
necessary, I don't think the BSP should be removed.




One of my clients uses the Phycore-MPC5554.  They missed the end-of life 
announcement for that board. They need to quickly update to something very 
compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has 
all the functionality they require without software changes.

I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop 
equivalent MPC5674F support.



OK for me.


A related question. I think "eb" has a "gwlcfm" target that uses this NXP architecture in one of 
their products.  "eb", are you planning another "gwlcfm", or are you done with that, and what 
platform would you move to?  I'd like to learn about an architecture that works as well as the old Motorola 
architecture does without custom FPGA programming.



I think it's possible that a new batch of the gwlcfm hardware will be 
manufactured in the next few years. But it's quite unlikely that the 
software will get an upgrade.


The question about a good architecture is quite difficult because it's 
always quite application specific.


For RTEMS work that I do, usually a customer already selected a chip 
(most of the time some ARM). Therefore, I can't pick a platform that 
often. For eb-projects, we usually use NXP or ST chips. On the NXP it 
would be i.MX or now also i.MXRT and for ST it's one of the many STM32 
chips.


Personally I would like to play a bit with Risc-V chips. But I haven't 
found any time yet. Additionally, it seems that there are still not that 
many manufacturers that produce Risc-V chips.




If I leave the old Motorola PowerPC's architecture targeted at engine control, 
I will miss how the ADC DMA chain works together with the eTPU and also 
schedules the output so cleanly do background motor control, and other timing 
intensive applications, so that the main CPU is free to e.g. run RTEMS (and in 
my case position servo control).


Difficult. Best bet is some NXP chip because they have quite some 
peripherals that are still based on the Motorola chips. But I think you 
know these chips already and it seems that they are not a good enough 
replacement. Otherwise, you wouldn't ask.


At the moment a lot of chips start to provide two different ARM cores. 
One bigger (often Cortex-A; sometimes multicore) and one smaller one 
(most of the time Cortex-M). I haven't used both CPUs of these dual CPU 
systems yet. But in theory they should allow some quite nice division of 
tasks: The small CPU can handle the timing intensive application (maybe 
with some bare metal code). The second CPU can handle higher level 
control and communication. It would be interesting to implement 
something like that.


Best regards

Christian



Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-13 Thread Peter Dufault 


> On Jul 25, 2023, at 10:14 , Joel Sherrill  wrote:
> 
> 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'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in 
July.

I am the one who added the Phycore-mpc5554 as a minor refinement to the 
Freescale MPC55xx embedded board BSPs developed by "eb".

It *is* time to retire the Phytec board as that board is no longer available.

But, I hope we can keep it around for a while as I now need to work on a 
follow-up to that BSP.

One of my clients uses the Phycore-MPC5554.  They missed the end-of life 
announcement for that board. They need to quickly update to something very 
compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has 
all the functionality they require without software changes.

I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop 
equivalent MPC5674F support.

A related question. I think "eb" has a "gwlcfm" target that uses this NXP 
architecture in one of their products.  "eb", are you planning another 
"gwlcfm", or are you done with that, and what platform would you move to?  I'd 
like to learn about an architecture that works as well as the old Motorola 
architecture does without custom FPGA programming.

If I leave the old Motorola PowerPC's architecture targeted at engine control, 
I will miss how the ADC DMA chain works together with the eTPU and also 
schedules the output so cleanly do background motor control, and other timing 
intensive applications, so that the main CPU is free to e.g. run RTEMS (and in 
my case position servo control).

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering





signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-07-25 Thread Christian MAUDERER 

Hello Joel,

On 2023-07-25 16:14, Joel Sherrill wrote:



On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER 
> wrote:


Hello Joel,

On 2023-07-25 15:46, Joel Sherrill wrote:
 >
 >
 > On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER
 > 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


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

Re: Outdated list of BSPs in rtems-tools/config

2023-07-25 Thread Joel Sherrill 
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
> >  > > 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

Re: Outdated list of BSPs in rtems-tools/config

2023-07-25 Thread Christian MAUDERER 

Hello Joel,

On 2023-07-25 15:46, Joel Sherrill wrote:



On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER 
> 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

Re: Outdated list of BSPs in rtems-tools/config

2023-07-25 Thread Joel Sherrill 
On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER <
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.


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

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.

--joel

>
> Best regards
>
> Christian
> --
> 
> embedded brains GmbH & Co. KG
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email:  christian.maude...@embedded-brains.de
> phone:  +49-89-18 94 741 - 18
> mobile: +49-176-152 206 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel