[PATCH v2] c-user: Generate Object Services documentation

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---

The generated documentation is available here:

https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf

v2:

Remove leading '_' from parameter names.

 c-user/object-services/directives.rst   | 978 ++--
 c-user/object-services/introduction.rst |  93 ++-
 2 files changed, 643 insertions(+), 428 deletions(-)

diff --git a/c-user/object-services/directives.rst 
b/c-user/object-services/directives.rst
index 87f0f5a..ce7a894 100644
--- a/c-user/object-services/directives.rst
+++ b/c-user/object-services/directives.rst
@@ -1,643 +1,805 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+.. Copyright (C) 1988, 2009 On-Line Applications Research Corporation (OAR)
+
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://docs.rtems.org/branches/master/user/support/bugs.html
+..
+.. For information on updating and regenerating please refer to:
+..
+.. https://docs.rtems.org/branches/master/eng/req/howto.html
+
+.. _ObjectServicesDirectives:
 
 Directives
 ==
 
+This section details the directives of the Object Services. A subsection is
+dedicated to each of this manager's directives and lists the calling sequence,
+parameters, description, return values, and notes of the directive.
+
+.. Generated from spec:/rtems/object/if/build-id
+
 .. raw:: latex
 
-   \clearpage
+\clearpage
+
+.. index:: rtems_build_id()
+
+.. _InterfaceRtemsBuildId:
+
+rtems_build_id()
+
+
+Builds the object identifier from the API, class, MPCI node, and index
+components.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+#define rtems_build_id( api, class, node, index )
 
-.. index:: build object name
-.. index:: rtems_build_name
+.. rubric:: PARAMETERS:
 
-.. _rtems_build_name:
+``api``
+This parameter is the API of the object identifier to build.
 
-BUILD_NAME - Build object name from characters
---
+``class``
+This parameter is the class of the object identifier to build.
 
-CALLING SEQUENCE:
-.. code-block:: c
+``node``
+This parameter is the MPCI node of the object identifier to build.
 
-rtems_name rtems_build_name(
-uint8_t c1,
-uint8_t c2,
-uint8_t c3,
-uint8_t c4
-);
+``index``
+This parameter is the index of the object identifier to build.
 
-DIRECTIVE STATUS CODES:
-Returns a name constructed from the four characters.
+.. rubric:: RETURN VALUES:
 
-DESCRIPTION:
-This service takes the four characters provided as arguments and constructs
-a thirty-two bit object name with ``c1`` in the most significant byte and
-``c4`` in the least significant byte.
+Returns the object identifier built from the API, class, MPCI node, and index
+components.
 
-NOTES:
-This directive is strictly local and does not impact task scheduling.
+.. rubric:: NOTES:
+
+This directive is strictly local and does not impact task scheduling.
+
+.. Generated from spec:/rtems/object/if/build-name
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
-.. index:: get name from id
-.. index:: obtain name from id
-.. index:: rtems_object_get_classic_name
+.. index:: rtems_build_name()
 
-.. _rtems_object_get_classic_name:
+.. _InterfaceRtemsBuildName:
 
-OBJECT_GET_CLASSIC_NAME - Lookup name from id
--
+rtems_build_name()
+--
 
-CALLING SEQUENCE:
-.. code-block:: c
+Builds the object name composed of the four characters.
 
-rtems_status_code rtems_object_get_classic_name(
-rtems_id  id,
-rtems_name   *name
-);
+.. rubric:: CALLING SEQUENCE:
 
-DIRECTIVE STATUS CODES:
-.. list-table::
- :class: rtems-table
+.. code-block:: c
 
- * - ``RTEMS_SUCCESSFUL``
-   - name looked up successfully
- * - ``RTEMS_INVALID_ADDRESS``
-   - invalid name pointer
- * - ``RTEMS_INVALID_ID``
-   - invalid object id
+#define rtems_build_name( c1, c2, c3, c4 )
 
-DESCRIPTION:
-This service looks up the name for the object ``id`` specified and, if
-found, places the result in ``*name``.
+.. rubric:: PARAMETERS:
 
-NOTES:
-This directive is strictly local and does not impact task scheduling.
+``c1``
+This parameter is the first character of the name.
 
-.. raw:: latex
+``c2``
+This parameter is the second character o

[PATCH] rtems: Generate

[Sebastian Huber]

Change license to BSD-2-Clause according to file histories and
documentation re-licensing agreement.

Update #3899.
Update #3993.
---
 cpukit/include/rtems/rtems/timer.h | 705 -
 1 file changed, 494 insertions(+), 211 deletions(-)

diff --git a/cpukit/include/rtems/rtems/timer.h 
b/cpukit/include/rtems/rtems/timer.h
index 244d5603ba..3d454e39ec 100644
--- a/cpukit/include/rtems/rtems/timer.h
+++ b/cpukit/include/rtems/rtems/timer.h
@@ -1,289 +1,493 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
- * @ingroup ClassicTimer
+ * @ingroup RTEMSImplClassicTimer
  *
- * @brief Classic Timer Manager API
+ * @brief This header file provides the Timer Manager API.
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+ *
+ * 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.
  */
 
 /*
- * COPYRIGHT (c) 1989-2011.
- * On-Line Applications Research Corporation (OAR).
+ * This file is part of the RTEMS quality process and was automatically
+ * generated.  If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://docs.rtems.org/branches/master/user/support/bugs.html
  *
- * Copyright (c) 2009, 2016 embedded brains GmbH.
+ * For information on updating and regenerating please refer to:
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
  */
 
+/* Generated from spec:/rtems/timer/if/header */
+
 #ifndef _RTEMS_RTEMS_TIMER_H
 #define _RTEMS_RTEMS_TIMER_H
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/timer/if/group */
+
 /**
- *  @defgroup ClassicTimer Timers
+ * @defgroup RTEMSAPIClassicTimer Timer Manager
  *
- *  @ingroup RTEMSAPIClassic
+ * @ingroup RTEMSAPIClassic
  *
- *  This encapsulates functionality related to the Classic API Timer
- *  Manager.  This manager provides functionality which allows the
- *  application to schedule the execution of methods at a specified
- *  time in the future.  These methods may be scheduled based upon
- *  interval or wall time and may be executed in either the clock tick
- *  ISR or in a special dedicated timer server task.
+ * @brief The Timer Manager provides support for timer facilities.
  */
-/**@{*/
 
-#define TIMER_CLASS_BIT_TIME_OF_DAY 0x1
+/* Generated from spec:/rtems/timer/if/class-bit-not-dormant */
+
+/**
+ * @ingroup RTEMSAPIClassicTimer
+ *
+ * @brief This timer class bit indicates that the timer is not dormant.
+ */
+#define TIMER_CLASS_BIT_NOT_DORMANT 0x4
+
+/* Generated from spec:/rtems/timer/if/class-bit-on-task */
 
+/**
+ * @ingroup RTEMSAPIClassicTimer
+ *
+ * @brief This timer class bit indicates that the timer routine executes in a
+ *   task context.
+ */
 #define TIMER_CLASS_BIT_ON_TASK 0x2
 
