date:20201119


Hello Chris,

On 17/11/2020 22:43, Chris Johns wrote:



On 17/11/20 6:14 pm, Sebastian Huber wrote:

On 16/11/2020 23:42, Chris Johns wrote:

On 16/11/20 5:40 pm, Sebastian Huber wrote:

On 16/11/2020 00:33, Chris Johns wrote:


In the proposal, limits are specified like this:


limits:
   sparc/gr712rc:
     DirtyCache:
   max-upper-bound: 0.05
   mean-upper-bound: 0.05
     FullCache:
   max-upper-bound: 0.05
   mean-upper-bound: 0.05
     HotCache:
   max-upper-bound: 0.05
   mean-upper-bound: 0.05
     Load/1:
   max-upper-bound: 0.1
   mean-upper-bound: 0.1
     Load/2:
   max-upper-bound: 0.1
   mean-upper-bound: 0.1
     Load/3:
   max-upper-bound: 0.1
   mean-upper-bound: 0.1
     Load/4:
   max-upper-bound: 0.1
   mean-upper-bound: 0.1

This neglects that the limits are subject to a board configuration. One
approach to cover this is the addition of a new BSP provided function:

const char *rtems_get_hardware_performance_hash();

The BSP feeds all performance related data into a hash function and

"data" here means configuration?

Yes, hardware configuration.

Why not make these values part of the BSP configuration? The defaults for the
BSP can have a set of suitable values. Different boards have different
configurations to match and a separate kernel build.


This doesn't work on BSPs which support configuration via a hardware
enumeration, boot loader settings, or device trees. Also changes in the BSP
options have no influence on the BSP name. Not only BSP configuration influence
performance, the CPU options play a role too, for example RTEMS_SMP. In order to
compare performance values over time we have to obtain the values under the same
conditions.

Maybe I am not understanding the context.

A BSP, which ever one, has a set of options that configure it. An example is the
xilinx_zynq_zc702 and the `ZYNQ_RAM_LENGTH = 0x4000`. If I have 2 Zynq
circuits one with 256M and one with 1G I need to build and maintain 2 RTEMS
builds and from a purists point of view I need to maintain 2 builds of the exact
same application.

I asked about the fixed memory and your answer was to use the BSP options, the
size is fixed in the linker command files via the BSP option. That is what I
have done.

I would expect there exists a set of values for the xilinx_zynq_zc702 with no
SMP and with SMP as this BSP supports SMP. Those values would match all the
other settings for the BSP such as ZYNQ_CLOCK_CPU_1X, BSP_ARM_A9MPCORE_PERIPHCLK
etc. If my clock is different (and they are) I would need to supply a suitable
set of performance values if I wanted to pass those tests.

I am not questioning the need for the values or the tests. I am suggesting the
values form part of the BSP settings so a user can adjust them to suite their
specific set up in the same way they adjust other BSP settings. I do not think
we should attempt to hold or manage an endless sets of possible values and I do
not see the need for complex encapsulation methods such as a base64 hashes. The
systems we interact with are too complex and list is endless.

I think it will be highly BSP-specific what parameters are relevant to the
performance limits. This is why I suggested to add a function which can be
implemented by each BSP.

const char *rtems_get_hardware_performance_something();

It should return a string which changes if a performance relevant parameter
changed. If it is only SMP/no-SMP, ZYNQ_CLOCK_CPU_1X, and
BSP_ARM_A9MPCORE_PERIPHCLK, then fine, just return "SMP/800MHz/400MHz" or 
whatever.

I suggest you avoid heading down a path of specific strings, ie avoid something
meaningful a human can read. Also performance characteristics are a part of a
wider configuration topic. Maybe considering that would solve the performance
specific parts as well.

A label for a build of RTEMS is a good idea (see below) that could serve the
human readable part. I would consider computing a hash for the config.ini file,
ie the build, and embedding it. If you wanted to capture the state of the RTEMS
source built optionally compute a hash for the entire source tree and embed that
as well. You can then have calls such as:

const char* rtems_config_build_hash(void);
const char* rtems_config_source_hash(void);

  [ the last one could return "NOT-AVAILABLE" if not enabled ]

The key point is defining markers, with defaults if optional, then wrapping your
configuration management system round them. Strings with a meaning such as
"SMP/800MHz/400MHz" are fragile because cosmetic changes break dependent
configuration management systems. A hash implies nothing specific, that task is
left to your CM systems.

For a BSP specific case of runtime values what about:

const char* rtems_config_bsp_hash(void);

with a default returning "DEFAULT". A BSP could override a weak function

Re: [PATCH] eng: Rework and clarify Doxygen Guidelines

On 10/11/2020 13:55, Sebastian Huber wrote:

Hello Joel,

On 09/11/2020 15:37, Sebastian Huber wrote:

On 09/11/2020 15:12, Joel Sherrill wrote:

On Mon, Nov 9, 2020 at 8:02 AM Sebastian Huber
> wrote:

---
eng/coding-doxygen.rst | 210
eng/coding-file-hdr.rst | 2 +
2 files changed, 149 insertions(+), 63 deletions(-)

diff --git a/eng/coding-doxygen.rst b/eng/coding-doxygen.rst
index f4308ef..b2e6b61 100644
--- a/eng/coding-doxygen.rst
+++ b/eng/coding-doxygen.rst
@@ -16,12 +16,13 @@ In the RTEMS source code, CamelCase is rarely
used, so this makes it easier to
search and replace Doxygen groups. It avoids ambiguous
references to

functions, types, defines, macros, and groups. All groups shall
have an
``RTEMS`` prefix. This makes it possible to include the RTEMS
files with
-Doxygen comments in a larger project without name conflicts.
+Doxygen comments in a larger project without name conflicts. The
group name
+shall use `Title Case
>`_.

.. code:: c

