date:20230628

Re: [PATCH v2 00/32] Integrate pre-qualified LEON3 BSP

2023-06-28 Thread Chris Johns

On 29/6/2023 3:41 am, Sebastian Huber wrote:
> On 16.06.23 08:00, Sebastian Huber wrote:
>> The register block specification were recently integrated in the RTEMS
>> Software Engineering manual.  Now it is time to integrate the
>> pre-qualified LEON3 BSP which uses the generated GRLIB header files.
>>
>> The existing tests in the RTEMS test suite are basically BSP
>> independent. This patch set introduces BSP-specific validation tests.
>> These tests are disabled for other BSPs through the build system, for
>> example:
>>
>> spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
>> [...]
>> cxxflags: []
>> enabled-by: sparc/gr712rc
>> features: c cprogram
>> [...]
>>
>> The patch set introduces new header files for GRLIB in
>> "bsps/include/grlib".  These header files were generated from
>> specification items in:
>>
>> https://github.com/RTEMS/rtems-central/tree/master/spec/dev/grlib/if
>>
>> The specification was created using the GRIP reference manual
>> (https://www.gaisler.com/products/grlib/grip.pdf) and is quite complete.
>> The generated header files were reviewed by the ISVV activity which
>> resulted in two tickets:
>>
>> https://devel.rtems.org/ticket/4828
>>
>> https://devel.rtems.org/ticket/4842
>>
>> In the long term, the existing GRLIB header files should be replaced by
>> the generated header files. Using specification items for the register
>> blocks has the potential benefit that, in addition to the C header
>> files, files for C++/Rust/Python could be generated.
>>
>> The main change for the sparc/gr712rc and sparc/gr740 BSPs is the
>> removal of the dynamic device enumeration in favor of a static
>> initialization.  This greatly simplifies the specification and
>> validation of the BSP-specific parts. It also reduces the code and data
>> size for applications which do not need the dynamic device enumeration.
>>
>> v2:
>>
>> * Move BSP-specific tests to "testsuites/validation/bsps".
>>
>> * Rearrange patches so that they build individually.
> 
> Any comments to this patch set? For the leon3-specific parts I wait for a 
> review
> from Gaisler.

Nothing new from me.

I still do not see how the reg struct is verified however you are fine with
that. I do not use this code.

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

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

2023-06-28 Thread Chris Johns

On 28/6/2023 3:33 pm, Sebastian Huber wrote:
> 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.

This sounds great. Would it be possible to add a simple comment in the commit
message this is a housekeeping update to the latest? It makes it easier
reviewing the commit log to understand changes of interest verses such as things
we need or make in newlib verses housekeeping.

>>
>> Are these versions of the compiler tracking tarfile packages?
> 
> No, the configurations track the release branches.
> 

For newlib this makes sense during development and releases because of newlib's
long release period. It also works for binutils, gcc and gdb when we are in
development however I am not sure it does with releases. Should we look to
tarfiles for releases for the binutils, gcc and gdb tools?

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

Re: [PATCH rtems] Remove unused _IO_Relax

2023-06-28 Thread Joel Sherrill

/

On Wed, Jun 28, 2023 at 12:17 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28.06.23 19:02, Joel Sherrill wrote:
> > On Wed, Jun 28, 2023 at 11:29 AM Sebastian Huber
> >  > > wrote:
> >
> > On 28.06.23 18:17, Joel Sherrill wrote:
> >  > On Wed, Jun 28, 2023 at 11:07 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > On 28.06.23 18:05, Joel Sherrill wrote:
> >  >  > The only use was in a test.
> >  >
> >  > This function is used by this patch set:
> >  >
> >  > https://lists.rtems.org/pipermail/devel/2023-June/075497.html
> > 
> >  >
> >    > >
> >  >
> >  >
> >  > (1) Not in the source repository
> >
> > I didn't expect that the BSP update integration takes about two
> years.
> >
> >  > (2) Even if it was, this code does not belong in the score. It
> looks
> >  > more like BSP support code that some drivers need.
> >
> > Where would you place this code?
> >
> >
> > If you want it on the cpukit side, dev/shared maybe. Otherwise,
> bsps/shared.
>
> Ok, I move it to cpukit/dev/io. At some point in time we probably need a
> bus space API.
>

Thanks. I am picking at moving all printk related functions into a single
location.

rtems/score/io.h really should not exist. Do you have any suggestions for
a more appropriate location and prefix for _IO_Base64url?

If it really is private as indicated by the _IO_ prefix, then it should not
be used where it is in the code. It needs a real public facing name and a
better location.

--joel

>
> --
> 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-central] spec/wake-after: Update references to intervals