-#define TIMER_CLASS_BIT_NOT_DORMANT 0x4
+/* Generated from spec:/rtems/timer/if/class-bit-time-of-day */
+
+/**
+ * @ingroup RTEMSAPIClassicTimer
+ *
+ * @brief This timer class bit indicates that the timer uses a time of day.
+ */
+#define TIMER_CLASS_BIT_TIME_OF_DAY 0x1
+
+/* Generated from spec:/rtems/timer/if/classes */
 
 /**
- *  The following enumerated type details the classes to which a timer
- *  may belong.
+ * @ingroup RTEMSAPIClassicTimer
+ *
+ * @brief The timer class indicates how the timer was most recently fired.
  */
 typedef enum {
   /**
-   * This value indicates the timer is c

[PATCH] c-user: Generate Timer Manager documentation

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---

The generated documentation is available here:

https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf

 c-user/timer/directives.rst   | 992 +-
 c-user/timer/introduction.rst |  57 +-
 2 files changed, 674 insertions(+), 375 deletions(-)

diff --git a/c-user/timer/directives.rst b/c-user/timer/directives.rst
index d9b9877..d65f263 100644
--- a/c-user/timer/directives.rst
+++ b/c-user/timer/directives.rst
@@ -1,463 +1,729 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://docs.rtems.org/branches/master/user/support/bugs.html
+..
+.. For information on updating and regenerating please refer to:
+..
+.. https://docs.rtems.org/branches/master/eng/req/howto.html
+
+.. _TimerManagerDirectives:
+
 Directives
 ==
 
-This section details the timer manager's directives.  A subsection is dedicated
-to each of this manager's directives and describes the calling sequence,
-related constants, usage, and status codes.
+This section details the directives of the Timer Manager. A subsection is
+dedicated to each of this manager's directives and lists the calling sequence,
+parameters, description, return values, and notes of the directive.
+
+.. Generated from spec:/rtems/timer/if/create
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
+
+.. index:: rtems_timer_create()
 .. index:: create a timer
-.. index:: rtems_timer_create
 
-.. _rtems_timer_create:
+.. _InterfaceRtemsTimerCreate:
 
-TIMER_CREATE - Create a timer
--
+rtems_timer_create()
+
+
+Creates a timer.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+rtems_status_code rtems_timer_create( rtems_name name, rtems_id *id );
+
+.. rubric:: PARAMETERS:
+
+``name``
+This parameter is the name of the timer.
+
+``id``
+This parameter is the pointer to an object identifier variable.  The
+identifier of the created timer object will be stored in this variable, in
+case of a successful operation.
+
+.. rubric:: DESCRIPTION:
 
-CALLING SEQUENCE:
-.. code-block:: c
-
-rtems_status_code rtems_timer_create(
-rtems_name  name,
-rtems_id   *id
-);
-
-DIRECTIVE STATUS CODES:
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_SUCCESSFUL``
-   - timer created successfully
- * - ``RTEMS_INVALID_ADDRESS``
-   - ``id`` is NULL
- * - ``RTEMS_INVALID_NAME``
-   - invalid timer name
- * - ``RTEMS_TOO_MANY``
-   - too many timers created
-
-DESCRIPTION:
-This directive creates a timer.  The assigned timer id is returned in id.
-This id is used to access the timer with other timer manager directives.
-For control and maintenance of the timer, RTEMS allocates a TMCB from the
-local TMCB free pool and initializes it.
-
-NOTES:
-This directive will obtain the allocator mutex and may cause the calling
-task to be preempted.
-
-In SMP configurations, the processor of the currently executing thread
-determines the processor used for the created timer.  During the life-time
-of the timer this processor is used to manage the timer internally.
+This directive creates a timer.  The assigned object identifier is returned in
+``id``.  This identifier is used to access the timer with other timer related
+directives.
+
+.. rubric:: RETURN VALUES:
+
+:c:macro:`RTEMS_SUCCESSFUL`
+The requested operation was successful.
+
+:c:macro:`RTEMS_INVALID_NAME`
+The timer name was invalid.
+
+:c:macro:`RTEMS_INVALID_ADDRESS`
+The ``id`` parameter was `NULL
+`_.
+
+:c:macro:`RTEMS_TOO_MANY`
+There was no inactive object available to create a new timer.  The number
+of timers available to the application is configured through the
+:ref:`CONFIGURE_MAXIMUM_TIMERS` configuration option.
+
+.. rubric:: NOTES:
+
+This directive may cause the calling task to be preempted due to an obtain and
+release of the object allocator mutex.
+
+For control and maintenance of the timer, RTEMS allocates a :term:`TMCB` from
+the local TMCB free pool and initializes it.
+
+In SMP configurations, the processor of the currently executing thread
+determines the processor used for the created timer.  During the life-time of
+the timer this processor is used to m

Re: [PATCH v1 1/3] bsps: Move zynq-uart to bsps/shared

[Sebastian Huber]

On 01/12/2020 21:57, Kinsey Moore wrote:


This moves the zynq-uart driver from bsps/arm/shared to bsps/shared to
accomodate use by AArch64 BSPs.

Ok.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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 v1 2/3] bsps: Move ARM GICv2 driver to bsps/shared

[Sebastian Huber]

On 01/12/2020 21:57, Kinsey Moore wrote:


This moves the ARM GICv2 driver to bsps/shared to be usable by AArch64
code.

Ok.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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 v1 3/3] Add AArch64 ZynpMP BSP

[Sebastian Huber]

On 01/12/2020 21:57, Kinsey Moore wrote:


This adds a BSP family that runs on the Xilinx Ultrascale+ MPSOC
(ZynqMP) family of chips. It is configured to be usable on the Qemu
ZCU102 machine definition and should be almost trivially portable to
ZynqMP development boards and custom hardware. It is also configured to
be usable with libbsd.

The BSP looks good. I have just some minor things.

---
  bsps/aarch64/xilinx-zynqmp/console/console.c  | 134 ++
  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  81 +++
  bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h  |  72 ++
  bsps/aarch64/xilinx-zynqmp/include/tm27.h |  46 ++
  bsps/aarch64/xilinx-zynqmp/start/bspstart.c   |  49 +++
  .../xilinx-zynqmp/start/bspstarthooks.c   |  50 +++
  spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml |  22 +++
  .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|  21 +++
  .../aarch64/xilinx-zynqmp/bspqemulp64.yml |  21 +++
  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |  44 ++
  .../aarch64/xilinx-zynqmp/linkcmds_ilp32.yml  |  72 ++
  .../aarch64/xilinx-zynqmp/linkcmds_lp64.yml   |  71 ++
  spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |  37 +
  .../bsps/aarch64/xilinx-zynqmp/optclkuart.yml |  20 +++
  .../aarch64/xilinx-zynqmp/optconminor.yml |  15 ++
  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  18 +++
  .../aarch64/xilinx-zynqmp/optnocachelen.yml   |  18 +++
  .../bsps/aarch64/xilinx-zynqmp/optramlen.yml  |  18 +++
  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  18 +++
  .../bsps/aarch64/xilinx-zynqmp/tstqemu.yml|  56 
  20 files changed, 883 insertions(+)
  create mode 100644 bsps/aarch64/xilinx-zynqmp/console/console.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/include/bsp.h
  create mode 100644 bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
  create mode 100644 bsps/aarch64/xilinx-zynqmp/include/tm27.h
  create mode 100644 bsps/aarch64/xilinx-zynqmp/start/bspstart.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/start/bspstarthooks.c
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_ilp32.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_lp64.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optclkuart.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optconminor.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optnocachelen.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optramlen.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
new file mode 100644
index 00..7bd85626d9
--- /dev/null
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsAArch64XilinxZynqMP
+ *
+ * @brief Console Configuration
+ */


The Doxygen recommendation for brief descriptions for @file and 
@defgroup changed recently:


https://docs.rtems.org/branches/master/eng/coding-doxygen.html#files


[...]
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_ilp32.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_ilp32.yml
new file mode 100644
index 00..88ed23f1c8
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_ilp32.yml
@@ -0,0 +1,72 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: config-file
+content: |
+  /*
+   * SPDX-License-Identifier: BSD-2-Clause
+   *
Please put the SPDX-License-Identifier separately in the first line of 
the file (and the others).

+   * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+   * Written by Kinsey Moore 
[...]
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optconminor.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/optconminor.yml
new file mode 100644
index 00..55074c6dac
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optconminor.yml
@@ -0,0 +1,15 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- define-condition: null
+build-type: option
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+default: true
+default-by-variant: []
+description: |
+  minor number of console device
+enabled-by: true
+links: []
+name: BSP_CONSOLE_MINOR
+type: build


This option is already used in two other BSPs:

spec/build/bsps/arm/xilinx-zynqmp/op

Re: GMP is now a required dependency for building GDB

[Sebastian Huber]

Hello Chris,

On 19/11/2020 09:52, Sebastian Huber wrote:

On 19/11/2020 09:33, Sebastian Huber wrote:


On 17/11/2020 14:49, Joel Sherrill wrote:



    The GMP library is not available by default on FreeBSD systems.
    For GCC
    we include a fixed version and build it together with GCC. What
    should
    be do for GDB?


I would lean to including the same version in GDB that we do in GCC.

Is this like gcc in that if they find it in the source tree, they 
will use it?



Ok, I will try this approach.

This didn't work. I guess we need to to something similar to libexpat.

what would be your approach to build the latest GDB on FreeBSD?

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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: BSP_CONSOLE_MINOR option for Zynq board with new build system

[Jan.Sommer]

Hi Sebastian,

I forgot to follow up with this until I ran into the same thing again. 
Your patch works and solves the problem.
Would you be so kind to push it to master?

Best regards,

Jan

> -Original Message-
> From: Sebastian Huber 
> Sent: Friday, September 25, 2020 4:14 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: BSP_CONSOLE_MINOR option for Zynq board with new build
> system
> 
> Hello Jan,
> 
> On 25/09/2020 15:36, jan.som...@dlr.de wrote:
> > Hello,
> >
> > I am currently making my first steps with the new build system and so far it
> is amazing.
> > Especially, the inheritance option is very handy for maintaining different
> configurations.
> > Therefore, a big thank you to Sebastian and everyone else involved.
> thanks for having a look at it.
> >
> > I ran into a smaller problem when compiling for a zynq-board.
> > I tried to override BSP_CONSOLE_MINOR=0, but it seems that the option is
> interpreted as a Boolean and then the define not set.
> > At least I run into:
> > ../../../bsps/arm/xilinx-zynq/start/bspreset.c: In function 'bsp_reset':
> > ../../../bsps/arm/xilinx-zynq/start/bspreset.c:37:49: error:
> 'BSP_CONSOLE_MINOR' undeclared (first use in this function)
> > 37 |
> zynq_uart_reset_tx_flush(&zynq_uart_instances[BSP_CONSOLE_MINOR]);
> 
> Yes, this could be a potential problem in several BSPs. I used a script to
> convert the BSP options, but to detect if it was an integer or boolean type
> was just an heuristic. In order to fix this, you first have to find the build
> specification item of the option:
> 
> spec/build/bsps/arm/xilinx-zynqmp/optconminor.yml:name:
> BSP_CONSOLE_MINOR
> spec/build/bsps/arm/xilinx-zynq/optconminor.yml:name:
> BSP_CONSOLE_MINOR
> 
> So, we have this option duplicated. This is an issue on its own. At some point
> in time we should unify the options across the BSPs.
> 
> Then open the file (spec/build/bsps/arm/xilinx-zynq/optconminor.yml):
> 
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-boolean: null
> - define-condition: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-
> brains.de)
> default: true
> default-by-variant: []
> description: |
>    minor number of console device
> enabled-by: true
> links: []
> name: BSP_CONSOLE_MINOR
> type: build
> 
> Under actions you see what is done with the value specified by the
> configuration file (or the default value). See also:
> 
> https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuild
> optionaction
> 
> This patch fixes probably the issue:
> 
> diff --git a/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> b/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> index 55074c6dac..486eb92d33 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> @@ -1,15 +1,16 @@
>   SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>   actions:
> -- get-boolean: null
> -- define-condition: null
> +- get-integer: null
> +- define: null
>   build-type: option
>   copyrights:
>   - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-
> brains.de)
> -default: true
> +default: 1
>   default-by-variant: []
>   description: |
>     minor number of console device
>   enabled-by: true
> +format: '{}'
>   links: []
>   name: BSP_CONSOLE_MINOR
>   type: build
> 
> The integer options need a "format" attribute.

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

[PATCH] updated python section

[Robin Mueller]

---
 user/hosts/windows.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/user/hosts/windows.rst b/user/hosts/windows.rst
index fac1366..ca8026d 100644
--- a/user/hosts/windows.rst
+++ b/user/hosts/windows.rst
@@ -126,6 +126,18 @@ Python2 package. The MSYS Python is version 3 and the RSB 
can support version 2
 and 3 of Python and it helps handle some of the long paths building GCC can
 generate.
 
+If the following error occurs during a build process
+
+.. code-block:: none
+
+  LookupError: unknown encoding: cp65001
+  
+it is recommended to run the following command:
+
+.. code-block:: none
+
+  export PYTHONIOENCODING=UTF-8
+
 .. _microsoft-windows-installation:
 
 MSYS2
-- 
2.29.2

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

[PATCH] doc improvements

[Robin Mueller]

---
 user/start/sources.rst | 9 +
 user/start/tools.rst   | 9 -
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/user/start/sources.rst b/user/start/sources.rst
index 8c40aa0..fddc439 100644
--- a/user/start/sources.rst
+++ b/user/start/sources.rst
@@ -86,12 +86,21 @@ You can clone the Git repository to get all versions of 
RTEMS including the
 development head.  Release branches in Git are kept stable however they may
 differ from a release's source archive.
 
+For this Quick Start guide, we will switch to the RTEMS 5 branches because the 
+master branch does not contain the version 5 `rtems-sparc` build set.
+If you wich to build with the master branch instead, it is recommended to
+replace the version number 5 with version 6 everywhere it is used in the Quick 
Start guide.
+
 .. code-block:: none
 
 mkdir -p $HOME/quick-start/src
 cd $HOME/quick-start/src
 git clone git://git.rtems.org/rtems-source-builder.git rsb
+git checkout origin/5
+git checkout -b 5
 git clone git://git.rtems.org/rtems.git
+git checkout origin/5
+git checkout -b 5
 
 The :file:`rsb` repository clone contains the :ref:`RTEMS Source Builder (RSB)
 `.  We clone it into :file:`rsb` to get shorter paths during the tool
diff --git a/user/start/tools.rst b/user/start/tools.rst
index baa2387..e0fe10d 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are tightly 
coupled.  For
 example, do not use a RTEMS version 5 tool suite with RTEMS version 4.11
 sources and vice versa.
 
-Build and install the tool suite:
+The available build sets can be displayed with:
+
+.. code-block:: none
+
+cd $HOME/quick-start/src/rsb/rtems
+../source-builder/sb-set-builder --list-bsets
+   
+Build and install the version 5 tool suite for the SPARC architecture:
 
 .. code-block:: none
 
-- 
2.29.2

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

Re: BSP_CONSOLE_MINOR option for Zynq board with new build system

[Sebastian Huber]

Hello Jan,

On 02/12/2020 11:19, jan.som...@dlr.de wrote:

I forgot to follow up with this until I ran into the same thing again.
Your patch works and solves the problem.
Would you be so kind to push it to master?


I think this should be fixed along with the new aarch64 BSP for Zynq:

https://lists.rtems.org/pipermail/devel/2020-December/063576.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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] doc improvements

[Robin Müller]

 [PATCH] doc improvements is related to ticket
https://devel.rtems.org/ticket/4187 which can then be closed

On Wed, 2 Dec 2020 at 13:46, Robin Mueller 
wrote:

> ---
>  user/start/sources.rst | 9 +
>  user/start/tools.rst   | 9 -
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/user/start/sources.rst b/user/start/sources.rst
> index 8c40aa0..fddc439 100644
> --- a/user/start/sources.rst
> +++ b/user/start/sources.rst
> @@ -86,12 +86,21 @@ You can clone the Git repository to get all versions
> of RTEMS including the
>  development head.  Release branches in Git are kept stable however they
> may
>  differ from a release's source archive.
>
> +For this Quick Start guide, we will switch to the RTEMS 5 branches
> because the
> +master branch does not contain the version 5 `rtems-sparc` build set.
> +If you wich to build with the master branch instead, it is recommended to
> +replace the version number 5 with version 6 everywhere it is used in the
> Quick Start guide.
> +
>  .. code-block:: none
>
>  mkdir -p $HOME/quick-start/src
>  cd $HOME/quick-start/src
>  git clone git://git.rtems.org/rtems-source-builder.git rsb
> +git checkout origin/5
> +git checkout -b 5
>  git clone git://git.rtems.org/rtems.git
> +git checkout origin/5
> +git checkout -b 5
>
>  The :file:`rsb` repository clone contains the :ref:`RTEMS Source Builder
> (RSB)
>  `.  We clone it into :file:`rsb` to get shorter paths during the tool
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index baa2387..e0fe10d 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
> tightly coupled.  For
>  example, do not use a RTEMS version 5 tool suite with RTEMS version 4.11
>  sources and vice versa.
>
> -Build and install the tool suite:
> +The available build sets can be displayed with:
> +
> +.. code-block:: none
> +
> +cd $HOME/quick-start/src/rsb/rtems
> +../source-builder/sb-set-builder --list-bsets
> +
> +Build and install the version 5 tool suite for the SPARC architecture:
>
>  .. code-block:: none
>
> --
> 2.29.2
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] doc improvements

[Sebastian Huber]

Hello Robin,

On 02/12/2020 13:46, Robin Mueller wrote:

---
  user/start/sources.rst | 9 +
  user/start/tools.rst   | 9 -
  2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/user/start/sources.rst b/user/start/sources.rst
index 8c40aa0..fddc439 100644
--- a/user/start/sources.rst
+++ b/user/start/sources.rst
@@ -86,12 +86,21 @@ You can clone the Git repository to get all versions of 
RTEMS including the
  development head.  Release branches in Git are kept stable however they may
  differ from a release's source archive.
  
+For this Quick Start guide, we will switch to the RTEMS 5 branches because the

+master branch does not contain the version 5 `rtems-sparc` build set.
+If you wich to build with the master branch instead, it is recommended to
+replace the version number 5 with version 6 everywhere it is used in the Quick 
Start guide.
the documentation for the master branch should not refer to the RTEMS 5 
release. So, the right fix is to replace '5' with '6' if needed.

+
  .. code-block:: none
  
  mkdir -p $HOME/quick-start/src

  cd $HOME/quick-start/src
  git clone git://git.rtems.org/rtems-source-builder.git rsb
+git checkout origin/5
+git checkout -b 5
  git clone git://git.rtems.org/rtems.git
+git checkout origin/5
+git checkout -b 5
  
  The :file:`rsb` repository clone contains the :ref:`RTEMS Source Builder (RSB)

  `.  We clone it into :file:`rsb` to get shorter paths during the tool
diff --git a/user/start/tools.rst b/user/start/tools.rst
index baa2387..e0fe10d 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are tightly 
coupled.  For
  example, do not use a RTEMS version 5 tool suite with RTEMS version 4.11
  sources and vice versa.
  
-Build and install the tool suite:

+The available build sets can be displayed with:
+
+.. code-block:: none
+
+cd $HOME/quick-start/src/rsb/rtems
+../source-builder/sb-set-builder --list-bsets
+   
+Build and install the version 5 tool suite for the SPARC architecture:
  
  .. code-block:: none

This part looks good to me.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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] doc improvements

[Robin Müller]

Actually, I just saw that when switching to the 5 branch for the RTEMS
sources, there is no waf tool (at least I can't run it) so later parts of
the QuickStart guide won't work..
I could just leave it like that, but then RTEMS 6 is built and all version
numbers would have to be corrected..

KInd Regards
Robin

On Wed, 2 Dec 2020 at 13:59, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> On 02/12/2020 13:46, Robin Mueller wrote:
> > ---
> >   user/start/sources.rst | 9 +
> >   user/start/tools.rst   | 9 -
> >   2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/user/start/sources.rst b/user/start/sources.rst
> > index 8c40aa0..fddc439 100644
> > --- a/user/start/sources.rst
> > +++ b/user/start/sources.rst
> > @@ -86,12 +86,21 @@ You can clone the Git repository to get all versions
> of RTEMS including the
> >   development head.  Release branches in Git are kept stable however
> they may
> >   differ from a release's source archive.
> >
> > +For this Quick Start guide, we will switch to the RTEMS 5 branches
> because the
> > +master branch does not contain the version 5 `rtems-sparc` build set.
> > +If you wich to build with the master branch instead, it is recommended
> to
> > +replace the version number 5 with version 6 everywhere it is used in
> the Quick Start guide.
> the documentation for the master branch should not refer to the RTEMS 5
> release. So, the right fix is to replace '5' with '6' if needed.
> > +
> >   .. code-block:: none
> >
> >   mkdir -p $HOME/quick-start/src
> >   cd $HOME/quick-start/src
> >   git clone git://git.rtems.org/rtems-source-builder.git rsb
> > +git checkout origin/5
> > +git checkout -b 5
> >   git clone git://git.rtems.org/rtems.git
> > +git checkout origin/5
> > +git checkout -b 5
> >
> >   The :file:`rsb` repository clone contains the :ref:`RTEMS Source
> Builder (RSB)
> >   `.  We clone it into :file:`rsb` to get shorter paths during the
> tool
> > diff --git a/user/start/tools.rst b/user/start/tools.rst
> > index baa2387..e0fe10d 100644
> > --- a/user/start/tools.rst
> > +++ b/user/start/tools.rst
> > @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
> tightly coupled.  For
> >   example, do not use a RTEMS version 5 tool suite with RTEMS version
> 4.11
> >   sources and vice versa.
> >
> > -Build and install the tool suite:
> > +The available build sets can be displayed with:
> > +
> > +.. code-block:: none
> > +
> > +cd $HOME/quick-start/src/rsb/rtems
> > +../source-builder/sb-set-builder --list-bsets
> > +
> > +Build and install the version 5 tool suite for the SPARC architecture:
> >
> >   .. code-block:: none
> This part looks good to me.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hub...@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] doc improvements

[Robin Müller]

I will provide another patch with version numbers corrected.

Kind Regards
Robin

On Wed, 2 Dec 2020 at 14:19, Robin Müller  wrote:

> Actually, I just saw that when switching to the 5 branch for the RTEMS
> sources, there is no waf tool (at least I can't run it) so later parts of
> the QuickStart guide won't work..
> I could just leave it like that, but then RTEMS 6 is built and all version
> numbers would have to be corrected..
>
> KInd Regards
> Robin
>
> On Wed, 2 Dec 2020 at 13:59, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Robin,
>>
>> On 02/12/2020 13:46, Robin Mueller wrote:
>> > ---
>> >   user/start/sources.rst | 9 +
>> >   user/start/tools.rst   | 9 -
>> >   2 files changed, 17 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/user/start/sources.rst b/user/start/sources.rst
>> > index 8c40aa0..fddc439 100644
>> > --- a/user/start/sources.rst
>> > +++ b/user/start/sources.rst
>> > @@ -86,12 +86,21 @@ You can clone the Git repository to get all
>> versions of RTEMS including the
>> >   development head.  Release branches in Git are kept stable however
>> they may
>> >   differ from a release's source archive.
>> >
>> > +For this Quick Start guide, we will switch to the RTEMS 5 branches
>> because the
>> > +master branch does not contain the version 5 `rtems-sparc` build set.
>> > +If you wich to build with the master branch instead, it is recommended
>> to
>> > +replace the version number 5 with version 6 everywhere it is used in
>> the Quick Start guide.
>> the documentation for the master branch should not refer to the RTEMS 5
>> release. So, the right fix is to replace '5' with '6' if needed.
>> > +
>> >   .. code-block:: none
>> >
>> >   mkdir -p $HOME/quick-start/src
>> >   cd $HOME/quick-start/src
>> >   git clone git://git.rtems.org/rtems-source-builder.git rsb
>> > +git checkout origin/5
>> > +git checkout -b 5
>> >   git clone git://git.rtems.org/rtems.git
>> > +git checkout origin/5
>> > +git checkout -b 5
>> >
>> >   The :file:`rsb` repository clone contains the :ref:`RTEMS Source
>> Builder (RSB)
>> >   `.  We clone it into :file:`rsb` to get shorter paths during the
>> tool
>> > diff --git a/user/start/tools.rst b/user/start/tools.rst
>> > index baa2387..e0fe10d 100644
>> > --- a/user/start/tools.rst
>> > +++ b/user/start/tools.rst
>> > @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
>> tightly coupled.  For
>> >   example, do not use a RTEMS version 5 tool suite with RTEMS version
>> 4.11
>> >   sources and vice versa.
>> >
>> > -Build and install the tool suite:
>> > +The available build sets can be displayed with:
>> > +
>> > +.. code-block:: none
>> > +
>> > +cd $HOME/quick-start/src/rsb/rtems
>> > +../source-builder/sb-set-builder --list-bsets
>> > +
>> > +Build and install the version 5 tool suite for the SPARC architecture:
>> >
>> >   .. code-block:: none
>> This part looks good to me.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hub...@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] quick start variable version number

[Robin Mueller]

---
 user/start/sources.rst | 10 --
 user/start/tools.rst   | 19 +--
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/user/start/sources.rst b/user/start/sources.rst
index 8c40aa0..836cab9 100644
--- a/user/start/sources.rst
+++ b/user/start/sources.rst
@@ -9,11 +9,14 @@
 Obtain the Sources
 ==
 
+The chosen RTEMS version (5 for a released build, 6 for the git clone) will be 
+replaced by $RTEMS_VERSION for some parts of the Quick Start.
 You have considered and chosen a suitable installation prefix in the previous
-section.  We have chosen :file:`$HOME/quick-start/rtems/5` as the installation
+section.  We have chosen :file:`$HOME/quick-start/rtems/$RTEMS_VERSION` as the 
installation
 prefix. We will show how to use a released version of RTEMS and then as an
 alternative we will show you using the :ref:`RSB Git repository
-`. Consider using a Git clone if you wish to make
+` master which uses RTEMS version 6. 
+Consider using a Git clone if you wish to make
 contributions to the RTEMS Project.
 
 You need the RTEMS Source Builder (RSB) to work with RTEMS and we prefer you
@@ -86,6 +89,9 @@ You can clone the Git repository to get all versions of RTEMS 
including the
 development head.  Release branches in Git are kept stable however they may
 differ from a release's source archive.
 
+The master branch by default uses RTEMS version 6 and does not 
+contain the version 5 `rtems-sparc` build set.
+
 .. code-block:: none
 
 mkdir -p $HOME/quick-start/src
diff --git a/user/start/tools.rst b/user/start/tools.rst
index baa2387..7f4a122 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -12,20 +12,27 @@ Install the Tool Suite
 
 You have chosen an installation prefix, the BSP to build, the tool's
 architecure and prepared the source for the RSB in the previous sections.  We
-have chosen :file:`$HOME/quick-start/rtems/5` as the installation prefix, the
-``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and unpacked
-the RSB source in :file:`$HOME/quick-start/src`.
+have chosen :file:`$HOME/quick-start/rtems/$RTEMS_VERSION` as the installation 
prefix, the
+``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5`` 
(``sparc-rtems6`` for the git clone), 
+and unpacked the RSB source in :file:`$HOME/quick-start/src`.
 
 The tool suite for RTEMS and the RTEMS sources are tightly coupled.  For
 example, do not use a RTEMS version 5 tool suite with RTEMS version 4.11
 sources and vice versa.
 
-Build and install the tool suite:
+The available build sets can be displayed with:
+
+.. code-block:: none
+
+cd $HOME/quick-start/src/rsb/rtems
+../source-builder/sb-set-builder --list-bsets
+   
+Build and install the tool suite for the SPARC architecture and RTEMS version:
 
 .. code-block:: none
 
 cd $HOME/quick-start/src/rsb/rtems
-../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 
5/rtems-sparc
+../source-builder/sb-set-builder 
--prefix=$HOME/quick-start/rtems/$RTEMS_VERSION $RTEMS_VERSION/rtems-sparc
 
 This command should output something like this (omitted lines are denoted by
 ...). The build host appears as part of the name of the package being
@@ -51,7 +58,7 @@ built. The name you see may vary depending on the host you 
are using:
 Build Set: Time 0:21:35.626294
 
 Once the build has successfully completed you can check if the cross C compiler
-works with the following command:
+works with the following command (replace 5 with 6 for RTEMS 6):
 
 .. code-block:: none
 
-- 
2.29.2

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

[PATCH] command correction to perform tests

[Robin Mueller]

---
The old command seems to be incosistent with the rest of the quick
start guide. I was able to run tests for both RTEMS5 (released build)
and RTEMS 6 ( git clone) with the following commands.
 user/start/bsp-test.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
index 9243f5d..af6194a 100644
--- a/user/start/bsp-test.rst
+++ b/user/start/bsp-test.rst
@@ -9,19 +9,19 @@ Test a Board Support Package (BSP)
 ==
 
 You built a BSP with tests in the previous section.  We built the
-``sparc/erc32`` BSP in :file:`$HOME/quick-start/src/rtems`.
+``sparc/erc32`` BSP in 
:file:`$HOME/quick-start/rtems/${RTEMS_VERSION}/sparc-rtems${RTEMS_VERSION}/erc32`.
 
 You should run the RTEMS test suite on your target hardware.  The RTEMS Project
 provides some support to do this, see the :ref:`Testing ` chapter for
 the details.
 
 On the ``sparc/erc32`` BSP we selected for this quick start chapter this is
-easy.  Just run this command:
+easy.  Just run this command and replace sparc-rtems:
 
 .. code-block:: none
 
-cd $HOME/quick-start/src/rtems
-rtems-test --rtems-bsp=erc32-sis build/sparc/erc32
+cd 
$HOME/quick-start/rtems/${RTEMS_VERSION}/sparc-rtems${RTEMS_VERSION}/erc32
+rtems-test --rtems-bsp=erc32-sis tests
 
 This command should output something like this (omitted lines are denoted by
 ...).  In this output the base directory :file:`$HOME/quick-start` was replaced
-- 
2.29.2

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

"invalid %if operator" in RTEMS source builder .cfg file

[Peter Dufault]

I'm building "Simple Open EtherCAT Master" with rtems-6.  I built it earlier 
with rtems-5.  I get the following error when I try to build it:

[dufault@build scripts]$ 
/home/dufault/development/rtems/rtems-source-builder/source-builder/sb-set-builder
 \
  --log=log_arm_soem \
  --prefix=/opt/flatland/opt/rtems-6 \
  --with-tools=/opt/flatland/opt/rtems-6 \
  --host=arm-rtems6 \
  --with-rtems-bsp=xilinx_zynq_zedboard \
  net/soem
RTEMS Source Builder - Set Builder, 6 (f8d1f3c00db9)
Build Set: net/soem
config: net/soem-master.cfg
error: rtems-bsp.cfg:169: invalid %if operator:  
-B/opt/flatland/opt/rtems-6/arm-rtems6/xilinx_zynq_a9_qemu/lib -qrtems ==
Build FAILED
Build Set: Time 0:00:00.055627
Build FAILED
[dufault@build scripts]$


It fails at the following "%if" directive:

#
# If there are no LDFLAGS create a path to RTEMS.
#
%if %{rtems_bsp_ldflags} == %{nil}
 %define rtems_bsp_ldflags -L%{rtems_bsp_prefix}/lib
%endif

Not being sure how to proceed I commented the three lines out and then it 
built.  Any suggestions?

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

This email is delivered through the public internet using protocols subject to 
interception and tampering.



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

CAN user space API for RTEMS

[Jan.Sommer]

Hello,

We have some upcoming projects which will use RTEMS and will require CAN.
RTEMS doesn't have a CAN user interface and as far as I can see there is also 
no such thing in FreeBSD (please correct me if I'm wrong) which we could take 
in via rtems-libbsd.
Now, our options are to just use keep everything internal and use some custom 
driver (maybe based on some micro controller implementations) or contribute 
some kind of CAN subsystem to RTEMS.
I find the latter option more appealing, but then the question would be if we 
can use an API known from somewhere else like for spi and i2c and there doesn't 
seem to be a lot of choices:
- SocketCan --> seems to be too much work to implement in RTEMS (would probably 
need a socket implementation as well). I found some discussions about an 
implementation for FreeBSD, but it seems to have died.
- Can4Linux: Seems to be still maintained, the header file seems to be licensed 
under 3-Clause BSD. Is uses chardev, so it is probably reasonably easy to 
implement similar to spidev.

Would there be any interest in having a can4linux implementation in RTEMS? Or 
are there other/better available APIs?

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer

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

[PATCH 0/1] Add yaml format to the supported report formats

[clrrm]

From: Cláudio Maia 

Two output formats were supported by RTEMS Tester: json and junit.
This patch adds yaml to the list of supported formats. 

The information being stored in the ouput file is the same as the one being
stored for the other formats, with the addition of adding a few more execution
details, such as the output of each test and the "debugger" output.

The feature can be used in the same manner as the other report formats, by 
using "--report-format=yaml --report-path=name-of-report".

The patch was tested using leon3 bsp and SIS.

Cláudio Maia (1):
  Add yaml format to the supported report formats

 tester/rt/test.py | 104 +-
 1 file changed, 102 insertions(+), 2 deletions(-)

-- 
2.17.1

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

[PATCH 1/1] Add yaml format to the supported report formats

[clrrm]

From: Cláudio Maia 

---
 tester/rt/test.py | 104 +-
 1 file changed, 102 insertions(+), 2 deletions(-)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index 9b157e9..0178a8d 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -339,9 +339,109 @@ def generate_junit_report(args, reports, start_time, 
end_time,
 with open(junit_file, 'w') as f:
 TestSuite.to_file(f, [ts], prettyprint = True)
 
+def generate_yaml_report(args, reports, start_time, end_time,
+ total, yaml_file):
+import yaml
+
+def format_output(output_list):
+return "\n".join(output_list).replace("] ", '').replace('=>  ', '')
+
+yaml_log = {}
+yaml_log['command-line'] = args
+yaml_log['host'] = host.label(mode='all')
+yaml_log['python'] = sys.version.replace('\n', '')
+yaml_log['summary'] = {}
+yaml_log['summary']['passed-count'] = reports.passed
+yaml_log['summary']['failed-count'] = reports.failed
+yaml_log['summary']['user-input-count'] = reports.user_input
+yaml_log['summary']['expected-fail-count'] = reports.expected_fail
+yaml_log['summary']['indeterminate-count'] = reports.indeterminate
+yaml_log['summary']['benchmark-count'] = reports.benchmark
+yaml_log['summary']['timeout-count'] = reports.timeouts
+yaml_log['summary']['test-too-long_count'] = reports.test_too_long
+yaml_log['summary']['invalid-count'] = reports.invalids
+yaml_log['summary']['wrong-version-count'] = reports.wrong_version
+yaml_log['summary']['wrong-build-count'] = reports.wrong_build
+yaml_log['summary']['wrong-tools-count'] = reports.wrong_tools
+yaml_log['summary']['total-count'] = reports.total
+time_delta = end_time - start_time
+yaml_log['summary']['average-test-time'] = str(time_delta / total)
+yaml_log['summary']['testing-time'] = str(time_delta)
+
+result_types = [
+'failed', 'user-input', 'expected-fail', 'indeterminate',
+'benchmark', 'timeout', 'test-too-long', 'invalid', 
'wrong-version',
+'wrong-build', 'wrong-tools'
+]
+for result_type in result_types:
+yaml_log['summary'][result_type] = []
+
+result_element = {}
+yaml_log['outputs'] = []
+
+# process output of each test
+for exe_name in reports.results:
+result_element['executable-name'] = path.basename(exe_name)
+result_element['executable-sha512'] = get_hash512(exe_name)
+result_element['execution-start'] = 
reports.results[exe_name]['start'].isoformat()
+result_element['execution-end'] = 
reports.results[exe_name]['end'].isoformat()
+date_diff = reports.results[exe_name]['end'] - 
reports.results[exe_name]['start']
+result_element['execution-duration'] = str(date_diff)
+result_element['execution-result'] = 
reports.results[exe_name]['result']
+result_element['bsp'] = reports.results[exe_name]['bsp']
+result_element['bsp-arch'] = reports.results[exe_name]['bsp_arch']
+result_output = reports.results[exe_name]['output']
+
+dbg_output = []
+test_output = []
+idxs_output = []  # store indices of given substrings
+for elem in result_output:
+if '=> ' in elem:
+idxs_output.append(result_output.index(elem))
+if '*** END' in elem:
+idxs_output.append(result_output.index(elem))
+
+if len(idxs_output) == 3:  # test executed and has result
+dbg_output = result_output[idxs_output[0]:idxs_output[1]]
+dbg_output.append("=== Executed Test ===")
+dbg_output = dbg_output + 
result_output[idxs_output[2]+1:len(result_output)]
+test_output = result_output[idxs_output[1]:idxs_output[2]+1]
+else:
+dbg_output = result_output
+
+result_element['debugger-output'] = format_output(dbg_output)
+result_element['console-output'] = format_output(test_output)
+yaml_log['outputs'].append(result_element)
+
+result_type = reports.results[exe_name]['result']
+# map "fatal-error" on to "failed"
+if result_type == "fatal-error":
+result_type = "failed"
+
+if result_type != 'passed':
+yaml_log['summary'][result_type].append(path.basename(exe_name))
+
+result_element = {}
+
+with open(yaml_file, 'w') as outfile:
+yaml.dump(yaml_log, outfile, default_flow_style=False, 
allow_unicode=True)
+
+
+def get_hash512(exe):
+""" returns SHA512 hash string of a given binary file passed as argument 
"""
+import hashlib
+
+hash = hashlib.sha512()
+with open(exe, "rb") as f:
+for byte_block in iter(lambda: f.read(4096), b""):
+hash.update(byte_block)
+return hash.hexdigest()
+
+
 report_formatters = {
 'json': generate_json_report,
-'junit': generate_junit_report
+'junit': generate_junit_report,

Re: CAN user space API for RTEMS

[Gedare Bloom]

Hello Jan,

There are some interested parties in CAN for RTEMS (but mostly of the
volunteer type). Have a look at Pavel's message from March this year:
https://lists.rtems.org/pipermail/devel/2020-March/058161.html

Gedare

On Wed, Dec 2, 2020 at 8:41 AM  wrote:

> Hello,
>
> We have some upcoming projects which will use RTEMS and will require CAN.
> RTEMS doesn't have a CAN user interface and as far as I can see there is
> also no such thing in FreeBSD (please correct me if I'm wrong) which we
> could take in via rtems-libbsd.
> Now, our options are to just use keep everything internal and use some
> custom driver (maybe based on some micro controller implementations) or
> contribute some kind of CAN subsystem to RTEMS.
> I find the latter option more appealing, but then the question would be if
> we can use an API known from somewhere else like for spi and i2c and there
> doesn't seem to be a lot of choices:
> - SocketCan --> seems to be too much work to implement in RTEMS (would
> probably need a socket implementation as well). I found some discussions
> about an implementation for FreeBSD, but it seems to have died.
> - Can4Linux: Seems to be still maintained, the header file seems to be
> licensed under 3-Clause BSD. Is uses chardev, so it is probably reasonably
> easy to implement similar to spidev.
>
> Would there be any interest in having a can4linux implementation in RTEMS?
> Or are there other/better available APIs?
>
> Best regards,
>
> Jan
>
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
> German Aerospace Center
> Institute for Software Technology | Software for Space Systems and
> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
>
> Jan Sommer
>
> ___
> 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] doc improvements

[Gedare Bloom]

A significant challenge with the version numbers arises during the release
process. I will leave all these doc patches for Chris to review/feedback,
but the concern is that when a release is cut all the version numbers need
to be injected to the release and then updated for the main branch.

On Wed, Dec 2, 2020 at 6:23 AM Robin Müller 
wrote:

> I will provide another patch with version numbers corrected.
>
> Kind Regards
> Robin
>
> On Wed, 2 Dec 2020 at 14:19, Robin Müller 
> wrote:
>
>> Actually, I just saw that when switching to the 5 branch for the RTEMS
>> sources, there is no waf tool (at least I can't run it) so later parts of
>> the QuickStart guide won't work..
>> I could just leave it like that, but then RTEMS 6 is built and all
>> version numbers would have to be corrected..
>>
>> KInd Regards
>> Robin
>>
>> On Wed, 2 Dec 2020 at 13:59, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello Robin,
>>>
>>> On 02/12/2020 13:46, Robin Mueller wrote:
>>> > ---
>>> >   user/start/sources.rst | 9 +
>>> >   user/start/tools.rst   | 9 -
>>> >   2 files changed, 17 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/user/start/sources.rst b/user/start/sources.rst
>>> > index 8c40aa0..fddc439 100644
>>> > --- a/user/start/sources.rst
>>> > +++ b/user/start/sources.rst
>>> > @@ -86,12 +86,21 @@ You can clone the Git repository to get all
>>> versions of RTEMS including the
>>> >   development head.  Release branches in Git are kept stable however
>>> they may
>>> >   differ from a release's source archive.
>>> >
>>> > +For this Quick Start guide, we will switch to the RTEMS 5 branches
>>> because the
>>> > +master branch does not contain the version 5 `rtems-sparc` build set.
>>> > +If you wich to build with the master branch instead, it is
>>> recommended to
>>> > +replace the version number 5 with version 6 everywhere it is used in
>>> the Quick Start guide.
>>> the documentation for the master branch should not refer to the RTEMS 5
>>> release. So, the right fix is to replace '5' with '6' if needed.
>>> > +
>>> >   .. code-block:: none
>>> >
>>> >   mkdir -p $HOME/quick-start/src
>>> >   cd $HOME/quick-start/src
>>> >   git clone git://git.rtems.org/rtems-source-builder.git rsb
>>> > +git checkout origin/5
>>> > +git checkout -b 5
>>> >   git clone git://git.rtems.org/rtems.git
>>> > +git checkout origin/5
>>> > +git checkout -b 5
>>> >
>>> >   The :file:`rsb` repository clone contains the :ref:`RTEMS Source
>>> Builder (RSB)
>>> >   `.  We clone it into :file:`rsb` to get shorter paths during
>>> the tool
>>> > diff --git a/user/start/tools.rst b/user/start/tools.rst
>>> > index baa2387..e0fe10d 100644
>>> > --- a/user/start/tools.rst
>>> > +++ b/user/start/tools.rst
>>> > @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
>>> tightly coupled.  For
>>> >   example, do not use a RTEMS version 5 tool suite with RTEMS version
>>> 4.11
>>> >   sources and vice versa.
>>> >
>>> > -Build and install the tool suite:
>>> > +The available build sets can be displayed with:
>>> > +
>>> > +.. code-block:: none
>>> > +
>>> > +cd $HOME/quick-start/src/rsb/rtems
>>> > +../source-builder/sb-set-builder --list-bsets
>>> > +
>>> > +Build and install the version 5 tool suite for the SPARC architecture:
>>> >
>>> >   .. code-block:: none
>>> This part looks good to me.
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hub...@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

Re: [PATCH v2] c-user: Generate Object Services documentation

[Gedare Bloom]

It looks ok to me. I still don't know what "A body is also provided." means
though.

On Wed, Dec 2, 2020 at 1:22 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The documentation is a consolidation of the comments in Doxygen markup
> and the documentation sources in Sphinx markup.  The documentation was
> transfered to interface specification items.  The documentation source
> files were generated from the items by a script.
>
> Update #3993.
> ---
>
> The generated documentation is available here:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
>
> v2:
>
> Remove leading '_' from parameter names.
>
>  c-user/object-services/directives.rst   | 978 ++--
>  c-user/object-services/introduction.rst |  93 ++-
>  2 files changed, 643 insertions(+), 428 deletions(-)
>
> diff --git a/c-user/object-services/directives.rst
> b/c-user/object-services/directives.rst
> index 87f0f5a..ce7a894 100644
> --- a/c-user/object-services/directives.rst
> +++ b/c-user/object-services/directives.rst
> @@ -1,643 +1,805 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation
> (OAR)
> +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de
> )
> +.. Copyright (C) 1988, 2009 On-Line Applications Research Corporation
> (OAR)
> +
> +.. This file is part of the RTEMS quality process and was automatically
> +.. generated.  If you find something that needs to be fixed or
> +.. worded better please post a report or patch to an RTEMS mailing list
> +.. or raise a bug report:
> +..
> +.. https://docs.rtems.org/branches/master/user/support/bugs.html
> +..
> +.. For information on updating and regenerating please refer to:
> +..
> +.. https://docs.rtems.org/branches/master/eng/req/howto.html
> +
> +.. _ObjectServicesDirectives:
>
>  Directives
>  ==
>
> +This section details the directives of the Object Services. A subsection
> is
> +dedicated to each of this manager's directives and lists the calling
> sequence,
> +parameters, description, return values, and notes of the directive.
> +
> +.. Generated from spec:/rtems/object/if/build-id
> +
>  .. raw:: latex
>
> -   \clearpage
> +\clearpage
> +
> +.. index:: rtems_build_id()
> +
> +.. _InterfaceRtemsBuildId:
> +
> +rtems_build_id()
> +
> +
> +Builds the object identifier from the API, class, MPCI node, and index
> +components.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +#define rtems_build_id( api, class, node, index )
>
> -.. index:: build object name
> -.. index:: rtems_build_name
> +.. rubric:: PARAMETERS:
>
> -.. _rtems_build_name:
> +``api``
> +This parameter is the API of the object identifier to build.
>
> -BUILD_NAME - Build object name from characters
> ---
> +``class``
> +This parameter is the class of the object identifier to build.
>
> -CALLING SEQUENCE:
> -.. code-block:: c
> +``node``
> +This parameter is the MPCI node of the object identifier to build.
>
> -rtems_name rtems_build_name(
> -uint8_t c1,
> -uint8_t c2,
> -uint8_t c3,
> -uint8_t c4
> -);
> +``index``
> +This parameter is the index of the object identifier to build.
>
> -DIRECTIVE STATUS CODES:
> -Returns a name constructed from the four characters.
> +.. rubric:: RETURN VALUES:
>
> -DESCRIPTION:
> -This service takes the four characters provided as arguments and
> constructs
> -a thirty-two bit object name with ``c1`` in the most significant byte
> and
> -``c4`` in the least significant byte.
> +Returns the object identifier built from the API, class, MPCI node, and
> index
> +components.
>
> -NOTES:
> -This directive is strictly local and does not impact task scheduling.
> +.. rubric:: NOTES:
> +
> +This directive is strictly local and does not impact task scheduling.
> +
> +.. Generated from spec:/rtems/object/if/build-name
>
>  .. raw:: latex
>
> -   \clearpage
> +\clearpage
>
> -.. index:: get name from id
> -.. index:: obtain name from id
> -.. index:: rtems_object_get_classic_name
> +.. index:: rtems_build_name()
>
> -.. _rtems_object_get_classic_name:
> +.. _InterfaceRtemsBuildName:
>
> -OBJECT_GET_CLASSIC_NAME - Lookup name from id
> --
> +rtems_build_name()
> +--
>
> -CALLING SEQUENCE:
> -.. code-block:: c
> +Builds the object name composed of the four characters.
>
> -rtems_status_code rtems_object_get_classic_name(
> -rtems_id  id,
> -rtems_name   *name
> -);
> +.. rubric:: CALLING SEQUENCE:
>
> -DIRECTIVE STATUS CODES:
> -.. list-table::
> - :class: rtems-table
> +.. code-block:: c
>
> - * - ``RTEMS_SUCCESSFUL``
> -   - name looked up successfully
> - * - ``RTEMS_INVALID_ADDRESS``
> -   - invalid name pointer
> - * - ``RTEMS_INVALID

Re: [PATCH] rtems: Generate

[Gedare Bloom]

Looks good to me.

On Wed, Dec 2, 2020 at 1:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Change license to BSD-2-Clause according to file histories and
> documentation re-licensing agreement.
>
> Update #3899.
> Update #3993.
> ---
>  cpukit/include/rtems/rtems/timer.h | 705 -
>  1 file changed, 494 insertions(+), 211 deletions(-)
>
> diff --git a/cpukit/include/rtems/rtems/timer.h
> b/cpukit/include/rtems/rtems/timer.h
> index 244d5603ba..3d454e39ec 100644
> --- a/cpukit/include/rtems/rtems/timer.h
> +++ b/cpukit/include/rtems/rtems/timer.h
> @@ -1,289 +1,493 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> - * @ingroup ClassicTimer
> + * @ingroup RTEMSImplClassicTimer
>   *
> - * @brief Classic Timer Manager API
> + * @brief This header file provides the Timer Manager API.
> + */
> +
> +/*
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de
> )
> + * Copyright (C) 1988, 2008 On-Line Applications Research Corporation
> (OAR)
> + *
> + * 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.
>   */
>
>  /*
> - * COPYRIGHT (c) 1989-2011.
> - * On-Line Applications Research Corporation (OAR).
> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://docs.rtems.org/branches/master/user/support/bugs.html
>   *
> - * Copyright (c) 2009, 2016 embedded brains GmbH.
> + * For information on updating and regenerating please refer to:
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * https://docs.rtems.org/branches/master/eng/req/howto.html
>   */
>
> +/* Generated from spec:/rtems/timer/if/header */
> +
>  #ifndef _RTEMS_RTEMS_TIMER_H
>  #define _RTEMS_RTEMS_TIMER_H
>
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
>
> +/* Generated from spec:/rtems/timer/if/group */
> +
>  /**
> - *  @defgroup ClassicTimer Timers
> + * @defgroup RTEMSAPIClassicTimer Timer Manager
>   *
> - *  @ingroup RTEMSAPIClassic
> + * @ingroup RTEMSAPIClassic
>   *
> - *  This encapsulates functionality related to the Classic API Timer
> - *  Manager.  This manager provides functionality which allows the
> - *  application to schedule the execution of methods at a specified
> - *  time in the future.  These methods may be scheduled based upon
> - *  interval or wall time and may be executed in either the clock tick
> - *  ISR or in a special dedicated timer server task.
> + * @brief The Timer Manager provides support for timer facilities.
>   */
> -/**@{*/
>
> -#define TIMER_CLASS_BIT_TIME_OF_DAY 0x1
> +/* Generated from spec:/rtems/timer/if/class-bit-not-dormant */
> +
> +/**
> + * @ingroup RTEMSAPIClassicTimer
> + *
> + * @brief This timer class bit indicates that the timer is not dormant.
> + */
> +#define TIMER_CLASS_BIT_NOT_DORMANT 0x4
> +
> +/* Generated from spec:/rtems/timer/if/class-bit-on-task */
>
> +/**
> + * @ingroup RTEMSAPIClassicTimer
> + *
> + * @brief This timer class bit indicates that the timer routine executes
> in a
> + *   task context.
> + */
>  #define TIMER_CLASS_BIT_ON_TASK 0x2
>
> -#define TIMER_CLASS_BIT_NOT_DORMANT 0x4
> +/* Generated from spec:/rtems/timer/if/class-bit-time-of-day */
> +
> +/**
> + * @ingroup RTEMSAPIClassicTimer
> + *
> + * @brief This timer class bit indicates that the timer uses a time of
> d

Re: [PATCH] c-user: Generate Timer Manager documentation

[Gedare Bloom]

Looks good to me.

On Wed, Dec 2, 2020 at 1:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The documentation is a consolidation of the comments in Doxygen markup
> and the documentation sources in Sphinx markup.  The documentation was
> transfered to interface specification items.  The documentation source
> files were generated from the items by a script.
>
> Update #3993.
> ---
>
> The generated documentation is available here:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
>
>  c-user/timer/directives.rst   | 992 +-
>  c-user/timer/introduction.rst |  57 +-
>  2 files changed, 674 insertions(+), 375 deletions(-)
>
> diff --git a/c-user/timer/directives.rst b/c-user/timer/directives.rst
> index d9b9877..d65f263 100644
> --- a/c-user/timer/directives.rst
> +++ b/c-user/timer/directives.rst
> @@ -1,463 +1,729 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de
> )
>  .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation
> (OAR)
>
> +.. This file is part of the RTEMS quality process and was automatically
> +.. generated.  If you find something that needs to be fixed or
> +.. worded better please post a report or patch to an RTEMS mailing list
> +.. or raise a bug report:
> +..
> +.. https://docs.rtems.org/branches/master/user/support/bugs.html
> +..
> +.. For information on updating and regenerating please refer to:
> +..
> +.. https://docs.rtems.org/branches/master/eng/req/howto.html
> +
> +.. _TimerManagerDirectives:
> +
>  Directives
>  ==
>
> -This section details the timer manager's directives.  A subsection is
> dedicated
> -to each of this manager's directives and describes the calling sequence,
> -related constants, usage, and status codes.
> +This section details the directives of the Timer Manager. A subsection is
> +dedicated to each of this manager's directives and lists the calling
> sequence,
> +parameters, description, return values, and notes of the directive.
> +
> +.. Generated from spec:/rtems/timer/if/create
>
>  .. raw:: latex
>
> -   \clearpage
> +\clearpage
> +
> +.. index:: rtems_timer_create()
>  .. index:: create a timer
> -.. index:: rtems_timer_create
>
> -.. _rtems_timer_create:
> +.. _InterfaceRtemsTimerCreate:
>
> -TIMER_CREATE - Create a timer
> --
> +rtems_timer_create()
> +
> +
> +Creates a timer.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +rtems_status_code rtems_timer_create( rtems_name name, rtems_id *id );
> +
> +.. rubric:: PARAMETERS:
> +
> +``name``
> +This parameter is the name of the timer.
> +
> +``id``
> +This parameter is the pointer to an object identifier variable.  The
> +identifier of the created timer object will be stored in this
> variable, in
> +case of a successful operation.
> +
> +.. rubric:: DESCRIPTION:
>
> -CALLING SEQUENCE:
> -.. code-block:: c
> -
> -rtems_status_code rtems_timer_create(
> -rtems_name  name,
> -rtems_id   *id
> -);
> -
> -DIRECTIVE STATUS CODES:
> -.. list-table::
> - :class: rtems-table
> -
> - * - ``RTEMS_SUCCESSFUL``
> -   - timer created successfully
> - * - ``RTEMS_INVALID_ADDRESS``
> -   - ``id`` is NULL
> - * - ``RTEMS_INVALID_NAME``
> -   - invalid timer name
> - * - ``RTEMS_TOO_MANY``
> -   - too many timers created
> -
> -DESCRIPTION:
> -This directive creates a timer.  The assigned timer id is returned in
> id.
> -This id is used to access the timer with other timer manager
> directives.
> -For control and maintenance of the timer, RTEMS allocates a TMCB from
> the
> -local TMCB free pool and initializes it.
> -
> -NOTES:
> -This directive will obtain the allocator mutex and may cause the
> calling
> -task to be preempted.
> -
> -In SMP configurations, the processor of the currently executing thread
> -determines the processor used for the created timer.  During the
> life-time
> -of the timer this processor is used to manage the timer internally.
> +This directive creates a timer.  The assigned object identifier is
> returned in
> +``id``.  This identifier is used to access the timer with other timer
> related
> +directives.
> +
> +.. rubric:: RETURN VALUES:
> +
> +:c:macro:`RTEMS_SUCCESSFUL`
> +The requested operation was successful.
> +
> +:c:macro:`RTEMS_INVALID_NAME`
> +The timer name was invalid.
> +
> +:c:macro:`RTEMS_INVALID_ADDRESS`
> +The ``id`` parameter was `NULL
> +`_.
> +
> +:c:macro:`RTEMS_TOO_MANY`
> +There was no inactive object available to create a new timer.  The
> number
> +of timers available to the application is configured through the
> +:ref:`CONFIGURE_MAXIMUM_TIMERS` configuration option.
> +
> +.. rubric:: NOTES:
> +
> +This directive may cause th

Re: [PATCH v2] c-user: Generate Object Services documentation

[Sebastian Huber]

On 02/12/2020 18:16, Gedare Bloom wrote:

It looks ok to me. I still don't know what "A body is also provided." 
means though.


This means that in addition to a macro or define there is a real 
function available. This is implemented in three different ways in 
RTEMS. Examples for each variant:


* rtems_interrupt_level_body()

* rtems_clock_get_ticks_per_second()

* rtems_build_name()

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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] doc improvements

[Sebastian Huber]

On 02/12/2020 18:09, Gedare Bloom wrote:

A significant challenge with the version numbers arises during the 
release process. I will leave all these doc patches for Chris to 
review/feedback, but the concern is that when a release is cut all the 
version numbers need to be injected to the release and then updated 
for the main branch.


I think its worth to have a closer look at the stuff provided by 
rtems-central/rtemsspec. The specification item based variable 
substitution is quite capable. You can execute arbitrary Python code to 
map a variable to a value. The RTEMS version numbers are already 
available in the build specification, so for example this patch


diff --git a/spec/rtems/part/if/get-buffer.yml 
b/spec/rtems/part/if/get-buffer.yml

index b2b13bd6..400909f9 100644
--- a/spec/rtems/part/if/get-buffer.yml
+++ b/spec/rtems/part/if/get-buffer.yml
@@ -29,6 +29,8 @@ links:
   uid: group
 name: rtems_partition_get_buffer
 notes: |
+  In RTEMS ${/build/cpukit/optvermaj:/actions[0]/set-value} some things 
changed.

+
   This directive will not cause the running task to be preempted.

   The buffer start alignment is determined by the memory area and 
buffer size


Results in rtems-docs:

diff --git a/c-user/partition/directives.rst 
b/c-user/partition/directives.rst

index e28ef2e..c5e6752 100644
--- a/c-user/partition/directives.rst
+++ b/c-user/partition/directives.rst
@@ -381,6 +381,8 @@ the ``buffer`` parameter.

 .. rubric:: NOTES:

+In RTEMS 6 some things changed.
+
 This directive will not cause the running task to be preempted.

 The buffer start alignment is determined by the memory area and buffer 
size


The mapping from ${/build/cpukit/optvermaj:/actions[0]/set-value} to '6' 
is a bit long, but this could be simplified if needed.


For the user manual of the Qualification Data Package of the ongoing ESA 
activity I generate the build output of an example application like this:


        self.config_mapper.add_get_value(
    f"{self.config_item.type}:/example-make", 
self._get_example_make)


[...]

    def _get_example_make(self, _ctx: ItemGetValueContext) -> Any:
    dir_state, _ = self.dependency("example")
    status = run_command(["make", "clean"], cwd=dir_state.directory)
    assert status == 0
    stdout = []  # type: List[str]
    status = run_command(["make"], cwd=dir_state.directory, 
stdout=stdout)

    assert status == 0
    content = SphinxContent()
    with content.directive("code-block", value="none"):
    content.add(stdout)
    return "\n".join(content.lines)

So, instead of manually doing a copy and paste of some commands to 
document files, the content is generated automatically in the 
environment and the version corresponding to the package.


Each item has an "enabled-by" attribute. You can use this to 
differentiate a generation for a release document and a development 
branch document.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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

What does fatal source: 0 and fatal code: 5 indicate?

[Richi Dubey]

Hi,

I am testing tm24 on the scheduler code that we developed in this year's
GSoC.

I am getting the following error:

fatal source: 0 (INTERNAL_ERROR_CORE)
fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)

and the backtrace goes something like this:

Tasks (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:129
129 }
(gdb)
0x00100f72 129 }
(gdb)
0x00100f74 129 }
(gdb)
0x00100f76 129 }
(gdb)
_Thread_Entry_adaptor_numeric (executing=0x201980
<_RTEMS_tasks_Objects+2576>) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadentryadaptornumeric.c:26
26 }
(gdb)
0x00109afa 26 }
(gdb)
0x00109afc 26 }
(gdb)
0x00109afe 26 }
(gdb)
_Thread_Handler () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:152
152  _User_extensions_Thread_exitted( executing );
(gdb)
0x00108708 152  _User_extensions_Thread_exitted( executing );
(gdb)
154  _Internal_error( INTERNAL_ERROR_THREAD_EXITTED );
(gdb)
0x0010870e 154  _Internal_error( INTERNAL_ERROR_THREAD_EXITTED );
(gdb)

Thread 1 hit Breakpoint 5, _Terminate (the_source=INTERNAL_ERROR_CORE,
the_error=5) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/interr.c:36
36  _User_extensions_Fatal( the_source, the_error );


Is there any information that might help me in debugging this error? Is
there something specific that I should look out for? I think that here the
thread exits its entry function and the scheduler code is not able to find
any other thread to execute (even though there are threads left), is that
right?
Please let me know.

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

Re: GMP is now a required dependency for building GDB

[Chris Johns]

On 2/12/20 7:56 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 19/11/2020 09:52, Sebastian Huber wrote:
>> On 19/11/2020 09:33, Sebastian Huber wrote:
>>
>>> On 17/11/2020 14:49, Joel Sherrill wrote:
>>>

     The GMP library is not available by default on FreeBSD systems.
     For GCC
     we include a fixed version and build it together with GCC. What
     should
     be do for GDB?


 I would lean to including the same version in GDB that we do in GCC.

 Is this like gcc in that if they find it in the source tree, they will use 
 it?

>>> Ok, I will try this approach.
>> This didn't work. I guess we need to to something similar to libexpat.
> what would be your approach to build the latest GDB on FreeBSD?

Yes the same as libexpat will work. Add to the bare/config/devel tree and then
added to the GDB list of packages.

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

Re: "invalid %if operator" in RTEMS source builder .cfg file

[Chris Johns]

On 3/12/20 1:48 am, Peter Dufault wrote:
> I'm building "Simple Open EtherCAT Master" with rtems-6.  I built it earlier 
> with rtems-5.  I get the following error when I try to build it:
> 
> [dufault@build scripts]$ 
> /home/dufault/development/rtems/rtems-source-builder/source-builder/sb-set-builder
>  \
>   --log=log_arm_soem \
>   --prefix=/opt/flatland/opt/rtems-6 \
>   --with-tools=/opt/flatland/opt/rtems-6 \
>   --host=arm-rtems6 \
>   --with-rtems-bsp=xilinx_zynq_zedboard \
>   net/soem
> RTEMS Source Builder - Set Builder, 6 (f8d1f3c00db9)
> Build Set: net/soem
> config: net/soem-master.cfg
> error: rtems-bsp.cfg:169: invalid %if operator:  
> -B/opt/flatland/opt/rtems-6/arm-rtems6/xilinx_zynq_a9_qemu/lib -qrtems ==
> Build FAILED
> Build Set: Time 0:00:00.055627
> Build FAILED
> [dufault@build scripts]$
> 
> 
> It fails at the following "%if" directive:
> 
> #
> # If there are no LDFLAGS create a path to RTEMS.
> #
> %if %{rtems_bsp_ldflags} == %{nil}
>  %define rtems_bsp_ldflags -L%{rtems_bsp_prefix}/lib
> %endif
> 
> Not being sure how to proceed I commented the three lines out and then it 
> built.  Any suggestions?

Was RTEMS built with the waf build system?

I wonder if the pkgconfig set of flags have changes between the build systems?

Chris

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

Re: [PATCH 1/1] Add yaml format to the supported report formats

[Chris Johns]

On 3/12/20 3:05 am, cl...@isep.ipp.pt wrote:
> From: Cláudio Maia 

Thanks. Does this work on python2?

> 
> ---
>  tester/rt/test.py | 104 +-
>  1 file changed, 102 insertions(+), 2 deletions(-)
> 
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index 9b157e9..0178a8d 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -339,9 +339,109 @@ def generate_junit_report(args, reports, start_time, 
> end_time,
>  with open(junit_file, 'w') as f:
>  TestSuite.to_file(f, [ts], prettyprint = True)
>  
> +def generate_yaml_report(args, reports, start_time, end_time,
> + total, yaml_file):
> +import yaml

I would catch an import error and generate a nice error message for the user
suggesting installing YAML from pip or where ever we recommend.

Chris

> +
> +def format_output(output_list):
> +return "\n".join(output_list).replace("] ", '').replace('=>  ', '')
> +
> +yaml_log = {}
> +yaml_log['command-line'] = args
> +yaml_log['host'] = host.label(mode='all')
> +yaml_log['python'] = sys.version.replace('\n', '')
> +yaml_log['summary'] = {}
> +yaml_log['summary']['passed-count'] = reports.passed
> +yaml_log['summary']['failed-count'] = reports.failed
> +yaml_log['summary']['user-input-count'] = reports.user_input
> +yaml_log['summary']['expected-fail-count'] = reports.expected_fail
> +yaml_log['summary']['indeterminate-count'] = reports.indeterminate
> +yaml_log['summary']['benchmark-count'] = reports.benchmark
> +yaml_log['summary']['timeout-count'] = reports.timeouts
> +yaml_log['summary']['test-too-long_count'] = reports.test_too_long
> +yaml_log['summary']['invalid-count'] = reports.invalids
> +yaml_log['summary']['wrong-version-count'] = reports.wrong_version
> +yaml_log['summary']['wrong-build-count'] = reports.wrong_build
> +yaml_log['summary']['wrong-tools-count'] = reports.wrong_tools
> +yaml_log['summary']['total-count'] = reports.total
> +time_delta = end_time - start_time
> +yaml_log['summary']['average-test-time'] = str(time_delta / total)
> +yaml_log['summary']['testing-time'] = str(time_delta)
> +
> +result_types = [
> +'failed', 'user-input', 'expected-fail', 'indeterminate',
> +'benchmark', 'timeout', 'test-too-long', 'invalid', 
> 'wrong-version',
> +'wrong-build', 'wrong-tools'
> +]
> +for result_type in result_types:
> +yaml_log['summary'][result_type] = []
> +
> +result_element = {}
> +yaml_log['outputs'] = []
> +
> +# process output of each test
> +for exe_name in reports.results:
> +result_element['executable-name'] = path.basename(exe_name)
> +result_element['executable-sha512'] = get_hash512(exe_name)
> +result_element['execution-start'] = 
> reports.results[exe_name]['start'].isoformat()
> +result_element['execution-end'] = 
> reports.results[exe_name]['end'].isoformat()
> +date_diff = reports.results[exe_name]['end'] - 
> reports.results[exe_name]['start']
> +result_element['execution-duration'] = str(date_diff)
> +result_element['execution-result'] = 
> reports.results[exe_name]['result']
> +result_element['bsp'] = reports.results[exe_name]['bsp']
> +result_element['bsp-arch'] = reports.results[exe_name]['bsp_arch']
> +result_output = reports.results[exe_name]['output']
> +
> +dbg_output = []
> +test_output = []
> +idxs_output = []  # store indices of given substrings
> +for elem in result_output:
> +if '=> ' in elem:
> +idxs_output.append(result_output.index(elem))
> +if '*** END' in elem:
> +idxs_output.append(result_output.index(elem))
> +
> +if len(idxs_output) == 3:  # test executed and has result
> +dbg_output = result_output[idxs_output[0]:idxs_output[1]]
> +dbg_output.append("=== Executed Test ===")
> +dbg_output = dbg_output + 
> result_output[idxs_output[2]+1:len(result_output)]
> +test_output = result_output[idxs_output[1]:idxs_output[2]+1]
> +else:
> +dbg_output = result_output
> +
> +result_element['debugger-output'] = format_output(dbg_output)
> +result_element['console-output'] = format_output(test_output)
> +yaml_log['outputs'].append(result_element)
> +
> +result_type = reports.results[exe_name]['result']
> +# map "fatal-error" on to "failed"
> +if result_type == "fatal-error":
> +result_type = "failed"
> +
> +if result_type != 'passed':
> +yaml_log['summary'][result_type].append(path.basename(exe_name))
> +
> +result_element = {}
> +
> +with open(yaml_file, 'w') as outfile:
> +yaml.dump(yaml_log, outfile, default_flow_style=False, 
> allow_unicode=True)
> +
> +
> +def get

Re: [PATCH] doc improvements

[Chris Johns]

On 3/12/20 4:09 am, Gedare Bloom wrote:
> A significant challenge with the version numbers arises during the release
> process. I will leave all these doc patches for Chris to review/feedback, but
> the concern is that when a release is cut all the version numbers need to be
> injected to the release and then updated for the main branch.

The version number in a formal sense is managed. In the documentation the
support is in common/version.py.

The complicated part is in the examples and commands because there is no easy
way in Sphinx to make them programmable. At various points in time I have
invested time in a solution and got no where. I consider pre-processing the
source with macros but changing a version number is only part of what is needed.
Newer versions of tools often have different output and we need to keep that
updated. A simple example is the version number of gcc.

As a result we either remove example output or we have to maintain the 
documents.

Chris

> 
> On Wed, Dec 2, 2020 at 6:23 AM Robin Müller  > wrote:
> 
> I will provide another patch with version numbers corrected.
> 
> Kind Regards
> Robin
> 
> On Wed, 2 Dec 2020 at 14:19, Robin Müller  > wrote:
> 
> Actually, I just saw that when switching to the 5 branch for the RTEMS
> sources, there is no waf tool (at least I can't run it) so later parts
> of the QuickStart guide won't work..
> I could just leave it like that, but then RTEMS 6 is built and all
> version numbers would have to be corrected..
> 
> KInd Regards
> Robin
> 
> On Wed, 2 Dec 2020 at 13:59, Sebastian Huber
>  > wrote:
> 
> Hello Robin,
> 
> On 02/12/2020 13:46, Robin Mueller wrote:
> > ---
> >   user/start/sources.rst | 9 +
> >   user/start/tools.rst   | 9 -
> >   2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/user/start/sources.rst b/user/start/sources.rst
> > index 8c40aa0..fddc439 100644
> > --- a/user/start/sources.rst
> > +++ b/user/start/sources.rst
> > @@ -86,12 +86,21 @@ You can clone the Git repository to get all
> versions of RTEMS including the
> >   development head.  Release branches in Git are kept stable
> however they may
> >   differ from a release's source archive.
> >   
> > +For this Quick Start guide, we will switch to the RTEMS 5
> branches because the
> > +master branch does not contain the version 5 `rtems-sparc` 
> build set.
> > +If you wich to build with the master branch instead, it is
> recommended to
> > +replace the version number 5 with version 6 everywhere it is 
> used
> in the Quick Start guide.
> the documentation for the master branch should not refer to the 
> RTEMS 5
> release. So, the right fix is to replace '5' with '6' if needed.
> > +
> >   .. code-block:: none
> >   
> >       mkdir -p $HOME/quick-start/src
> >       cd $HOME/quick-start/src
> >       git clone git://git.rtems.org/rtems-source-builder.git
>  rsb
> > +    git checkout origin/5
> > +    git checkout -b 5
> >       git clone git://git.rtems.org/rtems.git
> 
> > +    git checkout origin/5
> > +    git checkout -b 5
> >   
> >   The :file:`rsb` repository clone contains the :ref:`RTEMS 
> Source
> Builder (RSB)
> >   `.  We clone it into :file:`rsb` to get shorter paths
> during the tool
> > diff --git a/user/start/tools.rst b/user/start/tools.rst
> > index baa2387..e0fe10d 100644
> > --- a/user/start/tools.rst
> > +++ b/user/start/tools.rst
> > @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS 
> sources
> are tightly coupled.  For
> >   example, do not use a RTEMS version 5 tool suite with RTEMS
> version 4.11
> >   sources and vice versa.
> >   
> > -Build and install the tool suite:
> > +The available build sets can be displayed with:
> > +
> > +.. code-block:: none
> > +
> > +    cd $HOME/quick-start/src/rsb/rtems
> > +    ../source-builder/sb-set-builder --list-bsets
> > +     
> > +Build and install the version 5 tool suite for the SPARC
> architecture:
> >   

Re: [PATCH] doc improvements

[Chris Johns]

 [ Sorry, I did not see this post before ]

On 3/12/20 5:17 am, Sebastian Huber wrote:
> On 02/12/2020 18:09, Gedare Bloom wrote:
> 
>> A significant challenge with the version numbers arises during the release
>> process. I will leave all these doc patches for Chris to review/feedback, but
>> the concern is that when a release is cut all the version numbers need to be
>> injected to the release and then updated for the main branch.
> 
> I think its worth to have a closer look at the stuff provided by
> rtems-central/rtemsspec. The specification item based variable substitution is
> quite capable. You can execute arbitrary Python code to map a variable to a
> value. The RTEMS version numbers are already available in the build
> specification, so for example this patch

Interesting.

> diff --git a/spec/rtems/part/if/get-buffer.yml 
> b/spec/rtems/part/if/get-buffer.yml
> index b2b13bd6..400909f9 100644
> --- a/spec/rtems/part/if/get-buffer.yml
> +++ b/spec/rtems/part/if/get-buffer.yml
> @@ -29,6 +29,8 @@ links:
>    uid: group
>  name: rtems_partition_get_buffer
>  notes: |
> +  In RTEMS ${/build/cpukit/optvermaj:/actions[0]/set-value} some things 
> changed.
> +
>    This directive will not cause the running task to be preempted.
> 
>    The buffer start alignment is determined by the memory area and buffer size
> 
> Results in rtems-docs:
> 
> diff --git a/c-user/partition/directives.rst b/c-user/partition/directives.rst
> index e28ef2e..c5e6752 100644
> --- a/c-user/partition/directives.rst
> +++ b/c-user/partition/directives.rst
> @@ -381,6 +381,8 @@ the ``buffer`` parameter.
> 
>  .. rubric:: NOTES:
> 
> +In RTEMS 6 some things changed.
> +
>  This directive will not cause the running task to be preempted.
> 
>  The buffer start alignment is determined by the memory area and buffer size
> 
> The mapping from ${/build/cpukit/optvermaj:/actions[0]/set-value} to '6' is a
> bit long, but this could be simplified if needed.

Yes.

> 
> For the user manual of the Qualification Data Package of the ongoing ESA
> activity I generate the build output of an example application like this:
> 
>         self.config_mapper.add_get_value(
>     f"{self.config_item.type}:/example-make", self._get_example_make)
> 
> [...]
> 
>     def _get_example_make(self, _ctx: ItemGetValueContext) -> Any:
>     dir_state, _ = self.dependency("example")
>     status = run_command(["make", "clean"], cwd=dir_state.directory)
>     assert status == 0
>     stdout = []  # type: List[str]
>     status = run_command(["make"], cwd=dir_state.directory, stdout=stdout)
>     assert status == 0
>     content = SphinxContent()
>     with content.directive("code-block", value="none"):
>     content.add(stdout)
>     return "\n".join(content.lines)
> 
> So, instead of manually doing a copy and paste of some commands to document
> files, the content is generated automatically in the environment and the 
> version
> corresponding to the package.
> 
> Each item has an "enabled-by" attribute. You can use this to differentiate a
> generation for a release document and a development branch document.

This looks nice. I have no time to play with this.

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

RE: BSP_CONSOLE_MINOR option for Zynq board with new build system

[Kinsey Moore]

-Original Message-
From: devel  On Behalf Of Sebastian Huber
Sent: Wednesday, December 2, 2020 06:46
To: jan.som...@dlr.de; devel@rtems.org
Subject: Re: BSP_CONSOLE_MINOR option for Zynq board with new build system

> Hello Jan,
>
>> On 02/12/2020 11:19, jan.som...@dlr.de wrote:
>> I forgot to follow up with this until I ran into the same thing again.
>> Your patch works and solves the problem.
>> Would you be so kind to push it to master?
>
> I think this should be fixed along with the new aarch64 BSP for Zynq:
>
> https://lists.rtems.org/pipermail/devel/2020-December/063576.html

I'll include a patch with this fix in my next patch set since I'm shuffling 
things around anyway.

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

Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

Hello,
As discussed in this
 thread,
I have compiled a list of the tests that deal with inter stack
communication and fail with the thread stack protection option. Most of
these tests pass when, as Sebastian suggested and had provided a
wonderful example, I disable memory protection at places where contents of
different thread stacks are accessed by the current thread. There are a few
tests that still fail due to inter-stack access in the application code
itself.

The changes I have made are -

diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
index c176d4b8c5..a45b175395 100644
--- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
+++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
@@ -1,15 +1,49 @@
 #include 
 #include 
+#include 
 #include 

+bool set_memory_flags(Thread_Control* thread, void* arg)
+{
+  uintptr_t begin;
+  uintptr_t end;
+  uint32_t flags;
+  rtems_interrupt_level irq_level;
+  Thread_Control *executing;
+
+  executing = _Thread_Executing;
+
+  if(thread !=  executing) {
+
+flags = *( uint32_t *)( arg );
+begin = thread->Start.Initial_stack.area;
+end = begin + thread->Start.Initial_stack.size;
+
+rtems_interrupt_disable(irq_level);
+arm_cp15_set_translation_table_entries(begin, end, flags);
+rtems_interrupt_enable(irq_level);
+  }
+
+  return false;
+}
+
+rtems_status_code _Memory_protection_Enable( void )
+{
+  uint32_t access_flags;
+
+  access_flags = translate_flags(  RTEMS_NO_ACCESS );
+
+  _Thread_Iterate( set_memory_flags, &access_flags );
+
+  return RTEMS_SUCCESSFUL; // check the return values for iterating
function and current method.
+}
+
+rtems_status_code _Memory_protection_Disable( void )
+{
+  uint32_t access_flags;
+
+  access_flags = translate_flags(  RTEMS_READ_WRITE );
+
+  _Thread_Iterate( set_memory_flags, &access_flags );
+
+  return RTEMS_SUCCESSFUL;
 }
\ No newline at end of file
diff --git a/cpukit/include/rtems/score/coremsgimpl.h
b/cpukit/include/rtems/score/coremsgimpl.h
index e598dce96a..3719a3d3c8 100644
--- a/cpukit/include/rtems/score/coremsgimpl.h
+++ b/cpukit/include/rtems/score/coremsgimpl.h
@@ -27,6 +27,10 @@
 #include 
 #include 

+#if defined RTEMS_THREAD_STACK_PROTECTION
+ #include 
+#endif
+
 #include 
 #include 

@@ -586,7 +590,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
*_CORE_message_queue_Dequeue_receiver(
   if ( the_thread == NULL ) {
 return NULL;
   }
-
+#if defined RTEMS_THREAD_STACK_PROTECTION
+  _Memory_protection_Disable();
+#endif
*(size_t *) the_thread->Wait.return_argument = size;
the_thread->Wait.count = (uint32_t) submit_type;

@@ -595,6 +601,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
*_CORE_message_queue_Dequeue_receiver(
 the_thread->Wait.return_argument_second.mutable_object,
 size
   );
+#if defined RTEMS_THREAD_STACK_PROTECTION
+  _Memory_protection_Enable();
+#endif

   _Thread_queue_Extract_critical(
 &the_message_queue->Wait_queue.Queue,

diff --git a/cpukit/posix/src/psignalunblockthread.c
b/cpukit/posix/src/psignalunblockthread.c
index 80a0f33a09..e0f8468de6 100644
--- a/cpukit/posix/src/psignalunblockthread.c
+++ b/cpukit/posix/src/psignalunblockthread.c
@@ -24,6 +24,9 @@
 #include 

 #include 
+#if defined RTEMS_THREAD_STACK_PROTECTION
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -205,6 +208,10 @@ bool _POSIX_signals_Unblock_thread(

   the_info = (siginfo_t *) the_thread->Wait.return_argument;

+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Disable();
+#endif
+
   if ( !info ) {
 the_info->si_signo = signo;
 the_info->si_code = SI_USER;
@@ -212,6 +219,9 @@ bool _POSIX_signals_Unblock_thread(
   } else {
 *the_info = *info;
   }
+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Enable();
+#endif

   _Thread_queue_Extract_with_proxy( the_thread );
   return _POSIX_signals_Unblock_thread_done( the_thread, api, true );
diff --git a/cpukit/rtems/src/eventsurrender.c
b/cpukit/rtems/src/eventsurrender.c
index 49f77d2663..5de62ec292 100644
--- a/cpukit/rtems/src/eventsurrender.c
+++ b/cpukit/rtems/src/eventsurrender.c
@@ -23,6 +23,10 @@
 #include 
 #include 

+#if defined RTEMS_THREAD_STACK_PROTECTION
+  #include 
+#endif
+
 static void _Event_Satisfy(
   Thread_Control  *the_thread,
   Event_Control   *event,
@@ -31,7 +35,13 @@ static void _Event_Satisfy(
 )
 {
   event->pending_events = _Event_sets_Clear( pending_events, seized_events
);
+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Disable();
+#endif
   *(rtems_event_set *) the_thread->Wait.return_argument = seized_events;
+#if defined RTEMS_THREAD_STACK_PROTECTION
+_Memory_protection_Enable();
+#endif
 }

 static bool _Event_Is_blocking_on_event(
diff --git a/cpukit/rtems/src/regionprocessqueue.c
b/cpukit/rtems/src/regionprocessqueue.c
index 4adaf66674..29b078a38c 100644
--- a/cpukit/rtems/

Makefile.inc Issues

[Joel Sherrill]

Hi

I know a number of the flags were removed from the CFLAGS installed but we
lost -g which makes debugging impossible.

I understand dropping the warning flags but I question dropping the
recommended optimization and -g.

This came up debugging the rtems-examples.

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

[PATCH v2 2/4] samples/unlimited: Prevent compile error

[Kinsey Moore]

For architectures with relatively large minimum stack sizes, ensure that
the init task stack size is at least the minimum stack size to prevent a
configuration error during compilation.
---
 testsuites/samples/unlimited/system.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/testsuites/samples/unlimited/system.h 
b/testsuites/samples/unlimited/system.h
index 2624a696df..dafbf9f92e 100644
--- a/testsuites/samples/unlimited/system.h
+++ b/testsuites/samples/unlimited/system.h
@@ -12,6 +12,7 @@
  */
 
 #include 
+#include 
 
 /* functions */
 
@@ -50,7 +51,7 @@ extern void test3(void);
 #define TASK_ALLOCATION_SIZE (5)
 #define CONFIGURE_UNLIMITED_OBJECTS
 #define CONFIGURE_UNLIMITED_ALLOCATION_SIZE TASK_ALLOCATION_SIZE
-#define CONFIGURE_INIT_TASK_STACK_SIZE (8 * 1024)
+#define CONFIGURE_INIT_TASK_STACK_SIZE MAX(8 * 1024, 
CONFIGURE_MINIMUM_TASK_STACK_SIZE)
 
 
 #include 
