date:20230627

Re: [RSB 1/4] 6/7: Update Newlib

2023-06-27 Thread Sebastian Huber


Hello Chris,

On 28.06.23 04:39, Chris Johns wrote:

What has changed in this version? Is there anything specific we need to know
about or need?


this update has no specific reason.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
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: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

2023-06-27 Thread Sebastian Huber




On 27.06.23 23:37, Kinsey Moore wrote:

 >   This directive blocks the calling task for the specified
``ticks`` of clock
 >   ticks if the value is not equal to
:c:macro:`RTEMS_YIELD_PROCESSOR`.  When the
 > -requested interval has elapsed, the task is made ready.  The
clock tick
 > +requested number of ticks has elapsed, the task is made ready. 
The clock tick

 >   directives automatically updates the delay period.  The calling
task may give
 >   up the processor and remain in the ready state by specifying a
value of
 > -:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
 > +:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications
requiring use of a
 > +time base instead of system ticks should make use of
``nanosleep()`` or
 > +``clock_nanosleep()``.

What is a time base?


A delay specified in some subunit of seconds instead of clock ticks.


What about:

Applications requiring use of a clock (CLOCK_REALTIME or 
CLOCK_MONOTONIC) instead of clock ticks should make use of the ...


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
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: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

2023-06-27 Thread Sebastian Huber

On 28.06.23 01:07, Chris Johns wrote:

On 28/6/2023 7:37 am, Kinsey Moore wrote:

On Tue, Jun 27, 2023 at 4:05 PM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:

 On 27.06.23 22:18, Kinsey Moore wrote:
 > diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
 > index c082b51..3334679 100644
 > --- a/c-user/task/directives.rst
 > +++ b/c-user/task/directives.rst
 > @@ -1475,15 +1475,15 @@ The following constraints apply to this 
directive:
 >       \clearpage
 >
 >   .. index:: rtems_task_wake_after()
 > -.. index:: delay a task for an interval
 > -.. index:: wake up after an interval
 > +.. index:: delay a task for a number of ticks
 > +.. index:: wake up after a number of ticks
 >
 >   .. _InterfaceRtemsTaskWakeAfter:
 >
 >   rtems_task_wake_after()
 >   ---
 >
 > -Wakes up after an interval in :term:`clock ticks ` or 
yields the
 > +Wakes up after a number of :term:`clock ticks ` or yields 
the
 >   processor.
 >
 >   .. rubric:: CALLING SEQUENCE:
 > @@ -1502,10 +1502,12 @@ processor.
 >
 >   This directive blocks the calling task for the specified ``ticks`` of 
clock
 >   ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.
 When the
 > -requested interval has elapsed, the task is made ready.  The clock tick
 > +requested number of ticks has elapsed, the task is made ready.  The 
clock
 tick
 >   directives automatically updates the delay period.  The calling task 
may
 give
 >   up the processor and remain in the ready state by specifying a value of
 > -:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
 > +:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications requiring
 use of a
 > +time base instead of system ticks should make use of ``nanosleep()`` or
 > +``clock_nanosleep()``.

 What is a time base?

A delay specified in some subunit of seconds instead of clock ticks.

 nanosleep() has the same issues as rtems_task_wake_after(). If you want
 to wait for fixed intervals, then you have to use clock_nanosleep() with
 TIMER_ABSTIME and CLOCK_MONOTONIC.

 The wording with the interval is not really wrong. Only the clock
 resolution is a bit coarse (clock ticks). I guess the real problem is
 that if you want to implement a periodic task with

 while (1) {
         f();
         rtems_task_wake_after(period);
 }

 then this doesn't work if the time between calls to
 rtems_task_wake_after() varies within the range of clock ticks. This can
 be fixed by using clock_nanosleep() with TIMER_ABSTIME and CLOCK_MONOTONIC.

The issue with specifying "interval" is that "time interval" is a common phrase
in general and a clock tick can vary depending on application configuration.
While the use of "interval" isn't necessarily wrong, "time interval" is very
misleading in this context and could easily be assumed. Would "clock tick
interval" be reasonable for clarity as a way to distance the verbiage from "time
interval"?

The key issue is the use of language such as:

   ticks

 This parameter is the interval in clock ticks to delay the
 task or RTEMS_YIELD_PROCESSOR to yield the processor.

The task may not be delayed by the interval in clock ticks. The interference of
this language is the task is delayed by the period of a clock tick multiplied by
the interval. The task is delayed an indeterminate period of time because the
period of time from the call to the next tick is considered a "tick interval"
when it is only part of a tick interval. Better wording maybe:

Maybe this issue should be explained in the NOTES section.

  ticks

 This parameter is a count of clock ticks to delay the
 task or RTEMS_YIELD_PROCESSOR to yield the processor.

This version is a bit more clear to me.

This may seem apparent to some but it seems not to others and what we have
documented is taken at face value.

This came to light when testing RTEMS 5 and EPICS 7 when the EPICS
systemTickTest test was run. The issue tracking this is:

https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base/-/issues/30

A contributing factor is the improved timestamps introduced in RTEMS 5.

We need to document the fact users need to +1 to the interval if their usage is
the task needs to sleep for a period no shorter then the internal, ie internal x
clock_tick_period.

Yes, this should be documented. Just changing interval to ticks could be 
still confusing.

The test code shows clock_nanosleep() does the right thing and determines if the
remaining period until then next tick is shorter than the requested period and
if not the sleep is extended to the next tick.

Maybe this could be added also to the NOTES section.

To observe how this gets confusing, RTEMS 4.x + EPICS 7 is using the classic API
for epicsThreadSleep:

Re: [RSB 2/4] 6: Update GCC 10 and 12

2023-06-27 Thread Sebastian Huber


On 28.06.23 04:37, Chris Johns wrote:

Can you please provide something other than update in the commit message?

If it is to pick up patches on these gcc release branches then please say so.


This update has no particular reason. I just had a bit of time to run my 
update script. Ideally there would be an automatic update process in 
place. If you don't want to follow the upstream release branches, then 
please say so. However, this work helps to identify RTEMS related issues 
in the upstream development. Working tools for RTEMS need maintenance. 
It is not that release versions of GCC magically work on RTEMS.




Are these versions of the compiler tracking tarfile packages?


No, the configurations track the release branches.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
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: [PATCH rtems-tools] tester/rtems: add renode implementation

2023-06-27 Thread Muhammad Sulthan Mazaya

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
> <
> 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/ <
> 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
> PARTICULAR
> > PURPOSE
> > > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> > CONTRIBUTORS BE
> > > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> EXEMPLARY, OR
> > > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT OF
> > > +#

Re: [RSB 1/4] 6/7: Update Newlib

2023-06-27 Thread Chris Johns

Hi,

What has changed in this version? Is there anything specific we need to know
about or need?

Thanks
Chris

On 27/6/2023 8:21 pm, Sebastian Huber wrote:
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 39b97a5..870c06f 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -17,12 +17,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
> +  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> index 84b5223..0eff966 100644
> --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> @@ -20,12 +20,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
> +  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index f4c47d4..2277b01 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -38,13 +38,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
> +  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> index d39a0b5..8bc72d1 100644
> --- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> @@ -8,12 +8,12 @@
>  %hash sha512 %{gcc_expand_name}.tar.gz \
>
> E5KKObrZDIF1nEAFmZ6zGstL/VAPGCR+FIkCVW3akyTmAPITsmlaNErGHESHjG8PRmCO8zkCHkjkAv6MaHsWvQ==
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
>

Re: [RSB 2/4] 6: Update GCC 10 and 12

2023-06-27 Thread Chris Johns

Can you please provide something other than update in the commit message?

If it is to pick up patches on these gcc release branches then please say so.

Are these versions of the compiler tracking tarfile packages?

Thanks
Chris

On 27/6/2023 8:21 pm, Sebastian Huber wrote:
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 870c06f..e01542e 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -1,12 +1,12 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>  
> -%define gcc_version 52c451e
> +%define gcc_version ab134ec
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
>  %hash sha512 %{gcc_expand_name}.tar.gz \
> -  
> qjkDEEGK9YmRSSz8sQfwgzy9xPkvcvDNbo68vEM92jAEyVmzbTskJW/MtEyw7hwzOJgjWJsdoMKdsUa0yOXlcw==
> +  
> UQEiEegns9qDLBk35p7lrIfeoG3pHOlCPVbnEUqnL3Cqa2yjzl9cc8dNXKUTSvwOeuCQqGN2x08greTe9ZTqaA==
>  
>  %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch
>  %hash sha512 0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch 
> c2d1faed68aa0f60bef917365545cc4cc899df428a5d08f178417c06def4fd3cd3a749c1871c8a22552022c29dfae4a3d21161e2b01291e458ea8d670f01887e
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index 2277b01..7b0d4cb 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -1,12 +1,12 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>  
> -%define gcc_version efc21f1
> +%define gcc_version 0f54a73
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
>  %hash sha512 %{gcc_expand_name}.tar.gz \
> -  
> KTiGNk2WdP/uwZS8t8L1uy0mwzBjrIIDkD/lZycGyGW9TII7dO//2sRF3jfw1drTOoM6+/bqpkDLp3k1/6TZvA==
> +  
> 6q/FCgcnONitGrUuXF9y8nx6FiiSL3JSFwDh31pdJem4QvvcP7pFnybdw/Ve1uOIHab38xZyFVbEsANdAZN6Sg==
>  
>  %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
>  %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch \
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

2023-06-27 Thread Chris Johns

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 
> PARTICULAR
> PURPOSE
> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS BE
> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, 
> OR
> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
> PROCUREMENT OF
> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
> WHETHER IN
> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
> OTHERWISE)
> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 
> ADVISED
> OF

Re: [PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

2023-06-27 Thread Chris Johns

This looks good.

Thanks
Chris

On 28/6/2023 1:30 am, Kinsey Moore wrote:
> Note that this patch is for 6-freebsd-12 and its removal reduces the burden to
> make the master branch match functionality.
> 
> On Tue, Jun 27, 2023 at 10:28 AM Kinsey Moore  > wrote:
> 
> This removes the workaround applied on the fly for QEMU that disables
> priority queueing. The priority queue interrupt was not previously
> hooked up properly in QEMU and RSB now has the patches to allow it to
> work.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 26 +++---
>  1 file changed, 7 insertions(+), 19 deletions(-)
> 
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 689c3611..c1c88e77 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -133,7 +133,6 @@ struct cgem_softc {
>         uint32_t                net_ctl_shadow;
>  #ifdef __rtems__
>         uint32_t                net_cfg_shadow;
> -       int                     neednullqs;
>         int                     phy_contype;
>  #endif /* __rtems__ */
>         int                     ref_clk_num;
> @@ -458,9 +457,8 @@ cgem_setup_descs(struct cgem_softc *sc)
>         int desc_rings_size = CGEM_NUM_RX_DESCS * sizeof(struct 
> cgem_rx_desc) +
>             CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> 
> -       if (sc->neednullqs)
> -               desc_rings_size += sizeof(struct cgem_rx_desc) +
> -                   sizeof(struct cgem_tx_desc);
> +       desc_rings_size += sizeof(struct cgem_rx_desc) +
> +           sizeof(struct cgem_tx_desc);
>  #endif /* __rtems__ */
>         sc->txring = NULL;
>         sc->rxring = NULL;
> @@ -609,13 +607,11 @@ cgem_setup_descs(struct cgem_softc *sc)
>         sc->txring_queued = 0;
> 
>  #ifdef __rtems__
> -       if (sc->neednullqs) {
> -               sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
> -               sc->null_qs_physaddr = sc->txring_physaddr +
> -                   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> +       sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
> +       sc->null_qs_physaddr = sc->txring_physaddr +
> +           CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> 
> -               cgem_null_qs(sc);
> -       }
> +       cgem_null_qs(sc);
>  #endif /* __rtems__ */
> 
>         return (0);
> @@ -2074,15 +2070,7 @@ cgem_attach(device_t dev)
> 
>         sc->if_old_flags = if_getflags(ifp);
>         sc->rxbufs = DEFAULT_NUM_RX_BUFS;
> -#if defined(CGEM64) && defined(__rtems__)
> -       uint32_t design_cfg6 = RD4(sc, CGEM_DESIGN_CFG6);
> -       /*
> -        * QEMU does not have PBUF_CUTTHRU defined and is broken when 
> trying
> -        * to use nullqs
> -        */
> -       if ((design_cfg6 & CGEM_DESIGN_CFG6_PBUF_CUTTHRU))
> -               sc->neednullqs = 1;
> -#else
> +#if !defined(CGEM64) && defined(__rtems__)
>         sc->rxhangwar = 1;
>  #endif
> 
> -- 
> 2.30.2
> 
> ___
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

2023-06-27 Thread Chris Johns

On 28/6/2023 7:37 am, Kinsey Moore wrote:
> 
> On Tue, Jun 27, 2023 at 4:05 PM Sebastian Huber
>  >
> wrote:
> 
> On 27.06.23 22:18, Kinsey Moore wrote:
> > diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> > index c082b51..3334679 100644
> > --- a/c-user/task/directives.rst
> > +++ b/c-user/task/directives.rst
> > @@ -1475,15 +1475,15 @@ The following constraints apply to this 
> directive:
> >       \clearpage
> >   
> >   .. index:: rtems_task_wake_after()
> > -.. index:: delay a task for an interval
> > -.. index:: wake up after an interval
> > +.. index:: delay a task for a number of ticks
> > +.. index:: wake up after a number of ticks
> >   
> >   .. _InterfaceRtemsTaskWakeAfter:
> >   
> >   rtems_task_wake_after()
> >   ---
> >   
> > -Wakes up after an interval in :term:`clock ticks ` or 
> yields the
> > +Wakes up after a number of :term:`clock ticks ` or yields 
> the
> >   processor.
> >   
> >   .. rubric:: CALLING SEQUENCE:
> > @@ -1502,10 +1502,12 @@ processor.
> >   
> >   This directive blocks the calling task for the specified ``ticks`` of 
> clock
> >   ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`. 
> When the
> > -requested interval has elapsed, the task is made ready.  The clock tick
> > +requested number of ticks has elapsed, the task is made ready.  The 
> clock
> tick
> >   directives automatically updates the delay period.  The calling task 
> may
> give
> >   up the processor and remain in the ready state by specifying a value 
> of
> > -:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
> > +:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications requiring
> use of a
> > +time base instead of system ticks should make use of ``nanosleep()`` or
> > +``clock_nanosleep()``.
> 
> What is a time base?
> 
> 
> A delay specified in some subunit of seconds instead of clock ticks.
> 
> 
> nanosleep() has the same issues as rtems_task_wake_after(). If you want
> to wait for fixed intervals, then you have to use clock_nanosleep() with
> TIMER_ABSTIME and CLOCK_MONOTONIC.
> 
> The wording with the interval is not really wrong. Only the clock
> resolution is a bit coarse (clock ticks). I guess the real problem is
> that if you want to implement a periodic task with
> 
> while (1) {
>         f();
>         rtems_task_wake_after(period);
> }
> 
> then this doesn't work if the time between calls to
> rtems_task_wake_after() varies within the range of clock ticks. This can
> be fixed by using clock_nanosleep() with TIMER_ABSTIME and 
> CLOCK_MONOTONIC.
> 
> 
> The issue with specifying "interval" is that "time interval" is a common 
> phrase
> in general and a clock tick can vary depending on application configuration.
> While the use of "interval" isn't necessarily wrong, "time interval" is very
> misleading in this context and could easily be assumed. Would "clock tick
> interval" be reasonable for clarity as a way to distance the verbiage from 
> "time
> interval"?

The key issue is the use of language such as:

  ticks

This parameter is the interval in clock ticks to delay the
task or RTEMS_YIELD_PROCESSOR to yield the processor.

The task may not be delayed by the interval in clock ticks. The interference of
this language is the task is delayed by the period of a clock tick multiplied by
the interval. The task is delayed an indeterminate period of time because the
period of time from the call to the next tick is considered a "tick interval"
when it is only part of a tick interval. Better wording maybe:

 ticks

This parameter is a count of clock ticks to delay the
task or RTEMS_YIELD_PROCESSOR to yield the processor.

This may seem apparent to some but it seems not to others and what we have
documented is taken at face value.

This came to light when testing RTEMS 5 and EPICS 7 when the EPICS
systemTickTest test was run. The issue tracking this is:

https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base/-/issues/30

A contributing factor is the improved timestamps introduced in RTEMS 5.

We need to document the fact users need to +1 to the interval if their usage is
the task needs to sleep for a period no shorter then the internal, ie internal x
clock_tick_period.

The test code shows clock_nanosleep() does the right thing and determines if the
remaining period until then next tick is shorter than the requested period and
if not the sleep is extended to the next tick.

To observe how this gets confusing, RTEMS 4.x + EPICS 7 is using the classic API
for epicsThreadSleep:

https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/osi/os/RTEMS-score/osdThread.c#L494

and RTEMS 5,6 + EPICS 7 is using POSIX which is:

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

2023-06-27 Thread Kinsey Moore

On Tue, Jun 27, 2023 at 4:05 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 27.06.23 22:18, Kinsey Moore wrote:
> > diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> > index c082b51..3334679 100644
> > --- a/c-user/task/directives.rst
> > +++ b/c-user/task/directives.rst
> > @@ -1475,15 +1475,15 @@ The following constraints apply to this
> directive:
> >   \clearpage
> >
> >   .. index:: rtems_task_wake_after()
> > -.. index:: delay a task for an interval
> > -.. index:: wake up after an interval
> > +.. index:: delay a task for a number of ticks
> > +.. index:: wake up after a number of ticks
> >
> >   .. _InterfaceRtemsTaskWakeAfter:
> >
> >   rtems_task_wake_after()
> >   ---
> >
> > -Wakes up after an interval in :term:`clock ticks ` or
> yields the
> > +Wakes up after a number of :term:`clock ticks ` or yields
> the
> >   processor.
> >
> >   .. rubric:: CALLING SEQUENCE:
> > @@ -1502,10 +1502,12 @@ processor.
> >
> >   This directive blocks the calling task for the specified ``ticks`` of
> clock
> >   ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.
> When the
> > -requested interval has elapsed, the task is made ready.  The clock tick
> > +requested number of ticks has elapsed, the task is made ready.  The
> clock tick
> >   directives automatically updates the delay period.  The calling task
> may give
> >   up the processor and remain in the ready state by specifying a value of
> > -:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
> > +:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications requiring
> use of a
> > +time base instead of system ticks should make use of ``nanosleep()`` or
> > +``clock_nanosleep()``.
>
> What is a time base?
>

A delay specified in some subunit of seconds instead of clock ticks.

>
> nanosleep() has the same issues as rtems_task_wake_after(). If you want
> to wait for fixed intervals, then you have to use clock_nanosleep() with
> TIMER_ABSTIME and CLOCK_MONOTONIC.
>
> The wording with the interval is not really wrong. Only the clock
> resolution is a bit coarse (clock ticks). I guess the real problem is
> that if you want to implement a periodic task with
>
> while (1) {
> f();
> rtems_task_wake_after(period);
> }
>
> then this doesn't work if the time between calls to
> rtems_task_wake_after() varies within the range of clock ticks. This can
> be fixed by using clock_nanosleep() with TIMER_ABSTIME and CLOCK_MONOTONIC.
>

The issue with specifying "interval" is that "time interval" is a common
phrase in general and a clock tick can vary depending on application
configuration. While the use of "interval" isn't necessarily wrong, "time
interval" is very misleading in this context and could easily be assumed.
Would "clock tick interval" be reasonable for clarity as a way to distance
the verbiage from "time interval"?


> >
> >   .. rubric:: RETURN VALUES:
> >
>
> Could you please update
>
> https://git.rtems.org/rtems-central/tree/spec/rtems/task/if/wake-after.yml
>
> since this will keep also the Doxygen up to date.
>
> For clock_nanosleep() references, use ${/c/if/clock-nanosleep:/name}.
>

Will do.

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

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

2023-06-27 Thread Sebastian Huber


On 27.06.23 22:18, Kinsey Moore wrote:

diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
index c082b51..3334679 100644
--- a/c-user/task/directives.rst
+++ b/c-user/task/directives.rst
@@ -1475,15 +1475,15 @@ The following constraints apply to this directive:
  \clearpage
  
  .. index:: rtems_task_wake_after()

-.. index:: delay a task for an interval
-.. index:: wake up after an interval
+.. index:: delay a task for a number of ticks
+.. index:: wake up after a number of ticks
  
  .. _InterfaceRtemsTaskWakeAfter:
  
  rtems_task_wake_after()

  ---
  
-Wakes up after an interval in :term:`clock ticks ` or yields the

+Wakes up after a number of :term:`clock ticks ` or yields the
  processor.
  
  .. rubric:: CALLING SEQUENCE:

@@ -1502,10 +1502,12 @@ processor.
  
  This directive blocks the calling task for the specified ``ticks`` of clock

  ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.  When the
-requested interval has elapsed, the task is made ready.  The clock tick
+requested number of ticks has elapsed, the task is made ready.  The clock tick
  directives automatically updates the delay period.  The calling task may give
  up the processor and remain in the ready state by specifying a value of
-:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
+:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications requiring use of a
+time base instead of system ticks should make use of ``nanosleep()`` or
+``clock_nanosleep()``.


What is a time base?

nanosleep() has the same issues as rtems_task_wake_after(). If you want 
to wait for fixed intervals, then you have to use clock_nanosleep() with 
TIMER_ABSTIME and CLOCK_MONOTONIC.


The wording with the interval is not really wrong. Only the clock 
resolution is a bit coarse (clock ticks). I guess the real problem is 
that if you want to implement a periodic task with


while (1) {
f();
rtems_task_wake_after(period);
}

then this doesn't work if the time between calls to 
rtems_task_wake_after() varies within the range of clock ticks. This can 
be fixed by using clock_nanosleep() with TIMER_ABSTIME and CLOCK_MONOTONIC.


  
  .. rubric:: RETURN VALUES:
  


Could you please update

https://git.rtems.org/rtems-central/tree/spec/rtems/task/if/wake-after.yml

since this will keep also the Doxygen up to date.

For clock_nanosleep() references, use ${/c/if/clock-nanosleep:/name}.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
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

[PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

2023-06-27 Thread Kinsey Moore

rtems_task_wake_after takes a parameter in terms of ticks and not any
time base. This updates documentation to reflect that and refers any
applications needing a time base to nanosleep or clock_nanosleep.

Closes #4772
---
 c-user/scheduling-concepts/background.rst |  6 +++---
 c-user/task/directives.rst| 12 +++-
 c-user/task/operations.rst|  9 ++---
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/c-user/scheduling-concepts/background.rst 
b/c-user/scheduling-concepts/background.rst
index 1fe7089..00eb8f0 100644
--- a/c-user/scheduling-concepts/background.rst
+++ b/c-user/scheduling-concepts/background.rst
@@ -160,7 +160,7 @@ Manual Round-Robin
 
 The final mechanism for altering the RTEMS scheduling algorithm is called
 manual round-robin.  Manual round-robin is invoked by using
-the ``rtems_task_wake_after`` directive with a time interval of
+the ``rtems_task_wake_after`` directive with a ticks parameter of
 ``RTEMS_YIELD_PROCESSOR``.  This allows a task to give up the processor and be
 immediately returned to the ready chain at the end of its priority group.  If
 no other tasks of the same priority are ready to run, then the task does not
@@ -243,7 +243,7 @@ of the following conditions:
   option and the requested semaphore is unavailable.
 
 - The running task issues a ``rtems_task_wake_after`` directive which blocks
-  the task for the given time interval.  If the time interval specified is
+  the task for the given number of ticks.  If the number of ticks specified is
   zero, the task yields the processor and remains in the ready state.
 
 - The running task issues a ``rtems_task_wake_when`` directive which blocks the
@@ -280,7 +280,7 @@ conditions:
 - A running task issues a ``rtems_semaphore_release`` directive which releases
   the semaphore on which the blocked task is waiting.
 
-- A timeout interval expires for a task which was blocked by a call to the
+- A tick interval expires for a task which was blocked by a call to the
   ``rtems_task_wake_after`` directive.
 
 - A timeout period expires for a task which blocked by a call to the
diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
index c082b51..3334679 100644
--- a/c-user/task/directives.rst
+++ b/c-user/task/directives.rst
@@ -1475,15 +1475,15 @@ The following constraints apply to this directive:
 \clearpage
 
 .. index:: rtems_task_wake_after()
-.. index:: delay a task for an interval
-.. index:: wake up after an interval
+.. index:: delay a task for a number of ticks
+.. index:: wake up after a number of ticks
 
 .. _InterfaceRtemsTaskWakeAfter:
 
 rtems_task_wake_after()
 ---
 
-Wakes up after an interval in :term:`clock ticks ` or yields the
+Wakes up after a number of :term:`clock ticks ` or yields the
 processor.
 
 .. rubric:: CALLING SEQUENCE:
@@ -1502,10 +1502,12 @@ processor.
 
 This directive blocks the calling task for the specified ``ticks`` of clock
 ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.  When the
-requested interval has elapsed, the task is made ready.  The clock tick
+requested number of ticks has elapsed, the task is made ready.  The clock tick
 directives automatically updates the delay period.  The calling task may give
 up the processor and remain in the ready state by specifying a value of
-:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
+:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications requiring use of a
+time base instead of system ticks should make use of ``nanosleep()`` or
+``clock_nanosleep()``.
 
 .. rubric:: RETURN VALUES:
 
diff --git a/c-user/task/operations.rst b/c-user/task/operations.rst
index 6308d7b..9a55b6c 100644
--- a/c-user/task/operations.rst
+++ b/c-user/task/operations.rst
@@ -75,9 +75,9 @@ Delaying the Currently Executing Task
 -
 
 The ``rtems_task_wake_after`` directive creates a sleep timer which allows a
-task to go to sleep for a specified interval.  The task is blocked until the
-delay interval has elapsed, at which time the task is unblocked.  A task
-calling the ``rtems_task_wake_after`` directive with a delay interval of
+task to go to sleep for a specified number of ticks.  The task is blocked until
+the number of ticks has elapsed, at which time the task is unblocked.  A task
+calling the ``rtems_task_wake_after`` directive with a delay of
 ``RTEMS_YIELD_PROCESSOR`` ticks will yield the processor to any other ready
 task of equal or greater priority and remain ready to execute.
 
@@ -86,6 +86,9 @@ task to go to sleep until a specified date and time.  The 
calling task is
 blocked until the specified date and time has occurred, at which time the task
 is unblocked.
 
+Applications requiring intervals in a time base should use ``nanosleep()`` or
+``clock_nanosleep()``.
+
 Changing Task Priority
 --
 
-- 
2.30.2

___
devel mailing list

[PATCH rtems-lwip] Alter ownership of components in uLan

2023-06-27 Thread Kinsey Moore

This commit breaks up the uLan directory and removes its ORIGIN and
COPYING metadata in favor of this repository being the authoritative
source of these sources as per the wishes of the originator of these
files. More information can be found here:
https://lists.rtems.org/pipermail/devel/2023-March/074525.html

Closes #4867
---
 COPYING.uLan  | 33 ---
 ORIGIN.uLan   |  2 --
 defs/bsps/arm/tms570_base.json| 10 +++---
 defs/common/lwip.json |  4 +--
 .../arch => rtemslwip/common}/sys_arch.c  |  0
 .../os/rtems => rtemslwip/include}/arch/cc.h  |  0
 .../rtems => rtemslwip/include}/arch/perf.h   |  0
 .../include}/arch/sys_arch.h  |  0
 .../tms570}/eth_lwip.c|  0
 .../tms570/include}/eth_lwip.h|  0
 .../tms570/include}/eth_lwip_default.h|  0
 rtemslwip/tms570/{ => include}/lwipbspopts.h  |  0
 .../tms570/include}/phy_dp83848h.h|  0
 .../tms570/include}/ti_drv_emac.h |  0
 .../tms570/include}/ti_drv_mdio.h |  0
 .../tms570/include}/tms570_emac.h |  0
 .../tms570/include}/tms570_netif.h|  0
 .../tms570}/phy_dp83848h.c|  0
 .../tms570}/tms570_netif.c|  0
 19 files changed, 6 insertions(+), 43 deletions(-)
 delete mode 100644 COPYING.uLan
 delete mode 100644 ORIGIN.uLan
 rename {uLan/ports/os/rtems/arch => rtemslwip/common}/sys_arch.c (100%)
 rename {uLan/ports/os/rtems => rtemslwip/include}/arch/cc.h (100%)
 rename {uLan/ports/os/rtems => rtemslwip/include}/arch/perf.h (100%)
 rename {uLan/ports/os/rtems => rtemslwip/include}/arch/sys_arch.h (100%)
 rename {uLan/ports/driver/tms570_emac => rtemslwip/tms570}/eth_lwip.c (100%)
 rename {uLan/ports/driver/tms570_emac => rtemslwip/tms570/include}/eth_lwip.h 
(100%)
 rename {uLan/ports/driver/tms570_emac => 
rtemslwip/tms570/include}/eth_lwip_default.h (100%)
 rename rtemslwip/tms570/{ => include}/lwipbspopts.h (100%)
 rename {uLan/ports/driver/tms570_emac => 
rtemslwip/tms570/include}/phy_dp83848h.h (100%)
 rename {uLan/ports/driver/tms570_emac => 
rtemslwip/tms570/include}/ti_drv_emac.h (100%)
 rename {uLan/ports/driver/tms570_emac => 
rtemslwip/tms570/include}/ti_drv_mdio.h (100%)
 rename {uLan/ports/driver/tms570_emac => 
rtemslwip/tms570/include}/tms570_emac.h (100%)
 rename {uLan/ports/driver/tms570_emac => 
rtemslwip/tms570/include}/tms570_netif.h (100%)
 rename {uLan/ports/driver/tms570_emac => rtemslwip/tms570}/phy_dp83848h.c 
(100%)
 rename {uLan/ports/driver/tms570_emac => rtemslwip/tms570}/tms570_netif.c 
(100%)

diff --git a/COPYING.uLan b/COPYING.uLan
deleted file mode 100644
index e23898b..000
--- a/COPYING.uLan
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
- * All rights reserved. 
- * 
- * 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.
- * 3. The name of the author may not be used to endorse or promote products
- *derived from this software without specific prior written permission. 
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 
IMPLIED 
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT 
- * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
PROCUREMENT 
- * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING 
- * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
POSSIBILITY 
- * OF SUCH DAMAGE.
- *
- * This file is part of the lwIP TCP/IP stack.
- * 
- * Author: Adam Dunkels 
- *
- */
-
-
diff --git a/ORIGIN.uLan b/ORIGIN.uLan
deleted file mode 100644
index 8111d3d..000
--- a/ORIGIN.uLan
+++ /dev/null
@@ -1,2 +0,0 @@
-The files under the uLan/ directory are sourced from:
-git://git.code.sf.net/p/ulan/lwip-omk ulan-lwip-omk
diff --git a/defs/bsps/arm/tms570_base.json b/defs/bsps/arm/tms570_base.json
index e618d5c..93b421d 100644
--- a/defs/bsps/arm/tms570_base.json
+++ b/defs/bsps/arm/tms570_base.json
@@ -1,14 +1,12 @@
 {
"header-paths-to-import": [
-   "uLan/ports/driver/tms570_emac",

Re: doctest rtems example

2023-06-27 Thread Sam Price

I was testing the out of box version of gtest.
It does not support parsing arguments more than once.
I think you have to load / unload the library between runs.

I would really prefer to use google test.  Its what most of our tests
are already in, and has support for utbot.org

Sam

On Sun, Jun 18, 2023 at 7:25 PM Chris Johns  wrote:
>
> Hi Sam,
>
> Thanks for the post. The website for the code is:
>
> https://github.com/doctest/doctest
>
> I have been using this and I can port tests between Linux and RTEMS. I like it
> because it works and it is a single header. There is no need to build and link
> libraries.
>
> Chris
>
> On 16/6/2023 11:07 pm, Sam Price wrote:
> > /* Tell doctest to not use its own main */
> > #define DOCTEST_CONFIG_IMPLEMENT
> > /* tell doctest to not use sigint that rtems does not have */
> > #define DOCTEST_CONFIG_NO_POSIX_SIGNALS
> > #include "doctest.h"
> >
> > /* Setup command line part */
> > const char rtems_test_name[] = "DOCTEST UNIT TESTS";
> >
> > static int run_doctest_tests(int argc, char **argv) {
> >
> > // Initialize doctest context
> > doctest::Context context(argc, argv);
> >
> > int test_result = context.run(); // run queries, or run tests unless 
> > --no-run
> >
> > if(context.shouldExit()) // honor query flags and --exit
> > return test_result;
> > return 0;
> > }
> >
> > rtems_shell_cmd_t Shell_DOCTEST_Command = {
> > "doctest", /* name */
> > "doctest [doctest options]", /* usage */
> > "tests", /* topic */
> > run_doctest_tests, /* command */
> > NULL, /* alias */
> > NULL /* next */
> > };
> >
> > /* Inside of your Init add the following prior to starting shell */
> > rtems_task Init(rtems_task_argument ignored)
> > {
> > 
> >
> > rtems_shell_add_cmd_struct(_DOCTEST_Command);
> > /* Note i made this high priority, some of my tests require priority 
> > access. */
> > /* It may be better to use 100, and use the following in your test
> > rtems_task_priority old_priority;
> > rtems_task_set_priority(RTEMS_SELF, 0, _priority);
> > ...
> > rtems_task_set_priority(RTEMS_SELF, old_priority, 0x0);
> > */
> >
> > rtems_shell_init("shell0", 20 * 1024, 2, "/dev/console", 0, 1, NULL);
> > ...
> > }
> >
> > TEST_CASE("testing the addition function") {
> > CHECK((2 + 2) == 4);
> > CHECK((2 + 2) == 4.0);
> > }
> > ___
> > 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



-- 
Sincerely,

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

Re: [PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

2023-06-27 Thread Kinsey Moore

Note that this patch is for 6-freebsd-12 and its removal reduces the burden
to make the master branch match functionality.

On Tue, Jun 27, 2023 at 10:28 AM Kinsey Moore 
wrote:

> This removes the workaround applied on the fly for QEMU that disables
> priority queueing. The priority queue interrupt was not previously
> hooked up properly in QEMU and RSB now has the patches to allow it to
> work.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 26 +++---
>  1 file changed, 7 insertions(+), 19 deletions(-)
>
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 689c3611..c1c88e77 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -133,7 +133,6 @@ struct cgem_softc {
> uint32_tnet_ctl_shadow;
>  #ifdef __rtems__
> uint32_tnet_cfg_shadow;
> -   int neednullqs;
> int phy_contype;
>  #endif /* __rtems__ */
> int ref_clk_num;
> @@ -458,9 +457,8 @@ cgem_setup_descs(struct cgem_softc *sc)
> int desc_rings_size = CGEM_NUM_RX_DESCS * sizeof(struct
> cgem_rx_desc) +
> CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
>
> -   if (sc->neednullqs)
> -   desc_rings_size += sizeof(struct cgem_rx_desc) +
> -   sizeof(struct cgem_tx_desc);
> +   desc_rings_size += sizeof(struct cgem_rx_desc) +
> +   sizeof(struct cgem_tx_desc);
>  #endif /* __rtems__ */
> sc->txring = NULL;
> sc->rxring = NULL;
> @@ -609,13 +607,11 @@ cgem_setup_descs(struct cgem_softc *sc)
> sc->txring_queued = 0;
>
>  #ifdef __rtems__
> -   if (sc->neednullqs) {
> -   sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
> -   sc->null_qs_physaddr = sc->txring_physaddr +
> -   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> +   sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
> +   sc->null_qs_physaddr = sc->txring_physaddr +
> +   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
>
> -   cgem_null_qs(sc);
> -   }
> +   cgem_null_qs(sc);
>  #endif /* __rtems__ */
>
> return (0);
> @@ -2074,15 +2070,7 @@ cgem_attach(device_t dev)
>
> sc->if_old_flags = if_getflags(ifp);
> sc->rxbufs = DEFAULT_NUM_RX_BUFS;
> -#if defined(CGEM64) && defined(__rtems__)
> -   uint32_t design_cfg6 = RD4(sc, CGEM_DESIGN_CFG6);
> -   /*
> -* QEMU does not have PBUF_CUTTHRU defined and is broken when
> trying
> -* to use nullqs
> -*/
> -   if ((design_cfg6 & CGEM_DESIGN_CFG6_PBUF_CUTTHRU))
> -   sc->neednullqs = 1;
> -#else
> +#if !defined(CGEM64) && defined(__rtems__)
> sc->rxhangwar = 1;
>  #endif
>
> --
> 2.30.2
>
> ___
> 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

[PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

2023-06-27 Thread Kinsey Moore

This removes the workaround applied on the fly for QEMU that disables
priority queueing. The priority queue interrupt was not previously
hooked up properly in QEMU and RSB now has the patches to allow it to
work.
---
 freebsd/sys/dev/cadence/if_cgem.c | 26 +++---
 1 file changed, 7 insertions(+), 19 deletions(-)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 689c3611..c1c88e77 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -133,7 +133,6 @@ struct cgem_softc {
uint32_tnet_ctl_shadow;
 #ifdef __rtems__
uint32_tnet_cfg_shadow;
-   int neednullqs;
int phy_contype;
 #endif /* __rtems__ */
int ref_clk_num;
@@ -458,9 +457,8 @@ cgem_setup_descs(struct cgem_softc *sc)
int desc_rings_size = CGEM_NUM_RX_DESCS * sizeof(struct cgem_rx_desc) +
CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
 
-   if (sc->neednullqs)
-   desc_rings_size += sizeof(struct cgem_rx_desc) +
-   sizeof(struct cgem_tx_desc);
+   desc_rings_size += sizeof(struct cgem_rx_desc) +
+   sizeof(struct cgem_tx_desc);
 #endif /* __rtems__ */
sc->txring = NULL;
sc->rxring = NULL;
@@ -609,13 +607,11 @@ cgem_setup_descs(struct cgem_softc *sc)
sc->txring_queued = 0;
 
 #ifdef __rtems__
-   if (sc->neednullqs) {
-   sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
-   sc->null_qs_physaddr = sc->txring_physaddr +
-   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
+   sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
+   sc->null_qs_physaddr = sc->txring_physaddr +
+   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
 
-   cgem_null_qs(sc);
-   }
+   cgem_null_qs(sc);
 #endif /* __rtems__ */
 
return (0);
@@ -2074,15 +2070,7 @@ cgem_attach(device_t dev)
 
sc->if_old_flags = if_getflags(ifp);
sc->rxbufs = DEFAULT_NUM_RX_BUFS;
-#if defined(CGEM64) && defined(__rtems__)
-   uint32_t design_cfg6 = RD4(sc, CGEM_DESIGN_CFG6);
-   /*
-* QEMU does not have PBUF_CUTTHRU defined and is broken when trying
-* to use nullqs
-*/
-   if ((design_cfg6 & CGEM_DESIGN_CFG6_PBUF_CUTTHRU))
-   sc->neednullqs = 1;
-#else
+#if !defined(CGEM64) && defined(__rtems__)
sc->rxhangwar = 1;
 #endif
 
-- 
2.30.2

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

Triage Meeting Thursday on Discord

2023-06-27 Thread Joel Sherrill

Hi

Chris, Kinsey, Andrei, and Vijay dug through the tickets for 6.1 and did
some triage. I'd like to have another triage meeting this week in the hope
that other people can attend. Sebastian and Gedare both have tickets for
6.1 and it would be good to cover those in person.

We will try for around 430pm Chicago time (Central) Thursday which should
let Chris attend.

Anyone from the community is welcome to attend and certainly any help would
be appreciated in resolving issues. Some are just a matter of someone with
RTEMS knowledge spending a little time especially on some odd documentation
tickets.

Help and input is appreciated.

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

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

2023-06-27 Thread Joel Sherrill

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 <
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 PARTICULAR
>> PURPOSE
>> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>> CONTRIBUTORS BE
>> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>> IN
>> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> OTHERWISE)
>> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
>> OF THE
>> > +# POSSIBILITY OF SUCH DAMAGE.
>> > +#
>> > +
>> > +#
>> > +# The Kendrytek210 Renode BSP
>> > +#
>> > +[kendrytek210-renode]
>> > +bsp = kendrytek210-renode
>> > +arch= riscv
>> > +tester  = %{_rtscripts}/renode.cfg
>> > +bsp_resc_script = %{_rtscripts}/renode_scripts/kendrytek210.resc
>> > diff --git a/tester/rtems/testing/renode.cfg
>> b/tester/rtems/testing/renode.cfg
>> > new file mode 100644
>> > index 000..49e84a5
>> > --- /dev/null
>> > +++ b/tester/rtems/testing/renode.cfg
>> > @@ -0,0 +1,64 @@
>> > +#
>> > +# 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

[RSB 1/4] 6/7: Update Newlib

2023-06-27 Thread Sebastian Huber

---
 rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
index 39b97a5..870c06f 100644
--- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
@@ -17,12 +17,12 @@
 %patch add newlib -p1 
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
 %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
 
-%define newlib_version 9ae9eef
+%define newlib_version 4c7d0df
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
+  
tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
index 84b5223..0eff966 100644
--- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
@@ -20,12 +20,12 @@
 %patch add newlib -p1 
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
 %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
 
-%define newlib_version 9ae9eef
+%define newlib_version 4c7d0df
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
+  
tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index f4c47d4..2277b01 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -38,13 +38,13 @@
 
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
 # Comment above related to #4657 and patches ends here
 
-%define newlib_version 9ae9eef
+%define newlib_version 4c7d0df
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \

https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
+  
tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
index d39a0b5..8bc72d1 100644
--- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
@@ -8,12 +8,12 @@
 %hash sha512 %{gcc_expand_name}.tar.gz \
   
E5KKObrZDIF1nEAFmZ6zGstL/VAPGCR+FIkCVW3akyTmAPITsmlaNErGHESHjG8PRmCO8zkCHkjkAv6MaHsWvQ==
 
-%define newlib_version 9ae9eef
+%define newlib_version 4c7d0df
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
+  
tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
 
 %patch add newlib -p1 
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
 %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch

[RSB 2/4] 6: Update GCC 10 and 12

2023-06-27 Thread Sebastian Huber

---
 rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
index 870c06f..e01542e 100644
--- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version 52c451e
+%define gcc_version ab134ec
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
qjkDEEGK9YmRSSz8sQfwgzy9xPkvcvDNbo68vEM92jAEyVmzbTskJW/MtEyw7hwzOJgjWJsdoMKdsUa0yOXlcw==
+  
UQEiEegns9qDLBk35p7lrIfeoG3pHOlCPVbnEUqnL3Cqa2yjzl9cc8dNXKUTSvwOeuCQqGN2x08greTe9ZTqaA==
 
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch
 %hash sha512 0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch 
c2d1faed68aa0f60bef917365545cc4cc899df428a5d08f178417c06def4fd3cd3a749c1871c8a22552022c29dfae4a3d21161e2b01291e458ea8d670f01887e
diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index 2277b01..7b0d4cb 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version efc21f1
+%define gcc_version 0f54a73
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
KTiGNk2WdP/uwZS8t8L1uy0mwzBjrIIDkD/lZycGyGW9TII7dO//2sRF3jfw1drTOoM6+/bqpkDLp3k1/6TZvA==
+  
6q/FCgcnONitGrUuXF9y8nx6FiiSL3JSFwDh31pdJem4QvvcP7pFnybdw/Ve1uOIHab38xZyFVbEsANdAZN6Sg==
 
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
 %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch \
-- 
2.35.3

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

[RSB 3/4] 7: Update Binutils, GDB, and GCC

2023-06-27 Thread Sebastian Huber

---
 rtems/config/tools/rtems-binutils-head.cfg| 4 ++--
 rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gdb-head.cfg | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/rtems/config/tools/rtems-binutils-head.cfg 
b/rtems/config/tools/rtems-binutils-head.cfg
index 79d7881..e63d828 100644
--- a/rtems/config/tools/rtems-binutils-head.cfg
+++ b/rtems/config/tools/rtems-binutils-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define binutils_version 8f5cd47
+%define binutils_version cddbf40
 %define binutils_external 1
 %define binutils_expand_name sourceware-mirror-binutils-gdb-%{binutils_version}
 %source set binutils --rsb-file=%{binutils_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{binutils_version}
 %hash sha512 %{binutils_expand_name}.tar.gz \
-  
jq1QzKivWmc0YXn/dSBv0n6dVQNJX3mNpL5rAq40v9FagZ96iVtYgCJ4fY1eZuLde7xSXwzwRl6Dg29F38/f+Q==
+  
ECazhcPTJW236jHgombFh21ZeiDkX8529Sylopt0KXVc/8N09F6AJHxsE6W/A9ZJdHRJKo4NhGPOJsLC40kqHw==
 
 %define with_deterministic_archives 1
 %define with_64_bit_bfd 1
diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
index 8bc72d1..7297d85 100644
--- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version 0530254
+%define gcc_version 3162ca0
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
E5KKObrZDIF1nEAFmZ6zGstL/VAPGCR+FIkCVW3akyTmAPITsmlaNErGHESHjG8PRmCO8zkCHkjkAv6MaHsWvQ==
+  
RePiY4P5QBJOp4cqxL4CBV+/Os0vTLLY50HCa32BiTu8cscPHtiWM8GBtNd0bKYt7Sm0KQDtx0MMEapi47JEzg==
 
 %define newlib_version 4c7d0df
 %define newlib_external 1
diff --git a/rtems/config/tools/rtems-gdb-head.cfg 
b/rtems/config/tools/rtems-gdb-head.cfg
index 1223f7d..11abd6a 100644
--- a/rtems/config/tools/rtems-gdb-head.cfg
+++ b/rtems/config/tools/rtems-gdb-head.cfg
@@ -1,11 +1,11 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gdb_version 8f5cd47
+%define gdb_version cddbf40
 %define gdb_external 1
 %define gdb_expand_name sourceware-mirror-binutils-gdb-%{gdb_version}
 %source set gdb --rsb-file=%{gdb_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{gdb_version}
 %hash sha512 %{gdb_expand_name}.tar.gz \
-  
jq1QzKivWmc0YXn/dSBv0n6dVQNJX3mNpL5rAq40v9FagZ96iVtYgCJ4fY1eZuLde7xSXwzwRl6Dg29F38/f+Q==
+  
ECazhcPTJW236jHgombFh21ZeiDkX8529Sylopt0KXVc/8N09F6AJHxsE6W/A9ZJdHRJKo4NhGPOJsLC40kqHw==
 
 %include %{_configdir}/gdb-8-1.cfg
-- 
2.35.3

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

[RSB 4/4] tools: Add GCC 13 configuration

2023-06-27 Thread Sebastian Huber

---
 .../config/tools/rtems-gcc-13-newlib-head.cfg | 25 +++
 1 file changed, 25 insertions(+)
 create mode 100644 rtems/config/tools/rtems-gcc-13-newlib-head.cfg

diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
new file mode 100644
index 000..a507928
--- /dev/null
+++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
@@ -0,0 +1,25 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gcc_version 9599da7
+%define gcc_external 1
+%define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
+%source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
+%hash sha512 %{gcc_expand_name}.tar.gz \
+  
Bap0yX4QA/1mQVQeUJyicdu1qUBsFapuJwxKKtfluFOUX11AtDpXzUL/wt6P7KvJKX5dDVWW8ZW4pIb8IAW3aw==
+
+%define newlib_version 4c7d0df
+%define newlib_external 1
+%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
+%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
+%hash sha512 newlib-%{newlib_version}.tar.gz \
+  
tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
+
+%patch add newlib -p1 
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
+%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
+
+%define with_threads 1
+%define with_plugin 0
+%define with_iconv 1
+
+%include %{_configdir}/gcc-12.cfg
-- 
2.35.3

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

Re: [RSB 1/4] 6/7: Update Newlib

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

Re: [RSB 2/4] 6: Update GCC 10 and 12

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

Re: [RSB 1/4] 6/7: Update Newlib

Re: [RSB 2/4] 6: Update GCC 10 and 12

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

Re: [PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

[PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

[PATCH rtems-lwip] Alter ownership of components in uLan

Re: doctest rtems example

Re: [PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

[PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

Triage Meeting Thursday on Discord

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

[RSB 1/4] 6/7: Update Newlib

[RSB 2/4] 6: Update GCC 10 and 12

[RSB 3/4] 7: Update Binutils, GDB, and GCC

[RSB 4/4] tools: Add GCC 13 configuration

23 matches

Site Navigation

Mail list logo

Footer information