2023-06-28 Thread Kinsey Moore

Thanks, v2 coming shortly.

Kinsey

On Wed, Jun 28, 2023 at 1:28 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28.06.23 20:22, Kinsey Moore wrote:
> > rtems_task_wake_after takes a parameter in terms of a count of clock
> > ticks and not a measure in a subunit of seconds. This updates
> > documentation to reflect that and recommends clock_nanosleep() for
> > applications requiring sleep for a time-based duration instead of a
> > count of clock ticks.
> >
> > Updates #4772
> > ---
> >   spec/rtems/task/if/wake-after.yml | 26 +++---
> >   1 file changed, 15 insertions(+), 11 deletions(-)
> >
> > diff --git a/spec/rtems/task/if/wake-after.yml
> b/spec/rtems/task/if/wake-after.yml
> > index b3805251..a5791f14 100644
> > --- a/spec/rtems/task/if/wake-after.yml
> > +++ b/spec/rtems/task/if/wake-after.yml
> > @@ -1,7 +1,7 @@
> >   SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> >   brief: |
> > -  Wakes up after an interval in ${/glossary/clock-tick:/plural} or
> yields the
> > -  processor.
> > +  Wakes up after a count of ${/glossary/clock-tick:/plural} have
> occurred or
> > +  yields the processor.
> >   copyrights:
> >   - Copyright (C) 2021 embedded brains GmbH (
> http://www.embedded-brains.de)
> >   - Copyright (C) 1988, 2017 On-Line Applications Research Corporation
> (OAR)
>
> Maybe update to 2023.
>
> > @@ -15,15 +15,15 @@ definition:
> > variants: []
> >   description: |
> > This directive blocks the calling task for the specified
> ${.:/params[0]/name}
> > -  of clock ticks if the value is not equal to
> ${yield-processor:/name}.  When
> > -  the requested interval 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
> > -  ${yield-processor:/name} in ${.:/params[0]/name}.
> > +  count of clock ticks if the value is not equal to
> ${yield-processor:/name}.
> > +  When the requested count of ticks have occurred, the task is made
> ready.  The
> > +  clock tick directives automatically update the delay period.  The
> calling task
> > +  may give up the processor and remain in the ready state by specifying
> a value
> > +  of ${yield-processor:/name} in ${.:/params[0]/name}.
> >   enabled-by: true
> >   index-entries:
> > -- delay a task for an interval
> > -- wake up after an interval
> > +- delay a task for a count of clock ticks
> > +- wake up after a count of clock ticks
> >   interface-type: function
> >   links:
> >   - role: interface-placement
> > @@ -40,10 +40,14 @@ name: rtems_task_wake_after
> >   notes: |
> > Setting the system date and time with the ${../../clock/if/set:/name}
> > directive and similar directives which set
> ${/glossary/clock-realtime:/term}
> > -  have no effect on a ${wake-after:/name} blocked task.
> > +  have no effect on a ${wake-after:/name} blocked task.  The delay
> until first
> > +  clock tick will never be a whole clock tick interval since this
> directive will
> > +  never excute exactly on a clock tick.  Applications requiring use of
> a clock
> > +  (CLOCK_REALTIME or CLOCK_MONOTONIC) instead of clock ticks should
> make use of
>
> (${/glossary/clock-realtime:/term} or
> ${/glossary/clock-monotonic:/term}) instead...
>
> > +  ${/c/if/clock-nanosleep:/name}.
> >   params:
> >   - description: |
> > -is the interval in ${/glossary/clock-tick:/plural} to delay the
> task or
> > +is the count of ${/glossary/clock-tick:/plural} to delay the task or
> >   ${yield-processor:/name} to yield the processor.
> > dir: null
> > name: ticks
>
> Thanks, it is now clear to me.
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-central v2] spec/wake-after: Update references to intervals