-- 
2.20.1

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

[PATCH v2 1/4] zynq-uart: Fix set_attributes implementation

[Kinsey Moore]

The zynq-uart set_attributes implementation was configured to always
return false which causes spconsole01 to fail. This restores the
disabled implementation which sets the baud rate registers
appropriately and allows spconsole01 to pass. This also expands the
set_attributes functionality to allow setting of the stop bits,
character width, and parity.
---
 bsps/include/dev/serial/zynq-uart.h   |  5 ++
 bsps/shared/dev/serial/zynq-uart-polled.c |  2 +-
 bsps/shared/dev/serial/zynq-uart.c| 62 +--
 3 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/bsps/include/dev/serial/zynq-uart.h 
b/bsps/include/dev/serial/zynq-uart.h
index 2c0f250a3a..e3e8cae6fd 100644
--- a/bsps/include/dev/serial/zynq-uart.h
+++ b/bsps/include/dev/serial/zynq-uart.h
@@ -78,6 +78,11 @@ void zynq_uart_write_polled(
   */
 void zynq_uart_reset_tx_flush(zynq_uart_context *ctx);
 
+int zynq_cal_baud_rate(uint32_t  baudrate,
+   uint32_t* brgr,
+   uint32_t* bauddiv,
+   uint32_t  modereg);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/bsps/shared/dev/serial/zynq-uart-polled.c 
b/bsps/shared/dev/serial/zynq-uart-polled.c
index a1b51ea521..442431d502 100644
--- a/bsps/shared/dev/serial/zynq-uart-polled.c
+++ b/bsps/shared/dev/serial/zynq-uart-polled.c
@@ -40,7 +40,7 @@ uint32_t zynq_uart_input_clock(void)
   return ZYNQ_CLOCK_UART;
 }
 
