Re: [PATCH rtems-source-builder v2] bare/config: add renode rsb installation config

[Chris Johns]

On 12/7/2023 6:43 pm, Muhammad Sulthan Mazaya wrote:
> Use the design of how qemu handle config files + add version number to
> the config file name.
> 
> ---
>  bare/config/devel/renode-1.13.3-1.cfg | 11 ++
>  bare/config/devel/renode.bset |  7 
>  source-builder/config/renode-1.13.3.cfg   |  7 
>  source-builder/config/renode-common-1.cfg | 45 +++
>  4 files changed, 70 insertions(+)
>  create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
>  create mode 100644 bare/config/devel/renode.bset
>  create mode 100644 source-builder/config/renode-1.13.3.cfg

What happens if a new dot release comes out? Maybe this should be renode-1.cfg
and we only look at this file again if the major release changes?

Chris

>  create mode 100644 source-builder/config/renode-common-1.cfg
> 
> diff --git a/bare/config/devel/renode-1.13.3-1.cfg 
> b/bare/config/devel/renode-1.13.3-1.cfg
> new file mode 100644
> index 000..ad9b0ad
> --- /dev/null
> +++ b/bare/config/devel/renode-1.13.3-1.cfg
> @@ -0,0 +1,11 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +%define renode_version 1.13.3
> +
> +%include %{_configdir}/renode-1.13.3.cfg
> diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> new file mode 100644
> index 000..f89168d
> --- /dev/null
> +++ b/bare/config/devel/renode.bset
> @@ -0,0 +1,7 @@
> +#
> +# Build set for Renode
> +#
> +
> +%define release 1
> +
> +devel/renode-1.13.3-1
> diff --git a/source-builder/config/renode-1.13.3.cfg 
> b/source-builder/config/renode-1.13.3.cfg
> new file mode 100644
> index 000..5aff341
> --- /dev/null
> +++ b/source-builder/config/renode-1.13.3.cfg
> @@ -0,0 +1,7 @@
> +#
> +# Renode 1.13.3 Version 1.
> +#
> +# This configuration file configure's, make's and install's Renode.
> +#
> +
> +%include %{_configdir}/renode-common-1.cfg
> diff --git a/source-builder/config/renode-common-1.cfg 
> b/source-builder/config/renode-common-1.cfg
> new file mode 100644
> index 000..65be946
> --- /dev/null
> +++ b/source-builder/config/renode-common-1.cfg
> @@ -0,0 +1,45 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +Name:  renode-%{renode_version}-%{_host}-%{release}
> +Summary:   Renode v%{renode_version}
> +Version:   %{renode_version}
> +Release:   %{release}
> +URL:http://www.renode.io
> +
> +#
> +# Renode source
> +#
> +%source set renode 
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_renode="renode_%{renode_version}_source"
> +  %source setup renode -q -n renode_%{renode_version}_source
> +
> +  cd ${build_top}
> +
> +%build
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_renode}
> +  ./build.sh
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  mkdir -p %{_bindir}
> +  cp -r ./${source_dir_renode}/* %{_bindir}
> +
> +  cd ${build_top}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder v2] bare/config: add renode rsb installation config

[Muhammad Sulthan Mazaya]

Thanks Gedare,

I will write a blog about it and work on the documentation.

- Mazaya

On Tue, Jul 18, 2023 at 7:28 AM Gedare Bloom  wrote:

> This patch applies cleanly and builds renode for me. Thanks for making
> the changes, this recipe should be much easier to maintain for version
> updates of renode. i will push it if no one complains soon.
>
> We will definitely need some documentation for building this. At the
> least you should start with a blog post, but in general we should find
> a good place for documenting RSB build dependencies. Maybe a new
> section in https://docs.rtems.org/branches/master/user/rsb/index.html
>
> On Ubuntu, in addition to whatever "typical" development tools I
> already have installed, I had to add mono-devel and gtk-sharp2
>
> On Wed, Jul 12, 2023 at 2:43 AM Muhammad Sulthan Mazaya
>  wrote:
> >
> > Use the design of how qemu handle config files + add version number to
> > the config file name.
> >
> > ---
> >  bare/config/devel/renode-1.13.3-1.cfg | 11 ++
> >  bare/config/devel/renode.bset |  7 
> >  source-builder/config/renode-1.13.3.cfg   |  7 
> >  source-builder/config/renode-common-1.cfg | 45 +++
> >  4 files changed, 70 insertions(+)
> >  create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
> >  create mode 100644 bare/config/devel/renode.bset
> >  create mode 100644 source-builder/config/renode-1.13.3.cfg
> >  create mode 100644 source-builder/config/renode-common-1.cfg
> >
> > diff --git a/bare/config/devel/renode-1.13.3-1.cfg
> b/bare/config/devel/renode-1.13.3-1.cfg
> > new file mode 100644
> > index 000..ad9b0ad
> > --- /dev/null
> > +++ b/bare/config/devel/renode-1.13.3-1.cfg
> > @@ -0,0 +1,11 @@
> > +#
> > +# Renode from git
> > +#
> > +
> > +%if %{release} == %{nil}
> > + %define release 1
> > +%endif
> > +
> > +%define renode_version 1.13.3
> > +
> > +%include %{_configdir}/renode-1.13.3.cfg
> > diff --git a/bare/config/devel/renode.bset
> b/bare/config/devel/renode.bset
> > new file mode 100644
> > index 000..f89168d
> > --- /dev/null
> > +++ b/bare/config/devel/renode.bset
> > @@ -0,0 +1,7 @@
> > +#
> > +# Build set for Renode
> > +#
> > +
> > +%define release 1
> > +
> > +devel/renode-1.13.3-1
> > diff --git a/source-builder/config/renode-1.13.3.cfg
> b/source-builder/config/renode-1.13.3.cfg
> > new file mode 100644
> > index 000..5aff341
> > --- /dev/null
> > +++ b/source-builder/config/renode-1.13.3.cfg
> > @@ -0,0 +1,7 @@
> > +#
> > +# Renode 1.13.3 Version 1.
> > +#
> > +# This configuration file configure's, make's and install's Renode.
> > +#
> > +
> > +%include %{_configdir}/renode-common-1.cfg
> > diff --git a/source-builder/config/renode-common-1.cfg
> b/source-builder/config/renode-common-1.cfg
> > new file mode 100644
> > index 000..65be946
> > --- /dev/null
> > +++ b/source-builder/config/renode-common-1.cfg
> > @@ -0,0 +1,45 @@
> > +#
> > +# Renode from git
> > +#
> > +
> > +%if %{release} == %{nil}
> > + %define release 1
> > +%endif
> > +
> > +Name:  renode-%{renode_version}-%{_host}-%{release}
> > +Summary:   Renode v%{renode_version}
> > +Version:   %{renode_version}
> > +Release:   %{release}
> > +URL:  http://www.renode.io
> > +
> > +#
> > +# Renode source
> > +#
> > +%source set renode
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> > +
> > +#
> > +# Prepare the source code.
> > +#
> > +%prep
> > +  build_top=$(pwd)
> > +
> > +  source_dir_renode="renode_%{renode_version}_source"
> > +  %source setup renode -q -n renode_%{renode_version}_source
> > +
> > +  cd ${build_top}
> > +
> > +%build
> > +  build_top=$(pwd)
> > +
> > +  cd ${source_dir_renode}
> > +  ./build.sh
> > +
> > +  cd ${build_top}
> > +
> > +%install
> > +  build_top=$(pwd)
> > +
> > +  mkdir -p %{_bindir}
> > +  cp -r ./${source_dir_renode}/* %{_bindir}
> > +
> > +  cd ${build_top}
> > --
> > 2.34.1
> >
> > ___
> > 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: [PATCH rtems-tools] tester/rtems: add renode implementation

[Gedare Bloom]

The patch has 3 whitespace errors. I have fixed them, and I will push this soon.

On Tue, Jun 27, 2023 at 8:42 PM Muhammad Sulthan Mazaya
 wrote:
>
> Hi Joel and Chris,
>
> Yes, and I will be working on the rsb patch for renode installation next.
>
> Regards,
> Mazaya
>
> On Wed, Jun 28, 2023 at 12:34 PM Chris Johns  wrote:
>>
>> I am as well
>>
>> Chris
>>
>> On 28/6/2023 12:25 am, Joel Sherrill wrote:
>> > I'm OK with this patch.
>> >
>> > Is it assuming that you installed renode on your own -- not using the RSB?
>> >
>> > --joel
>> >
>> > On Mon, Jun 26, 2023 at 5:37 PM Muhammad Sulthan Mazaya
>> > mailto:msulthanmaz...@gmail.com>> wrote:
>> >
>> > Hi Chris,
>> >
>> > Yes they are the same. I thought there was an email error, so I 
>> > re-send it
>> > twice.
>> >
>> > On Tue, 27 Jun 2023, 07:46 Chris Johns, > > > wrote:
>> >
>> > Hi Muhammad,
>> >
>> > The patch looks good, thanks.
>> >
>> > Are the 3 posted patches the same version?
>> >
>> > Chris
>> >
>> > On 26/6/2023 2:17 pm, Muhammad Sulthan Mazaya wrote:
>> > > Patch for the implementation of renode on rtems-test. Currently, 
>> > renode
>> > > installation has not been implemented in rsb. Thus, for testing, 
>> > you can
>> > > install renode by referring to the documentation link below.
>> > >
>> > > Downloads for debian, fedora, arch, macOS, and windows:
>> > > https://renode.io/#downloads 
>> > >
>> > > Alternatively, you can access Renode's GitHub releases:
>> > > https://github.com/renode/renode/releases/tag/v1.13.3
>> > 
>> > >
>> > > You can also build it from source:
>> > >
>> > 
>> > https://renode.readthedocs.io/en/latest/advanced/building_from_sources.html#building-from-source
>> >  
>> > 
>> > >
>> > > This patch consists of changes to test kendrytek210 using 
>> > renode. To
>> > > test it, you can build the kendrytek210 test suite as instructed 
>> > in the
>> > > rtems-docs (Alan's patch here:
>> > https://lists.rtems.org/pipermail/devel/2023-April/074838.html
>> > ).
>> > > Then, use the following command to run the test suite.
>> > >
>> > > rtems-test --rtems-bsp=kendrytek210-renode [test-suite-path]
>> > >
>> > > ---
>> > >  .../testing/bsps/kendrytek210-renode.ini  | 38 +++
>> > >  tester/rtems/testing/renode.cfg   | 64 
>> > +++
>> > >  .../testing/renode_scripts/kendrytek210.resc  | 53 
>> > +++
>> > >  3 files changed, 155 insertions(+)
>> > >  create mode 100644 
>> > tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > >  create mode 100644 tester/rtems/testing/renode.cfg
>> > >  create mode 100644 
>> > tester/rtems/testing/renode_scripts/kendrytek210.resc
>> > >
>> > > diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > b/tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > > new file mode 100644
>> > > index 000..95850c5
>> > > --- /dev/null
>> > > +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > > @@ -0,0 +1,38 @@
>> > > +#
>> > > +# RTEMS Tools Project (http://www.rtems.org/ 
>> > )
>> > > +# Copyright 2010-2014 Chris Johns (chr...@rtems.org
>> > )
>> > > +# All rights reserved.
>> > > +#
>> > > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> > > +#
>> > > +# Redistribution and use in source and binary forms, with or 
>> > without
>> > > +# modification, are permitted provided that the following 
>> > conditions
>> > are met:
>> > > +#
>> > > +# 1. Redistributions of source code must retain the above 
>> > copyright
>> > notice,
>> > > +# this list of conditions and the following disclaimer.
>> > > +#
>> > > +# 2. Redistributions in binary form must reproduce the above
>> > copyright notice,
>> > > +# this list of conditions and the following disclaimer in the
>> > documentation
>> > > +# and/or other materials provided with the distribution.
>> > > +#
>> > > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
>> > CONTRIBUTORS
>> > "AS IS"
>> > > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
>> > LIMITED
>> > TO, THE
>> > > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
>> 

Re: [PATCH rtems-source-builder v2] bare/config: add renode rsb installation config

[Gedare Bloom]

This patch applies cleanly and builds renode for me. Thanks for making
the changes, this recipe should be much easier to maintain for version
updates of renode. i will push it if no one complains soon.

We will definitely need some documentation for building this. At the
least you should start with a blog post, but in general we should find
a good place for documenting RSB build dependencies. Maybe a new
section in https://docs.rtems.org/branches/master/user/rsb/index.html

On Ubuntu, in addition to whatever "typical" development tools I
already have installed, I had to add mono-devel and gtk-sharp2

On Wed, Jul 12, 2023 at 2:43 AM Muhammad Sulthan Mazaya
 wrote:
>
> Use the design of how qemu handle config files + add version number to
> the config file name.
>
> ---
>  bare/config/devel/renode-1.13.3-1.cfg | 11 ++
>  bare/config/devel/renode.bset |  7 
>  source-builder/config/renode-1.13.3.cfg   |  7 
>  source-builder/config/renode-common-1.cfg | 45 +++
>  4 files changed, 70 insertions(+)
>  create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
>  create mode 100644 bare/config/devel/renode.bset
>  create mode 100644 source-builder/config/renode-1.13.3.cfg
>  create mode 100644 source-builder/config/renode-common-1.cfg
>
> diff --git a/bare/config/devel/renode-1.13.3-1.cfg 
> b/bare/config/devel/renode-1.13.3-1.cfg
> new file mode 100644
> index 000..ad9b0ad
> --- /dev/null
> +++ b/bare/config/devel/renode-1.13.3-1.cfg
> @@ -0,0 +1,11 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +%define renode_version 1.13.3
> +
> +%include %{_configdir}/renode-1.13.3.cfg
> diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> new file mode 100644
> index 000..f89168d
> --- /dev/null
> +++ b/bare/config/devel/renode.bset
> @@ -0,0 +1,7 @@
> +#
> +# Build set for Renode
> +#
> +
> +%define release 1
> +
> +devel/renode-1.13.3-1
> diff --git a/source-builder/config/renode-1.13.3.cfg 
> b/source-builder/config/renode-1.13.3.cfg
> new file mode 100644
> index 000..5aff341
> --- /dev/null
> +++ b/source-builder/config/renode-1.13.3.cfg
> @@ -0,0 +1,7 @@
> +#
> +# Renode 1.13.3 Version 1.
> +#
> +# This configuration file configure's, make's and install's Renode.
> +#
> +
> +%include %{_configdir}/renode-common-1.cfg
> diff --git a/source-builder/config/renode-common-1.cfg 
> b/source-builder/config/renode-common-1.cfg
> new file mode 100644
> index 000..65be946
> --- /dev/null
> +++ b/source-builder/config/renode-common-1.cfg
> @@ -0,0 +1,45 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +Name:  renode-%{renode_version}-%{_host}-%{release}
> +Summary:   Renode v%{renode_version}
> +Version:   %{renode_version}
> +Release:   %{release}
> +URL:  http://www.renode.io
> +
> +#
> +# Renode source
> +#
> +%source set renode 
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_renode="renode_%{renode_version}_source"
> +  %source setup renode -q -n renode_%{renode_version}_source
> +
> +  cd ${build_top}
> +
> +%build
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_renode}
> +  ./build.sh
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  mkdir -p %{_bindir}
> +  cp -r ./${source_dir_renode}/* %{_bindir}
> +
> +  cd ${build_top}
> --
> 2.34.1
>
> ___
> 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: [PATCH rtems 6/6] bsps/imxrt: Add imxrt1166_cm7_saltshaker BSP

[oss]

Hello Jacob,

Am 14.07.23 um 09:08 schrieb Christian MAUDERER:

Hello Jacob,

On 2023-07-14 08:36, Christian MAUDERER wrote:

Hello Jacob,

On 2023-07-13 18:59, Jacob Killelea wrote:

Hi Christian,

This looks awesome! Do you have any interest in adding support for 
the i.MXRT1062 based Teensy 4.0 and Teensy 4.1?


- Jacob


the Teensy look like interesting boards. Maybe a bit low on memory. 
That would make it difficult to run libbsd on them. The boards don't 
have network, so it's not a problem for the network part. But on the 
i.MXRT, I also use the MMC/SD stack from libbsd so the SD card would 
be a problem.




Just noted: The Teensy 4.1 has an optional Ethernet. So some network 
library would be good. But like I said: The target has too few memory 
for libbsd. lwIP would be a candidate. But I haven't tried that on the 
i.MXRT yet.


Best regards

Christian


It was mean from you to point me to that board. It seems like an 
interesting challenge ;)


I've thrown together a quick prototype for a BSP. It's not yet tested. 
It doesn't even link the tests yet, because the linker command file 
isn't adapted yet. But the BSP sources at least compile without problems:


  https://gitlab.com/c-mauderer/rtems/-/tree/cm/20230717_teensy41

If I find some more time and maybe some hardware, I maybe continue to 
try to write the linker command file. But I don't promise anything ;-)


Best regards

Christian



On the Teensy 4.1, the two memories (optional Flash and optional 
PSRAM) on the FlexSPI maybe can be a bit tricky.


These boards would be pure hobby time. I don't think that I will find 
enough time to fully support the boards at the moment. But I would 
expect that the basics should work with the i.MXRT1052 BSP already. 
The 1050 and 1060 family is quite similar. If you want, I can give you 
some guidance what would be necessary to support the boards.


Best regards

Christian



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

Re: grlib changes Fwd: New Defects reported by Coverity Scan for RTEMS

[Joel Sherrill]

On Mon, Jul 17, 2023 at 1:15 PM Gedare Bloom  wrote:

> Sebastian fixed it now. The local variable was shadowed. Another good
> reason to keep local variables at the start of a function ;)
>

+1

The first time I saw GCC spit this warning out was for some particularly
horrible code. It had shadowed global variables and parameters.

And we should get a Coverity email which says it is fixed. :)

--joel


>
> On Sat, Jul 15, 2023 at 9:38 AM Joel Sherrill  wrote:
> >
> >
> > The recent grlib changes introduced a Coverity issues.
> >
> > -- Forwarded message -
> > From: 
> > Date: Sat, Jul 15, 2023 at 12:22 AM
> > Subject: New Defects reported by Coverity Scan for RTEMS
> > To: 
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to RTEMS found
> with Coverity Scan.
> >
> > 1 new defect(s) introduced to RTEMS found with Coverity Scan.
> >
> >
> > New defect(s) Reported-by: Coverity Scan
> > Showing 1 of 1 defect(s)
> >
> >
> > ** CID 1538314:  Uninitialized variables  (UNINIT)
> > /bsps/shared/grlib/uart/apbuart_cons.c: 448 in first_open()
> >
> >
> >
> 
> > *** CID 1538314:  Uninitialized variables  (UNINIT)
> > /bsps/shared/grlib/uart/apbuart_cons.c: 448 in first_open()
> > 442 return false;
> > 443 }
> > 444
> > 445 uart->sending = 0;
> > 446
> > 447 /* Turn on RX interrupts */
> > >>> CID 1538314:  Uninitialized variables  (UNINIT)
> > >>> Using uninitialized value "ctrl".
> > 448 ctrl |= APBUART_CTRL_RI;
> > 449 if (uart->cap & CAP_DI) {
> > 450 /* Use RX FIFO interrupt only if delayed
> interrupt available. */
> > 451 ctrl |= (APBUART_CTRL_DI |
> APBUART_CTRL_RF);
> > 452 }
> > 453 }
> >
> >
> >
> 
> > To view the defects in Coverity Scan visit,
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3DHAM__EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMo-2BfWe9y-2FQVPI3NBuKOOB9pEF0PWPhWQO6FUVOcAwwdagvzNKH7AA8SymQIigXNwofEBIHyLL-2FrZJgQDgEg0O4g4HS-2FjBhvvcGAhWWb-2FxsDZrRDyXAMAUd-2BRwY7jJKszizp8zBz7IR2apEMP0z49hqJcf-2F9hLs1Dn-2B7C8NzR5v-2Bdg-3D-3D
> >
> > ___
> > build mailing list
> > bu...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/build
> > ___
> > 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: [PATCH] TMS570 console driver, SCI frame error (baudrate calculation error)