2023-06-28 Thread Kinsey Moore

rtems_task_wake_after takes a parameter in terms of a count of clock
ticks and not a measure in a subunit of seconds. This updates
documentation to reflect that and recommends clock_nanosleep() for
applications requiring sleep for a time-based duration instead of a
count of clock ticks.

Updates #4772
---
 spec/rtems/task/if/wake-after.yml | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/spec/rtems/task/if/wake-after.yml 
b/spec/rtems/task/if/wake-after.yml
index b3805251..0524a26a 100644
--- a/spec/rtems/task/if/wake-after.yml
+++ b/spec/rtems/task/if/wake-after.yml
@@ -1,10 +1,10 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 brief: |
-  Wakes up after an interval in ${/glossary/clock-tick:/plural} or yields the
-  processor.
+  Wakes up after a count of ${/glossary/clock-tick:/plural} have occurred or
+  yields the processor.
 copyrights:
 - Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
-- Copyright (C) 1988, 2017 On-Line Applications Research Corporation (OAR)
+- Copyright (C) 1988, 2023 On-Line Applications Research Corporation (OAR)
 definition:
   default:
 attributes: null
@@ -15,15 +15,15 @@ definition:
   variants: []
 description: |
   This directive blocks the calling task for the specified ${.:/params[0]/name}
-  of clock ticks if the value is not equal to ${yield-processor:/name}.  When
-  the requested interval 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
-  ${yield-processor:/name} in ${.:/params[0]/name}.
+  count of clock ticks if the value is not equal to ${yield-processor:/name}.
+  When the requested count of ticks have occurred, the task is made ready.  The
+  clock tick directives automatically update the delay period.  The calling 
task
+  may give up the processor and remain in the ready state by specifying a value
+  of ${yield-processor:/name} in ${.:/params[0]/name}.
 enabled-by: true
 index-entries:
-- delay a task for an interval
-- wake up after an interval
+- delay a task for a count of clock ticks
+- wake up after a count of clock ticks
 interface-type: function
 links:
 - role: interface-placement
@@ -40,10 +40,14 @@ name: rtems_task_wake_after
 notes: |
   Setting the system date and time with the ${../../clock/if/set:/name}
   directive and similar directives which set ${/glossary/clock-realtime:/term}
-  have no effect on a ${wake-after:/name} blocked task.
+  have no effect on a ${wake-after:/name} blocked task.  The delay until first
+  clock tick will never be a whole clock tick interval since this directive 
will
+  never excute exactly on a clock tick.  Applications requiring use of a clock
+  (${/glossary/clock-realtime:/term} or ${/glossary/clock-monotonic:/term})
+  instead of clock ticks should make use of ${/c/if/clock-nanosleep:/name}.
 params:
 - description: |
-is the interval in ${/glossary/clock-tick:/plural} to delay the task or
+is the count of ${/glossary/clock-tick:/plural} to delay the task or
 ${yield-processor:/name} to yield the processor.
   dir: null
   name: ticks
-- 
2.30.2

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

Re: [PATCH rtems-central] spec/wake-after: Update references to intervals

2023-06-28 Thread Sebastian Huber


On 28.06.23 20:22, Kinsey Moore wrote:

rtems_task_wake_after takes a parameter in terms of a count of clock
ticks and not a measure in a subunit of seconds. This updates
documentation to reflect that and recommends clock_nanosleep() for
applications requiring sleep for a time-based duration instead of a
count of clock ticks.

Updates #4772
---
  spec/rtems/task/if/wake-after.yml | 26 +++---
  1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/spec/rtems/task/if/wake-after.yml 