-static int zynq_cal_baud_rate(uint32_t  baudrate,
+int zynq_cal_baud_rate(uint32_t  baudrate,
   uint32_t* brgr,
   uint32_t* bauddiv,
   uint32_t  modereg)
diff --git a/bsps/shared/dev/serial/zynq-uart.c 
b/bsps/shared/dev/serial/zynq-uart.c
index 41adb196ab..e2b614c270 100644
--- a/bsps/shared/dev/serial/zynq-uart.c
+++ b/bsps/shared/dev/serial/zynq-uart.c
@@ -142,25 +142,77 @@ static bool zynq_uart_set_attributes(
   const struct termios *term
 )
 {
-#if 0
-  volatile zynq_uart *regs = zynq_uart_get_regs(minor);
+  zynq_uart_context *ctx = (zynq_uart_context *) context;
+  volatile zynq_uart *regs = ctx->regs;
   uint32_t brgr = 0;
   uint32_t bauddiv = 0;
+  uint32_t mode = 0;
   int rc;
 
   rc = zynq_cal_baud_rate(115200, &brgr, &bauddiv, regs->mode);
   if (rc != 0)
 return rc;
 
+  /*
+   * Configure the mode register
+   */
+  mode |= ZYNQ_UART_MODE_CHMODE(ZYNQ_UART_MODE_CHMODE_NORMAL);
+
+  /*
+   * Parity
+   */
+
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE);
+  if (term->c_cflag & PARENB) {
+if (!(term->c_cflag & PARODD))
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_ODD);
+else
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_EVEN);
+  }
+
+  /*
+   * Character Size
+   */
+
+  if (term->c_cflag & CSIZE) {
+switch (term->c_cflag & CSIZE) {
+  case CS5:
+   return false;
+  case CS6:
+   mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_6);
+   break;
+  case CS7:
+   mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_7);
+   break;
+  case CS8:
+   mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8);
+   break;
+}
+  } else {
+/* default to 9600,8,N,1 */
+mode |= ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8);
+  }
+
+  /*
+   * Stop Bits
+   */
+
+  if (term->c_cflag & CSTOPB) {
+/* 2 stop bits */
+mode |= ZYNQ_UART_MODE_NBSTOP(ZYNQ_UART_MODE_NBSTOP_STOP_2);
+  } else {
+/* 1 stop bit */
+mode |= ZYNQ_UART_MODE_NBSTOP(ZYNQ_UART_MODE_NBSTOP_STOP_1);
+  }
+
+
   regs->control &= ~(ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN);