/**
- * @defgroup RTEMSScoreThread
+ * @defgroup RTEMSScoreThread Thread Handler
*
* @ingrop RTEMSScore
*
@@ -36,18 +37,28 @@ global variable declaration shall belong to at
least one Doxygen group. Use
``@defgroup`` and ``@addtogroup`` with ``@{`` and ``@}`` brackets
to add
members to a group. A group shall be defined at most once. Each
group shall
be documented with an ``@brief`` description and an optional
detailed

-description. The ``@brief`` description shall use
-`Title Case >`_.
-Use grammatically correct sentences for the detailed descriptions.
+description. Use grammatically correct sentences for the
``@brief`` and
+detailed descriptions.
+
+For the ``@brief`` description use phrases like this:
+
+* This group contains ... and so on.
+
+* The XYZ Handler provides ... and so on.
+
+* The ABC Component contains ... and so on.

I don't know where the idea @brief should be short sentences came from.
I reviewed the Doxgyen HTML and PDF output and come to the conclusion
that the use of Title Case makes no sense for the brief descriptions.

@brief is used to make table of contents type pages and those should
read more like titles than the first sentence of the detailed
description.

https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/modules.html

That Doxgyen removes a trailing '.' from the brief descriptions is a
bug or feature. I didn't find a corresponding view in the PDF.

If you look at the PDF, it really is used for the Table of Contents and
a sentence is quite odd there.

It should read like a chapter title

I looked at the PDF output and the brief descriptions are not
included in the table of contents. The group names are included in
the table of contents. For the group names Title Case should be used.
The brief descriptions are the first sentence of the module
description. This is identical to the HTML output.

Please have a look at:

https://ftp.rtems.org/pub/rtems/people/sebh/refman.pdf

https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/group__ClassicEvent.html#details

You also have the autobrief options which use the first line (until
the first dot) as the brief description.

do you still have issues with this change?

If nobody objects, then I will commit this on Monday and continue with
my documentation work.

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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: GMP is now a required dependency for building GDB


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



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


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

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



Ok, I will try this approach.

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: 
https://embedded-brains.de/datenschutzerklaerung/

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

[PATCH rtems v3 0/7] Add imxrt BSP

Hello,

again an updated version. There haven't been relevant changes beneath
patch 3 (some follow up ones in 7) so I'm only sending patch 3.

Changes:

- renames like suggested by Sebastian
- the MPU is now disabled, set up and re-enabled
- every MPU region is only set up once due to that
- I moved the constants for STM32H7 into a separate file to enable the
  main advantage of that initialization: Allowing the user to provide
  a different configuration in his application.

Best regards

Christian


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

[PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

Modify the MPU functions of the stm32h7 BSP to be table based and
available for all ARMV7M BSPs.

Update #4180
---
 bsps/arm/stm32h7/include/stm32h7/mpu-config.h |  44 +++
 bsps/arm/stm32h7/start/bspstarthooks.c| 120 +-
 bsps/arm/stm32h7/start/mpu-config.c   |  75 +++
 .../cpu/arm/include/rtems/score/armv7m.h  | 102 +++
 spec/build/bsps/arm/stm32h7/bspstm32h7.yml|   2 +
 5 files changed, 225 insertions(+), 118 deletions(-)
 create mode 100644 bsps/arm/stm32h7/include/stm32h7/mpu-config.h
 create mode 100644 bsps/arm/stm32h7/start/mpu-config.c

diff --git a/bsps/arm/stm32h7/include/stm32h7/mpu-config.h 
b/bsps/arm/stm32h7/include/stm32h7/mpu-config.h
new file mode 100644
index 00..274532
--- /dev/null
+++ b/bsps/arm/stm32h7/include/stm32h7/mpu-config.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 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 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 LIBBSP_ARM_STM32H7_STM32H7_MPU_CONFIG_H
+#define LIBBSP_ARM_STM32H7_STM32H7_MPU_CONFIG_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern const ARMV7M_MPU_Region_config stm32h7_config_mpu_region[];
+extern const size_t stm32h7_config_mpu_region_count;
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_STM32H7_STM32H7_MPU_CONFIG_H */
diff --git a/bsps/arm/stm32h7/start/bspstarthooks.c 
b/bsps/arm/stm32h7/start/bspstarthooks.c
index 565bd6876a..dcd4b0bef2 100644
--- a/bsps/arm/stm32h7/start/bspstarthooks.c
+++ b/bsps/arm/stm32h7/start/bspstarthooks.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -83,123 +84,6 @@ static void init_peripheral_clocks(void)
   }
 }
 
-static uint32_t get_region_size(uintptr_t size)
-{
-  if ((size & (size - 1)) == 0) {
-return ARMV7M_MPU_RASR_SIZE(30 - __builtin_clz(size));
-  } else {
-return ARMV7M_MPU_RASR_SIZE(31 - __builtin_clz(size));
-  }
-}
-
-static void set_region(
-  volatile ARMV7M_MPU *mpu,
-  uint32_t region,
-  uint32_t rasr,
-  const void *begin,
-  const void *end
-)
-{
-  uintptr_t size;
-  uint32_t rbar;
-
-  RTEMS_OBFUSCATE_VARIABLE(begin);
-  RTEMS_OBFUSCATE_VARIABLE(end);
-  size = (uintptr_t) end - (uintptr_t) begin;
-
-  if ( size > 0 ) {
-rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
-rasr |= get_region_size(size);
-  } else {
-rbar = region;
-rasr = 0;
-  }
-
-  mpu->rbar = rbar;
-  mpu->rasr = rasr;
-}
-
-static void init_mpu(void)
-{
-  volatile ARMV7M_MPU *mpu;
-  volatile ARMV7M_SCB *scb;
-  uint32_t region_count;
-  uint32_t region;
-
-  mpu = _ARMV7M_MPU;
-  scb = _ARMV7M_SCB;
-
-  region_count = ARMV7M_MPU_TYPE_DREGION_GET(mpu->type);
-
-  for (region = 0; region < region_count; ++region) {
-mpu->rbar = ARMV7M_MPU_RBAR_VALID | region;
-mpu->rasr = 0;
-  }
-
-  set_region(
-mpu,
-0,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_sram_axi_begin,
-stm32h7_memory_sram_axi_end
-  );
-  set_region(
-mpu,
-1,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_sdram_1_begin,
-stm32h7_memory_sdram_1_end
-  );
-  set_region(
-mpu,
-2,
-ARMV7M_MPU_RASR_AP(0x5)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-bsp_section_start_begin,
-bsp_section_text_end
-  );
-  set_re

Re: GMP is now a required dependency for building GDB


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


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



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


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

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



Ok, I will try this approach.

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

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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: Fatal exceptions on context-switching for more than two isolated threads


On 18/11/2020 18:53, Utkarsh Rai wrote:




On Wed, 18 Nov, 2020, 11:20 PM Gedare Bloom, > wrote:


Hi Utkarsh,

I think I would like to see you try to unify the design so it works
the same with or without stack protections. In other words, redesign
these iterators to avoid inter-stack references between threads. Note
also Sebastian's last comment about nested iteration. Depending on the
design, to do this might require allocating space from the workspace
instead, and therefore using the configuration to control the
allocation limit. I can't be certain, but you might want to sketch out
a design idea first for how to make the iterators independent of the
thread stacks.

Gedare



Okay, I will look into this.


The support for nested iterations is necessary. I added an assert like this:

diff --git a/cpukit/score/src/userextiterate.c 
b/cpukit/score/src/userextiterate.c

index 06665a2d7a..e3aaae452f 100644
--- a/cpukit/score/src/userextiterate.c
+++ b/cpukit/score/src/userextiterate.c
@@ -190,6 +190,7 @@ void _User_extensions_Iterate(

   if ( executing != NULL ) {
 iter.previous = executing->last_user_extensions_iterator;
+    _Assert( executing->last_user_extensions_iterator == NULL );
 executing->last_user_extensions_iterator = &iter;
   }

This assertion fails on a couple of tests, for example psxcleanup.exe:

Breakpoint 5, _Terminate (the_source=RTEMS_FATAL_SOURCE_ASSERT, 
the_error=2136680) at ../../../cpukit/score/src/interr.c:36

36    _User_extensions_Fatal( the_source, the_error );
(gdb) bt
#0  _Terminate (the_source=RTEMS_FATAL_SOURCE_ASSERT, the_error=2136680) 
at ../../../cpukit/score/src/interr.c:36
#1  0x00101186 in rtems_fatal (fatal_source=RTEMS_FATAL_SOURCE_ASSERT, 
error_code=2136680) at ../../../cpukit/include/rtems/fatal.h:86
#2  0x001011f0 in __assert_func (file=0x12b6b4 
"../../../cpukit/score/src/userextiterate.c", line=193, func=0x12b6e0 
<__func__.3> "_User_extensions_Iterate", failedexpr=0x12b680 
"executing->last_user_extensions_iterator == NULL") at 
../../../cpukit/libcsupport/src/__assert.c:52
#3  0x00118b54 in _User_extensions_Iterate (arg=0x201f80 
<_POSIX_Threads_Objects+1304>, visitor=0x118a61 
<_User_extensions_Thread_terminate_visitor>, 
direction=CHAIN_ITERATOR_BACKWARD) at 
../../../cpukit/score/src/userextiterate.c:193
#4  0x00116256 in _User_extensions_Thread_terminate (executing=0x201f80 
<_POSIX_Threads_Objects+1304>) at 
../../../cpukit/include/rtems/score/userextimpl.h:461
#5  0x0011667c in _Thread_Life_action_handler (executing=0x201f80 
<_POSIX_Threads_Objects+1304>, action=0x2021c4 
<_POSIX_Threads_Objects+1884>, lock_context=0x209b0c) at 
../../../cpukit/score/src/threadrestart.c:320
#6  0x00110a18 in _Thread_Run_post_switch_actions (executing=0x201f80 
<_POSIX_Threads_Objects+1304>) at 
../../../cpukit/score/src/threaddispatch.c:250
#7  0x00110b56 in _Thread_Do_dispatch (cpu_self=0x2005c0 
<_Per_CPU_Information>, level=1611596115) at 
../../../cpukit/score/src/threaddispatch.c:328
#8  0x00110b82 in _Thread_Dispatch_direct (cpu_self=0x2005c0 
<_Per_CPU_Information>) at ../../../cpukit/score/src/threaddispatch.c:359
#9  0x0010943a in pthread_exit (value_ptr=0x0) at 
../../../cpukit/posix/src/pthreadexit.c:38
#10 0x001092a6 in _POSIX_Threads_Exitted_extension (executing=0x201f80 
<_POSIX_Threads_Objects+1304>) at 
../../../cpukit/posix/src/pthreadcreate.c:470
#11 0x00118a26 in _User_extensions_Thread_exitted_visitor 
(executing=0x201f80 <_POSIX_Threads_Objects+1304>, arg=0x201f80 
<_POSIX_Threads_Objects+1304>, callouts=0x2001d0 
<_POSIX_Threads_User_extensions+20>) at 
../../../cpukit/score/src/userextiterate.c:116
#12 0x00118b88 in _User_extensions_Iterate (arg=0x201f80 
<_POSIX_Threads_Objects+1304>, visitor=0x118a09 
<_User_extensions_Thread_exitted_visitor>, 
direction=CHAIN_ITERATOR_FORWARD) at 
../../../cpukit/score/src/userextiterate.c:205
#13 0x0011101a in _User_extensions_Thread_exitted (executing=0x201f80 
<_POSIX_Threads_Objects+1304>) at 
../../../cpukit/include/rtems/score/userextimpl.h:425
#14 0x001110da in _Thread_Handler () at 
../../../cpukit/score/src/threadhandler.c:152