b/spec/rtems/task/if/wake-after.yml
index b3805251..a5791f14 100644
--- a/spec/rtems/task/if/wake-after.yml
+++ b/spec/rtems/task/if/wake-after.yml
@@ -1,7 +1,7 @@
  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
  brief: |
-  Wakes up after an interval in ${/glossary/clock-tick:/plural} or yields the
-  processor.
+  Wakes up after a count of ${/glossary/clock-tick:/plural} have occurred or
+  yields the processor.
  copyrights:
  - Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
  - Copyright (C) 1988, 2017 On-Line Applications Research Corporation (OAR)


Maybe update to 2023.


@@ -15,15 +15,15 @@ definition:
variants: []
  description: |
This directive blocks the calling task for the specified 
${.:/params[0]/name}
-  of clock ticks if the value is not equal to ${yield-processor:/name}.  When
-  the requested interval 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
-  ${yield-processor:/name} in ${.:/params[0]/name}.
+  count of clock ticks if the value is not equal to ${yield-processor:/name}.
+  When the requested count of ticks have occurred, the task is made ready.  The
+  clock tick directives automatically update the delay period.  The calling 
task
+  may give up the processor and remain in the ready state by specifying a value
+  of ${yield-processor:/name} in ${.:/params[0]/name}.
  enabled-by: true
  index-entries:
-- delay a task for an interval
-- wake up after an interval
+- delay a task for a count of clock ticks
+- wake up after a count of clock ticks
  interface-type: function
  links:
  - role: interface-placement
@@ -40,10 +40,14 @@ name: rtems_task_wake_after
  notes: |
Setting the system date and time with the ${../../clock/if/set:/name}
directive and similar directives which set ${/glossary/clock-realtime:/term}
-  have no effect on a ${wake-after:/name} blocked task.
+  have no effect on a ${wake-after:/name} blocked task.  The delay until first
+  clock tick will never be a whole clock tick interval since this directive 
will
+  never excute exactly on a clock tick.  Applications requiring use of a clock
+  (CLOCK_REALTIME or CLOCK_MONOTONIC) instead of clock ticks should make use of


(${/glossary/clock-realtime:/term} or 
${/glossary/clock-monotonic:/term}) instead...



+  ${/c/if/clock-nanosleep:/name}.
  params:
  - description: |
-is the interval in ${/glossary/clock-tick:/plural} to delay the task or
+is the count of ${/glossary/clock-tick:/plural} to delay the task or
  ${yield-processor:/name} to yield the processor.
dir: null
name: ticks


Thanks, it is now clear to me.

--
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 v2] c-user: Update references to rtems_task_wake_after

2023-06-28 Thread Kinsey Moore

rtems_task_wake_after takes a parameter in terms of a count of clock
ticks and not a measure in a subunit of seconds. This updates
documentation to reflect that.

Updates #4772
---
 c-user/scheduling-concepts/background.rst | 8 
 c-user/task/operations.rst| 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/c-user/scheduling-concepts/background.rst 
b/c-user/scheduling-concepts/background.rst
index 1fe7089..38b77ee 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 count of ticks.  If the count 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,8 +280,8 @@ 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
-  ``rtems_task_wake_after`` directive.
+- The requested count of ticks has elapsed 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
   ``rtems_task_wake_when`` directive.
diff --git a/c-user/task/operations.rst b/c-user/task/operations.rst
index 6308d7b..438eea5 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 count of clock ticks.  The task is blocked
+until the count of clock 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.
 
-- 
2.30.2

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

[PATCH rtems-central] spec/wake-after: Update references to intervals

2023-06-28 Thread Kinsey Moore

rtems_task_wake_after takes a parameter in terms of a count of clock
ticks and not a measure in a subunit of seconds. This updates
documentation to reflect that and recommends clock_nanosleep() for
applications requiring sleep for a time-based duration instead of a
count of clock ticks.

Updates #4772
---
 spec/rtems/task/if/wake-after.yml | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/spec/rtems/task/if/wake-after.yml 
b/spec/rtems/task/if/wake-after.yml
index b3805251..a5791f14 100644
--- a/spec/rtems/task/if/wake-after.yml
+++ b/spec/rtems/task/if/wake-after.yml
@@ -1,7 +1,7 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 brief: |
-  Wakes up after an interval in ${/glossary/clock-tick:/plural} or yields the
-  processor.
+  Wakes up after a count of ${/glossary/clock-tick:/plural} have occurred or
+  yields the processor.
 copyrights:
 - Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
 - Copyright (C) 1988, 2017 On-Line Applications Research Corporation (OAR)
@@ -15,15 +15,15 @@ definition:
   variants: []
 description: |
   This directive blocks the calling task for the specified ${.:/params[0]/name}
-  of clock ticks if the value is not equal to ${yield-processor:/name}.  When
-  the requested interval 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
-  ${yield-processor:/name} in ${.:/params[0]/name}.
+  count of clock ticks if the value is not equal to ${yield-processor:/name}.
+  When the requested count of ticks have occurred, the task is made ready.  The
+  clock tick directives automatically update the delay period.  The calling 
task
+  may give up the processor and remain in the ready state by specifying a value
+  of ${yield-processor:/name} in ${.:/params[0]/name}.
 enabled-by: true
 index-entries:
-- delay a task for an interval
-- wake up after an interval
+- delay a task for a count of clock ticks
+- wake up after a count of clock ticks
 interface-type: function
 links:
 - role: interface-placement
@@ -40,10 +40,14 @@ name: rtems_task_wake_after
 notes: |
   Setting the system date and time with the ${../../clock/if/set:/name}
   directive and similar directives which set ${/glossary/clock-realtime:/term}
-  have no effect on a ${wake-after:/name} blocked task.
+  have no effect on a ${wake-after:/name} blocked task.  The delay until first
+  clock tick will never be a whole clock tick interval since this directive 
will
+  never excute exactly on a clock tick.  Applications requiring use of a clock
+  (CLOCK_REALTIME or CLOCK_MONOTONIC) instead of clock ticks should make use of
+  ${/c/if/clock-nanosleep:/name}.
 params:
 - description: |
-is the interval in ${/glossary/clock-tick:/plural} to delay the task or
+is the count of ${/glossary/clock-tick:/plural} to delay the task or
 ${yield-processor:/name} to yield the processor.
   dir: null
   name: ticks
-- 
2.30.2

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

Re: [PATCH v2 00/32] Integrate pre-qualified LEON3 BSP

2023-06-28 Thread Sebastian Huber


On 16.06.23 08:00, Sebastian Huber wrote:

The register block specification were recently integrated in the RTEMS
Software Engineering manual.  Now it is time to integrate the
pre-qualified LEON3 BSP which uses the generated GRLIB header files.

The existing tests in the RTEMS test suite are basically BSP
independent. This patch set introduces BSP-specific validation tests.
These tests are disabled for other BSPs through the build system, for
example:

spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
[...]
cxxflags: []
enabled-by: sparc/gr712rc
features: c cprogram
[...]

The patch set introduces new header files for GRLIB in
"bsps/include/grlib".  These header files were generated from
specification items in:

https://github.com/RTEMS/rtems-central/tree/master/spec/dev/grlib/if

The specification was created using the GRIP reference manual
(https://www.gaisler.com/products/grlib/grip.pdf) and is quite complete.
The generated header files were reviewed by the ISVV activity which
resulted in two tickets:

https://devel.rtems.org/ticket/4828

https://devel.rtems.org/ticket/4842

In the long term, the existing GRLIB header files should be replaced by
the generated header files. Using specification items for the register
blocks has the potential benefit that, in addition to the C header
files, files for C++/Rust/Python could be generated.

The main change for the sparc/gr712rc and sparc/gr740 BSPs is the
removal of the dynamic device enumeration in favor of a static
initialization.  This greatly simplifies the specification and
validation of the BSP-specific parts. It also reduces the code and data
size for applications which do not need the dynamic device enumeration.

v2:

* Move BSP-specific tests to "testsuites/validation/bsps".

* Rearrange patches so that they build individually.


Any comments to this patch set? For the leon3-specific parts I wait for 
a review from Gaisler.


--
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] Remove unused _IO_Relax