+  regs->mode = mode;
   regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
   regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
   regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
 
   return true;
-#else
-  return false;
-#endif
 }
 
 const rtems_termios_device_handler zynq_uart_handler = {
-- 
2.20.1

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

[PATCH v2 4/4] spec/optconminor: Fix value type

[Kinsey Moore]

The option for defining the console minor should be an integer, not a
boolean.
---
 spec/build/bsps/optconminor.yml | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/spec/build/bsps/optconminor.yml b/spec/build/bsps/optconminor.yml
index 55074c6dac..486eb92d33 100644
--- a/spec/build/bsps/optconminor.yml
+++ b/spec/build/bsps/optconminor.yml
@@ -1,15 +1,16 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 actions:
-- get-boolean: null
-- define-condition: null
+- get-integer: null
+- define: null
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
-default: true
+default: 1
 default-by-variant: []
 description: |
   minor number of console device
 enabled-by: true
+format: '{}'
 links: []
 name: BSP_CONSOLE_MINOR
 type: build
-- 
2.20.1

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

[PATCH v2 3/4] Add AArch64 ZynpMP BSP

[Kinsey Moore]

This adds a BSP family that runs on the Xilinx Ultrascale+ MPSOC
(ZynqMP) family of chips. It is configured to be usable on the Qemu
ZCU102 machine definition and should be almost trivially portable to
ZynqMP development boards and custom hardware. It is also configured to
be usable with libbsd.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  | 134 ++
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  74 ++
 bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h  |  72 ++
 bsps/aarch64/xilinx-zynqmp/include/tm27.h |  46 ++
 bsps/aarch64/xilinx-zynqmp/start/bspstart.c   |  49 +++
 .../xilinx-zynqmp/start/bspstarthooks.c   |  51 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml |  22 +++
 .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|  21 +++
 .../aarch64/xilinx-zynqmp/bspqemulp64.yml |  21 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |  44 ++
 .../aarch64/xilinx-zynqmp/linkcmds_ilp32.yml  |  72 ++
 .../aarch64/xilinx-zynqmp/linkcmds_lp64.yml   |  71 ++
 spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |  37 +
 .../bsps/aarch64/xilinx-zynqmp/optclkuart.yml |  20 +++
 .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  18 +++
 .../aarch64/xilinx-zynqmp/optnocachelen.yml   |  18 +++
 .../bsps/aarch64/xilinx-zynqmp/optramlen.yml  |  18 +++
 .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  18 +++
 .../bsps/aarch64/xilinx-zynqmp/tstqemu.yml|  53 +++
 spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +-
 .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +-
 .../bsps/arm/xilinx-zynqmp/optconminor.yml|  15 --
 .../{arm/xilinx-zynq => }/optconminor.yml |   0
 23 files changed, 861 insertions(+), 17 deletions(-)
 create mode 100644 bsps/aarch64/xilinx-zynqmp/console/console.c
 create mode 100644 bsps/aarch64/xilinx-zynqmp/include/bsp.h
 create mode 100644 bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
 create mode 100644 bsps/aarch64/xilinx-zynqmp/include/tm27.h
 create mode 100644 bsps/aarch64/xilinx-zynqmp/start/bspstart.c
 create mode 100644 bsps/aarch64/xilinx-zynqmp/start/bspstarthooks.c
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspqemuilp32.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspqemulp64.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_ilp32.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/linkcmds_lp64.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optclkuart.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optnocachelen.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optramlen.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
 delete mode 100644 spec/build/bsps/arm/xilinx-zynqmp/optconminor.yml
 rename spec/build/bsps/{arm/xilinx-zynq => }/optconminor.yml (100%)

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
new file mode 100644
index 00..a22a194782
--- /dev/null
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsAArch64XilinxZynqMP
+ *
+ * @brief This source file contains this BSP's console configuration.
+ */
+
+/*
+ * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore 
+ *
+ * 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 ADVI

Re: Makefile.inc Issues

[Chris Johns]

On 3/12/20 12:07 pm, Joel Sherrill wrote:
> I know a number of the flags were removed from the CFLAGS installed but we 
> lost
> -g which makes debugging impossible. 
> 
> I understand dropping the warning flags but I question dropping the 
> recommended
> optimization and -g.

I consider the exporting of flags other than those related to the ABI, include
paths or libraries as a bug.

Something must be wrong as ...

https://git.rtems.org/rtems-examples/tree/wscript#n36

... adds `-g`. Maybe doing this is not working.

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

Re: Makefile.inc Issues

[Chris Johns]

On 3/12/20 12:42 pm, Chris Johns wrote:
> Something must be wrong as ...
> 
> https://git.rtems.org/rtems-examples/tree/wscript#n36
> 
> ... adds `-g`. Maybe doing this is not working.
> 

Oh sorry this is Makefile.inc. I would add the flags you want ...

CFLAGS += -g

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

Re: [PATCH v2 2/4] samples/unlimited: Prevent compile error

[Sebastian Huber]

On 03/12/2020 02:12, Kinsey Moore wrote:


-#define CONFIGURE_INIT_TASK_STACK_SIZE (8 * 1024)
+#define CONFIGURE_INIT_TASK_STACK_SIZE MAX(8 * 1024, 
CONFIGURE_MINIMUM_TASK_STACK_SIZE)
The 8KiB looks a bit arbitrary. I didn't see anything in the test which 
needs a large stack size. I would remove this option.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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 v2 1/4] zynq-uart: Fix set_attributes implementation

[Sebastian Huber]

On 03/12/2020 02:12, Kinsey Moore wrote:

The zynq-uart set_attributes implementation was configured to always
return false which causes spconsole01 to fail. This restores the
disabled implementation which sets the baud rate registers
appropriately and allows spconsole01 to pass. This also expands the
set_attributes functionality to allow setting of the stop bits,
character width, and parity.
---
  bsps/include/dev/serial/zynq-uart.h   |  5 ++
  bsps/shared/dev/serial/zynq-uart-polled.c |  2 +-
  bsps/shared/dev/serial/zynq-uart.c| 62 +--
  3 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/bsps/include/dev/serial/zynq-uart.h 
b/bsps/include/dev/serial/zynq-uart.h
index 2c0f250a3a..e3e8cae6fd 100644
--- a/bsps/include/dev/serial/zynq-uart.h
+++ b/bsps/include/dev/serial/zynq-uart.h
@@ -78,6 +78,11 @@ void zynq_uart_write_polled(
*/
  void zynq_uart_reset_tx_flush(zynq_uart_context *ctx);
  
+int zynq_cal_baud_rate(uint32_t  baudrate,

+   uint32_t* brgr,
+   uint32_t* bauddiv,
+   uint32_t  modereg);

New coding style?

+
  #ifdef __cplusplus
  }
  #endif /* __cplusplus */
