[PATCH 3/6] rtems: From to

[Sebastian Huber]

Move task related declarations and definitions to .
The goal is to make  an include only header file.
---
 cpukit/include/rtems.h | 29 -
 cpukit/include/rtems/rtems/tasks.h | 29 +
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index 763b1e7fc3..b716796fdc 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -56,40 +56,11 @@
 #endif
 
 #include 
-#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
-/**
- * @brief Minimum stack size which every thread must exceed.
- *
- * It is the minimum stack size recommended for use on this processor. This
- * value is selected by the RTEMS developers conservatively to minimize the
- * risk of blown stacks for most user applications. Using this constant when
- * specifying the task stack size, indicates that the stack size will be at
- * least RTEMS_MINIMUM_STACK_SIZE bytes in size. If the user configured minimum
- * stack size is larger than the recommended minimum, then it will be used.
- */
-#define RTEMS_MINIMUM_STACK_SIZE  STACK_MINIMUM_SIZE
-
-/**
- * @brief Specifies that the task should be created with the configured minimum
- * stack size.
- *
- * Using this constant when specifying the task stack size indicates that this
- * task is to be created with a stack size of the minimum stack size that was
- * configured by the application. If not explicitly configured by the
- * application, the default configured minimum stack size is the processor
- * dependent value RTEMS_MINIMUM_STACK_SIZE. Since this uses the configured
- * minimum stack size value, you may get a stack size that is smaller or larger
- * than the recommended minimum. This can be used to provide large stacks for
- * all tasks on complex applications or small stacks on applications that are
- * trying to conserve memory.
- */
-#define RTEMS_CONFIGURED_MINIMUM_STACK_SIZE  0
-
 /**
  * @brief Constant for indefinite wait.
  *
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index aebd3e0f0d..f685c315e3 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -50,6 +51,34 @@ extern "C" {
  */
 #define RTEMS_YIELD_PROCESSOR WATCHDOG_NO_TIMEOUT
 
+/**
+ * @brief Minimum stack size which every thread must exceed.
+ *
+ * It is the minimum stack size recommended for use on this processor. This
+ * value is selected by the RTEMS developers conservatively to minimize the
+ * risk of blown stacks for most user applications. Using this constant when
+ * specifying the task stack size, indicates that the stack size will be at
+ * least RTEMS_MINIMUM_STACK_SIZE bytes in size. If the user configured minimum
+ * stack size is larger than the recommended minimum, then it will be used.
+ */
+#define RTEMS_MINIMUM_STACK_SIZE  STACK_MINIMUM_SIZE
+
+/**
+ * @brief Specifies that the task should be created with the configured minimum
+ * stack size.
+ *
+ * Using this constant when specifying the task stack size indicates that this
+ * task is to be created with a stack size of the minimum stack size that was
+ * configured by the application. If not explicitly configured by the
+ * application, the default configured minimum stack size is the processor
+ * dependent value RTEMS_MINIMUM_STACK_SIZE. Since this uses the configured
+ * minimum stack size value, you may get a stack size that is smaller or larger
+ * than the recommended minimum. This can be used to provide large stacks for
+ * all tasks on complex applications or small stacks on applications that are
+ * trying to conserve memory.
+ */
+#define RTEMS_CONFIGURED_MINIMUM_STACK_SIZE  0
+
 /**
  *  Define the type for an RTEMS API task priority.
  */
-- 
2.26.2

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

[PATCH 2/6] rtems: From to

[Sebastian Huber]

