Re: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

[Chris Johns]

On 15/6/21 3:44 pm, Sebastian Huber wrote:
> On 15/06/2021 06:03, Chris Johns wrote:
>> On 8/6/21 10:23 pm, Sebastian Huber wrote:
>>> On 08/06/2021 14:08, Joel Sherrill wrote:
 Is the kernel rsb recipe fixed yet? That was a blocker.
>>> Is this really a blocker? Can't this be done on demand when someone wants to
>>> update them?
>> This depends on our shared view of supporting an eco-system.
>>
>> Support was added before we moved the build system to waf to build the 
>> kernel as
>> part of a vertical software stack and this I consider important.
> 
> I didn't say the contrary. What I don't agree with is the work package 
> ordering
> and dependency chain. The time I wasted on keeping the build system zombie 
> more
> or less alive I could have spent on updating the RSB.

No doubt. I am responding to your comment that this task can get done on demand.
How does the ecosystem view of this fit into your "demand" driven view?

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

Re: [PATCH] c-user: Use a common phrase for pointer parameters

[Sebastian Huber]

On 14/06/2021 16:54, Gedare Bloom wrote:

ok.


Thanks, for having a look at it.

--
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: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

[Sebastian Huber]

On 15/06/2021 06:03, Chris Johns wrote:

On 8/6/21 10:23 pm, Sebastian Huber wrote:

On 08/06/2021 14:08, Joel Sherrill wrote:

Is the kernel rsb recipe fixed yet? That was a blocker.

Is this really a blocker? Can't this be done on demand when someone wants to
update them?

This depends on our shared view of supporting an eco-system.

Support was added before we moved the build system to waf to build the kernel as
part of a vertical software stack and this I consider important.


I didn't say the contrary. What I don't agree with is the work package 
ordering and dependency chain. The time I wasted on keeping the build 
system zombie more or less alive I could have spent on updating the RSB.


--
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: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

[Chris Johns]

On 8/6/21 10:23 pm, Sebastian Huber wrote:
> On 08/06/2021 14:08, Joel Sherrill wrote:
>> Is the kernel rsb recipe fixed yet? That was a blocker.
> 
> Is this really a blocker? Can't this be done on demand when someone wants to
> update them?

This depends on our shared view of supporting an eco-system.

Support was added before we moved the build system to waf to build the kernel as
part of a vertical software stack and this I consider important.

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

Re: Running SPARC/LEON3 in TSIM-LEON3 simulator

[j...@gaisler.se]

Try the perf command. It will give you the load and performance per core. Sis 
is fairly accurate for basic benchmarking ...-- Ursprungligt 
meddelande--Från: Đức AnhDatum: mån 14 juni 2021 10:54Till: Jiri 
Gaisler;Kopia: rtems-de...@rtems.org;Ämne:Re: Running SPARC/LEON3 in TSIM-LEON3 
simulatorHi Jiri,Thanks for the suggestion. It works. However, it looks like it 
just simulates the instruction. I am looking for a cycle-accurate simulator and 
can provide the performance information on each core. Do you know any?Best,Duc 
AnhOn Fri, 11 Jun 2021 at 22:10, Jiri Gaisler  wrote:
  

  
  


On 6/11/21 12:37 PM, Đức Anh wrote:


  
  Hi Sebastian,


Thank you. I didn't notice that.


I recompile with SMP enabled, and the application doesn't
  run successfully in the TSIM-LEON3 simulator. Below is the
  error message:


Initializing
  and
 starting from 0x4000
   
    CPU 0 in error mode (tt=0x80, trap instruction)
    (In trap table for tt=0x02, illegal instruction)
        70150  4020  91d02000   ta        0                
         start + 0x20


The thing is, the same code will work if I compile with SMP
  disabled. When the SMP is enabled, the simulator will crash
  like above, even with the simple hello world application.


Have anyone here run into a similar issue? Or do you know
  any other leon3 (or sparc) simulator that I can try?
  



You can try with sis:
sparc-rtem6-sis -leon3 -m 4 hello.exe
Should work without problems. For SMP, you need the '-m 4' switch
  to enable 4 cores ...
Jiri.




  


Best regards,
Duc Anh
  
  
  
On Wed, 9 Jun 2021 at 18:46,
  Sebastian Huber
 
  wrote:

On
  09/06/2021 18:39, Đức Anh wrote:
  > - Is there a way to enable SMP for SPARC/LEON3 in RTEMS
  6?
  
  Just set "RTEMS_SMP = True" in your config.ini:
  
  
https://docs.rtems.org/branches/master/user/bld/index.html#migration-from-autoconf-automake
  
  -- 
  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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1] GcovData: Convert to c++ and fix formatting

[Ryan Long]

Converted printf statements to c++'s method of printing, adjusted to use
c++ file handling, changed char arrays to strings, fixed inconsistent
formatting.
---
 tester/covoar/GcovData.cc | 388 +---
 tester/covoar/GcovData.h  |  32 +--
 tester/covoar/GcovFunctionData.cc | 457 --
 tester/covoar/GcovFunctionData.h  |  76 ---
 4 files changed, 509 insertions(+), 444 deletions(-)

diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc
index e8b8573..7847ce6 100644
--- a/tester/covoar/GcovData.cc
+++ b/tester/covoar/GcovData.cc
@@ -1,5 +1,4 @@
 /*
- *  TODO: use strings instead of cstrings for reliability and saving memory
  *  TODO: use global buffers
  *
  */
@@ -34,71 +33,73 @@ namespace Gcov {
   {
   }
 
-  bool GcovData::readGcnoFile( const char* const  fileName )
+  bool GcovData::readGcnoFile( const std::string& fileName )
   {
-intstatus;
-FILE*  gcovFile;
-char*  tempString;
-char*  tempString2;
-char*  tempString3;
-
-if ( strlen(fileName) >= FILE_NAME_LENGTH ){
-  fprintf(
-stderr,
-"ERROR: File name is too long to be correctly stored: %u\n",
-(unsigned int) strlen(fileName)
-  );
+int status;
+std::ifstream   gcovFile;
+std::string tempString;
+std::string tempString2;
+std::string tempString3;
+size_t  index;
+
+if ( fileName.length() >= FILE_NAME_LENGTH ) {
+  std::cerr << "ERROR: File name is too long to be correctly stored: "
+<< fileName.length() << std::endl;
   return false;
 }
-strcpy( gcnoFileName, fileName );
-strcpy( gcdaFileName, fileName );
-strcpy( textFileName, fileName );
-strcpy( cFileName, fileName );
-tempString = strstr( gcdaFileName,".gcno" );
-tempString2 = strstr( textFileName,".gcno" );
-tempString3 = strstr( cFileName,".gcno" );
-
-if ( (tempString == NULL) && (tempString2 == NULL) ){
-  fprintf(stderr, "ERROR: incorrect name of *.gcno file\n");
-}
-else
-{
-  strcpy( tempString, ".gcda"); // construct gcda file name
-  strcpy( tempString2, ".txt"); // construct report file name
-  strcpy( tempString3, ".c");   // construct source file name
+
+gcnoFileName = fileName;
+gcdaFileName = fileName;
+textFileName = fileName;
+cFileName= fileName;
+tempString   = gcdaFileName;
+tempString2  = textFileName;
+tempString3  = cFileName;
+
+index = tempString.find( ".gcno" );
+if ( index == std::string::npos ) {
+  std::cerr << "ERROR: incorrect name of *.gcno file" << std::endl;
+  return false;
+} else {
+  // construct gcda file name
+  tempString = tempString.replace( index, strlen( ".gcno" ), ".gcda" );
+
+  // construct report file name
+  tempString2 = tempString2.replace( index, strlen( ".gcno" ), ".txt" );
+
+  // construct source file name
+  tempString3 = tempString3.replace( index, strlen( ".gcno" ), ".c" );
 }
 
 // Debug message
-// fprintf( stderr, "Readning file: %s\n",  gcnoFileName);
+// std::cerr << "Reading file: " << gcnoFileName << std::endl;
 
 // Open the notes file.
-gcovFile = fopen( gcnoFileName, "r" );
+gcovFile.open( gcnoFileName );
 if ( !gcovFile ) {
-  fprintf( stderr, "Unable to open %s\n", gcnoFileName );
+  std::cerr << "Unable to open " << gcnoFileName << std::endl;
   return false;
 }
 
 // Read and validate the gcnoPreamble (magic, version, timestamp) from the 
file
-status = readFilePreamble( , gcovFile, GCNO_MAGIC );
-if ( status <= 0 ){
-  fprintf( stderr, "Unable to read %s\n", gcnoFileName );
-  fclose( gcovFile );
+status = readFilePreamble( , , GCNO_MAGIC );
+if ( status <= 0 ) {
+  std::cerr << "Unable to read " << gcnoFileName << std::endl;
   return false;
 }
 
 //Read all remaining frames from file
-while( readFrame(gcovFile) ){}
+while( readFrame(  ) ) {}
 
-fclose( gcovFile );
 return true;
   }
 
 
-  bool GcovData::writeGcdaFile ()
+  bool GcovData::writeGcdaFile()
   {
 gcov_preamble preamble;
 gcov_frame_header header;
-FILE* gcdaFile;
+std::ofstream gcdaFile;
 functions_iterator_t  currentFunction;
 arcs_iterator_t   currentArc;
 uint32_t  buffer;
@@ -109,32 +110,35 @@ namespace Gcov {
 uint64_t  llBuffer[4096];// TODO: Use common buffer
 gcov_statistics   objectStats;
 gcov_statistics   programStats;
-size_tstatus;
+size_tbytes_before;
+size_tbytes_after;
 
 // Debug message
-// fprintf( stderr, "Writing file: %s\n",  gcdaFileName);
+//std::cerr << "Writing file: " <<  gcdaFileName << 

Re: How to write a build script to the rsb

[Gedare Bloom]

Hi Ida,

On Fri, Jun 11, 2021 at 1:51 PM Ida Delphine  wrote:
>
> Hi everyone,
>
> So I'm working on automatic style checking for RTEMS score and some time ago 
> we agreed on using clang-format. Since I will be making some costum changes 
> to the source code of clang-format, I intend using the rsb to build it before 
> it can be used to format files to match the RTEMS style.
>
> I'm not sure how to go about writing this script to build clang-format using 
> the rsb. Please I will love some guidance on how to go about it...

First thing is to be able to build the software by hand or shell
script, so that you have something that works to copy from.

Have you looked through
https://docs.rtems.org/branches/master/user/rsb/index.html for the
relevant advice?

> ___
> 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] c-user: Use a common phrase for pointer parameters

[Gedare Bloom]

ok.

On Mon, Jun 14, 2021 at 1:20 AM Sebastian Huber
 wrote:
>
> Mention the type of the pointer in the parameter description.  Use the
> more general term "object" instead of "variable".
>
> Update #3993.
> ---
>  c-user/barrier/directives.rst | 15 +++
>  c-user/clock/directives.rst   | 44 +++-
>  c-user/dual-ported-memory/directives.rst  | 20 -
>  c-user/interrupt/directives.rst   |  7 ++--
>  c-user/io/directives.rst  |  6 +--
>  c-user/message/directives.rst | 28 ++---
>  c-user/object-services/directives.rst | 11 ++---
>  c-user/partition/directives.rst   | 12 +++---
>  c-user/rate-monotonic/directives.rst  | 20 -
>  c-user/region/directives.rst  | 32 +++
>  c-user/scheduling-concepts/directives.rst | 41 +--
>  c-user/semaphore/directives.rst   | 14 +++
>  c-user/task/directives.rst| 50 +++
>  c-user/timer/directives.rst   | 14 +++
>  c-user/user-extensions/directives.rst |  8 ++--
>  15 files changed, 163 insertions(+), 159 deletions(-)
>
> diff --git a/c-user/barrier/directives.rst b/c-user/barrier/directives.rst
> index ec40844..59abc51 100644
> --- a/c-user/barrier/directives.rst
> +++ b/c-user/barrier/directives.rst
> @@ -67,9 +67,9 @@ Creates a barrier.
>  barrier.
>
>  ``id``
> -This parameter is the pointer to an object identifier variable.  When the
> +This parameter is the pointer to an :c:type:`rtems_id` object.  When the
>  directive call is successful, the identifier of the created barrier will 
> be
> -stored in this variable.
> +stored in this object.
>
>  .. rubric:: DESCRIPTION:
>
> @@ -175,9 +175,9 @@ Identifies a barrier by the object name.
>  This parameter is the object name to look up.
>
>  ``id``
> -This parameter is the pointer to an object identifier variable.  When the
> +This parameter is the pointer to an :c:type:`rtems_id` object.  When the
>  directive call is successful, the object identifier of an object with the
> -specified name will be stored in this variable.
> +specified name will be stored in this object.
>
>  .. rubric:: DESCRIPTION:
>
> @@ -380,9 +380,10 @@ Releases the barrier.
>  This parameter is the barrier identifier.
>
>  ``released``
> -This parameter is the pointer to an integer variable.  When the directive
> -call is successful, the number of released tasks will be stored in this
> -variable.
> +This parameter is the pointer to an `uint32_t
> +`_ object.  When the
> +directive call is successful, the number of released tasks will be stored
> +in this object.
>
>  .. rubric:: DESCRIPTION:
>
> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
> index 4ed1c58..e0f858a 100644
> --- a/c-user/clock/directives.rst
> +++ b/c-user/clock/directives.rst
> @@ -126,10 +126,10 @@ Gets the time of day associated with the current 
> :term:`CLOCK_REALTIME`.
>  .. rubric:: PARAMETERS:
>
>  ``time_of_day``
> -This parameter is the pointer to a RTEMS time of day variable.  When the
> -directive call is successful, the time of day associated with the
> +This parameter is the pointer to an :c:type:`rtems_time_of_day` object.
> +When the directive call is successful, the time of day associated with 
> the
>  :term:`CLOCK_REALTIME` at some point during the directive call will be
> -stored in this variable.
> +stored in this object.
>
>  .. rubric:: RETURN VALUES:
>
> @@ -179,10 +179,12 @@ current :term:`CLOCK_REALTIME`.
>  .. rubric:: PARAMETERS:
>
>  ``time_of_day``
> -This parameter is the pointer to a timeval structure variable.  When the
> -directive call is successful, the seconds and microseconds elapsed since
> -the :term:`Unix epoch` and the :term:`CLOCK_REALTIME` at some point 
> during
> -the directive call will be stored in this variable.
> +This parameter is the pointer to a `struct timeval
> +
> `_
> +object.  When the directive call is successful, the seconds and
> +microseconds elapsed since the :term:`Unix epoch` and the
> +:term:`CLOCK_REALTIME` at some point during the directive call will be
> +stored in this object.
>
>  .. rubric:: RETURN VALUES:
>
> @@ -234,10 +236,10 @@ Gets the seconds elapsed since the :term:`RTEMS epoch` 
> and the current
>  .. rubric:: PARAMETERS:
>
>  ``seconds_since_rtems_epoch``
> -This parameter is the pointer to an interval variable.  When the 
> directive
> -call is successful, the seconds elapsed since the :term:`RTEMS epoch` and
> -the :term:`CLOCK_REALTIME` at some point during the directive call will 
> be
> -stored in this variable.
> +This parameter is the pointer to an 

Re: Running SPARC/LEON3 in TSIM-LEON3 simulator

[Đức Anh]

Hi Jiri,

Thanks for the suggestion. It works. However, it looks like it just
simulates the instruction. I am looking for a cycle-accurate simulator and
can provide the performance information on each core. Do you know any?

Best,
Duc Anh

On Fri, 11 Jun 2021 at 22:10, Jiri Gaisler  wrote:

>
> On 6/11/21 12:37 PM, Đức Anh wrote:
>
> Hi Sebastian,
>
> Thank you. I didn't notice that.
>
> I recompile with SMP enabled, and the application doesn't run successfully
> in the TSIM-LEON3 simulator. Below is the error message:
>
> Initializing and starting from 0x4000
>>
>>   CPU 0 in error mode (tt=0x80, trap instruction)
>>   (In trap table for tt=0x02, illegal instruction)
>>   70150  4020  91d02000   ta0
>>  start + 0x20
>
>
> The thing is, the same code will work if I compile with SMP disabled. When
> the SMP is enabled, the simulator will crash like above, even with the
> simple hello world application.
>
> Have anyone here run into a similar issue? Or do you know any other leon3
> (or sparc) simulator that I can try?
>
>
> You can try with sis:
>
> sparc-rtem6-sis -leon3 -m 4 hello.exe
>
> Should work without problems. For SMP, you need the '-m 4' switch to
> enable 4 cores ...
>
> Jiri.
>
>
>
> Best regards,
> Duc Anh
>
> On Wed, 9 Jun 2021 at 18:46, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 09/06/2021 18:39, Đức Anh wrote:
>> > - Is there a way to enable SMP for SPARC/LEON3 in RTEMS 6?
>>
>> Just set "RTEMS_SMP = True" in your config.ini:
>>
>>
>> https://docs.rtems.org/branches/master/user/bld/index.html#migration-from-autoconf-automake
>>
>> --
>> 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 listdevel@rtems.orghttp://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 1/1] user/bsps/arm/raspberrypi: Changed the link to the Raspberry Pi Firmware to point to Firmware Version 1.20200601

[Gedare Bloom]

On Mon, Jun 14, 2021 at 3:02 AM pranav  wrote:
>
> Updated the link to the Raspberry Pi Firmware in RTEMS 5 docs, since the BSP 
> works with an older version of the firmware currently.
> ---
>  user/bsps/arm/raspberrypi.rst | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
> index c26f4b5..84e45b9 100644
> --- a/user/bsps/arm/raspberrypi.rst
> +++ b/user/bsps/arm/raspberrypi.rst
> @@ -19,9 +19,10 @@ The bootloader looks for a kernel image, by default the 
> kernel images must
>  have a name of the form ``kernel*.img`` but this can be changed by adding
>  `kernel=` to ``config.txt``.
>
> -You must provide the required files for the GPU to proceed. These files
> -can be downloaded from
> -`the Raspberry Pi Firmware Repository 
> `_.
> +You must provide the required files for the GPU to proceed. The BSP
> +currently boots with an older version of the official Raspberry Pi Firmware.

Can you please expand on this sentence to explain why / that newer
versions don't work?

> +These files can be downloaded from
> +`the Raspberry Pi Firmware Repository 
> `_.
>  You can remove the ``kernel*.img`` files if you want too, but don't touch
>  the other files.
>
> --
> 2.27.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

Re: Error in building The RTEMS 5 Docs

[Gedare Bloom]

On Sun, Jun 13, 2021 at 12:05 PM Christian Mauderer  wrote:
>
> Hello Pranav,
>
> On 13/06/2021 20:00, Pranav Dangi wrote:
> > Building the RTEMS 5 docs using the waf build system fails and throws up
> > an error in sphinx:
> >
> > err:
> > Extension error:
> > You must configure the bibtex_bibfiles setting.
> >
>
> thanks for reporting. Like discussed in discord, a cherry-pick of the
> following two patches solves the problem:
>
> https://git.rtems.org/rtems-docs/commit/?id=4563bb6a8b5622b8502437929f
> https://git.rtems.org/rtems-docs/commit/?id=1568c2baa7d3ea0846b7d96952
>
> Especially Gedare and Chris (you wrote the commits): Do you think we
> should back port the two to the 5 branch? Or would that make more
> problems than it solves?
>

My concern would be backward compatibility to older hosts/versions.
I'd rather not touch a release for host-side updates that happened
after the release was cut, unless absolutely necessary and we can
isolate the versions affected.

> Best regards
>
> Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs 1/1] user/bsps/arm/raspberrypi: Changed the link to the Raspberry Pi Firmware to point to Firmware Version 1.20200601

[pranav]

Updated the link to the Raspberry Pi Firmware in RTEMS 5 docs, since the BSP 
works with an older version of the firmware currently.
---
 user/bsps/arm/raspberrypi.rst | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
index c26f4b5..84e45b9 100644
--- a/user/bsps/arm/raspberrypi.rst
+++ b/user/bsps/arm/raspberrypi.rst
@@ -19,9 +19,10 @@ The bootloader looks for a kernel image, by default the 
kernel images must
 have a name of the form ``kernel*.img`` but this can be changed by adding
 `kernel=` to ``config.txt``.
 
-You must provide the required files for the GPU to proceed. These files
-can be downloaded from
-`the Raspberry Pi Firmware Repository 
`_.
+You must provide the required files for the GPU to proceed. The BSP 
+currently boots with an older version of the official Raspberry Pi Firmware.
+These files can be downloaded from
+`the Raspberry Pi Firmware Repository 
`_.
 You can remove the ``kernel*.img`` files if you want too, but don't touch
 the other files.
 
-- 
2.27.0

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

[PATCH] c-user: Use a common phrase for pointer parameters

[Sebastian Huber]

Mention the type of the pointer in the parameter description.  Use the
more general term "object" instead of "variable".

Update #3993.
---
 c-user/barrier/directives.rst | 15 +++
 c-user/clock/directives.rst   | 44 +++-
 c-user/dual-ported-memory/directives.rst  | 20 -
 c-user/interrupt/directives.rst   |  7 ++--
 c-user/io/directives.rst  |  6 +--
 c-user/message/directives.rst | 28 ++---
 c-user/object-services/directives.rst | 11 ++---
 c-user/partition/directives.rst   | 12 +++---
 c-user/rate-monotonic/directives.rst  | 20 -
 c-user/region/directives.rst  | 32 +++
 c-user/scheduling-concepts/directives.rst | 41 +--
 c-user/semaphore/directives.rst   | 14 +++
 c-user/task/directives.rst| 50 +++
 c-user/timer/directives.rst   | 14 +++
 c-user/user-extensions/directives.rst |  8 ++--
 15 files changed, 163 insertions(+), 159 deletions(-)

diff --git a/c-user/barrier/directives.rst b/c-user/barrier/directives.rst
index ec40844..59abc51 100644
--- a/c-user/barrier/directives.rst
+++ b/c-user/barrier/directives.rst
@@ -67,9 +67,9 @@ Creates a barrier.
 barrier.
 
 ``id``
-This parameter is the pointer to an object identifier variable.  When the
+This parameter is the pointer to an :c:type:`rtems_id` object.  When the
 directive call is successful, the identifier of the created barrier will be
-stored in this variable.
+stored in this object.
 
 .. rubric:: DESCRIPTION:
 
@@ -175,9 +175,9 @@ Identifies a barrier by the object name.
 This parameter is the object name to look up.
 
 ``id``
-This parameter is the pointer to an object identifier variable.  When the
+This parameter is the pointer to an :c:type:`rtems_id` object.  When the
 directive call is successful, the object identifier of an object with the
-specified name will be stored in this variable.
+specified name will be stored in this object.
 
 .. rubric:: DESCRIPTION:
 
@@ -380,9 +380,10 @@ Releases the barrier.
 This parameter is the barrier identifier.
 
 ``released``
-This parameter is the pointer to an integer variable.  When the directive
-call is successful, the number of released tasks will be stored in this
-variable.
+This parameter is the pointer to an `uint32_t
+`_ object.  When the
+directive call is successful, the number of released tasks will be stored
+in this object.
 
 .. rubric:: DESCRIPTION:
 
diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
index 4ed1c58..e0f858a 100644
--- a/c-user/clock/directives.rst
+++ b/c-user/clock/directives.rst
@@ -126,10 +126,10 @@ Gets the time of day associated with the current 
:term:`CLOCK_REALTIME`.
 .. rubric:: PARAMETERS:
 
 ``time_of_day``
-This parameter is the pointer to a RTEMS time of day variable.  When the
-directive call is successful, the time of day associated with the
+This parameter is the pointer to an :c:type:`rtems_time_of_day` object.
+When the directive call is successful, the time of day associated with the
 :term:`CLOCK_REALTIME` at some point during the directive call will be
-stored in this variable.
+stored in this object.
 
 .. rubric:: RETURN VALUES:
 
@@ -179,10 +179,12 @@ current :term:`CLOCK_REALTIME`.
 .. rubric:: PARAMETERS:
 
 ``time_of_day``
-This parameter is the pointer to a timeval structure variable.  When the
-directive call is successful, the seconds and microseconds elapsed since
-the :term:`Unix epoch` and the :term:`CLOCK_REALTIME` at some point during
-the directive call will be stored in this variable.
+This parameter is the pointer to a `struct timeval
+
`_
+object.  When the directive call is successful, the seconds and
+microseconds elapsed since the :term:`Unix epoch` and the
+:term:`CLOCK_REALTIME` at some point during the directive call will be
+stored in this object.
 
 .. rubric:: RETURN VALUES:
 
@@ -234,10 +236,10 @@ Gets the seconds elapsed since the :term:`RTEMS epoch` 
and the current
 .. rubric:: PARAMETERS:
 
 ``seconds_since_rtems_epoch``
-This parameter is the pointer to an interval variable.  When the directive
-call is successful, the seconds elapsed since the :term:`RTEMS epoch` and
-the :term:`CLOCK_REALTIME` at some point during the directive call will be
-stored in this variable.
+This parameter is the pointer to an :c:type:`rtems_interval` object.  When
+the directive call is successful, the seconds elapsed since the
+:term:`RTEMS epoch` and the :term:`CLOCK_REALTIME` at some point during the
+directive call will be stored in this object.
 
 .. rubric:: RETURN VALUES:
 
@@ -370,11