2023-06-28 Thread Sebastian Huber


On 28.06.23 19:02, Joel Sherrill wrote:
On Wed, Jun 28, 2023 at 11:29 AM Sebastian Huber 
> wrote:


On 28.06.23 18:17, Joel Sherrill wrote:
 > On Wed, Jun 28, 2023 at 11:07 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 28.06.23 18:05, Joel Sherrill wrote:
 >      > The only use was in a test.
 >
 >     This function is used by this patch set:
 >
 > https://lists.rtems.org/pipermail/devel/2023-June/075497.html

 >   
  >
 >
 >
 > (1) Not in the source repository

I didn't expect that the BSP update integration takes about two years.

 > (2) Even if it was, this code does not belong in the score. It looks
 > more like BSP support code that some drivers need.

Where would you place this code?


If you want it on the cpukit side, dev/shared maybe. Otherwise, bsps/shared.


Ok, I move it to cpukit/dev/io. At some point in time we probably need a 
bus space API.


--
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] Remove unused _IO_Relax

2023-06-28 Thread Joel Sherrill

On Wed, Jun 28, 2023 at 11:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28.06.23 18:17, Joel Sherrill wrote:
> > On Wed, Jun 28, 2023 at 11:07 AM Sebastian Huber
> >  > > wrote:
> >
> > On 28.06.23 18:05, Joel Sherrill wrote:
> >  > The only use was in a test.
> >
> > This function is used by this patch set:
> >
> > https://lists.rtems.org/pipermail/devel/2023-June/075497.html
> > 
> >
> >
> > (1) Not in the source repository
>
> I didn't expect that the BSP update integration takes about two years.
>
> > (2) Even if it was, this code does not belong in the score. It looks
> > more like BSP support code that some drivers need.
>
> Where would you place this code?
>

If you want it on the cpukit side, dev/shared maybe. Otherwise, bsps/shared.

I think it's bsp/driver support code.

--joel


>
> --
> 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] Remove unused _IO_Relax

2023-06-28 Thread Sebastian Huber


On 28.06.23 18:17, Joel Sherrill wrote:
On Wed, Jun 28, 2023 at 11:07 AM Sebastian Huber 
> wrote:


On 28.06.23 18:05, Joel Sherrill wrote:
 > The only use was in a test.

This function is used by this patch set:

https://lists.rtems.org/pipermail/devel/2023-June/075497.html



(1) Not in the source repository


I didn't expect that the BSP update integration takes about two years.

(2) Even if it was, this code does not belong in the score. It looks 
more like BSP support code that some drivers need.


Where would you place this code?

--
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] Remove unused _IO_Relax

2023-06-28 Thread Joel Sherrill

On Wed, Jun 28, 2023 at 11:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28.06.23 18:05, Joel Sherrill wrote:
> > The only use was in a test.
>
> This function is used by this patch set:
>
> https://lists.rtems.org/pipermail/devel/2023-June/075497.html


(1) Not in the source repository

(2) Even if it was, this code does not belong in the score. It looks more
like BSP support code that some drivers need.

If you want it to stay, rename and move it. I am starting a pass to clean
some things in the score that are not really core to the OS proper and are
in the wrong place.

--joel

>
>
> --
> 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] Remove unused _IO_Relax

2023-06-28 Thread Sebastian Huber


On 28.06.23 18:05, Joel Sherrill wrote:

The only use was in a test.


This function is used by this patch set:

https://lists.rtems.org/pipermail/devel/2023-June/075497.html

--
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] Remove unused _IO_Relax

2023-06-28 Thread Joel Sherrill

The only use was in a test.
---
 cpukit/include/rtems/score/io.h|  8 ---
 cpukit/score/src/iorelax.c | 53 -
 spec/build/cpukit/librtemscpu.yml  |  1 -
 spec/build/testsuites/validation/libvalidation.yml |  1 -
 testsuites/validation/tx-io-relax.c| 67 --
 5 files changed, 130 deletions(-)
 delete mode 100644 cpukit/score/src/iorelax.c
 delete mode 100644 testsuites/validation/tx-io-relax.c