Move object related declarations and definitions to
.  The goal is to make  an include only
header file.
---
 cpukit/include/rtems.h  | 59 -
 cpukit/include/rtems/rtems/object.h | 59 +
 2 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index 6bdca97769..763b1e7fc3 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -62,65 +62,6 @@
 extern "C" {
 #endif
 
-/**
- *  CONSTANTS WHICH MAY BE USED IN OBJECT NAME TO ID SEARCHES
- **/
-
-/**
- * @brief Indicates that a search is across all nodes.
- */
-#define RTEMS_SEARCH_ALL_NODES   OBJECTS_SEARCH_ALL_NODES
-
-/**
- * @brief Indicates that a search is across all nodes except the one the call
- * is made from.
- */
-#define RTEMS_SEARCH_OTHER_NODES OBJECTS_SEARCH_OTHER_NODES
-
-/**
- * @brief Indicates that the search is to be restricted to the local node.
- */
-#define RTEMS_SEARCH_LOCAL_NODE  OBJECTS_SEARCH_LOCAL_NODE
-
-/**
- * @brief Indicates that the caller wants to obtain the name of the currently
- * executing thread.
- *
- * This constant is only meaningful when obtaining the name of a task.
- */
-#define RTEMS_WHO_AM_I   OBJECTS_WHO_AM_I
-
-/**
- *Parameters and return Id's for _Objects_Get_next
- **/
-
-/**
- * @brief Lowest valid index value for the index portion of an object
- * identifier.
- */
-#define RTEMS_OBJECT_ID_INITIAL_INDEXOBJECTS_ID_INITIAL_INDEX
-
-/**
- * @brief Maximum valid index value for the index portion of an object
- * identifier.
- */
-#define RTEMS_OBJECT_ID_FINAL_INDEX  OBJECTS_ID_FINAL_INDEX
-
-/**
- * @brief Returns the identifier of the object with the lowest valid index
- * value.
- *
- * The object is specified by the API @a _api, the object class @a _class and
- * the node @a _node where the object resides.
- */
-#define RTEMS_OBJECT_ID_INITIAL(_api, _class, _node) \
-   OBJECTS_ID_INITIAL(_api, _class, _node)
-
-/**
- * @brief Maximum valid object identifier.
- */
-#define RTEMS_OBJECT_ID_FINALOBJECTS_ID_FINAL
-
 /**
  * @brief Minimum stack size which every thread must exceed.
  *
diff --git a/cpukit/include/rtems/rtems/object.h 
b/cpukit/include/rtems/rtems/object.h
index d6ae058425..8e8bfbf293 100644
--- a/cpukit/include/rtems/rtems/object.h
+++ b/cpukit/include/rtems/rtems/object.h
@@ -367,6 +367,65 @@ RTEMS_INLINE_ROUTINE uint16_t rtems_object_get_local_node( 
void )
   return _Objects_Local_node;
 }
 
+/**
+ *  CONSTANTS WHICH MAY BE USED IN OBJECT NAME TO ID SEARCHES
+ **/
+
+/**
+ * @brief Indicates that a search is across all nodes.
+ */
+#define RTEMS_SEARCH_ALL_NODES   OBJECTS_SEARCH_ALL_NODES
+
+/**
+ * @brief Indicates that a search is across all nodes except the one the call
+ * is made from.
+ */
+#define RTEMS_SEARCH_OTHER_NODES OBJECTS_SEARCH_OTHER_NODES
+
+/**
+ * @brief Indicates that the search is to be restricted to the local node.
+ */
+#define RTEMS_SEARCH_LOCAL_NODE  OBJECTS_SEARCH_LOCAL_NODE
+
+/**
+ * @brief Indicates that the caller wants to obtain the name of the currently
+ * executing thread.
+ *
+ * This constant is only meaningful when obtaining the name of a task.
+ */
+#define RTEMS_WHO_AM_I   OBJECTS_WHO_AM_I
+
+/**
+ *Parameters and return Id's for _Objects_Get_next
+ **/
+
+/**
+ * @brief Lowest valid index value for the index portion of an object
+ * identifier.
+ */
+#define RTEMS_OBJECT_ID_INITIAL_INDEXOBJECTS_ID_INITIAL_INDEX
+
+/**
+ * @brief Maximum valid index value for the index portion of an object
+ * identifier.
+ */
+#define RTEMS_OBJECT_ID_FINAL_INDEX  OBJECTS_ID_FINAL_INDEX
+
+/**
+ * @brief Returns the identifier of the object with the lowest valid index
+ * value.
+ *
+ * The object is specified by the API @a _api, the object class @a _class and
+ * the node @a _node where the object resides.
+ */
+#define RTEMS_OBJECT_ID_INITIAL(_api, _class, _node) \
+   OBJECTS_ID_INITIAL(_api, _class, _node)
+
+/**
+ * @brief Maximum valid object identifier.
+ */
+#define RTEMS_OBJECT_ID_FINALOBJECTS_ID_FINAL
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.26.2

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

[PATCH 6/6] rtems: Generate

[Sebastian Huber]

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

Update #3053.
Update #3899.
Update #3993.
---
 cpukit/include/rtems.h | 100 +++--
 1 file changed, 67 insertions(+), 33 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index dc0472b233..cda2bd5b24 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -1,60 +1,94 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
- * 
+ *
  * @ingroup RTEMSAPIClassic
  *
- * the Public Interface to the RTEMS Classic API
+ * @brief This header file defines the RTEMS Classic API.
  */
 
-/* COPYRIGHT (c) 1989-2008.
- * On-Line Applications Research Corporation (OAR).
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
  *
- * 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.
+ * 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.
  */
 
-#ifndef _RTEMS_H
-#define _RTEMS_H
-
-/**
- * @defgroup RTEMSAPIClassic Classic
+/*
+ * This file was automatically generated.  Do not edit it manually.
+ * Please have a look at
  *
- * @ingroup RTEMSAPI
- * 
- * @brief RTEMS Classic API definitions and modules.
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
+ *
+ * for information how to maintain and re-generate this file.
  */
 
-#include 
-#include 
+#ifndef _RTEMS_H
+#define _RTEMS_H
 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #if defined(RTEMS_MULTIPROCESSING)
-#include 
+  #include 
 #endif
 
-#include 
+#ifdef __cplusplus
+extern "C" {
+#endif
 
+/**
+ * @defgroup RTEMSAPIClassic Classic
+ *
+ * @ingroup RTEMSAPI
+ *
+ * @brief This group contains the Classic API groups.
+ */
+
+#ifdef __cplusplus
+}
 #endif
-/* end of include file */
+
+#endif /* _RTEMS_H */
-- 
2.26.2

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

[PATCH 4/6] rtems: From to

[Sebastian Huber]

Move type related definition to .  The goal is to
make  an include only header file.
---
 cpukit/include/rtems.h | 7 ---
 cpukit/include/rtems/rtems/types.h | 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index b716796fdc..ff0cb69bcf 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -61,13 +61,6 @@
 extern "C" {
 #endif
 
-/**
- * @brief Constant for indefinite wait.
- *
- * This is actually an illegal interval value.
- */
-#define RTEMS_NO_TIMEOUT  ((rtems_interval) WATCHDOG_NO_TIMEOUT)
-
 /**
  * @brief An MPCI must support packets of at least this size.
  */
diff --git a/cpukit/include/rtems/rtems/types.h 
b/cpukit/include/rtems/rtems/types.h
index e5dd1afc3b..5ce3eb6604 100644
--- a/cpukit/include/rtems/rtems/types.h
+++ b/cpukit/include/rtems/rtems/types.h
@@ -85,6 +85,13 @@ typedef CPU_Interrupt_framertems_interrupt_frame;
  */
 typedef Watchdog_Interval rtems_interval;
 
+/**
+ * @brief Constant for indefinite wait.
+ *
+ * This is actually an illegal interval value.
+ */
+#define RTEMS_NO_TIMEOUT  ((rtems_interval) WATCHDOG_NO_TIMEOUT)
+
 /**
  * @brief Data structure to manage and manipulate calendar
  * @ref ClassicRTEMSSecTime "time".
-- 
2.26.2

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

[PATCH 1/6] rtems: Move from to

[Sebastian Huber]

Move configuration related declarations and definitions to
.  The goal is to make  an include only header
file.
---
 cpukit/include/rtems.h   | 16 
 cpukit/include/rtems/config.h| 17 +
 cpukit/sapi/src/getcopyrightnotice.c |  2 +-
 cpukit/sapi/src/getversionstring.c   |  2 +-
 4 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index 4392f08ce8..6bdca97769 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -62,22 +62,6 @@
 extern "C" {
 #endif
 
-/**
- * @brief Returns the pointer to the RTEMS copyright notice.
- */
-const char *rtems_get_copyright_notice(void);
-
-/**
- * @brief Returns the pointer to the RTEMS version string.
- */
-const char *rtems_get_version_string(void);
-
-/**
- * @brief Indicates whether this processor variant has hardware floating point
- * support.
- */
-#define RTEMS_HAS_HARDWARE_FP CPU_HARDWARE_FP
-
 /**
  *  CONSTANTS WHICH MAY BE USED IN OBJECT NAME TO ID SEARCHES
  **/
diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
index e82c7abf11..1fbcf22f2e 100644
--- a/cpukit/include/rtems/config.h
+++ b/cpukit/include/rtems/config.h
@@ -27,6 +27,7 @@
  *  the configuration table.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -164,6 +165,22 @@ uint32_t rtems_configuration_get_maximum_extensions( void 
);
 #define rtems_configuration_get_maximum_processors() \
 (_SMP_Processor_configured_maximum)
 
+/**
+ * @brief Returns the pointer to the RTEMS copyright notice.
+ */
+const char *rtems_get_copyright_notice(void);
+
+/**
+ * @brief Returns the pointer to the RTEMS version string.
+ */
+const char *rtems_get_version_string(void);
+
+/**
+ * @brief Indicates whether this processor variant has hardware floating point
+ * support.
+ */
+#define RTEMS_HAS_HARDWARE_FP CPU_HARDWARE_FP
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/sapi/src/getcopyrightnotice.c 
b/cpukit/sapi/src/getcopyrightnotice.c
index 4e5df66524..cd601254e6 100644
--- a/cpukit/sapi/src/getcopyrightnotice.c
+++ b/cpukit/sapi/src/getcopyrightnotice.c
@@ -39,7 +39,7 @@
 
 #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 
-#include 
+#include 
 #include 
 
 const char *rtems_get_copyright_notice( void )
diff --git a/cpukit/sapi/src/getversionstring.c 
b/cpukit/sapi/src/getversionstring.c
index a036fe2fbf..f8380f7b4f 100644
--- a/cpukit/sapi/src/getversionstring.c
+++ b/cpukit/sapi/src/getversionstring.c
@@ -19,7 +19,7 @@
 #include "config.h"
 #endif
 
-#include 
+#include 
 #include 
 
 const char *rtems_get_version_string(void)
-- 
2.26.2

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

[PATCH 0/6] Make an include only header file

[Sebastian Huber]

This patch set moves all defines and function declarations out of
 to specialized header files.  The last patches replace it with
a generated version and changes the license to BSD-2-Clause.

Sebastian Huber (6):
  rtems: Move from  to 
  rtems: From  to 
  rtems: From  to 
  rtems: From  to 
  rtems: From  to 
  rtems: Generate 

 cpukit/include/rtems.h   | 216 +++
 cpukit/include/rtems/config.h|  17 +++
 cpukit/include/rtems/rtems/mp.h  |  16 ++
 cpukit/include/rtems/rtems/object.h  |  59 
 cpukit/include/rtems/rtems/tasks.h   |  29 
 cpukit/include/rtems/rtems/types.h   |   7 +
 cpukit/sapi/src/getcopyrightnotice.c |   2 +-
 cpukit/sapi/src/getversionstring.c   |   2 +-
 8 files changed, 187 insertions(+), 161 deletions(-)

-- 
2.26.2

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

[PATCH 5/6] rtems: From to

[Sebastian Huber]

Move multiprocessing related definitions to .  This
makes  an include only header file.
---
 cpukit/include/rtems.h  | 25 -
 cpukit/include/rtems/rtems/mp.h | 16 
 2 files changed, 16 insertions(+), 25 deletions(-)

diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index ff0cb69bcf..dc0472b233 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -24,7 +24,6 @@
  * 
  * @brief RTEMS Classic API definitions and modules.
  */
-/** @{ */
 
 #include 
 #include 
@@ -57,29 +56,5 @@
 
 #include 
 
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/**
- * @brief An MPCI must support packets of at least this size.
- */
-#define RTEMS_MINIMUM_PACKET_SIZE  MP_PACKET_MINIMUM_PACKET_SIZE
-
-/**
- * @brief Defines the count of @c uint32_t numbers in a packet which must be
- * converted to native format in a heterogeneous system.
- *
- * In packets longer than this value, some of the extra data may be a user
- * message buffer which is not automatically endian swapped.
- */
-#define RTEMS_MINIMUN_HETERO_CONVERSION  MP_PACKET_MINIMUN_HETERO_CONVERSION
-
-#ifdef __cplusplus
-}
-#endif
-
-/** @} */
-
 #endif
 /* end of include file */
diff --git a/cpukit/include/rtems/rtems/mp.h b/cpukit/include/rtems/rtems/mp.h
index a3de1e6682..0ddeaf7d53 100644
--- a/cpukit/include/rtems/rtems/mp.h
+++ b/cpukit/include/rtems/rtems/mp.h
@@ -18,6 +18,8 @@
 #ifndef _RTEMS_RTEMS_MP_H
 #define _RTEMS_RTEMS_MP_H
 
+#include 
+
 /**
  *  @defgroup ClassicMP Multiprocessing
  *
@@ -32,6 +34,20 @@
 extern "C" {
 #endif
 
+/**
+ * @brief An MPCI must support packets of at least this size.
+ */
+#define RTEMS_MINIMUM_PACKET_SIZE  MP_PACKET_MINIMUM_PACKET_SIZE
+
+/**
+ * @brief Defines the count of @c uint32_t numbers in a packet which must be
+ * converted to native format in a heterogeneous system.
+ *
+ * In packets longer than this value, some of the extra data may be a user
+ * message buffer which is not automatically endian swapped.
+ */
+#define RTEMS_MINIMUN_HETERO_CONVERSION  MP_PACKET_MINIMUN_HETERO_CONVERSION
+
 /**
  *  @brief RTEMS Multiprocessing Announce
  *
-- 
2.26.2

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

Re: [PATCH rtems-libbsd 1/3] Add helper script to find licenses.

[Chris Johns]

On 18/9/20 4:39 pm, Christian Mauderer wrote:
> You mentioned that libbsd.py should be taught to
> handle licenses. Do you plan anything into that direction? In that case
> touching the script wouldn't be really useful.

Yes it is on my list.

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

Re: [PATCH] gitignore: ignore top-level ini files

[Chris Johns]

On 18/9/20 2:46 pm, Sebastian Huber wrote:
> On 17/09/2020 20:55, Gedare Bloom wrote:
> 
>> ping: decision needed--should we git-ignore .ini everywhere, .ini in
>> top-level, or just the default config.ini in top-level?
> I tend to ignore the top-level *.ini files.

Then maybe git should also do this. It would stop someone accidental adding one.

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

Re: [PATCH] gitignore: ignore top-level ini files

[Sebastian Huber]

On 18/09/2020 09:42, Chris Johns wrote:


On 18/9/20 2:46 pm, Sebastian Huber wrote:

On 17/09/2020 20:55, Gedare Bloom wrote:


ping: decision needed--should we git-ignore .ini everywhere, .ini in
top-level, or just the default config.ini in top-level?

I tend to ignore the top-level *.ini files.

Then maybe git should also do this. It would stop someone accidental adding one.

Yes, I am fine with Gedare's patch as it is.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/3] grlib: Some clean ups

[Sebastian Huber]

Sebastian Huber (3):
  grlib: Remove superfluous forward decls
  grlib: Remove unused conversion macros
  grlib: Add ambapp_common_info to derived types

 bsps/include/grlib/ambapp.h   | 48 ++-
 bsps/shared/grlib/amba/ambapp.c   | 14 
 bsps/shared/grlib/amba/ambapp_freq.c  |  2 +-
 bsps/shared/grlib/ascs/grascs.c   |  2 +-
 bsps/shared/grlib/can/satcan.c|  2 +-
 bsps/shared/grlib/drvmgr/ambapp_bus.c | 20 +--
 bsps/shared/grlib/pci/grpci.c |  2 +-
 bsps/shared/grlib/pci/grpci2.c|  4 +--
 bsps/shared/grlib/pci/pcif.c  |  2 +-
 bsps/shared/grlib/slink/grslink.c |  2 +-
 bsps/shared/grlib/spw/grspw_pkt.c |  2 +-
 bsps/shared/grlib/stat/l4stat.c   |  2 +-
 bsps/sparc/leon3/console/console.c|  2 +-
 bsps/sparc/leon3/net/leon_open_eth.c  |  2 +-
 14 files changed, 46 insertions(+), 60 deletions(-)

-- 
2.26.2

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

[PATCH 1/3] grlib: Remove superfluous forward decls

[Sebastian Huber]

---
 bsps/include/grlib/ambapp.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/bsps/include/grlib/ambapp.h b/bsps/include/grlib/ambapp.h
index 6b617ada70..2ad66713e0 100644
--- a/bsps/include/grlib/ambapp.h
+++ b/bsps/include/grlib/ambapp.h
@@ -35,11 +35,6 @@ extern "C" {
 /* Max supported AHB buses */
 #define AHB_BUS_MAX 6
 
-struct ambapp_dev;
-struct ambapp_core;
-struct ambapp_apb_info;
-struct ambapp_ahb_info;
-
 struct ambapp_dev {
struct ambapp_dev *next;/* Next */
struct ambapp_dev *prev;/* Previous Device. If (this == 
-- 
2.26.2

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

[PATCH 3/3] grlib: Add ambapp_common_info to derived types

[Sebastian Huber]

This avoids a cast in DEV_TO_COMMON().
---
 bsps/include/grlib/ambapp.h   | 38 ---
 bsps/shared/grlib/amba/ambapp.c   | 14 +-
 bsps/shared/grlib/amba/ambapp_freq.c  |  2 +-
 bsps/shared/grlib/ascs/grascs.c   |  2 +-
 bsps/shared/grlib/can/satcan.c|  2 +-
 bsps/shared/grlib/drvmgr/ambapp_bus.c | 20 +++---
 bsps/shared/grlib/pci/grpci.c |  2 +-
 bsps/shared/grlib/pci/grpci2.c|  4 +--
 bsps/shared/grlib/pci/pcif.c  |  2 +-
 bsps/shared/grlib/slink/grslink.c |  2 +-
 bsps/shared/grlib/spw/grspw_pkt.c |  2 +-
 bsps/shared/grlib/stat/l4stat.c   |  2 +-
 bsps/sparc/leon3/console/console.c|  2 +-
 bsps/sparc/leon3/net/leon_open_eth.c  |  2 +-
 14 files changed, 46 insertions(+), 50 deletions(-)

diff --git a/bsps/include/grlib/ambapp.h b/bsps/include/grlib/ambapp.h
index 9202669ec0..3c3d3e9e3e 100644
--- a/bsps/include/grlib/ambapp.h
+++ b/bsps/include/grlib/ambapp.h
@@ -35,18 +35,6 @@ extern "C" {
 /* Max supported AHB buses */
 #define AHB_BUS_MAX 6
 
-struct ambapp_dev {
-   struct ambapp_dev *next;/* Next */
-   struct ambapp_dev *prev;/* Previous Device. If (this == 
-* rev->child) prev is bus bridge */
-   struct ambapp_dev *children;/* Points to first device on sub-bus */
-   void *owner;/* Owner of this AMBA device */
-   unsigned char dev_type; /* AHB MST, AHB SLV or APB SLV*/
-   unsigned char vendor;   /* Vendor ID */
-   unsigned short device;  /* Device ID */
-   int devinfo[0]; /* Device info (APB/AHB dep. on type) */
-};
-
 #define AMBAPP_FLAG_FFACT_DIR  0x100   /* Frequency factor direction, 0=down, 
1=up */
 #define AMBAPP_FLAG_FFACT  0x0f0   /* Frequency factor against top bus */
 #define AMBAPP_FLAG_MBUS   0x00c
@@ -55,7 +43,7 @@ struct ambapp_dev {
 /* Get APB or AHB information from a AMBA device */
 #define DEV_TO_APB(adev) ((struct ambapp_apb_info *)((adev)->devinfo))
 #define DEV_TO_AHB(adev) ((struct ambapp_ahb_info *)((adev)->devinfo))
-#define DEV_TO_COMMON(adev) ((struct ambapp_common_info *)((adev)->devinfo))
+#define DEV_TO_COMMON(adev) (((adev)->devinfo))
 
 struct ambapp_common_info {
unsigned char irq;
@@ -64,10 +52,7 @@ struct ambapp_common_info {
 };
 
 struct ambapp_apb_info {
-   /* COMMON */
-   unsigned char irq;
-   unsigned char ver;
-   unsigned char ahbidx;   /* AHB Bus Index */
+   struct ambapp_common_info common;
 
/* APB SPECIFIC */
unsigned int start;
@@ -75,10 +60,7 @@ struct ambapp_apb_info {
 };
 
 struct ambapp_ahb_info {
-   /* COMMON */
-   unsigned char irq;
-   unsigned char ver;
-   unsigned char ahbidx;   /* AHB Bus Index */
+   struct ambapp_common_info common;
 
/* AHB SPECIFIC */
unsigned int start[4];
@@ -88,6 +70,20 @@ struct ambapp_ahb_info {
unsigned int custom[3];
 };
 
+struct ambapp_dev {
+   struct ambapp_dev *next;/* Next */
+   struct ambapp_dev *prev;/* Previous Device. If (this ==
+* rev->child) prev is bus bridge */
+   struct ambapp_dev *children;/* Points to first device on sub-bus */
+   void *owner;/* Owner of this AMBA device */
+   unsigned char dev_type; /* AHB MST, AHB SLV or APB SLV*/
+   unsigned char vendor;   /* Vendor ID */
+   unsigned short device;  /* Device ID */
+
+   /* Device info (APB/AHB dep. on type) */
+   struct ambapp_common_info devinfo[0];
+};
+
 /* Describes a complete AMBA Core. Each device may consist of 3 interfaces */
 struct ambapp_core {
charirq;/* irq=-1 indicate no IRQ */
diff --git a/bsps/shared/grlib/amba/ambapp.c b/bsps/shared/grlib/amba/ambapp.c
index 69018f47e7..e87c86a586 100644
--- a/bsps/shared/grlib/amba/ambapp.c
+++ b/bsps/shared/grlib/amba/ambapp.c
@@ -71,9 +71,9 @@ static void ambapp_ahb_dev_init(
   dev->vendor = ambapp_pnp_vendor(ahb->id);
   dev->device = ambapp_pnp_device(ahb->id);
   ahb_info = DEV_TO_AHB(dev);
-  ahb_info->ver = ambapp_pnp_ver(ahb->id);
-  ahb_info->irq = ambapp_pnp_irq(ahb->id);
-  ahb_info->ahbidx = ahbidx;
+  ahb_info->common.ver = ambapp_pnp_ver(ahb->id);
+  ahb_info->common.irq = ambapp_pnp_irq(ahb->id);
+  ahb_info->common.ahbidx = ahbidx;
   ahb_info->custom[0] = (unsigned int)ahb->custom[0];
   ahb_info->custom[1] = (unsigned int)ahb->custom[1];
   ahb_info->custom[2] = (unsigned int)ahb->custom[2];
@@ -116,9 +116,9 @@ static void ambapp_apb_dev_init(
   dev->vendor = ambapp_pnp_vendor(apb->id);
   dev->device = ambapp_pnp_device(apb->id);
   apb_info = DEV_TO_APB(dev);
-  apb_info->ver = ambapp_pnp_ver(apb->id);
-  apb_info->irq = ambapp_pnp_irq(apb->id);
-  apb_info->ahbidx = ahbidx;
+  apb_info->common.ver = ambapp_pnp_ver(apb->id);
+  ap

[PATCH 2/3] grlib: Remove unused conversion macros

[Sebastian Huber]

---
 bsps/include/grlib/ambapp.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/bsps/include/grlib/ambapp.h b/bsps/include/grlib/ambapp.h
index 2ad66713e0..9202669ec0 100644
--- a/bsps/include/grlib/ambapp.h
+++ b/bsps/include/grlib/ambapp.h
@@ -56,11 +56,6 @@ struct ambapp_dev {
 #define DEV_TO_APB(adev) ((struct ambapp_apb_info *)((adev)->devinfo))
 #define DEV_TO_AHB(adev) ((struct ambapp_ahb_info *)((adev)->devinfo))
 #define DEV_TO_COMMON(adev) ((struct ambapp_common_info *)((adev)->devinfo))
-/* Convert address of ambapp_apb_info/ambapp_ahb_info into ambapp_dev */
-#define APB_TO_DEV(apb_info) ((struct ambapp_dev *)(unsigned int(apb_info) - \
-   offsetof(struct ambapp_dev, devinfo)))
-#define AHB_TO_DEV(ahb_info) ((struct ambapp_dev *)(unsigned int(ahb_info) - \
-   offsetof(struct ambapp_dev, devinfo)))
 
 struct ambapp_common_info {
unsigned char irq;
-- 
2.26.2

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

Re: [PATCH 00/26] leon: various fixes and TN0018 errata workaround

[Sebastian Huber]

Hallo Daniel,

what are your plans with respect to this patch set?

Please also have a look at:

https://lists.rtems.org/pipermail/devel/2020-September/062176.html

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

RE: legacy stack or libbsd

[Gabriel.Moyano]

Hi Chris,

>I will get back around to it. There are 2 sets of changes. In PTP itself a
>change is to add kqueue support because select in libbsd does not support
>signals. The PTP code runs a number of timers and they run of an alarm signal.
>The other piece of support is to the score to bring in the FreeBSD kern_ntp
>support to sit besides the timercounters.

May I ask what are the necessary tasks to get kern_ntp support? We are also 
interested on getting running PTP on RTEMS.

Best regards,
Gabriel


--
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
Institute for Software Technology | SC-OSS | Lilienthalplatz 7 | 38108 
Braunschweig  | Germany

Gabriel Moyano | Research Scientist in Onboard Software Systems group
gabriel.moy...@dlr.de
DLR.de



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

Re: [PATCH] gitignore: ignore top-level ini files

[Gedare Bloom]

On Fri, Sep 18, 2020 at 1:43 AM Sebastian Huber
 wrote:
>
> On 18/09/2020 09:42, Chris Johns wrote:
>
> > On 18/9/20 2:46 pm, Sebastian Huber wrote:
> >> On 17/09/2020 20:55, Gedare Bloom wrote:
> >>
> >>> ping: decision needed--should we git-ignore .ini everywhere, .ini in
> >>> top-level, or just the default config.ini in top-level?
> >> I tend to ignore the top-level *.ini files.
> > Then maybe git should also do this. It would stop someone accidental adding 
> > one.
> Yes, I am fine with Gedare's patch as it is.

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

Re: [PATCH] score: Improve Scheduler Handler documentation

[Gedare Bloom]

Thanks, just a couple minor nits.

On Fri, Sep 18, 2020 at 12:38 AM Sebastian Huber
 wrote:
>
> ---
>  cpukit/include/rtems/score/scheduler.h | 23 -
>  cpukit/include/rtems/score/schedulerimpl.h | 29 +-
>  2 files changed, 38 insertions(+), 14 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/scheduler.h 
> b/cpukit/include/rtems/score/scheduler.h
> index 9a6515ba1e..4b9936d756 100644
> --- a/cpukit/include/rtems/score/scheduler.h
> +++ b/cpukit/include/rtems/score/scheduler.h
> @@ -30,12 +30,7 @@ extern "C" {
>  struct Per_CPU_Control;
>
>  /**
> - * @defgroup RTEMSScoreScheduler Scheduler Handler
> - *
> - * @ingroup RTEMSScore
> - *
> - * This handler encapsulates functionality related to managing sets of 
> threads
> - * that are ready for execution.
> + * @addtogroup RTEMSScoreScheduler
>   *
>   * @{
>   */
> @@ -300,22 +295,24 @@ struct _Scheduler_Control {
>  };
>
>  /**
> - * @brief Registered schedulers.
> + * @brief This table contains the configured schedulers.
>   *
> - * Application provided via .
> + * The table is defined by  through the
> + * #CONFIGURE_SCHEDULER_TABLE_ENTRIES application configuration option.
>   *
>   * @see _Scheduler_Count.
>   */
>  extern const Scheduler_Control _Scheduler_Table[];
>
>  /**
> - * @brief Count of registered schedulers.
> + * @brief This constant contains the count of configured schedulers.
>   *
> - * Application provided via  on SMP configurations.
> + * In SMP configurations, the constant is defined by  
> through
> + * the count of entries of the #CONFIGURE_SCHEDULER_TABLE_ENTRIES application
> + * configuration option.
>   *
> - * It is very important that this is a compile-time constant on uni-processor
> - * configurations (in this case RTEMS_SMP is not defined) so that the 
> compiler
> - * can optimize the some loops away
> + * In uniprocessor configurations, this is a compile time constant set to 
> one.
> + * This is important so that the compiler can optimize the some loops away
s/the some/some
add a period at end.

Not introduced by you, but good to fix.

>   *
>   * @see _Scheduler_Table.
>   */
> diff --git a/cpukit/include/rtems/score/schedulerimpl.h 
> b/cpukit/include/rtems/score/schedulerimpl.h
> index e7fbb8b166..f37d9ecdc8 100644
> --- a/cpukit/include/rtems/score/schedulerimpl.h
> +++ b/cpukit/include/rtems/score/schedulerimpl.h
> @@ -34,7 +34,34 @@ extern "C" {
>  #endif
>
>  /**
> - * @addtogroup RTEMSScoreScheduler
> + * @defgroup RTEMSScoreScheduler Scheduler Handler
> + *
> + * @ingroup RTEMSScore
> + *
> + * @brief This handler encapsulates functionality related to managing sets of
> + *   threads that are ready for execution.
> + *
> + * Schedulers are used by the system to manage sets of threads that are ready
> + * for execution.  A scheduler consists of
> + *
> + * * a scheduler algorithm implementation,
> + *
> + * * a scheduler index and an associated name, and
> + *
> + * * a set of processors own by the scheduler (may be empty, but never 
> overlaps
s/own/owned

> + *   with a set owned by another scheduler).
> + *
> + * Each thread uses exactly one scheduler as its home scheduler.  Threads may
> + * temporarily use also other scheduler due to actions of locking protocols.
s/also other/another

> + *
> + * All properties of a scheduler can be configured and controlled by the 
> user.
> + * Some properties are fixed at link time (defined by application 
> configuration
> + * options), other properties can be changed at runtime through directive
> + * calls.
> + *
> + * The scheduler index, name, and initial processor set are defined for a
> + * particular application by the application configuration.  The schedulers 
> are
> + * registered in the ::_Scheduler_Table which has ::_Scheduler_Count entries.
>   *
>   * @{
>   */
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/6] Make an include only header file

[Gedare Bloom]

The set looks fine to me. The only thing I noticed is that config.h is
a weird place for the copyright notice and version string
declarations, but I don't know of anything better than that.

On Fri, Sep 18, 2020 at 1:35 AM Sebastian Huber
 wrote:
>
> This patch set moves all defines and function declarations out of
>  to specialized header files.  The last patches replace it with
> a generated version and changes the license to BSD-2-Clause.
>
> Sebastian Huber (6):
>   rtems: Move from  to 
>   rtems: From  to 
>   rtems: From  to 
>   rtems: From  to 
>   rtems: From  to 
>   rtems: Generate 
>
>  cpukit/include/rtems.h   | 216 +++
>  cpukit/include/rtems/config.h|  17 +++
>  cpukit/include/rtems/rtems/mp.h  |  16 ++
>  cpukit/include/rtems/rtems/object.h  |  59 
>  cpukit/include/rtems/rtems/tasks.h   |  29 
>  cpukit/include/rtems/rtems/types.h   |   7 +
>  cpukit/sapi/src/getcopyrightnotice.c |   2 +-
>  cpukit/sapi/src/getversionstring.c   |   2 +-
>  8 files changed, 187 insertions(+), 161 deletions(-)
>
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/6] Make an include only header file

[Joel Sherrill]

On Fri, Sep 18, 2020 at 11:02 AM Gedare Bloom  wrote:

> The set looks fine to me. The only thing I noticed is that config.h is
> a weird place for the copyright notice and version string
> declarations, but I don't know of anything better than that.
>

Agree this all looks OK. I am sure we have other things that don't have
an obvious home.

>
> On Fri, Sep 18, 2020 at 1:35 AM Sebastian Huber
>  wrote:
> >
> > This patch set moves all defines and function declarations out of
> >  to specialized header files.  The last patches replace it with
> > a generated version and changes the license to BSD-2-Clause.
> >
> > Sebastian Huber (6):
> >   rtems: Move from  to 
> >   rtems: From  to 
> >   rtems: From  to 
> >   rtems: From  to 
> >   rtems: From  to 
> >   rtems: Generate 
> >
> >  cpukit/include/rtems.h   | 216 +++
> >  cpukit/include/rtems/config.h|  17 +++
> >  cpukit/include/rtems/rtems/mp.h  |  16 ++
> >  cpukit/include/rtems/rtems/object.h  |  59 
> >  cpukit/include/rtems/rtems/tasks.h   |  29 
> >  cpukit/include/rtems/rtems/types.h   |   7 +
> >  cpukit/sapi/src/getcopyrightnotice.c |   2 +-
> >  cpukit/sapi/src/getversionstring.c   |   2 +-
> >  8 files changed, 187 insertions(+), 161 deletions(-)
> >
> > --
> > 2.26.2
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Flight Software Workshop (Feb 2021 - Virtual)

[Joel Sherrill]

  Hi

Passing this along to the RTEMS Community. Hopefully some of you will
submit presentations. This is a very interesting workshop and always
includes presentations on some cool RTEMS projects.

--joel


Dear Flight Software Workshop Community,
The Johns Hopkins University Applied Physics Laboratory, in conjunction
with NASA Jet Propulsion Laboratory, NASA Goddard Space Flight Center, The
Aerospace Corporation, and Southwest Research Institute, is hosting
the 13th Workshop
on Spacecraft Flight Software (FSW-2021). While we had hoped to hold a
great in-person event, out of consideration for the health and well-being
of our community, this workshop will be hosted virtually Monday, February 8
th to Thursday, February 11th 2021.

The Flight Software Workshop is a presentation-only (i.e., no papers)
conference that draws top engineers from leading aerospace organizations
from around the world to present on current and next generation flight
architectures, software development and verification techniques, challenges
and solutions.

This year, we are opening up the themes decision to the community and
asking you to let us know which topics you are most interested in or would
like to see. Themes help tailor the call for abstracts, hone the selection
process, and make the year's Workshop one of a kind. Help us by
recommending the 2021 Workshop themes via our questionnaire:
FSW Workshop 2021 | Themes Questionnaire

As a result of not needing a venue and not having other costs associated
with an in-person workshop, this year’s Flight Software Workshop will be
FREE for attendees and presenters!

Here are some important dates along with the official Workshop website to
get more information:
Workshop Website: http://flightsoftware.org


Registration Opens: October 1st, 2020
First Call for Abstracts: October 1st, 2020
Abstract Submission Deadline: January 1st, 2021
Abstract Acceptance Notification:  January 15th, 2021
Presentation Submission Deadline: February 1st, 2021
Virtual Workshop: February 8th-11th 2021
Mark your calendars and please consider presenting!

Thanks, and we’re looking forward to another great Flight Software
Workshop.
Chris Monaco, JHU/APL
Flight Software Workshop Organizing Committee
http://flightsoftware.org

i...@flightsoftware.org
Flight Software

Workshop Website

Contact Us! 
FSW-21 Themes Questionnaire

Flight Software Workshop | 11101 Johns Hopkins Road, Embedded Flight
Software Group, Space Department, Laurel, MD 20723
Unsubscribe joel.sherr...@oarcorp.com

Update Profile

libbsd master broken for pc686 BSP

[Karel Gardas]

Hello,

I've just tried to build libbsd master branch against the pc686 BSP
build from rtems master and this still does not fly and fails with:

/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
./libbsd.a(uipc_mbuf.c.25.o): in function `m_unmappedtouio':
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1813:
undefined reference to `PHYS_TO_VM_PAGE'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1814:
undefined reference to `uiomove_fromphys'
collect2: error: ld returned 1 exit status

/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
./libbsd.a(uipc_mbuf.c.25.o): in function `m_unmappedtouio':
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1813:
undefined reference to `PHYS_TO_VM_PAGE'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1814:
undefined reference to `uiomove_fromphys'
collect2: error: ld returned 1 exit status

/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
testsuite/arphole/test_main.c.54.o:/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../rtemsbsd/include/bsp/nexus-devices.h:165:
undefined reference to `_bsd_lem_pcimodule_sys_init'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
./libbsd.a(uipc_mbuf.c.25.o): in function `m_unmappedtouio':
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1813:
undefined reference to `PHYS_TO_VM_PAGE'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1814:
undefined reference to `uiomove_fromphys'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
./libbsd.a(iflib.c.25.o): in function `iflib_pseudo_register':
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/net/iflib.c:4857:
undefined reference to `IFDI_CLONEATTACH'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/net/iflib.c:4983:
undefined reference to `IFDI_RX_CLSET'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
./libbsd.a(iflib.c.25.o):(.rodata+0x190): undefined reference to
`noop_attach'
/export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
./libbsd.a(iflib.c.25.o):(.rodata+0x198): undefined reference to
`iflib_pseudo_detach'
collect2: error: ld returned 1 exit status


Any help or fix for this highly appreciated!

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

Re: How to use lvgl on pc386 BSP.

[Karel Gardas]

Hello Christian,

On 9/7/20 6:22 PM, Christian Mauderer wrote:
> Depending on your application, you might want to think about switching
> to the current master instead of the release. But note that I didn't
> compile the PC BSP there. So I'm not sure how well it works. i386 is
> normally not a platform that I use for RTEMS applications.

I've found some time to experiment more with fb on pc686 using
libbsd/littlevgl/example combo -- all projects with master branch
checkout as of today.

It looks like the reason why the demo was not working for me last time
was that framebuffer device can't be open. I've digged more and the
reason is that the device is missing due to example missing #define
CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER in its code.

The reason BBB was/is working is that it's using fb driver from libbsd,
but pc686 is using fb driver directly from BSP hence app needs to show
interest in using it this way I guess.

So after small fix, I've been (app was) able to open fb0, but then
output shows very strange values for x and y of screen. This was due to
fact that lvgl is using libbsd fb API by default, but pc686 provides
minimalistic linux API. So I've switched to linux with small patch to
lvgl and then found out that lvgl is using more rich linux API than
implemented by the pc686 VBE fb driver. So yet another patch to pc686 to
make lvgl compilable and I was able to get real values from the
fbdev_init lvgl function. Unfortunately function fails on me with error
that mmap of framebuffer is not suported.

Whole demo output looks:

i386: isr=0 irr=1
i386: isr=0 irr=1
FB_VESA_RM frame buffer -- driver initializing..


RTEMS LVGL HELLO WORLD

nexus0: 
pcib0 pcibus 0
pci0:  on pcib0
pci0:  at device 0.0 (no driver attached)
pci0:  at device 1.0 (no driver attached)
pci0:  at device 1.1 (no driver attached)
pci0:  at device 1.3 (no driver attached)
pci0:  at device 2.0 (no driver attached)
pci0:  at device 3.0 (no driver attached)
cpu0
FB_VESA_RM open device
The framebuffer device was opened successfully.
FB_VESA_RM ioctl called, cmd=4602
fbxres 1024, fbyres 768
fbbpp 32
FB_VESA_RM ioctl called, cmd=4600
fbxres 1024, fbyres 768
fbbpp 32
1024x768, 32bpp
3145728 screen size.
Error: failed to map framebuffer device to memory: Not supported


All patches required to get here are attached for your reference.

Any idea why mmaping RTEMS /dev/fb0 fails is highly appreciated.

Thanks,
Karel
diff --git a/lvgl/gui/test.c b/lvgl/gui/test.c
index 7ff263e..8eff5ee 100644
--- a/lvgl/gui/test.c
+++ b/lvgl/gui/test.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -251,8 +251,8 @@ SYSINIT_DRIVER_REFERENCE(ums, uhub);
 
 #define CONFIGURE_SHELL_USER_COMMANDS \
   &bsp_interrupt_shell_command, \
-  &rtems_shell_ARP_Command, \
-  &rtems_shell_I2C_Command
+  &rtems_shell_ARP_Command /* , \
+  &rtems_shell_I2C_Command */
 
 #define CONFIGURE_SHELL_COMMANDS_ALL
 
diff --git a/lvgl/gui/wscript b/lvgl/gui/wscript
index 5474181..2f8c6a5 100644
--- a/lvgl/gui/wscript
+++ b/lvgl/gui/wscript
@@ -25,4 +25,4 @@ def build(bld):
 target = 'lvgl_gui.exe',
 source = ['test.c'],
 includes = include_paths,
-lib = ['m', 'lvgl', 'bsd'])
+lib = ['m', 'lvgl', 'bsd', 'z'])
diff --git a/lvgl/hello/test.c b/lvgl/hello/test.c
index d6948b3..9bf3312 100644
--- a/lvgl/hello/test.c
+++ b/lvgl/hello/test.c
@@ -16,7 +16,7 @@
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  * ARE DISCLAIMED.	IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODSb
  * 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
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -67,6 +67,9 @@ Init(rtems_task_argument arg)
 	sc = rtems_bsd_initialize();
 	assert(sc == RTEMS_SUCCESSFUL);
 
+/*sc = frame_buffer_initialize(0, 0, NULL);
+assert(sc == RTEMS_SUCCESSFUL);
+*/
 	lv_init();
 
 	fbdev_init();
@@ -107,6 +110,7 @@ Init(rtems_task_argument arg)
  */
 #define CONFIGURE_MICROSECONDS_PER_TICK 1000
 
+#define CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
@@ -146,8 +150,8 @@ Init(rtems_task_argument arg)
 
 #define CONFIGURE_SHELL_USER_COMMANDS \
   &bsp_interrupt_shell_command, \
-  &rtems_shell_ARP_Command, \
-  &rtems_shell_I2C_Command
+  &rtems_shell_ARP_Command /* , \
+  &rtems_shell_I2C_Command */
 
 #define CO

Re: libbsd master broken for pc686 BSP

[Joel Sherrill]

If you really meant the master, try 6-freebsd12 instead.

Branch names are complicated in libbsd because they need to reflect RTEMS
and FreeBSD version.

I'm not really sure how to make this any less confusing. :(

--joel

On Fri, Sep 18, 2020 at 3:01 PM Karel Gardas 
wrote:

>
> Hello,
>
> I've just tried to build libbsd master branch against the pc686 BSP
> build from rtems master and this still does not fly and fails with:
>
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(uipc_mbuf.c.25.o): in function `m_unmappedtouio':
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1813:
> undefined reference to `PHYS_TO_VM_PAGE'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1814:
> undefined reference to `uiomove_fromphys'
> collect2: error: ld returned 1 exit status
>
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(uipc_mbuf.c.25.o): in function `m_unmappedtouio':
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1813:
> undefined reference to `PHYS_TO_VM_PAGE'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1814:
> undefined reference to `uiomove_fromphys'
> collect2: error: ld returned 1 exit status
>
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
>
> testsuite/arphole/test_main.c.54.o:/export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../rtemsbsd/include/bsp/nexus-devices.h:165:
> undefined reference to `_bsd_lem_pcimodule_sys_init'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(uipc_mbuf.c.25.o): in function `m_unmappedtouio':
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1813:
> undefined reference to `PHYS_TO_VM_PAGE'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/kern/uipc_mbuf.c:1814:
> undefined reference to `uiomove_fromphys'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(iflib.c.25.o): in function `iflib_pseudo_register':
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/net/iflib.c:4857:
> undefined reference to `IFDI_CLONEATTACH'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
>
> /export/home/karel/git/rtems/rtems-libbsd/build/i386-rtems6-pc686-everything/../../freebsd/sys/net/iflib.c:4983:
> undefined reference to `IFDI_RX_CLSET'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(iflib.c.25.o):(.rodata+0x190): undefined reference to
> `noop_attach'
>
> /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(iflib.c.25.o):(.rodata+0x198): undefined reference to
> `iflib_pseudo_detach'
> collect2: error: ld returned 1 exit status
>
>
> Any help or fix for this highly appreciated!
>
> Thanks,
> Karel
> ___
> 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: libbsd master broken for pc686 BSP

[Karel Gardas]

On 9/19/20 12:15 AM, Joel Sherrill wrote:
> If you really meant the master, try 6-freebsd12 instead. 
> 

Not sure, but Christian in a thread 'How to use lvgl on pc386 BSP'
analysed my report about missing input.h IIRC and concluded that I need
to use master, so hence I'm here on master.

> Branch names are complicated in libbsd because they need to reflect
> RTEMS and FreeBSD version.

That's fine. Besides this I've been able to temporarily worked around
this compilation failure -- see my reply to 'How to use lvgl on pc386
BSP', all patches including libbsd "fix" are there.

Thanks!
Karel

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

Re: How to use lvgl on pc386 BSP.

[Karel Gardas]

On 9/18/20 11:51 PM, Karel Gardas wrote:
> Whole demo output looks:
> 
> i386: isr=0 irr=1
> i386: isr=0 irr=1
> FB_VESA_RM frame buffer -- driver initializing..
> 
> 
> RTEMS LVGL HELLO WORLD
> 
> nexus0: 
> pcib0 pcibus 0
> pci0:  on pcib0
> pci0:  at device 0.0 (no driver attached)
> pci0:  at device 1.0 (no driver attached)
> pci0:  at device 1.1 (no driver attached)
> pci0:  at device 1.3 (no driver attached)
> pci0:  at device 2.0 (no driver attached)
> pci0:  at device 3.0 (no driver attached)
> cpu0
> FB_VESA_RM open device
> The framebuffer device was opened successfully.
> FB_VESA_RM ioctl called, cmd=4602
> fbxres 1024, fbyres 768
> fbbpp 32
> FB_VESA_RM ioctl called, cmd=4600
> fbxres 1024, fbyres 768
> fbbpp 32
> 1024x768, 32bpp
> 3145728 screen size.
> Error: failed to map framebuffer device to memory: Not supported
> 
>

^ that was form Qemu, from my testing hw box it looks as follows. Sorry
for the dead Reaktek. Also it looks like VBE bios is kind of limited
since EDID recommended resolution is monitors native: 2560x1440, but
BIOS does not support it hence offers 1920x1440 as most close.

i386: isr=0 irr=1
FB_VESA_RM frame buffer -- driver initializing..

RTEMS LVGL HELLO WORLD

nexus0: 
pcib0 pcibus 0
pci0:  on pcib0
pci0:  at device 0.0 (no driver attached)
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 5.0 (no driver attached)
pci1:  at device 5.1 (no driver attached)
pcib2:  irq 10 at device 10.0 on pci0
pci2:  on pcib2
re0:  port
0xd800-0xd8ff mem 0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 10 at
device 0.0 on pci2
re0: Chip rev. 0x2c00
re0: MAC rev. 0x0020
re0: PHY write failed
re0: PHY write failed
re0: PHY read failed
re0: attaching PHYs failed
device_attach: re0 attach returned 6
pci0:  at device 17.0 (no driver attached)
pci0:  at device 18.0 (no driver attached)
pci0:  at device 18.2 (no driver attached)
pci0:  at device 19.0 (no driver attached)
pci0:  at device 19.2 (no driver attached)
pci0:  at device 20.2 (no driver attached)
pci0:  at device 20.3 (no driver attached)
pcib3:  at device 20.4 on pci0
pci3:  on pcib3
re0: 
port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff irq 3 at device 5.0 on pci3
re0: Chip rev. 0x0400
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1w
info: re0: Using defaults for TSO: 65518/35/2048
info: re0: Ethernet address: 00:0e:2e:7b:da:0b
pci0:  at device 20.5 (no driver attached)
pci0:  at device 22.0 (no driver attached)
pci0:  at device 22.2 (no driver attached)
pci0:  at device 24.0 (no driver attached)
pci0:  at device 24.1 (no driver attached)
pci0:  at device 24.2 (no driver attached)
pci0:  at device 24.3 (no driver attached)
pci0:  at device 24.4 (no driver attached)
cpu0
TheFB_VESA_RM ioctl called, cmd=4602
fbxres 1920, fbyres 1440
fbbpp 32
FB_VESA_RM ioctl called, cmd=4600
fbxres 1920, fbyres 1440
fbbpp 32
 framebuffer device was opened successfully.
1920x1440, 32bpp
11059200 screen size.
Error: failed to map framebuffer device to memory: Not supported

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
--
Exception 13 caught at PC  by thread 167837697
--
Processor execution context at time of the fault was  :
--
 EAX = 0EBX = 0 ECX = 3662e4EDX = 0
 ESI = 0EDI = 3662bcEBP = ffESP = 3af0a8
--
Error code pushed by processor itself (if not 0) = 0
--
Call Stack Trace of EIP:
0xef7eef7e 0x
*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
--
Exception 13 caught at PC 2ae863 by thread 167837697
--
Processor execution context at time of the fault was  :
--
 EAX = bEBX =   ECX = 339feeEDX = 0
 ESI = 3EDI = 2adc40EBP = 3aef58ESP = 3aef1c
--
Error code pushed by processor itself (if not 0) = 0
--
Call Stack Trace of EIP:
0x002906f8 0x002add03 0x002a7a4e 0x002ae4d9
0x002ae2f8
RTEMS version: 6.0.0.97559a7077ee0996012bcbc6952bbfb96923d6ae
RTEMS tools: 10.2.1 20200904 (RTEMS 6, RSB
a81a237f3e2318d88a16b31aadb82333498e06fd, Newlib a0d7982)
executing thread ID: 0x08a010001
executing thread name: UI1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: legacy stack or libbsd

[Chris Johns]

On 19/9/20 12:45 am, gabriel.moy...@dlr.de wrote:
> Hi Chris,
> 
>> I will get back around to it. There are 2 sets of changes. In PTP itself a
>> change is to add kqueue support because select in libbsd does not support
>> signals. The PTP code runs a number of timers and they run of an alarm 
>> signal.
>> The other piece of support is to the score to bring in the FreeBSD kern_ntp
>> support to sit besides the timercounters.
> 
> May I ask what are the necessary tasks to get kern_ntp support? We are also 
> interested on getting running PTP on RTEMS.

Thank you for your interest and I am sorry I did not have time to answer the
question.

I will try and take a look next week to see if I can get the RTEMS side of the
changes in a state they can posted for review.

Chris


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

Comments in spec files in rtems.git

[Chris Johns]

Hi,

Can comments be added to the .yml files under specs in rtems.git?

I was looking over a few files and wonder if some comments would help.

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

Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?

[small...@aliyun.com]

Flash disk is used in our normal procedure. We use qspi interface to read and 
write data from/to a flash disk in order to record our logs.
The flash disk is parted to several parts. In such case, a new part could be 
allocated to save the crash data.



small...@aliyun.com
 
From: Sebastian Huber
Date: 2020-09-18 12:42
To: small...@aliyun.com; devel
Subject: Re: does rtems 5.1 support create a core dump file when accessing a 
invalid address or other fatal errors?
On 18/09/2020 03:24, small...@aliyun.com wrote:
 
> It is a good starting place to handle the crash problem. Especially 
> the records could be packed to send to a host computer using TCP/IP.
> One of the question for us is there is no network interface. But we 
> have a flash disk. So we should modify the send flow using file system 
> instead of network.
> Moreover, we need expand the recorded data to get more information of 
> the crash.
Saving crash data to a flash disk is normally a bit too complex and 
involves interrupts and DMA. I would save the crash data to a volatile 
memory area which survives a soft reset. After the soft reset, check if 
crash data is available and save it to the disk.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel