Re: [PATCH 0/3] Add MicroBlaze port and BSP

[Chris Johns]

On 1/10/21 3:43 pm, Alex White wrote:
> This patch set adds support for the MicroBlaze architecture along with
> a basic BSP based on Xilinx's KCU105 PetaLinux BSP configuration.
> 
> The initial architecture port was started 6 or 7 years ago, I believe.
> To make authorship clear and preserve file history, the work is broken
> up into three patches. I made an effort to prune the first two patches
> of any files related to the old build system.

Looks good and many thanks to you, OAR and Hesham for this port.

I have raised a minor question, otherwise I am OK with this being added.

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

Re: [PATCH 3/3] microblaze: Rework for RTEMS 6

[Chris Johns]

On 1/10/21 3:43 pm, Alex White wrote:
>  bsps/microblaze/include/common/xil_types.h|  197 +++
>  bsps/microblaze/include/dev/serial/uartlite.h |   62 +
>  .../include/dev/serial/uartlite_l.h   |  323 +
>  bsps/microblaze/shared/dev/serial/uartlite.c  |  145 ++
>  .../microblaze/shared/dev/serial/uartlite_l.c |   99 ++

Are these Xilinx files shared in the their SDK?

Should we start here and then move to a generic location if used on another
architecture?

>  .../microblaze_fpga/startup/sim-crtinit.S |   46 +-

FPGA or simulator? The naming seems to contradict it self.

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

Re: [PATCH rtems-docs] eng: Add rules for attribution

[Chris Johns]

On 30/9/21 4:55 pm, Christian MAUDERER wrote:
> Am 30.09.21 um 02:23 schrieb Chris Johns:
>> On 29/9/21 6:38 pm, Christian MAUDERER wrote:
>>> Am 29.09.21 um 02:40 schrieb Chris Johns:
 On 28/9/21 11:11 pm, Christian MAUDERER wrote:
> Hello Joel,
>
> Am 28.09.21 um 14:48 schrieb Joel Sherrill:
>>
>>
>> On Tue, Sep 28, 2021, 1:40 AM Christian MAUDERER
>> > > wrote:
>>
>>   Hello Joel,
>>
>>   Am 28.09.21 um 01:12 schrieb Joel Sherrill:
>>    > The Microblaze port is interesting for attribution. I did 
>> initial
>>   work
>>    > on it. Hesham added to that and got Hello on a board. Alex is
>>   close to
>>    > submitting the port in a nice state.
>>    >
>>    > This is almost seven years across three developers.. The 
>> original
>>   work
>>    > predates source code reorganisation. Alex deleted the autoconf
>>   support
>>    > and created waf. Hesham and I agreed to convert to BSD-2.
>>    >
>>    > When submitted, we decided it was best for Alex to submit a Joel
>>   patch,
>>    > then Hesham, then Alex to finish it off. This keeps git blame
>>   working.
>>    >
>>    > Not quite the same topic but related to credit due.
>>
>>   But maybe an important extension. Should we replace "sponsored" 
>> with
>>   "sponsored or supported"? That would allow to mention anyone who 
>> helps
>>   in any way, regardless whether it's financial, with information, 
>> with
>>   hobby time or with whatever else.
>>
>>
>> I usually use the word sponsored. Support implies commercial activities 
>> the
>> way I/we tend to use it.
>>
>
> Seems that I picked the wrong word then. Maybe you can help me finding the
> correct term:
>
> The one case is clear: Someone pays that someone else develops for 
> example a
> driver. I think for that "sponsored" is a good term.
>
> Another similar case could be the following: You get help with writing a
> driver
> for example with information or some other form of help that doesn't 
> result
> in a
> copyright for that person or company. It doesn't involve money or some 
> other
> form of payment (T-shirts, pizza, ...) so it's not really sponsoring. 
> Despite
> that it might would be nice to mention them if they want to be mentioned. 
> I
> think the right location would be the same place like the one we just 
> discuss
> for sponsoring. What would be a good term for that?

 I think we should take baby steps with this.
>>>
>>> OK. I'll concentrate only on the case where some work is really sponsored 
>>> with
>>> money. I think a lot of work on RTEMS falls in that category. Most of the 
>>> times
>>> the sponsors don't want to appear with a name but in my case that caused 
>>> this
>>> discussion they do.
>>
>> I appreciate the customer may want this however my role is to ensure the 
>> process
>> makes sense for the whole community. I am still not sure.
>>
> 
> I fully agree that you should discuss it from a community point of view here. 
> I
> can't take that role in this discussion.
> 
>> It will be your customer's decision to have the changes merged and for the 
>> repo
>> to absorb them and maintain them. They always have the right to hold on to 
>> the
>> changes and maintain them if they do not agree with the outcome of this 
>> process.
>>
> 
> Of course.
> 
 I have some reservation on where
 this could go and the long term effects. If too widely spread and embedded 
 in
 the source it could be difficult to remove or change if we find an issue in
 doing this.

>>>
>>> Understood.
>>>
 In a private chat on the subject Gedare suggested a "Supporters" file? This
 could list those who have provided support and wish to be listed. I am 
 avoiding
 sponsorship and other words here on purpose for now. I have no idea what 
 works
 legally around the world.
>>>
>>> To be honest: If sponsored work is a legal problem, we have that with or 
>>> without
>>> a note in the files. It's only more visible with a note in the files. I 
>>> don't
>>> think that a legal problem would be avoidable just by not mentioning it.
>>
>> That is not the legal aspect I have in mind. There exists constraints about
>> payments for work done in relation to tax law and this varies around the 
>> world.
>> A notice could be taken as evidence. For example a functioning non-profit 
>> such
>> as the RTEMS Foundation can accept donations and how that money is spent is 
>> up
>> to the foundation. The contributor has no input on that process otherwise it 
>> is
>> tax avoidance. This area is strict and the governance is important. I will 
>> let
>> 

Re: [PATCH rtems-docs] eng: Add rules for attribution

[Chris Johns]

On 30/9/21 5:33 pm, Thomas DOERFLER wrote:
> Am 30.09.21 um 02:23 schrieb Chris Johns:
>> On 29/9/21 6:38 pm, Christian MAUDERER wrote:
>>>
>>> To be honest: If sponsored work is a legal problem, we have that with or 
>>> without
>>> a note in the files. It's only more visible with a note in the files. I 
>>> don't
>>> think that a legal problem would be avoidable just by not mentioning it.
>>
>> That is not the legal aspect I have in mind. There exists constraints about
>> payments for work done in relation to tax law and this varies around the 
>> world.
>> A notice could be taken as evidence. For example a functioning non-profit 
>> such
>> as the RTEMS Foundation can accept donations and how that money is spent is 
>> up
>> to the foundation. The contributor has no input on that process otherwise it 
>> is
>> tax avoidance. This area is strict and the governance is important. I will 
>> let
>> you consider the relationship between fair attribution for the whole 
>> community
>> and those contributing to a non-profit.
> 
> Surely this must be considered, but OTOH RTEMS code is definitively a project
> which combines non-profit and with-profit people to create and maintain code,
> especially since the birth of the project was with-profit.
> 
> So if it comes to contributions e.g. from our company: Yes, they are created
> with profit.

This is fine. An organisation and their tax system have well established
processes to audit and collect the related tax. Contributing to a non-profit to
complete task X or any directed task then claiming that payment as a tax
deduction is not allowed. That loop hole was closed many years ago.

> Certain areas are handled non-profit. Maybe the question then is, how to
> properly distinguish them.

For a non-profit it is the role of that organisation and not this project. It
would be concerning if the project started to take on that role. The rules
around a non-profit and it's sponsors are for it to administer.

>>> A foundation wouldn't change the problem discussed here. Don't get me 
>>> wrong: I
>>> would love to see the foundation. But I don't think that the foundation 
>>> would be
>>> the the same as the RTEMS open source project from a legal point of view. It
>>> would only be another (much needed) sponsor of work and infrastructure.
>>
>> Sorry, a non-profit does not work that way as I stated above so no 
>> attribution
>> can happen. This makes attribution fundamentally unfair.
>>
> I agree that a "sponsored by RTEMS Foundation" entry wouldn't make sense,
> because the whole idea of the Foundation is to maintain RTEMS.
> 
> But, regarding the "sponsored by" entry, I wouldn't talk about fairness. 

Maybe fairness is not a good word in this case.

> In the
> past we always had the question "who is using RTEMS" and in many cases had to
> shrug shoulders because we either don't know or shouldn't tell. If RTEMS user
> companies officially ask to be visible, I think this is something we should 
> push
> and not block, right?

I welcome a user placing a "power by RTEMS" on their box or in there marketing
or documentation.

>> I have to say I not entirely comfortable with this happening and I will not 
>> be
>> encouraging additions. If Thomas wishes to discuss this further I suggest he
>> reaches out to me personally.
> 
> That makes sense, I will try next week when being back at work.

Thanks and please do.

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

Re: [PATCH v2 5/6] cpukit: Add signal mapping support

[Chris Johns]

On 1/10/21 11:33 pm, Sebastian Huber wrote:
> The fatal extensions have a well defined order (position in the
> table). The user has the full control over the initial extensions table.

Is it backwards compatible when this new mode is enabled?

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

Re: [PATCH v2 2/6] cpukit: Add Exception Manager

[Kinsey Moore]

On 10/1/2021 08:29, Sebastian Huber wrote:

On 01/10/2021 06:39, Gedare Bloom wrote:

You also might separate the exception manager addition away from the
topic of recoverable exceptions. This introduces/extends the classic
API, so it needs to be vetted carefully. Although the new header
claims to be a classic API, it appears to not follow classic API
conventions. You might need to think about what needs to be exposed to
the application level, and how, versus what should be internal. And
follow the conventions for classic API usage (e.g., opaque types not
pointers).


Yes, the  is reserved for API header files. The 
architecture-independent implementation part (Exception Handler) 
should go to . The architecture-dependent part should 
go in .  If something really (!) needs to be 
visible to the API, then it should go in . The 
architecture-dependent parts should be documented in the no_cpu header 
files.


Please make the architecture-dependent interface more abstract. From 
my point of view your current approach contains to many details of the 
aarch64 port.


There should be documentation in the RTEMS CPU Supplement with a 
status for each architecture (similar to the TLS support).


At the moment I only see one API element and this is the new 
application configuration option.


If you really need new rtems_* interfaces, then please add a proper 
documentation for them so that it could be included in the RTEMS 
Classic API Guide. I would prefer to wait with new API elements until 
at this is implemented on at least another architecture.


Thanks for the feedback, Gedare and Sebastian. I'll get this refactored 
as suggested and keep everything but the configuration option out of the 
API.



Sebastian,

Could you be more specific about which parts of the 
architecture-dependent interface still seem tied to the AArch64 port? I 
thought I had made them sufficiently abstract by relying on 
architecture-specific functions to manipulate and take action on the 
exception frame. The signal mapping code written on top of this should 
work for any architecture that implements those functions and contains 
no reliance on architecture that I can see. The set of exception classes 
in particular includes exceptions that don't exist on AArch64, but were 
added because they're known to be present on SPARC and need to be 
handled. I'm only really familiar with ARM and AArch64, so that could be 
why I'm missing it.



Kinsey

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

Re: [PATCH v2 1/6] cpukit/aarch64: Use correct interrupt level types

[Kinsey Moore]

On 9/30/2021 23:24, Gedare Bloom wrote:

If the rest of the patch set isn't ready, please split this out for
separate submission. It looks fine to me.


It appears not. I'll go ahead and get this patch committed and remove it 
from the set.



Thanks,

Kinsey

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

[PATCH 6/6] posix: Remove "RTEMS" from POSIX API group

[Sebastian Huber]

Clarify group description.

Update #3706.
---
 cpukit/include/rtems/posix/posixapi.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/posix/posixapi.h 
b/cpukit/include/rtems/posix/posixapi.h
index 122dd644e6..8d30ee21e5 100644
--- a/cpukit/include/rtems/posix/posixapi.h
+++ b/cpukit/include/rtems/posix/posixapi.h
@@ -28,14 +28,15 @@
 #include 
 
 /**
- * @defgroup POSIXAPI RTEMS POSIX API
+ * @defgroup POSIXAPI POSIX API
  *
  * @ingroup RTEMSImpl
  *
- * RTEMS POSIX API definitions and modules.
+ * @brief This group contains definitions and modules which are used to
+ *   implement the POSIX APIs supported by RTEMS.
  *
+ * @{
  */
-/**@{**/
 
 extern const int _POSIX_Get_by_name_error_table[ 3 ];
 
-- 
2.31.1

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

[PATCH 5/6] scoe: Move workspace group definition

[Sebastian Huber]

Define the group in the header file which is used by .

Update #3706.
---
 cpukit/include/rtems/score/wkspace.h | 10 +-
 cpukit/include/rtems/score/wkspacedata.h | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/cpukit/include/rtems/score/wkspace.h 
b/cpukit/include/rtems/score/wkspace.h
index b37f257ed6..a3af86e878 100644
--- a/cpukit/include/rtems/score/wkspace.h
+++ b/cpukit/include/rtems/score/wkspace.h
@@ -28,15 +28,7 @@ extern "C" {
 #endif
 
 /**
- * @defgroup RTEMSScoreWorkspace Workspace Handler
- *
- * @ingroup RTEMSScore
- *
- * @brief This group contains the Workspace Handler implementation.
- *
- * This handler encapsulates functionality related to the management of the
- * RTEMS Workspace.  It provides mechanisms which can be used to define,
- * initialize and manipulate the RTEMS Workspace.
+ * @addtogroup RTEMSScoreWorkspace
  *
  * @{
  */
diff --git a/cpukit/include/rtems/score/wkspacedata.h 
b/cpukit/include/rtems/score/wkspacedata.h
index 3de4b02bd2..f1ca524fa0 100644
--- a/cpukit/include/rtems/score/wkspacedata.h
+++ b/cpukit/include/rtems/score/wkspacedata.h
@@ -47,7 +47,15 @@ extern "C" {
 struct Heap_Control;
 
 /**
- * @addtogroup RTEMSScoreWorkspace
+ * @defgroup RTEMSScoreWorkspace Workspace Handler
+ *
+ * @ingroup RTEMSScore
+ *
+ * @brief This group contains the Workspace Handler implementation.
+ *
+ * This handler encapsulates functionality related to the management of the
+ * RTEMS Workspace.  It provides mechanisms which can be used to define,
+ * initialize and manipulate the RTEMS Workspace.
  *
  * @{
  */
-- 
2.31.1

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

[PATCH 4/6] rtems: Add ASR implementation to existing group

[Sebastian Huber]

Update #3706.
---
 cpukit/include/rtems/rtems/asrdata.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/rtems/asrdata.h 
b/cpukit/include/rtems/rtems/asrdata.h
index 3f44d3b030..924e616a9a 100644
--- a/cpukit/include/rtems/rtems/asrdata.h
+++ b/cpukit/include/rtems/rtems/asrdata.h
@@ -1,7 +1,7 @@
 /**
  * @file
  *
- * @ingroup RTEMSImplClassicASR
+ * @ingroup RTEMSImplClassicSignal
  *
  * @brief This header file provides data structures used by the implementation
  *   and the @ref RTEMSImplApplConfig to ultimately define
@@ -26,7 +26,7 @@ extern "C" {
 #endif
 
 /**
- * @addtogroup RTEMSImplClassicASR
+ * @addtogroup RTEMSImplClassicSignal
  *
  * @{
  */
-- 
2.31.1

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

[PATCH 3/6] score: Add Hash Handler to group

[Sebastian Huber]

Update #3706.
---
 cpukit/include/rtems/score/hash.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cpukit/include/rtems/score/hash.h 
b/cpukit/include/rtems/score/hash.h
index 8a269cc548..c6f9ebf463 100644
--- a/cpukit/include/rtems/score/hash.h
+++ b/cpukit/include/rtems/score/hash.h
@@ -49,6 +49,8 @@ extern "C" {
 /**
  * @defgroup RTEMSScoreHash Hash Handler
  *
+ * @ingroup RTEMSScore
+ *
  * @brief This group contains the Hash Handler implementation.
  *
  * @{
-- 
2.31.1

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

[PATCH 2/6] rtems: Canonicalize Doxygen in

[Sebastian Huber]

Update #3706.
---
 cpukit/include/rtems/counter.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/counter.h b/cpukit/include/rtems/counter.h
index 5bf7736e4a..0053afcbd5 100644
--- a/cpukit/include/rtems/counter.h
+++ b/cpukit/include/rtems/counter.h
@@ -1,9 +1,10 @@
 /**
  * @file
  *
- * @ingroup ClassicCounter
+ * @ingroup RTEMSAPICounter
  * 
- * @brief Free-Running Counter and Busy Wait Delay API
+ * @brief This header file defines the Free-Running Counter and Busy Wait Delay
+ *   API.
  */
 
 /*
-- 
2.31.1

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

[PATCH 0/6] Doxygen groups cleanup

[Sebastian Huber]

Sebastian Huber (6):
  rtems: Canonicalize Doxygen in 
  rtems: Canonicalize Doxygen in 
  score: Add Hash Handler to group
  rtems: Add ASR implementation to existing group
  scoe: Move workspace group definition
  posix: Remove "RTEMS" from POSIX API group

 cpukit/include/rtems/counter.h   |  5 +++--
 cpukit/include/rtems/posix/posixapi.h|  7 ---
 cpukit/include/rtems/rtems/asrdata.h |  4 ++--
 cpukit/include/rtems/score/hash.h|  2 ++
 cpukit/include/rtems/score/wkspace.h | 10 +-
 cpukit/include/rtems/score/wkspacedata.h | 10 +-
 cpukit/include/rtems/seterr.h| 10 +-
 7 files changed, 26 insertions(+), 22 deletions(-)

-- 
2.31.1

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

[PATCH 1/6] rtems: Canonicalize Doxygen in

[Sebastian Huber]

Update #3706.
---
 cpukit/include/rtems/seterr.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/cpukit/include/rtems/seterr.h b/cpukit/include/rtems/seterr.h
index 711382d732..adce762dc9 100644
--- a/cpukit/include/rtems/seterr.h
+++ b/cpukit/include/rtems/seterr.h
@@ -1,10 +1,10 @@
 /**
- *  @file
+ * @file
  *
- *  @brief Data which Ease the Burden of Consistently Setting Errno
+ * @ingroup RTEMSAPISetErrno
  *
- *  This file contains macros and definitions which ease the burden
- *  of consistently setting errno and returning -1.
+ * @brief This header file defines macros to set ``errno`` and return minus
+ *   one.
  */
 
 /*
@@ -22,7 +22,7 @@
 #include 
 
 /**
- * @defgroup RTEMSAPISetErrno Set Errno
+ * @defgroup RTEMSAPISetErrno Set Error Number Support
  *
  * @ingroup RTEMSAPI
  *
-- 
2.31.1

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

[PATCH] rtems: Generate

[Sebastian Huber]

Write the documentation from scratch.
---
 cpukit/include/rtems/cpuuse.h | 217 --
 1 file changed, 178 insertions(+), 39 deletions(-)

diff --git a/cpukit/include/rtems/cpuuse.h b/cpukit/include/rtems/cpuuse.h
index 50c986671d..da51e9708a 100644
--- a/cpukit/include/rtems/cpuuse.h
+++ b/cpukit/include/rtems/cpuuse.h
@@ -1,87 +1,226 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
  * @ingroup libmisc_cpuuse
  *
- * @brief CPU Usage Report
+ * @brief This header file provides the CPU usage reporting API.
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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 include file contains information necessary to utilize
- * and install the cpu usage reporting mechanism.
+ * 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://www.rtems.org/bugs.html
  *
- * 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.
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
+ *
+ * https://docs.rtems.org
  */
 
-#ifndef __RTEMS_CPUUSE_h
-#define __RTEMS_CPUUSE_h
+/* Generated from spec:/rtems/cpuuse/if/header */
 
-#include 
-#include 
+#ifndef _RTEMS_CPUUSE_H
+#define _RTEMS_CPUUSE_H
 
-/**
- *  @defgroup libmisc_cpuuse CPU Usage
- *
- *  @ingroup RTEMSAPIClassic
- */
-/**@{*/
 #ifdef __cplusplus
 extern "C" {
 #endif
 
-/*
- * rtems_cpu_usage_report_with_handler
+/* Generated from spec:/rtems/cpuuse/if/group */
+
+/**
+ * @defgroup libmisc_cpuuse CPU Usage Reporting
+ *
+ * @ingroup RTEMSAPI
+ *
+ * @brief The CPU usage reporting directives can be used to report and reset
+ *   the CPU usage of threads.
  */
 
-void rtems_cpu_usage_report_with_plugin( const rtems_printer *printer );
+/* Generated from spec:/rtems/cpuuse/if/printer */
+
+/* Forward declaration */
+struct rtems_printer;
+
+/* Generated from spec:/rtems/cpuuse/if/cpu-info-report */
 
 /**
- *  @brief Report CPU usage.
+ * @ingroup libmisc_cpuuse
+ *
+ * @brief Reports the CPU information using the printer plugin.
+ *
+ * @param printer is the printer plugin to output the report.
  *
- *  CPU Usage Reporter
+ * @par Constraints
+ * @parblock
+ * The following constraints apply to this directive:
+ *
+ * * The directive may be called from within any runtime context.
+ *
+ * * The directive will not cause the calling task to be preempted.
+ * @endparblock
  */
+int rtems_cpu_info_report( const struct rtems_printer *printer );
 
+/* Generated from spec:/rtems/cpuuse/if/report */
+
+/**
+ * @ingroup libmisc_cpuuse
+ *
+ * @brief Reports the CPU usage of each thread using the printk() printer.
+ *
+ * @par Notes
+ * See also rtems_cpu_usage_report_with_plugin().
+ *
+ * @par Constraints
+ * @parblock
+ * The following constraints apply to this directive:
+ *
+ * * The directive may be called from within device driver initialization
+ *   context.
+ *
+ * * The directive may be called from within task context.
+ *
+ * * The directive may obtain and release the object allocator mutex.  This may
+ *   cause the calling task to be preempted.
+ * 

Re: Workspace Initialization Faliure Bug

[Joel Sherrill]

On Fri, Oct 1, 2021, 12:10 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 01/10/2021 16:27, Joel Sherrill wrote:
> >
> >
> > On Fri, Oct 1, 2021, 8:42 AM Sebastian Huber
> >  > > wrote:
> >
> > On 01/10/2021 00:38, Joel Sherrill wrote:
> >  > I think in this configuration, the workspace is essentially
> unneeded
> >  > but has to be able to be initialized. It shows that the static
> >  > allocation work has succeeded in trimming the workspace at least.
> But
> >  > now we have to account for an empty one. :)
> >
> > Did you get this error with an unmodified master branch?
> >
> >
> > Not yet. I am updating to 5 first since the last released version was
> from a
> > pre-branching spot and the decision was made to move to the release
> > branch.
> >
> > I am hoping to get it updated to where we can more easily track the
> > master but there are a few things ahead of that.
>
> I would update to the master. We should be close to an RTEMS 6 release.
> Our pre-qualification activity is nearly done.
>

That's not really a schedule option for this next drop.

It is needed long term.

>
> >
> >
> > Why is the workspace initialized? I tried to arrange everything so
> that
> > the workspace doesn't get initialized if it is not needed. What
> pulled
> > in the workspace initialization?
> >
> >
> > Looking at the map from ticker, it looks like it comes from
> > malloc_initialize.c
> >
> > ./../../cpukit/librtemscpu.a(wkspace.o)
> >
> > ./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Area)
> > ./../../cpukit/librtemscpu.a(wkspaceisunifieddefault.o)
> >
> > ./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Is_unified)
> >
> > And malloc_initialize.c looks different in 5 versus master.
> >
> > I don't want to get into pulling back a LOT of code. If there is a small
> > patch
> > set that can be backported, I'm ok with that. But a simple fix to let it
> > have a
> > minimum workspace is safe and simple on 5.
> >
> > But this can really occur on 5 so we need at least a fix there.
>
> Back porting things in the workspace and confdefs.h area will be difficult.
>

Then maybe my one line addition is the right work around for 5.

I will make a ticket for 5 and propose my one line addition. Anything else
seems to complicated and risky.

For 6, I'll see if this happens when I test the idle stack allocator.


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Workspace Initialization Faliure Bug

[Sebastian Huber]

On 01/10/2021 16:27, Joel Sherrill wrote:



On Fri, Oct 1, 2021, 8:42 AM Sebastian Huber 
> wrote:


On 01/10/2021 00:38, Joel Sherrill wrote:
 > I think in this configuration, the workspace is essentially unneeded
 > but has to be able to be initialized. It shows that the static
 > allocation work has succeeded in trimming the workspace at least. But
 > now we have to account for an empty one. :)

Did you get this error with an unmodified master branch?


Not yet. I am updating to 5 first since the last released version was from a
pre-branching spot and the decision was made to move to the release
branch.

I am hoping to get it updated to where we can more easily track the
master but there are a few things ahead of that.


I would update to the master. We should be close to an RTEMS 6 release. 
Our pre-qualification activity is nearly done.





Why is the workspace initialized? I tried to arrange everything so that
the workspace doesn't get initialized if it is not needed. What pulled
in the workspace initialization?


Looking at the map from ticker, it looks like it comes from 
malloc_initialize.c


./../../cpukit/librtemscpu.a(wkspace.o)
   
./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Area)

./../../cpukit/librtemscpu.a(wkspaceisunifieddefault.o)
   
./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Is_unified)


And malloc_initialize.c looks different in 5 versus master.

I don't want to get into pulling back a LOT of code. If there is a small 
patch
set that can be backported, I'm ok with that. But a simple fix to let it 
have a

minimum workspace is safe and simple on 5.

But this can really occur on 5 so we need at least a fix there.


Back porting things in the workspace and confdefs.h area will be difficult.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] record-main-lttng.cc: Change size of empty array

[Joel Sherrill]

The short message is misleading. It isn't an empty array -- it is an
emptyName string. :)

I'm ok with the patch but I reviewed it before submission so another
ACK from someone else is appreciated.

On Thu, Sep 30, 2021 at 3:17 PM Ryan Long  wrote:
>
> Change size of kEmptyThreadName from THREAD_API_COUNT to
> THREAD_NAME_SIZE.
>
> Closes #4519
> ---
>  trace/record/record-main-lttng.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/trace/record/record-main-lttng.cc 
> b/trace/record/record-main-lttng.cc
> index 7cfa48c..faa762d 100644
> --- a/trace/record/record-main-lttng.cc
> +++ b/trace/record/record-main-lttng.cc
> @@ -59,7 +59,7 @@
>  #define BITS_PER_CHAR 8
>  #define COMPACT_HEADER_ID 31
>
> -static const uint8_t kEmptyThreadName[THREAD_API_COUNT] = "";
> +static const uint8_t kEmptyThreadName[THREAD_NAME_SIZE] = "";
>
>  static const uint8_t kUUID[] = {0x6a, 0x77, 0x15, 0xd0, 0xb5, 0x02, 0x4c, 
> 0x65,
>  0x86, 0x78, 0x67, 0x77, 0xac, 0x7f, 0x75, 
> 0x5a};
> --
> 1.8.3.1
>
> ___
> 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: Workspace Initialization Faliure Bug

[Joel Sherrill]

On Fri, Oct 1, 2021, 8:42 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 01/10/2021 00:38, Joel Sherrill wrote:
> > I think in this configuration, the workspace is essentially unneeded
> > but has to be able to be initialized. It shows that the static
> > allocation work has succeeded in trimming the workspace at least. But
> > now we have to account for an empty one. :)
>
> Did you get this error with an unmodified master branch?
>

Not yet. I am updating to 5 first since the last released version was from a
pre-branching spot and the decision was made to move to the release
branch.

I am hoping to get it updated to where we can more easily track the
master but there are a few things ahead of that.


> Why is the workspace initialized? I tried to arrange everything so that
> the workspace doesn't get initialized if it is not needed. What pulled
> in the workspace initialization?
>

Looking at the map from ticker, it looks like it comes from
malloc_initialize.c

./../../cpukit/librtemscpu.a(wkspace.o)

./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Area)
./../../cpukit/librtemscpu.a(wkspaceisunifieddefault.o)

./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Is_unified)

And malloc_initialize.c looks different in 5 versus master.

I don't want to get into pulling back a LOT of code. If there is a small
patch
set that can be backported, I'm ok with that. But a simple fix to let it
have a
minimum workspace is safe and simple on 5.

But this can really occur on 5 so we need at least a fix there.

--joel


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Workspace Initialization Faliure Bug

[Sebastian Huber]

On 01/10/2021 00:38, Joel Sherrill wrote:

I think in this configuration, the workspace is essentially unneeded
but has to be able to be initialized. It shows that the static
allocation work has succeeded in trimming the workspace at least. But
now we have to account for an empty one. :)


Did you get this error with an unmodified master branch?

Why is the workspace initialized? I tried to arrange everything so that 
the workspace doesn't get initialized if it is not needed. What pulled 
in the workspace initialization?


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/6] cpukit/aarch64: Use correct interrupt level types

[Sebastian Huber]

On 01/10/2021 06:24, Gedare Bloom wrote:

If the rest of the patch set isn't ready, please split this out for
separate submission. It looks fine to me.


Yes, sorry for the slow review. I somehow overlooked this patch set.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 5/6] cpukit: Add signal mapping support

[Sebastian Huber]

On 23/09/2021 04:41, Kinsey Moore wrote:

On 9/22/2021 21:06, Chris Johns wrote:

On 23/9/21 10:16 am, Kinsey Moore wrote:

This adds a confdef option allowing an application to request mapping
machine exceptions to POSIX signals. This is required for some languages
such as Ada.> --- a/cpukit/include/rtems/confdefs/extensions.h
+++ b/cpukit/include/rtems/confdefs/extensions.h
@@ -93,6 +93,10 @@
    #include 
  #endif
+#ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
+  #include 
+#endif
+
  #ifdef __cplusplus
  extern "C" {
  #endif
@@ -103,6 +107,9 @@ extern "C" {
    || defined(CONFIGURE_INITIAL_EXTENSIONS) \
    || defined(BSP_INITIAL_EXTENSION)
    const User_extensions_Table _User_extensions_Initial_extensions[] 
= {

+    #ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
+  { .fatal = _Exception_map_signal },
There is something amiss adding a recoverable interface and support 
that hooks
`.fatal`. Either this field is now badly named or should there be 
something else

added? Another extension? I do not know.
I agree and that's partially the reason my previous patch had this split 
out into a different extension type. This API is not something I feel 
comfortable breaking for users, so I'd lean away from renaming it.


The "fatal" extension should definitely not get renamed. This extension 
was generalized over time. Thanks to the fatal source parameter this 
extension is easy to extend.


My 
takeaway from our discussion was that this should be implemented as a 
fatal error extension with an epilogue function to break out of the 
normal call stack and perform exception cleanup tasks.


Yes, exactly.

What happens to my default fatal handler if I decide to enable this 
support?


If you enable this support, some fatal errors will be deemed recoverable 
and recovered errors will not propagate to further fatal error handlers. 
If enabled, handlers of this variety must run first to avoid any side 
effects on the system caused by other fatal handlers taking final 
actions on what they expect is a dead system.


Yes, exactly. The fatal extensions have a well defined order (position 
in the table). The user has the full control over the initial extensions 
table.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCHv5] improve the format error reporting on i386

[Joel Sherrill]

Zack,

I think your mailer is formatting the patch incorrectly. Can you
compress it and send it to me privately as an attachment?

Thanks.

--joel

On Thu, Sep 30, 2021 at 11:15 PM Gedare Bloom  wrote:
>
> Joel, i think the patch looks good.
>
> On Fri, Sep 24, 2021 at 6:19 PM zack leung  wrote:
> >
> > bump
> >
> >
> > On Thu, 23 Sept 2021 at 00:21, zack leung  wrote:
> >>
> >> I can send an example of the exception if you want.
> >>
> >> zack
> >>
> >> On Wed, 22 Sept 2021 at 18:01, Gedare Bloom  wrote:
> >>>
> >>> Joel,
> >>>
> >>> This looks good to me. I don't know if you can easily test it?
> >>>
> >>> Gedare
> >>>
> >>> On Wed, Sep 22, 2021 at 11:26 AM zack leung  
> >>> wrote:
> >>> >
> >>> > ll hex values now have 8 character width
> >>> > thread id is now hex
> >>> > updates #4203
> >>> > ---
> >>> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
> >>> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >>> >
> >>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> >>> > index 77b7a7161c..786cf8b0b6 100644
> >>> > --- a/cpukit/score/cpu/i386/cpu.c
> >>> > +++ b/cpukit/score/cpu/i386/cpu.c
> >>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
> >>> > CPU_Exception_frame *ctx)
> >>> >  {
> >>> >unsigned int faultAddr = 0;
> >>> >
> >>> > printk("--\n");
> >>> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> >>> > PRId32 "\n",
> >>> > +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread 
> >>> > 0x%08"
> >>> > PRIx32 "\n",
> >>> >   ctx->idtIndex,
> >>> >   ctx->eip,
> >>> >   _Thread_Executing->Object.id);
> >>> >
> >>> > printk("--\n");
> >>> >printk("Processor execution context at time of the fault was  :\n");
> >>> >
> >>> > printk("--\n");
> >>> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
> >>> > EDX = %" PRIx32 "\n",
> >>> > +  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
> >>> > 0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
> >>> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> >>> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
> >>> > ESP = %" PRIx32 "\n",
> >>> > +  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
> >>> > 0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
> >>> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
> >>> >
> >>> > printk("--\n");
> >>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> >>> > "\n",
> >>> > --
> >>> > 2.33.0
> >>> > ___
> >>> > devel mailing list
> >>> > devel@rtems.org
> >>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/6] cpukit: Add Exception Manager

[Sebastian Huber]

On 01/10/2021 06:39, Gedare Bloom wrote:

You also might separate the exception manager addition away from the
topic of recoverable exceptions. This introduces/extends the classic
API, so it needs to be vetted carefully. Although the new header
claims to be a classic API, it appears to not follow classic API
conventions. You might need to think about what needs to be exposed to
the application level, and how, versus what should be internal. And
follow the conventions for classic API usage (e.g., opaque types not
pointers).


Yes, the  is reserved for API header files. The 
architecture-independent implementation part (Exception Handler) should 
go to . The architecture-dependent part should go in 
.  If something really (!) needs to be visible to 
the API, then it should go in . The 
architecture-dependent parts should be documented in the no_cpu header 
files.


Please make the architecture-dependent interface more abstract. From my 
point of view your current approach contains to many details of the 
aarch64 port.


There should be documentation in the RTEMS CPU Supplement with a status 
for each architecture (similar to the TLS support).


At the moment I only see one API element and this is the new application 
configuration option.


If you really need new rtems_* interfaces, then please add a proper 
documentation for them so that it could be included in the RTEMS Classic 
API Guide. I would prefer to wait with new API elements until at this is 
implemented on at least another architecture.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsp/imx: Add cs_change support to SPI

[Christian Mauderer]

---
 bsps/arm/imx/spi/imx-ecspi.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index 26ba812f62..4732b84713 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -350,6 +350,9 @@ static void imx_ecspi_interrupt(void *arg)
   } else if (bus->in_transfer > 0) {
 regs->intreg = IMX_ECSPI_RR;
   } else {
+if (bus->msg->cs_change) {
+  imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+}
 --bus->msg_todo;
 ++bus->msg;
 imx_ecspi_next_msg(bus, regs);
@@ -376,9 +379,6 @@ static int imx_ecspi_check_messages(
 (msg->cs > IMX_ECSPI_MAX_CHIPSELECTS || !bus->cspins[msg->cs].valid)) {
   return -EINVAL;
 }
-if (msg->cs_change != 0) {
-  return -EINVAL;
-}
 
 ++msg;
 --size;
@@ -407,7 +407,9 @@ static int imx_ecspi_transfer(
 
 imx_ecspi_next_msg(bus, bus->regs);
 rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
-imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+if (msgs[n-1].cs_change) {
+  imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+}
   }
   return rv;
 }
-- 
2.31.1

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