diff --git a/cpukit/include/rtems/score/io.h b/cpukit/include/rtems/score/io.h
index 9cd401e..7fe6984 100644
--- a/cpukit/include/rtems/score/io.h
+++ b/cpukit/include/rtems/score/io.h
@@ -133,14 +133,6 @@ int _IO_Base64url(
   int  wordlen
 );
 
-/**
- * @brief Issues a couple of no-operation instructions.
- *
- * This function may be used to burn a couple of processor cycles with minimum
- * impact on the system bus.  It may be used in busy wait loops.
- */
-void _IO_Relax( void );
-
 /** @} */ 
 
 #ifdef __cplusplus
diff --git a/cpukit/score/src/iorelax.c b/cpukit/score/src/iorelax.c
deleted file mode 100644
index 1b15537..000
--- a/cpukit/score/src/iorelax.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup RTEMSScoreIO
- *
- * @brief This source file contains the implementation of _IO_Relax().
- */
-
-/*
- * Copyright (C) 2021 embedded brains GmbH & Co. KG
- *
- * 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 OWNER 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.
- */
-
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#endif
-
-#include 
-#include 
-
-void _IO_Relax( void )
-{
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-  _CPU_Instruction_no_operation();
-}
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 3654e7f..a1f614a 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -1434,7 +1434,6 @@ source:
 - cpukit/score/src/interr.c
 - cpukit/score/src/iobase64.c
 - cpukit/score/src/ioprintf.c
-- cpukit/score/src/iorelax.c
 - cpukit/score/src/iovprintf.c
 - cpukit/score/src/isr.c
 - cpukit/score/src/isrisinprogress.c
diff --git a/spec/build/testsuites/validation/libvalidation.yml 
b/spec/build/testsuites/validation/libvalidation.yml
index f73b0f7..9b326b8 100644
--- a/spec/build/testsuites/validation/libvalidation.yml
+++ b/spec/build/testsuites/validation/libvalidation.yml
@@ -14,7 +14,6 @@ source:
 - testsuites/validation/tx-call-within-isr.c
 - testsuites/validation/tx-default-task-config.c
 - testsuites/validation/tx-interrupt.c
-- testsuites/validation/tx-io-relax.c
 - testsuites/validation/tx-memory-alloc.c
 - testsuites/validation/tx-preemption-intervention.c
 - testsuites/validation/tx-support.c
diff --git a/testsuites/validation/tx-io-relax.c 
b/testsuites/validation/tx-io-relax.c
deleted file mode 100644
index 30cc097..000
--- a/testsuites/validation/tx-io-relax.c
+++ /dev/null
@@ -1,67 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup RTEMSTestSuitesValidation
- *
- * @brief This source file contains the implementation of SetIORelaxHandler().
- */
-
-/*
- * Copyright (C) 2021 embedded brains GmbH & Co. KG
- *
- * 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.

Re: [PATCH v2 00/32] Integrate pre-qualified LEON3 BSP

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

Re: [PATCH rtems] Remove unused _IO_Relax

Re: [PATCH rtems-central] spec/wake-after: Update references to intervals

[PATCH rtems-central v2] spec/wake-after: Update references to intervals

Re: [PATCH rtems-central] spec/wake-after: Update references to intervals

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

[PATCH rtems-central] spec/wake-after: Update references to intervals

Re: [PATCH v2 00/32] Integrate pre-qualified LEON3 BSP

Re: [PATCH rtems] Remove unused _IO_Relax

Re: [PATCH rtems] Remove unused _IO_Relax

Re: [PATCH rtems] Remove unused _IO_Relax

Re: [PATCH rtems] Remove unused _IO_Relax

Re: [PATCH rtems] Remove unused _IO_Relax

[PATCH rtems] Remove unused _IO_Relax

15 matches

Site Navigation

Mail list logo

Footer information