You cannot use the workspace in this environment.

There are a couple of other areas in RTEMS in which the stack of another 
thread may be accessed (events, message queues, signals). How did you 
solve this?


One option is to temporarily disable the thread stack protection in 
these areas. Something like:


state = disable_thread_stack_protection();

/* Access stack of another thread */

restore_thread_stack_protection(state);

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU


On 19/11/2020 09:51, Christian Mauderer wrote:


+  _Assert(cfg_count > region_count);


 _Assert(cfg_count <= region_count)

With this change it is fine to check in.

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: 
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU



On 19/11/2020 09:51, Christian Mauderer wrote:

+  mpu = _ARMV7M_MPU;
+  scb = _ARMV7M_SCB;
+
+  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
I think it is not necessary to touch the shcsr. Disabling the MPU should 
be enough.

+  mpu->ctrl = 0;
+
+  _ARM_Data_synchronization_barrier();
+  _ARM_Instruction_synchronization_barrier();


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: 
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU


Am 19.11.20 um 10:14 schrieb Sebastian Huber:

On 19/11/2020 09:51, Christian Mauderer wrote:


+  _Assert(cfg_count > region_count);


  _Assert(cfg_count <= region_count)

With this change it is fine to check in.



Stupid mistake. Sorry. I'll fix it before check in.

I'll give the other patches one more day for review.

Best regards

Christian
--

embedded brains GmbH
Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU


Am 19.11.20 um 10:15 schrieb Sebastian Huber:


On 19/11/2020 09:51, Christian Mauderer wrote:

+  mpu = _ARMV7M_MPU;
+  scb = _ARMV7M_SCB;
+
+  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
I think it is not necessary to touch the shcsr. Disabling the MPU should 
be enough.


OK. I'll try it on the imxrt.


+  mpu->ctrl = 0;
+
+  _ARM_Data_synchronization_barrier();
+  _ARM_Instruction_synchronization_barrier();




--

embedded brains GmbH
Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU


Am 19.11.20 um 10:22 schrieb Christian Mauderer:

Am 19.11.20 um 10:15 schrieb Sebastian Huber:


On 19/11/2020 09:51, Christian Mauderer wrote:

+  mpu = _ARMV7M_MPU;
+  scb = _ARMV7M_SCB;
+
+  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
I think it is not necessary to touch the shcsr. Disabling the MPU 
should be enough.


OK. I'll try it on the imxrt.


Seems to be no problem to remove that line. I'll do that before pushing.




+  mpu->ctrl = 0;
+
+  _ARM_Data_synchronization_barrier();
+  _ARM_Instruction_synchronization_barrier();






--

embedded brains GmbH
Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
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 1/2] config: Simplify task stack allocator init


On 19/11/2020 08:41, Sebastian Huber wrote:


+  RTEMS_STATIC_ASSERT(
+CONFIGURE_TASK_STACK_ALLOCATOR != NULL,
+CONFIGURE_TASK_STACK_ALLOCATOR_MUST_NOT_BE_NULL
+  );
+
const Stack_Allocator_allocate _Stack_Allocator_allocate =
  CONFIGURE_TASK_STACK_ALLOCATOR;


This can lead to warnings from the C++ compiler (GCC):

warning: the address of ‘i’ will never be NULL [-Waddress]

clang:

warning: comparison of address of 'i' not equal to a null pointer is 
always true [-Wtautological-pointer-compare]


It can be fixed by using for GCC:

(uintp_t) CONFIGURE_TASK_STACK_ALLOCATOR != 0

However, clang doesn't like this:

error: static_assert expression is not an integral constant expression
static_assert((long)&i != 0, "x");

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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] eng: Rework and clarify Doxygen Guidelines

2020-11-19 Thread Joel Sherrill

OK.I must have been remembering some old Doxygen stuff. I first used it
20 years ago and I am sure plenty has changed over the years.

Is there guidance on embedding figures? dot, plantuml, mscgen? I don't
recall if there are actual graphic images embedded. But if there are, we
should have source in some acceptable open format.

On Thu, Nov 19, 2020 at 2:32 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 10/11/2020 13:55, Sebastian Huber wrote:
>
> > Hello Joel,
> >
> > On 09/11/2020 15:37, Sebastian Huber wrote:
> >> On 09/11/2020 15:12, Joel Sherrill wrote:
> >>
> >>> On Mon, Nov 9, 2020 at 8:02 AM Sebastian Huber
> >>>  >>> > wrote:
> >>>
> >>> ---
> >>>  eng/coding-doxygen.rst  | 210
> >>> 
> >>>  eng/coding-file-hdr.rst |   2 +
> >>>  2 files changed, 149 insertions(+), 63 deletions(-)
> >>>
> >>> diff --git a/eng/coding-doxygen.rst b/eng/coding-doxygen.rst
> >>> index f4308ef..b2e6b61 100644
> >>> --- a/eng/coding-doxygen.rst
> >>> +++ b/eng/coding-doxygen.rst
> >>> @@ -16,12 +16,13 @@ In the RTEMS source code, CamelCase is rarely
> >>> used, so this makes it easier to
> >>>  search and replace Doxygen groups.  It avoids ambiguous
> >>> references to
> >>>  functions, types, defines, macros, and groups.  All groups shall
> >>> have an
> >>>  ``RTEMS`` prefix.  This makes it possible to include the RTEMS
> >>> files with
> >>> -Doxygen comments in a larger project without name conflicts.
> >>> +Doxygen comments in a larger project without name conflicts. The
> >>> group name
> >>> +shall use `Title Case
> >>>  >>> >`_.
> >>>
> >>>  .. code:: c
> >>>
> >>>  /**
> >>> - * @defgroup RTEMSScoreThread
> >>> + * @defgroup RTEMSScoreThread Thread Handler
> >>>   *
> >>>   * @ingrop RTEMSScore
> >>>   *
> >>> @@ -36,18 +37,28 @@ global variable declaration shall belong to at
> >>> least one Doxygen group.  Use
> >>>  ``@defgroup`` and ``@addtogroup`` with ``@{`` and ``@}`` brackets
> >>> to add
> >>>  members to a group.  A group shall be defined at most once. Each
> >>> group shall
> >>>  be documented with an ``@brief`` description and an optional
> >>> detailed
> >>> -description.  The ``@brief`` description shall use
> >>> -`Title Case  >>> >`_.
> >>> -Use grammatically correct sentences for the detailed descriptions.
> >>> +description.  Use grammatically correct sentences for the
> >>> ``@brief`` and
> >>> +detailed descriptions.
> >>> +
> >>> +For the ``@brief`` description use phrases like this:
> >>> +
> >>> +* This group contains ... and so on.
> >>> +
> >>> +* The XYZ Handler provides ... and so on.
> >>> +
> >>> +* The ABC Component contains ... and so on.
> >>>
> >>>
> >>> I don't know where the idea @brief should be short sentences came from.
> >> I reviewed the Doxgyen HTML and PDF output and come to the conclusion
> >> that the use of Title Case makes no sense for the brief descriptions.
> >>> @brief is used to make table of contents type pages and those should
> >>> read more like titles than the first sentence of the detailed
> >>> description.
> >>>
> >>>
> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/modules.html
> >>> <
> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/modules.html>
>
> >>>
> >> That Doxgyen removes a trailing '.' from the brief descriptions is a
> >> bug or feature. I didn't find a corresponding view in the PDF.
> >>>
> >>> If you look at the PDF, it really is used for the Table of Contents and
> >>> a sentence is quite odd there.
> >>>
> >>> It should read like a chapter title
> >>
> >> I looked at the PDF output and the brief descriptions are not
> >> included in the table of contents. The group names are included in
> >> the table of contents. For the group names Title Case should be used.
> >> The brief descriptions are the first sentence of the module
> >> description. This is identical to the HTML output.
> >>
> >> Please have a look at:
> >>
> >> https://ftp.rtems.org/pub/rtems/people/sebh/refman.pdf
> >>
> >>
> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/group__ClassicEvent.html#details
> >>
> >>
> >> You also have the autobrief options which use the first line (until
> >> the first dot) as the brief description.
> >>
> > do you still have issues with this change?
> >
> If nobody objects, then I will commit this on Monday and continue with
> my documentation work.
>
> --
> embedded brains GmbH
> Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.h

[PATCH v2 2/2] config: Initialize task stack allocator on demand

Register a custom task stack allocator initialization handler only if
necessary.
---
 cpukit/include/rtems/confdefs/wkspace.h | 19 +++
 cpukit/score/src/stackallocatorinit.c   |  5 +
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
b/cpukit/include/rtems/confdefs/wkspace.h
index 81d172815e..803d8bdc10 100644
--- a/cpukit/include/rtems/confdefs/wkspace.h
+++ b/cpukit/include/rtems/confdefs/wkspace.h
@@ -150,10 +150,19 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
   #endif
 
   #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT
+RTEMS_STATIC_ASSERT(
+  CONFIGURE_TASK_STACK_ALLOCATOR_INIT != NULL,
+  CONFIGURE_TASK_STACK_ALLOCATOR_INIT_MUST_NOT_BE_NULL
+);
+
 const Stack_Allocator_initialize _Stack_Allocator_initialize =
   CONFIGURE_TASK_STACK_ALLOCATOR_INIT;
-  #else
-const Stack_Allocator_initialize _Stack_Allocator_initialize = NULL;
+
+RTEMS_SYSINIT_ITEM(
+  _Stack_Allocator_do_initialize,
+  RTEMS_SYSINIT_DIRTY_MEMORY,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
   #endif
 
   RTEMS_STATIC_ASSERT(
@@ -172,12 +181,6 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
   const Stack_Allocator_free _Stack_Allocator_free =
 CONFIGURE_TASK_STACK_DEALLOCATOR;
 
-  RTEMS_SYSINIT_ITEM(
-_Stack_Allocator_do_initialize,
-RTEMS_SYSINIT_DIRTY_MEMORY,
-RTEMS_SYSINIT_ORDER_MIDDLE
-  );
-
   #pragma GCC diagnostic pop
 #elif defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
   || defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
diff --git a/cpukit/score/src/stackallocatorinit.c 
b/cpukit/score/src/stackallocatorinit.c
index 412e3142b3..31e239bd46 100644
--- a/cpukit/score/src/stackallocatorinit.c
+++ b/cpukit/score/src/stackallocatorinit.c
@@ -45,8 +45,5 @@ void _Stack_Allocator_do_initialize( void )
   rtems_stack_allocate_init_hook init_hook;
 
   init_hook = rtems_configuration_get_stack_allocate_init_hook();
-
-  if ( init_hook  != NULL ) {
-(*init_hook )( rtems_configuration_get_stack_space_size() );
-  }
+  ( *init_hook )( rtems_configuration_get_stack_space_size() );
 }
-- 
2.26.2

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

[PATCH v2 1/2] config: Simplify task stack allocator init

Replace runtime checks with compile time assertions.  This makes the
INTERNAL_ERROR_BAD_STACK_HOOK obsolete.
---
v2:

Add pragmas to ignore potential warnings from the static assertions.

 cpukit/include/rtems/confdefs/wkspace.h | 18 ++
 cpukit/include/rtems/score/interr.h |  2 +-
 cpukit/score/src/stackallocatorinit.c   |  8 -
 spec/build/testsuites/sptests/grp.yml   |  2 --
 spec/build/testsuites/sptests/spfatal06.yml | 19 ---
 testsuites/sptests/Makefile.am  |  9 -
 testsuites/sptests/configure.ac |  1 -
 testsuites/sptests/spfatal06/init.c | 38 -
 testsuites/sptests/spfatal06/spfatal06.doc  | 20 ---
 testsuites/sptests/spfatal06/spfatal06.scn  |  3 --
 testsuites/sptests/spinternalerror01/init.c | 15 ++--
 testsuites/sptests/sptimecounter01/init.c   | 15 ++--
 12 files changed, 45 insertions(+), 105 deletions(-)
 delete mode 100644 spec/build/testsuites/sptests/spfatal06.yml
 delete mode 100644 testsuites/sptests/spfatal06/init.c
 delete mode 100644 testsuites/sptests/spfatal06/spfatal06.doc
 delete mode 100644 testsuites/sptests/spfatal06/spfatal06.scn

diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
b/cpukit/include/rtems/confdefs/wkspace.h
index d40194cbec..81d172815e 100644
--- a/cpukit/include/rtems/confdefs/wkspace.h
+++ b/cpukit/include/rtems/confdefs/wkspace.h
@@ -137,6 +137,12 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
 
 #if defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
   && defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
+  /* Ignore potential warnings from the static assertions below */
+  #pragma GCC diagnostic push
+  #pragma GCC diagnostic ignored "-Waddress"
+  #pragma GCC diagnostic ignored "-Wpragmas"
+  #pragma GCC diagnostic ignored "-Wtautological-pointer-compare"
+
   #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_AVOIDS_WORK_SPACE
 const bool _Stack_Allocator_avoids_workspace = true;
   #else
@@ -150,9 +156,19 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
 const Stack_Allocator_initialize _Stack_Allocator_initialize = NULL;
   #endif
 
+  RTEMS_STATIC_ASSERT(
+CONFIGURE_TASK_STACK_ALLOCATOR != NULL,
+CONFIGURE_TASK_STACK_ALLOCATOR_MUST_NOT_BE_NULL
+  );
+
   const Stack_Allocator_allocate _Stack_Allocator_allocate =
 CONFIGURE_TASK_STACK_ALLOCATOR;
 