[Gedare Bloom]

No, because we don't have a reproducible test case.

On Fri, Jul 14, 2023 at 7:38 PM zack leung  wrote:
>
> hi, so do you want me make this change?
>
> On Wed, 12 Jul 2023 at 10:54, Gedare Bloom  wrote:
>>
>> On Wed, Jul 12, 2023 at 8:06 AM Joel Sherrill  wrote:
>> >
>> >
>> > Pavel this was filed as https://devel.rtems.org/ticket/4903. The ticket 
>> > submitter
>> > didn't give a patch, just a code change snippet and explanation. Zack 
>> > turned it into
>> > a patch. You will need to post that on the ticket to get the submitter's 
>> > feedback.
>> >
>> > I hope you don't mind copying that to the ticket and seeing what you think 
>> > is
>> > really up.
>> >
>> I posted it over there. Thanks Pavel and Joel.
>>
>> > Thanks.
>> >
>> > --joel
>> >
>> > On Wed, Jul 12, 2023 at 8:49 AM Pavel Pisa  wrote:
>> >>
>> >> Hello Zack and Gedare,
>> >>
>> >> On Tuesday 11 of July 2023 19:52:27 Gedare Bloom wrote:
>> >> > Thanks for the patch. Someone should probably test it, or identify in
>> >> > the documentation why this calculation was off-by-1. Pavel, any clues?
>> >> > On Sun, Jul 9, 2023 at 10:09 PM zack  wrote:
>> >> > > Fixes #4903
>> >> > > diff --git a/bsps/arm/tms570/console/tms570-sci.c
>> >> > > b/bsps/arm/tms570/console/tms570-sci.c index 768770a4c8..59a0b7e6f1
>> >> > > 100644
>> >> > > --- a/bsps/arm/tms570/console/tms570-sci.c
>> >> > > +++ b/bsps/arm/tms570/console/tms570-sci.c
>> >> > > @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes(
>> >> > >/* Apply baudrate to the hardware */
>> >> > >baudrate *= 2 * 16;
>> >> > >bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
>> >> > > -  ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
>> >> > > +  ctx->regs->BRS = bauddiv? bauddiv - 2: 0;
>> >>
>> >> I think that change is not correct. The actual used values
>> >> for BSP_PLL_OUT_CLOCK and baudrate should be provided to analyze
>> >> the case. The code can result in some rounding error and can
>> >> be enhanced if fractional divider is used or even super finegrained
>> >> fractional divider. But these options are available only for
>> >> for SCI/LIN peripheral case.
>> >>
>> >> According to
>> >>
>> >> TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller
>> >> Technical Reference Manual
>> >> Literature Number: SPNU499B
>> >>
>> >> 26.2.3 SCI Baud Rate
>> >>
>> >>   SCICLK Frequency = VCLK Frequency / (P + 1 + M / 16)
>> >>
>> >>   Asynchronous baud value = SCICLK Frequency / 16
>> >>
>> >> So the substraction of one corresponds to the manual.
>> >>
>> >> Actual code does not use M part. It would be problem if it is
>> >> leftover from some boot/monitor but it is part of BRS 32-bit
>> >> register which is overwritten in the whole, so such problem
>> >> should not appear either.
>> >>
>> >> So I vote against the proposed change for now and suggest
>> >> to do analysis what happens in the computation and what
>> >> are input values and output. Change would/could affect
>> >> negatively large number of combinations of the baudrate
>> >> and clocks.
>> >>
>> >> I would consider to discuss if the rounding formula
>> >> could/should be updated, but I think that it is the best
>> >> which cane be achieved for rations which do not result
>> >> in exact ratio.
>> >>
>> >>   (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
>> >>
>> >> If there is interrest then code can be enhanced by fraction
>> >> dividers for SCI/LIN peripheral case. The field with variant
>> >> should be added into tms570_sci_context and in this case
>> >> the alternative formula can be used
>> >>
>> >>   long long bauddiv;
>> >>   bauddiv = (BSP_PLL_OUT_CLOCK * 16ll + baudrate / 2) / baudrate;
>> >>   ctx->regs->BRS = ((bauddiv >> 4) & 0xff) | ((bauddiv & 0xf) << 24);
>> >>
>> >> which should be rewritten after header for SCI/LIN update to
>> >>
>> >>   ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) | 
>> >> TMS570_LIN_BRS_M(bauddiv & 0xf);
>> >
>> >
>> >
>> >>
>> >>
>> >> Best wishes,
>> >>
>> >>
>> >> Pavel
>> >> --
>> >> Pavel Pisa
>> >> phone:  +420 603531357
>> >> e-mail: p...@cmp.felk.cvut.cz
>> >> Department of Control Engineering FEE CVUT
>> >> Karlovo namesti 13, 121 35, Prague 2
>> >> university: http://control.fel.cvut.cz/
>> >> personal:   http://cmp.felk.cvut.cz/~pisa
>> >> projects:   https://www.openhub.net/accounts/ppisa
>> >> CAN related:http://canbus.pages.fel.cvut.cz/
>> >> RISC-V education: https://comparch.edu.cvut.cz/
>> >> Open Technologies Research Education and Exchange Services
>> >> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>> >>
>> >> ___
>> >> 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: grlib changes Fwd: New Defects reported by Coverity Scan for RTEMS

[Gedare Bloom]

Sebastian fixed it now. The local variable was shadowed. Another good
reason to keep local variables at the start of a function ;)

On Sat, Jul 15, 2023 at 9:38 AM Joel Sherrill  wrote:
>
>
> The recent grlib changes introduced a Coverity issues.
>
> -- Forwarded message -
> From: 
> Date: Sat, Jul 15, 2023 at 12:22 AM
> Subject: New Defects reported by Coverity Scan for RTEMS
> To: 
>
>
> Hi,
>
> Please find the latest report on new defect(s) introduced to RTEMS found with 
> Coverity Scan.
>
> 1 new defect(s) introduced to RTEMS found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
>
>
> ** CID 1538314:  Uninitialized variables  (UNINIT)
> /bsps/shared/grlib/uart/apbuart_cons.c: 448 in first_open()
>
>
> 
> *** CID 1538314:  Uninitialized variables  (UNINIT)
> /bsps/shared/grlib/uart/apbuart_cons.c: 448 in first_open()
> 442 return false;
> 443 }
> 444
> 445 uart->sending = 0;
> 446
> 447 /* Turn on RX interrupts */
> >>> CID 1538314:  Uninitialized variables  (UNINIT)
> >>> Using uninitialized value "ctrl".
> 448 ctrl |= APBUART_CTRL_RI;
> 449 if (uart->cap & CAP_DI) {
> 450 /* Use RX FIFO interrupt only if delayed 
> interrupt available. */
> 451 ctrl |= (APBUART_CTRL_DI | APBUART_CTRL_RF);
> 452 }
> 453 }
>
>
> 
> To view the defects in Coverity Scan visit, 
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3DHAM__EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMo-2BfWe9y-2FQVPI3NBuKOOB9pEF0PWPhWQO6FUVOcAwwdagvzNKH7AA8SymQIigXNwofEBIHyLL-2FrZJgQDgEg0O4g4HS-2FjBhvvcGAhWWb-2FxsDZrRDyXAMAUd-2BRwY7jJKszizp8zBz7IR2apEMP0z49hqJcf-2F9hLs1Dn-2B7C8NzR5v-2Bdg-3D-3D
>
> ___
> build mailing list
> bu...@rtems.org
> http://lists.rtems.org/mailman/listinfo/build
> ___
> 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