diff --git a/bsps/shared/dev/serial/zynq-uart-polled.c 
b/bsps/shared/dev/serial/zynq-uart-polled.c
index a1b51ea521..442431d502 100644
--- a/bsps/shared/dev/serial/zynq-uart-polled.c
+++ b/bsps/shared/dev/serial/zynq-uart-polled.c
@@ -40,7 +40,7 @@ uint32_t zynq_uart_input_clock(void)
return ZYNQ_CLOCK_UART;
  }
  
-static int zynq_cal_baud_rate(uint32_t  baudrate,

+int zynq_cal_baud_rate(uint32_t  baudrate,
uint32_t* brgr,
uint32_t* bauddiv,
uint32_t  modereg)
diff --git a/bsps/shared/dev/serial/zynq-uart.c 
b/bsps/shared/dev/serial/zynq-uart.c
index 41adb196ab..e2b614c270 100644
--- a/bsps/shared/dev/serial/zynq-uart.c
+++ b/bsps/shared/dev/serial/zynq-uart.c
@@ -142,25 +142,77 @@ static bool zynq_uart_set_attributes(
const struct termios *term
  )
  {
-#if 0
-  volatile zynq_uart *regs = zynq_uart_get_regs(minor);
+  zynq_uart_context *ctx = (zynq_uart_context *) context;
+  volatile zynq_uart *regs = ctx->regs;
uint32_t brgr = 0;
uint32_t bauddiv = 0;
+  uint32_t mode = 0;
int rc;
  
rc = zynq_cal_baud_rate(115200, &brgr, &bauddiv, regs->mode);

if (rc != 0)
  return rc;
  
+  /*

+   * Configure the mode register
+   */
+  mode |= ZYNQ_UART_MODE_CHMODE(ZYNQ_UART_MODE_CHMODE_NORMAL);
+
+  /*
+   * Parity
+   */
+
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE);
+  if (term->c_cflag & PARENB) {
+if (!(term->c_cflag & PARODD))

https://docs.rtems.org/branches/master/eng/coding-conventions.html#language-and-compiler

+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_ODD);
+else
+  mode |= ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_EVEN);

I think we should use { } also for one liner if/else.

+  }
+
+  /*
+   * Character Size
+   */
+
+  if (term->c_cflag & CSIZE) {
+switch (term->c_cflag & CSIZE) {
+  case CS5:
+   return false;


Why not use the default case here?

Indentation level is wrong.

[...]

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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 v2 3/4] Add AArch64 ZynpMP BSP

[Sebastian Huber]

On 03/12/2020 02:12, Kinsey Moore wrote:


This adds a BSP family that runs on the Xilinx Ultrascale+ MPSOC
(ZynqMP) family of chips. It is configured to be usable on the Qemu
ZCU102 machine definition and should be almost trivially portable to
ZynqMP development boards and custom hardware. It is also configured to
be usable with libbsd.

Thanks, looks good.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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 v2 4/4] spec/optconminor: Fix value type

[Sebastian Huber]

On 03/12/2020 02:12, Kinsey Moore wrote:


The option for defining the console minor should be an integer, not a
boolean.

Ok.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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 commit] bsps: Move zynq-uart to bsps/shared

[Sebastian Huber]

On 03/12/2020 01:51, Joel Sherrill wrote:


diff --git a/spec/build/bsps/obj.yml b/spec/build/bsps/obj.yml
index a454783..7ea560b 100644
--- a/spec/build/bsps/obj.yml
+++ b/spec/build/bsps/obj.yml
@@ -52,6 +52,8 @@ install:
source:
- bsps/include/dev/serial/arm-pl011-regs.h
- bsps/include/dev/serial/arm-pl011.h
+  - bsps/include/dev/serial/zynq-uart-regs.h
+  - bsps/include/dev/serial/zynq-uart.h
  - destination: ${BSP_INCLUDEDIR}/rtems/zilog