+  RTEMS_STATIC_ASSERT(
+CONFIGURE_TASK_STACK_DEALLOCATOR != NULL,
+CONFIGURE_TASK_STACK_DEALLOCATOR_MUST_NOT_BE_NULL
+  );
+
   const Stack_Allocator_free _Stack_Allocator_free =
 CONFIGURE_TASK_STACK_DEALLOCATOR;
 
@@ -161,6 +177,8 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
 RTEMS_SYSINIT_DIRTY_MEMORY,
 RTEMS_SYSINIT_ORDER_MIDDLE
   );
+
+  #pragma GCC diagnostic pop
 #elif defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
   || defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
   #error "CONFIGURE_TASK_STACK_ALLOCATOR and CONFIGURE_TASK_STACK_DEALLOCATOR 
must be both defined or both undefined"
diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 85767d0bc5..4b06199ae9 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -177,7 +177,7 @@ typedef enum {
   INTERNAL_ERROR_OUT_OF_GLOBAL_OBJECTS = 11,
   INTERNAL_ERROR_OUT_OF_PROXIES = 12,
   INTERNAL_ERROR_INVALID_GLOBAL_ID = 13,
-  INTERNAL_ERROR_BAD_STACK_HOOK = 14,
+  /* INTERNAL_ERROR_BAD_STACK_HOOK = 14, */
   /* INTERNAL_ERROR_BAD_ATTRIBUTES = 15, */
   /* INTERNAL_ERROR_IMPLEMENTATION_KEY_CREATE_INCONSISTENCY = 16, */
   /* INTERNAL_ERROR_IMPLEMENTATION_BLOCKING_OPERATION_CANCEL = 17, */
diff --git a/cpukit/score/src/stackallocatorinit.c 
b/cpukit/score/src/stackallocatorinit.c
index 60d243631f..412e3142b3 100644
--- a/cpukit/score/src/stackallocatorinit.c
+++ b/cpukit/score/src/stackallocatorinit.c
@@ -38,20 +38,12 @@
 #endif
 
 #include 
-#include 
 #include 
 
 void _Stack_Allocator_do_initialize( void )
 {
   rtems_stack_allocate_init_hook init_hook;
 
-  if (
-rtems_configuration_get_stack_allocate_hook() == NULL
-  || rtems_configuration_get_stack_free_hook() == NULL
-  ) {
-_Internal_error( INTERNAL_ERROR_BAD_STACK_HOOK );
-  }
-
   init_hook = rtems_configuration_get_stack_allocate_init_hook();
 
   if ( init_hook  != NULL ) {
diff --git a/spec/build/testsuites/sptests/grp.yml 
b/spec/build/testsuites/sptests/grp.yml
index 64b0a54b0e..1c865777a7 100644
--- a/spec/build/testsuites/sptests/grp.yml
+++ b/spec/build/testsuites/sptests/grp.yml
@@ -226,8 +226,6 @@ links:
   uid: spfatal04
 - role: build-dependency
   uid: spfatal05
-- role: build-dependency
-  uid: spfatal06
 - role: build-dependency
   uid: spfatal09
 - role: build-dependency
diff --git a/spec/build/testsuites/sptests/spfatal06.yml 
b/spec/build/testsuites/sptests/spfatal06.yml
deleted file mode 100644
index 6e4be90a2a..00
--- a/spec/build/testsuites/sptests/spfatal06.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-SPDX-Lic

Re: Fatal exceptions on context-switching for more than two isolated threads

Hi Utkarsh,

On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber
 wrote:
>
> On 19/11/2020 11:47, Utkarsh Rai wrote:
>
> > There are a couple of other areas in RTEMS in which the stack of
> > another
> > thread may be accessed (events, message queues, signals). How did you
> > solve this?
> >
> >
> > When we enable the thread stack protection, all the services in which
> > a different stack is accessed becomes invalid ( This will have to be
> > documented  ).
> > The user has to share the stack of the threads that will be using
> > services like message queue with each other from the application using
> > mmap(),shm_open(), etc. (This was a part of the work I did during GSoC).
>
> This is a bit too restrictive from my point of view. Consider for
> example this very common use of rtems_event_receive():
>
> rtems_event_set events;
>
> rtems_event_receive(..., &events, ...);
>
Let's try to keep the technical discussion on the mailing list. I
agree with Sebastian's point here, which is well taken. Maybe it would
be good for you to determine the set of tests and from that the
features that break with strict task isolation. This way, we can
determine whether each is better handled as imposing a requirement on
the user, e.g., to mmap/share explicitly in case they want to pass
data (such as with an mq), or if RTEMS needs to make it work
implicitly such as with event sets and maybe these iterators.

Gedare

> --
> embedded brains GmbH
> 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
> PGP: Public key available on request.
>
> embedded brains GmbH
> 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: Doubt in rtems_task_wake_after

On Wed, Nov 18, 2020 at 11:13 PM Richi Dubey  wrote:
>
> Hi,
>
> In the program tm24, the Init task creates only 1 HIGH task that executes 
> (after Init task finishes) the High_task function and then the Init task 
> creates 100 REST or LOOP task which execute (After High_task finishes) the 
> Tasks function.
>
> Then, how can the High_task call rtems_task_wake_after 100 times? Shouldn't 
> it exit right after a single call to rtems_task_wake_after, since the 
> function yields the processor that is held by the executing thread?
>
Yield is only to give up the processor to same priority tasks. Does that help?

> Please let me know how this works.
>
> Thanks,
> Richi.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Update internal error list

ok.

On Thu, Nov 19, 2020 at 12:55 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/fatal_error.rst | 37 -
>  1 file changed, 8 insertions(+), 29 deletions(-)
>
> diff --git a/c-user/fatal_error.rst b/c-user/fatal_error.rst
> index 2c72deb..81cfa0c 100644
> --- a/c-user/fatal_error.rst
> +++ b/c-user/fatal_error.rst
> @@ -146,15 +146,6 @@ INTERNAL_ERROR_TOO_LITTLE_WORKSPACE (2)
>  There is not enough memory for the workspace.  This fatal error may occur
>  during system initialization.  It is an application configuration error.
>
> -INTERNAL_ERROR_WORKSPACE_ALLOCATION (3)
> -An allocation from the workspace failed.  This fatal error may occur 
> during
> -system initialization.  It is an application configuration error.
> -
> -INTERNAL_ERROR_INTERRUPT_STACK_TOO_SMALL (4)
> -The configured interrupt stack size is too small.  This fatal error may
> -occur during system initialization.  It is an application configuration
> -error.
> -
>  INTERNAL_ERROR_THREAD_EXITTED (5)
>  A non-POSIX thread entry function returned.  This is an API usage error.
>
> @@ -222,17 +213,6 @@ INTERNAL_ERROR_INVALID_GLOBAL_ID (13)
>  find the global object for a specific object identifier.  In case this
>  happens, then this is probably an operating system bug.
>
> -INTERNAL_ERROR_BAD_STACK_HOOK (14)
> -The stack allocator hook or stack free hook is NULL.  This fatal error 
> may
> -occur during system initialization.  It is an application configuration
> -error.
> -
> -INTERNAL_ERROR_UNLIMITED_AND_MAXIMUM_IS_0 (19)
> -An object class is configured to use the unlimited objects option, 
> however,
> -the count of objects for each extension is zero.  This fatal error may
> -occur during system initialization.  It is an application configuration
> -error.
> -
>  INTERNAL_ERROR_NO_MEMORY_FOR_HEAP (23)
>  There is not enough memory for the C program heap.  This fatal error may
>  occur during system initialization.  It is an application configuration
> @@ -372,15 +352,6 @@ INTERNAL_ERROR_POSIX_INIT_THREAD_CREATE_FAILED (33)
>  occur during system initialization.  It is an application configuration
>  error.
>
> -INTERNAL_ERROR_LIBIO_USER_ENV_KEY_CREATE_FAILED (34)
> -Creation of the IO library user environment POSIX key failed.  This fatal
> -error may occur during system initialization.  It is an application
> -configuration error.
> -
> -INTERNAL_ERROR_LIBIO_SEM_CREATE_FAILED (35)
> -Creation of the IO library semaphore failed.  This fatal error may occur
> -during system initialization.  It is an application configuration error.
> -
>  INTERNAL_ERROR_LIBIO_STDOUT_FD_OPEN_FAILED (36)
>  Open of the standard output file descriptor failed or resulted in an
>  unexpected file descriptor number.  This fatal error may occur during
> @@ -405,6 +376,14 @@ INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA (40)
>  enough memory available to populate the per-CPU data areas, see
>  ` 
> `_.
>
> +INTERNAL_ERROR_TOO_LARGE_TLS_SIZE (41)
> +This fatal error may happen during system initialization.  The actual
> +thread-local storage (TLS) size of the application exceeds the configured
> +maximum, see
> +:ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE 
> `.
> +You can get the thread-local storage size of an application using the 
> RTEMS
> +tool ``rtems-execinfo``.
> +
>  Operations
>  ==
>
> --
> 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 v2 2/2] config: Initialize task stack allocator on demand

On Thu, Nov 19, 2020 at 9:42 AM Sebastian Huber
 wrote:
>
> Register a custom task stack allocator initialization handler only if
> necessary.
> ---
>  cpukit/include/rtems/confdefs/wkspace.h | 19 +++
>  cpukit/score/src/stackallocatorinit.c   |  5 +
>  2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
> b/cpukit/include/rtems/confdefs/wkspace.h
> index 81d172815e..803d8bdc10 100644
> --- a/cpukit/include/rtems/confdefs/wkspace.h
> +++ b/cpukit/include/rtems/confdefs/wkspace.h
> @@ -150,10 +150,19 @@ const uintptr_t _Stack_Space_size = 
> _CONFIGURE_STACK_SPACE_SIZE;
>#endif
>
>#ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT
> +RTEMS_STATIC_ASSERT(
> +  CONFIGURE_TASK_STACK_ALLOCATOR_INIT != NULL,
> +  CONFIGURE_TASK_STACK_ALLOCATOR_INIT_MUST_NOT_BE_NULL
> +);
> +
>  const Stack_Allocator_initialize _Stack_Allocator_initialize =
>CONFIGURE_TASK_STACK_ALLOCATOR_INIT;
> -  #else
> -const Stack_Allocator_initialize _Stack_Allocator_initialize = NULL;
> +
> +RTEMS_SYSINIT_ITEM(
> +  _Stack_Allocator_do_initialize,
> +  RTEMS_SYSINIT_DIRTY_MEMORY,
> +  RTEMS_SYSINIT_ORDER_MIDDLE
> +);
>#endif
>
>RTEMS_STATIC_ASSERT(
> @@ -172,12 +181,6 @@ const uintptr_t _Stack_Space_size = 
> _CONFIGURE_STACK_SPACE_SIZE;
>const Stack_Allocator_free _Stack_Allocator_free =
>  CONFIGURE_TASK_STACK_DEALLOCATOR;
>
> -  RTEMS_SYSINIT_ITEM(
> -_Stack_Allocator_do_initialize,
> -RTEMS_SYSINIT_DIRTY_MEMORY,
> -RTEMS_SYSINIT_ORDER_MIDDLE
> -  );
> -
>#pragma GCC diagnostic pop
>  #elif defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
>|| defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
> diff --git a/cpukit/score/src/stackallocatorinit.c 
> b/cpukit/score/src/stackallocatorinit.c
> index 412e3142b3..31e239bd46 100644
> --- a/cpukit/score/src/stackallocatorinit.c
> +++ b/cpukit/score/src/stackallocatorinit.c
> @@ -45,8 +45,5 @@ void _Stack_Allocator_do_initialize( void )
>rtems_stack_allocate_init_hook init_hook;
>
>init_hook = rtems_configuration_get_stack_allocate_init_hook();
> -
> -  if ( init_hook  != NULL ) {
this could be made an assert, but anyway seems ok

> -(*init_hook )( rtems_configuration_get_stack_space_size() );
> -  }
> +  ( *init_hook )( rtems_configuration_get_stack_space_size() );
>  }
> --
> 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 rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

Hi Sebastian, Christian:

I saw the req

On Thu, Nov 19, 2020 at 3:17 AM Christian Mauderer
 wrote:
>
> Am 19.11.20 um 10:22 schrieb Christian Mauderer:
> > Am 19.11.20 um 10:15 schrieb Sebastian Huber:
> >>
> >> On 19/11/2020 09:51, Christian Mauderer wrote:
> >>> +  mpu = _ARMV7M_MPU;
> >>> +  scb = _ARMV7M_SCB;
> >>> +
> >>> +  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
> >> I think it is not necessary to touch the shcsr. Disabling the MPU
> >> should be enough.
> >
> > OK. I'll try it on the imxrt.
>
> Seems to be no problem to remove that line. I'll do that before pushing.
>
> >
> >>> +  mpu->ctrl = 0;
> >>> +
> >>> +  _ARM_Data_synchronization_barrier();
> >>> +  _ARM_Instruction_synchronization_barrier();
> >>
> >
>
> --
> 
> embedded brains GmbH
> Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> embedded brains GmbH
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

On Thu, Nov 19, 2020 at 1:13 PM Gedare Bloom  wrote:
>
> Hi Sebastian, Christian:
>
> I saw the req
Oops, gmail shortcuts cut me off.

I saw the request to change the names, but I think the _ARMV7M_MPU_yyy
is correct, because MPU is the capitalized first "word" of the
subgroup there. It is consistent with the naming of other
_ARMV7M_Xxx_yyy routines.

>
> On Thu, Nov 19, 2020 at 3:17 AM Christian Mauderer
>  wrote:
> >
> > Am 19.11.20 um 10:22 schrieb Christian Mauderer:
> > > Am 19.11.20 um 10:15 schrieb Sebastian Huber:
> > >>
> > >> On 19/11/2020 09:51, Christian Mauderer wrote:
> > >>> +  mpu = _ARMV7M_MPU;
> > >>> +  scb = _ARMV7M_SCB;
> > >>> +
> > >>> +  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
> > >> I think it is not necessary to touch the shcsr. Disabling the MPU
> > >> should be enough.
> > >
> > > OK. I'll try it on the imxrt.
> >
> > Seems to be no problem to remove that line. I'll do that before pushing.
> >
> > >
> > >>> +  mpu->ctrl = 0;
> > >>> +
> > >>> +  _ARM_Data_synchronization_barrier();
> > >>> +  _ARM_Instruction_synchronization_barrier();
> > >>
> > >
> >
> > --
> > 
> > embedded brains GmbH
> > Christian MAUDERER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: christian.maude...@embedded-brains.de
> > Phone: +49-89-18 94 741 - 18
> > Fax:   +49-89-18 94 741 - 08
> > PGP: Public key available on request.
> >
> > embedded brains GmbH
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

On 19/11/2020 21:14, Gedare Bloom wrote:
> On Thu, Nov 19, 2020 at 1:13 PM Gedare Bloom  wrote:
>>
>> Hi Sebastian, Christian:
>>
>> I saw the req
> Oops, gmail shortcuts cut me off.
> 
> I saw the request to change the names, but I think the _ARMV7M_MPU_yyy
> is correct, because MPU is the capitalized first "word" of the
> subgroup there. It is consistent with the naming of other
> _ARMV7M_Xxx_yyy routines.

But there is for example

_ARMV7M_NVIC_Is_enabled
_ARMV7M_NVIC_Set_enable
_ARMV7M_DWT_Enable_CYCCNT
ARMV7M_MPU_Access_permissions

and some others in the same file. So I would lean towards what Sebastian
suggested. Otherwise the new functions wouldn't fit the scheme of the
existing ones.

> 
>>
>> On Thu, Nov 19, 2020 at 3:17 AM Christian Mauderer
>>  wrote:
>>>
>>> Am 19.11.20 um 10:22 schrieb Christian Mauderer:
 Am 19.11.20 um 10:15 schrieb Sebastian Huber:
>
> On 19/11/2020 09:51, Christian Mauderer wrote:
>> +  mpu = _ARMV7M_MPU;
>> +  scb = _ARMV7M_SCB;
>> +
>> +  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
> I think it is not necessary to touch the shcsr. Disabling the MPU
> should be enough.

 OK. I'll try it on the imxrt.
>>>
>>> Seems to be no problem to remove that line. I'll do that before pushing.
>>>

>> +  mpu->ctrl = 0;
>> +
>> +  _ARM_Data_synchronization_barrier();
>> +  _ARM_Instruction_synchronization_barrier();
>

>>>
>>> --
>>> 
>>> embedded brains GmbH
>>> Christian MAUDERER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: christian.maude...@embedded-brains.de
>>> Phone: +49-89-18 94 741 - 18
>>> Fax:   +49-89-18 94 741 - 08
>>> PGP: Public key available on request.
>>>
>>> embedded brains GmbH
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libdl: How to debug dl object with GDB

2020-11-19 Thread Chris Johns

On 19/11/20 5:33 pm, Hesham Almatary wrote:
> Thanks for the info, Chris.
> 
> On Wed, 18 Nov 2020 at 02:43, Chris Johns  wrote:
>> On 17/11/20 10:43 pm, Hesham Almatary wrote:
>>> Hello,
>>>
>>> I am trying to debug a dynamically loaded ELF object with GDB: My setup is:
>>> rtems-riscv64:
>>> GDB: GNU gdb (GDB) 10.0.50.20200904-git (build with RSB/rtems6)
>>> Host: Ubuntu 20.04.1 LTS
>>>
>>> GDB doesn't seem to notice when I dlopen an object (which gets loaded,
>>> linked and run fine).
>>
>> libdl has the NetBSD type support built in for debugging. A function is 
>> called
>> when a module is loaded and there is a table of modules GDB reads and then 
>> loads
>> the object file.
>>
> Is that expected to work on Linux with recent GDB versions? 

We need a patch for GDB to add the support needed for RTEMS.

> GDB
> doesn't seem to detect when "_rtld_debug_state" is called from dlopen,
> and consequently isn't aware of the list of objects. Does that need
> GDB to be modified with solib-rtems* or something?

A patch was created as part the 2013 RTL GSoC project (an excellent year for
students :)). The repo is https://github.com/MrVan/gdb/commits/rtems-gdb. The
only problem is GDB has moved to C++ since then and I am not sure what effect
that has had on the patch.

>>> Any instructions or idea how to troubleshoot that further?
>>
>> At this point the simplest path is to get the load address(es) and load the
>> symbols with the VMA.
>>
> I can use "add-symbol-file" filename for each object and give it the
> text_base address. This only allows me to break on functions within
> loaded objects. If that's not what you mean, how can I load the
> symbols with the VMA?

I think using a command is always going to be a bit of a hack. The patch Peng
created allowed you to set breakpoints in code that was not loaded and it would
break when loaded _and_ executed.

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

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

On Thu, Nov 19, 2020 at 1:19 PM Christian Mauderer  wrote:
>
> On 19/11/2020 21:14, Gedare Bloom wrote:
> > On Thu, Nov 19, 2020 at 1:13 PM Gedare Bloom  wrote:
> >>
> >> Hi Sebastian, Christian:
> >>
> >> I saw the req
> > Oops, gmail shortcuts cut me off.
> >
> > I saw the request to change the names, but I think the _ARMV7M_MPU_yyy
> > is correct, because MPU is the capitalized first "word" of the
> > subgroup there. It is consistent with the naming of other
> > _ARMV7M_Xxx_yyy routines.
>
> But there is for example
>
> _ARMV7M_NVIC_Is_enabled
> _ARMV7M_NVIC_Set_enable
> _ARMV7M_DWT_Enable_CYCCNT
> ARMV7M_MPU_Access_permissions
>
> and some others in the same file. So I would lean towards what Sebastian
> suggested. Otherwise the new functions wouldn't fit the scheme of the
> existing ones.
>
OK, I don't think those are proper, but consistency is good. You can
proceed with the MPU_Xxx

> >
> >>
> >> On Thu, Nov 19, 2020 at 3:17 AM Christian Mauderer
> >>  wrote:
> >>>
> >>> Am 19.11.20 um 10:22 schrieb Christian Mauderer:
>  Am 19.11.20 um 10:15 schrieb Sebastian Huber:
> >
> > On 19/11/2020 09:51, Christian Mauderer wrote:
> >> +  mpu = _ARMV7M_MPU;
> >> +  scb = _ARMV7M_SCB;
> >> +
> >> +  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
> > I think it is not necessary to touch the shcsr. Disabling the MPU
> > should be enough.
> 
>  OK. I'll try it on the imxrt.
> >>>
> >>> Seems to be no problem to remove that line. I'll do that before pushing.
> >>>
> 
> >> +  mpu->ctrl = 0;
> >> +
> >> +  _ARM_Data_synchronization_barrier();
> >> +  _ARM_Instruction_synchronization_barrier();
> >
> 
> >>>
> >>> --
> >>> 
> >>> embedded brains GmbH
> >>> Christian MAUDERER
> >>> Dornierstr. 4
> >>> 82178 Puchheim
> >>> Germany
> >>> email: christian.maude...@embedded-brains.de
> >>> Phone: +49-89-18 94 741 - 18
> >>> Fax:   +49-89-18 94 741 - 08
> >>> PGP: Public key available on request.
> >>>
> >>> embedded brains GmbH
> >>> Registergericht: Amtsgericht München
> >>> Registernummer: HRB 157899
> >>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >>> Unsere Datenschutzerklärung finden Sie hier:
> >>> https://embedded-brains.de/datenschutzerklaerung/
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fatal exceptions on context-switching for more than two isolated threads

2020-11-19 Thread Utkarsh Rai

On Thu, Nov 19, 2020 at 11:39 PM Gedare Bloom  wrote:

> Hi Utkarsh,
>
> On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber
>  wrote:
> >
> > On 19/11/2020 11:47, Utkarsh Rai wrote:
> >
> > > There are a couple of other areas in RTEMS in which the stack of
> > > another
> > > thread may be accessed (events, message queues, signals). How did
> you
> > > solve this?
> > >
> > >
> > > When we enable the thread stack protection, all the services in which
> > > a different stack is accessed becomes invalid ( This will have to be
> > > documented  ).
> > > The user has to share the stack of the threads that will be using
> > > services like message queue with each other from the application using
> > > mmap(),shm_open(), etc. (This was a part of the work I did during
> GSoC).
> >
> > This is a bit too restrictive from my point of view. Consider for
> > example this very common use of rtems_event_receive():
> >
> > rtems_event_set events;
> >
> > rtems_event_receive(..., &events, ...);
> >
> Let's try to keep the technical discussion on the mailing list.


Oh sorry, I somehow forgot to cc the mailing list.


> I
> agree with Sebastian's point here, which is well taken. Maybe it would
> be good for you to determine the set of tests and from that the
> features that break with strict task isolation. This way, we can
> determine whether each is better handled as imposing a requirement on
> the user, e.g., to mmap/share explicitly in case they want to pass
> data (such as with an mq), or if RTEMS needs to make it work
> implicitly such as with event sets and maybe these iterators.
>
> Gedare
>


Ok.


>
> > --
> > embedded brains GmbH
> > 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
> > PGP: Public key available on request.
> >
> > embedded brains GmbH
> > 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: Fatal exceptions on context-switching for more than two isolated threads

2020-11-19 Thread Joel Sherrill

On Thu, Nov 19, 2020, 5:00 PM Utkarsh Rai  wrote:

>
>
> On Thu, Nov 19, 2020 at 11:39 PM Gedare Bloom  wrote:
>
>> Hi Utkarsh,
>>
>> On Thu, Nov 19, 2020 at 4:59 AM Sebastian Huber
>>  wrote:
>> >
>> > On 19/11/2020 11:47, Utkarsh Rai wrote:
>> >
>> > > There are a couple of other areas in RTEMS in which the stack of
>> > > another
>> > > thread may be accessed (events, message queues, signals). How did
>> you
>> > > solve this?
>> > >
>> > >
>> > > When we enable the thread stack protection, all the services in which
>> > > a different stack is accessed becomes invalid ( This will have to be
>> > > documented  ).
>> > > The user has to share the stack of the threads that will be using
>> > > services like message queue with each other from the application using
>> > > mmap(),shm_open(), etc. (This was a part of the work I did during
>> GSoC).
>> >
>> > This is a bit too restrictive from my point of view. Consider for
>> > example this very common use of rtems_event_receive():
>> >
>> > rtems_event_set events;
>> >
>> > rtems_event_receive(..., &events, ...);
>> >
>> Let's try to keep the technical discussion on the mailing list.
>
>
> Oh sorry, I somehow forgot to cc the mailing list.
>
>
>> I
>> agree with Sebastian's point here, which is well taken. Maybe it would
>> be good for you to determine the set of tests and from that the
>> features that break with strict task isolation. This way, we can
>> determine whether each is better handled as imposing a requirement on
>> the user, e.g., to mmap/share explicitly in case they want to pass
>> data (such as with an mq), or if RTEMS needs to make it work
>> implicitly such as with event sets and maybe these iterators.
>>
>
I believe that sending a message that unblocks a thread will have to
disable the protection.

The approach of identifying the few places in RTEMS that can legitimately
be expected to copy from one thread to another thread stack can be
identified and protection disabled for those segments of code. This would
at least properly annotate the known cases via communication and
synchronization and you could come back later and possibly tighten those
restrictions.

>
>> Gedare
>>
>
>
> Ok.
>
>
>>
>> > --
>> > embedded brains GmbH
>> > 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
>> > PGP: Public key available on request.
>> >
>> > embedded brains GmbH
>> > Registergericht: Amtsgericht München
>> > Registernummer: HRB 157899
>> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> > Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>> >
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Proposal for hardware configuration dependent performance limits

2020-11-19 Thread Chris Johns

On 19/11/20 7:26 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 17/11/2020 22:43, Chris Johns wrote:
> 
>>
>> On 17/11/20 6:14 pm, Sebastian Huber wrote:
>>> On 16/11/2020 23:42, Chris Johns wrote:
 On 16/11/20 5:40 pm, Sebastian Huber wrote:
> On 16/11/2020 00:33, Chris Johns wrote:
>
> In the proposal, limits are specified like this:
>
>
> limits:
>    sparc/gr712rc:
>  DirtyCache:
>    max-upper-bound: 0.05
>    mean-upper-bound: 0.05
>  FullCache:
>    max-upper-bound: 0.05
>    mean-upper-bound: 0.05
>  HotCache:
>    max-upper-bound: 0.05
>    mean-upper-bound: 0.05
>  Load/1:
>    max-upper-bound: 0.1
>    mean-upper-bound: 0.1
>  Load/2:
>    max-upper-bound: 0.1
>    mean-upper-bound: 0.1
>  Load/3:
>    max-upper-bound: 0.1
>    mean-upper-bound: 0.1
>  Load/4:
>    max-upper-bound: 0.1
>    mean-upper-bound: 0.1
>
> This neglects that the limits are subject to a board configuration. 
> One
> approach to cover this is the addition of a new BSP provided function:
>
> const char *rtems_get_hardware_performance_hash();
>
> The BSP feeds all performance related data into a hash function and
 "data" here means configuration?
>>> Yes, hardware configuration.
>> Why not make these values part of the BSP configuration? The defaults 
>> for the
>> BSP can have a set of suitable values. Different boards have different
>> configurations to match and a separate kernel build.
>>
> This doesn't work on BSPs which support configuration via a hardware
> enumeration, boot loader settings, or device trees. Also changes in the 
> BSP
> options have no influence on the BSP name. Not only BSP configuration
> influence
> performance, the CPU options play a role too, for example RTEMS_SMP. In
> order to
> compare performance values over time we have to obtain the values under 
> the
> same
> conditions.
 Maybe I am not understanding the context.

 A BSP, which ever one, has a set of options that configure it. An example 
 is
 the
 xilinx_zynq_zc702 and the `ZYNQ_RAM_LENGTH = 0x4000`. If I have 2 Zynq
 circuits one with 256M and one with 1G I need to build and maintain 2 RTEMS
 builds and from a purists point of view I need to maintain 2 builds of the
 exact
 same application.

 I asked about the fixed memory and your answer was to use the BSP options, 
 the
 size is fixed in the linker command files via the BSP option. That is what 
 I
 have done.

 I would expect there exists a set of values for the xilinx_zynq_zc702 with 
 no
 SMP and with SMP as this BSP supports SMP. Those values would match all the
 other settings for the BSP such as ZYNQ_CLOCK_CPU_1X,
 BSP_ARM_A9MPCORE_PERIPHCLK
 etc. If my clock is different (and they are) I would need to supply a 
 suitable
 set of performance values if I wanted to pass those tests.

 I am not questioning the need for the values or the tests. I am suggesting 
 the
 values form part of the BSP settings so a user can adjust them to suite 
 their
 specific set up in the same way they adjust other BSP settings. I do not 
 think
 we should attempt to hold or manage an endless sets of possible values and 
 I do
 not see the need for complex encapsulation methods such as a base64 
 hashes. The
 systems we interact with are too complex and list is endless.
>>> I think it will be highly BSP-specific what parameters are relevant to the
>>> performance limits. This is why I suggested to add a function which can be
>>> implemented by each BSP.
>>>
>>> const char *rtems_get_hardware_performance_something();
>>>
>>> It should return a string which changes if a performance relevant parameter
>>> changed. If it is only SMP/no-SMP, ZYNQ_CLOCK_CPU_1X, and
>>> BSP_ARM_A9MPCORE_PERIPHCLK, then fine, just return "SMP/800MHz/400MHz" or
>>> whatever.
>> I suggest you avoid heading down a path of specific strings, ie avoid 
>> something
>> meaningful a human can read. Also performance characteristics are a part of a
>> wider configuration topic. Maybe considering that would solve the performance
>> specific parts as well.
>>
>> A label for a build of RTEMS is a good idea (see below) that could serve the
>> human readable part. I would consider computing a hash for the config.ini 
>> file,
>> ie the build, and embedding it. If you wanted to capture the state of the 
>> RTEM

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU


On 19/11/2020 23:19, Gedare Bloom wrote:


But there is for example

_ARMV7M_NVIC_Is_enabled
_ARMV7M_NVIC_Set_enable
_ARMV7M_DWT_Enable_CYCCNT
ARMV7M_MPU_Access_permissions

and some others in the same file. So I would lean towards what Sebastian
suggested. Otherwise the new functions wouldn't fit the scheme of the
existing ones.


OK, I don't think those are proper, but consistency is good. You can
proceed with the MPU_Xxx


The idea was to have support for several hardware modules in this file. 
So, from the naming convention point of view _ARMV7M_NVIC and 
_ARMV7M_DWT are the modules and not simply _ARMV7M.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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: Fatal exceptions on context-switching for more than two isolated threads