Libbsd situation.

[Karel Gardas]

  Hello,

if I'm right than RTEMS 6 should be accompanied with libbsd from 
6-freebsd-12 branch which should be based on freebsd-12 (stable/12 
branch). Please correct me if I'm wrong here.


If I'm right above, then there are few things which worries me a bit:

(1) FreeBSD's 12 branch is going to be EoLed soon, e.g. December 31, 
2023 as claimed on https://www.freebsd.org/security/#sup


(2) 6-freebsd-12 branch latest commit in freebsd-org is from Feb 9 
22:15:35 2020. Based on that it looks like 6-freebsd-12 branch is >6k 
commits behind the FreeBSD's stable/12 branch.


May this outage be solved by using libbsd master branch? It does not 
look like as:


(i) latest commit in freebsd-org in libbsd master branch is even older 
than in 6-freebsd-12 and it is from Sep 24 01:58:54 2019.


(ii) even if I consider Sebastian's own master-update branch available 
on his github.com account, it seem this branch synced with what is in 
6-freebsd-12 and ends exactly on 2020-02-09. So, it looks like master is 
also missing few thousands patches from FreeBSD development...


Anyway, my biggest worry is that RTEMS 6 libbsd may be based on source 
code which will lose upstream project support soon after the RTEMS 6 
release (assuming RTEMS 6 will happen before Dec 31 2023). So I'm 
curious if with all those outdatnes it would not be good to jump and 
update master which would be supported by another 5 years (assuming this 
is stable/14 branch).
E.g. the situation is exactly like with GCC where Sebastian clearly 
warned about it and project moved from 10 to 12 and now it looks like we 
will even move to GCC 13 release for RTEMS 6... Except that in case of 
libbsd it has not happened yet.


Am I missing something or is this really a situation with libbsd as of 
today?


Thanks!
Karel

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