source:
- bsps/include/rtems/zilog/z8036.h
@@ -94,6 +96,8 @@ source:
  - bsps/shared/dev/serial/ns16550.c
  - bsps/shared/dev/serial/ns16550-context.c
  - bsps/shared/dev/serial/serprobe.c
+- bsps/shared/dev/serial/zynq-uart.c
+- bsps/shared/dev/serial/zynq-uart-polled.c
  - bsps/shared/start/bootcard.c
  - bsps/shared/rtems-version.c
  type: build


I just realized that the Zynq UART is now built for every BSP. This 
causes new warnings:


[  65/1925] Compiling bsps/shared/dev/serial/zynq-uart-polled.c
[  93/1925] Compiling bsps/shared/dev/serial/zynq-uart.c
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp.h:47,
 from ../../../bsps/include/dev/irq/arm-gic-irq.h:26,
 from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:43,
 from ../../../bsps/shared/dev/serial/zynq-uart.c:30:
bsps/include/bspopts.h:11: warning: "ZYNQ_CLOCK_UART" redefined
   11 | #define ZYNQ_CLOCK_UART 5000
  |
In file included from ../../../bsps/shared/dev/serial/zynq-uart.c:28:
../../../bsps/include/dev/serial/zynq-uart.h:64: note: this is the 
location of the previous definition

   64 | #define ZYNQ_CLOCK_UART 1
  |

In file included from ../../../bsps/shared/dev/serial/zynq-uart-polled.c:31:
bsps/include/bspopts.h:11: warning: "ZYNQ_CLOCK_UART" redefined
   11 | #define ZYNQ_CLOCK_UART 5000
  |
In file included from ../../../bsps/shared/dev/serial/zynq-uart-polled.c:28:
../../../bsps/include/dev/serial/zynq-uart.h:64: note: this is the 
location of the previous definition

   64 | #define ZYNQ_CLOCK_UART 1
  |

Please move the Zynq UART into a new build object item, for example 
"spec/build/bsps/objdevserialzynq.yml" and reference it in the grp.yml 
of the BSPs which use it. Remove the:


+#ifndef ZYNQ_CLOCK_UART
+#define ZYNQ_CLOCK_UART 1
+#endif
+

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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