Re: Proposal for hardware configuration dependent performance limits

[Sebastian Huber]

On 25/11/2020 21:37, Chris Johns wrote:


Maybe a configuration option for the RTEMS Tester should be added which allows
you to set the performance hash and ignore the hash provided by the test output.
This could be used to compare a custom board with values obtain from an
evaluation board.

Why not let the tester take an alternative set of values for the same hash to
override the "standard" set?


Do you mean that the performance limits should be specified with a 
particular hash like this:


limits:
    sparc/gr712rc/XrY7u+Ae7tCTyyK7j1rNww==:
  DirtyCache:
    max-upper-bound: 0.05
    mean-upper-bound: 0.05

In another item (for example the BSP build item) we could add a mapping from 
this hash value to a list of other hash values. For example:

performance-hash-equivalence-classes:
  XrY7u+Ae7tCTyyK7j1rNww==:
  - abc
  - def
  - ghi

We probably need also description:

performance-hash-description:
  XrY7u+Ae7tCTyyK7j1rNww==: |
Description.

Taking performance limits into account for test runs requires a bit of 
maintenance. The first step is being able to do it. The next step is to discuss 
if and how this could be done in the scope of the RTEMS Project.

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

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

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

[PATCH] rtems: Move "Set Errno" group to the API

[Sebastian Huber]

---
 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 27faca7694..711382d732 100644
--- a/cpukit/include/rtems/seterr.h
+++ b/cpukit/include/rtems/seterr.h
@@ -19,15 +19,15 @@
 #ifndef _RTEMS_SETERR_H
 #define _RTEMS_SETERR_H
 
+#include 
+
 /**
- *  @defgroup RTEMSScoreSetErr Set Errno
+ * @defgroup RTEMSAPISetErrno Set Errno
  *
- *  @ingroup RTEMSScore
+ * @ingroup RTEMSAPI
  *
+ * @{
  */
-/**@{*/
-
-#include 
 
 /**
  *  This is a helper macro which will set the variable errno and return
-- 
2.26.2

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

[PATCH] sapi: Remove obsolete README file

[Sebastian Huber]

---
 cpukit/sapi/include/rtems/README | 129 ---
 1 file changed, 129 deletions(-)
 delete mode 100644 cpukit/sapi/include/rtems/README

diff --git a/cpukit/sapi/include/rtems/README b/cpukit/sapi/include/rtems/README
deleted file mode 100644
index 1b6dd77619..00
--- a/cpukit/sapi/include/rtems/README
+++ /dev/null
@@ -1,129 +0,0 @@
-Configuring a System Using the Template in confdefs.h
-=
-
-The file confdefs.h is a Configuration Template file which can be
-used to greatly simplify the creation and maintenance of RTEMS
-Configuration Tables.  The basic concepts are:
-
-   + confdefs.h provides defaults for all configuration parameters
-
-   + applications specify only those values they wish to override
-
-   + confdefs.h can be the only file which knows the precise layout
- of the RTEMS Configuration Tables.
-
-The Configuration Template setup is used by all RTEMS tests to
-simplify the maintenance of the tests.
-
-Here is the section from the system.h file from test tm21 from 
-the Timing Test Suite:
-
-   /* configuration information */
- 
-   #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
-   #define CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER
- 
-   #define CONFIGURE_MAXIMUM_TASKS  102
-   #define CONFIGURE_MAXIMUM_TIMERS 100
-   #define CONFIGURE_MAXIMUM_SEMAPHORES 100
-   #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 100
-   #define CONFIGURE_MAXIMUM_PARTITIONS 100
-   #define CONFIGURE_MAXIMUM_REGIONS100
-   #define CONFIGURE_MAXIMUM_PORTS  100
-   #define CONFIGURE_MAXIMUM_PERIODS100
- 
-   #define CONFIGURE_TICKS_PER_TIMESLICE0
- 
-   #include 
- 
-
-The above example overrides a number of the configuration parameters.
-It informs the template that it is a member of the Timing Suite, 
-requires a console and timer driver, and that it needs 102 tasks,
-100 timers, 100 semaphores, 100 message queues, 100 partitions, 
-100 regions, 100 ports, and 100 periods.   By default, the test
-would have gotten no drivers, 10 tasks, and no other RTEMS objects.
-
-The following shows the configuration tables generated by the 
-template by default.
-
-
-#include 
-
-#define NULL_DRIVER_TABLE_ENTRY \
- { NULL, NULL, NULL, NULL, NULL, NULL }
- 
-rtems_driver_address_table Device_drivers[] = {
-#ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
-  CONSOLE_DRIVER_TABLE_ENTRY,
-#endif
-#ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
-  CLOCK_DRIVER_TABLE_ENTRY,
-#endif
-#ifdef CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
-  STUB_DRIVER_TABLE_ENTRY,
-#endif
-  NULL_DRIVER_TABLE_ENTRY,
-};
-
-rtems_initialization_tasks_table Initialization_tasks[] = {
-  { rtems_build_name( 'U', 'I', '1', ' ' ), /* init task name */
-RTEMS_MINIMUM_STACK_SIZE,   /* init task stack size */
-1,  /* init task priority */
-RTEMS_DEFAULT_ATTRIBUTES,   /* init task attributes */
-Init,   /* init task entry point */
-RTEMS_NO_PREEMPT,   /* init task initial mode */
-0   /* init task argument list */
-  }
-};
-
-#ifdef CONFIGURE_MP_APPLICATION
-/*
- *  NODE_NUMBER is assumed to be set on the compile line.
- */
-
-rtems_multiprocessing_table Multiprocessing_configuration = {
-  NODE_NUMBER,   /* local node number */
-  2, /* maximum # nodes in system */
-  32,/* maximum # global objects */
-  32,/* maximum # proxies */
-  &MPCI_table/* pointer to MPCI config table */
-};
-#endif
-
-/*
- *  CONFIGURE_EXECUTIVE_RAM_SIZE is a rough guess based on the number of
- *  tasks in the system plus enough extra to get a whole 64K extra.
- *
- *  The NULL address for the workspace area is assumed to be assigned
- *  at startup time by the BSP.
- */
-   
-rtems_configuration_table Configuration = {
-  NULL,  /* executive RAM work area */
-  CONFIGURE_EXECUTIVE_RAM_SIZE, /* executive RAM size */
-  10,/* maximum # tasks */
-  0, /* maximum # timers */
-  0, /* maximum # semaphores */
-  0, /* maximum # message queues */
-  0, /* maximum # messages */
-  0, /* maximum # partitions */
-  0, /* maximum # regions */
-  0, /* maximum # dp memory areas */
-  0, /* maximum # periods */
-  0, /* maximum # user extensions */
-  RTEMS_MILLISECONDS_TO_MICROSECONDS(10), /* # us in a tick */
-  50,/* # ticks in a timeslice */
-  sizeof (Initialization_tasks) / sizeof(rtems_initialization_tasks_table),
-

How to set values depending on BSP options in spec files?

[Jan.Sommer]

Hello,

I tried to get further acquainted with the new build system and how the spec 
files work.
Following a previous discussion 
(https://lists.rtems.org/pipermail/users/2020-November/067971.html) I thought 
adding support for the 4 kB MMU pages to the xilinx_zynq_* BSPs might be a 
small task to check things out.
Unfortunately, I still ran in some problems.
What I essentially have to do is:
1. Add the option ARM_MMU_USE_SMALL_PAGES to the xilinx_zynq BSPs.
2. Update the linker script to reserve enough space for the small table 
descriptors.

1.) was pretty straight forward. I just added the a link to optmmusmallpages to 
the xilinx-zynq/grp.yml of the BSP family.

For 2.) I essentially only have to update the ARM_MMU_TRANSLATION_TABLE_SIZE to 
the right value.
The default value of 16kiB is set in arm/optmmusz.yml. For option 
ARM_MMU_USE_SMALL_PAGES enabled this would need to be 4MiB+16kiB.
How would I achieve to set the MMU table size dependent on the 
ARM_MMU_USE_SMALL_PAGES option?

Would it be somewhere in xilinx-zynq/grp.yml?
Or in the arm/optmmusz.yml somehow with the "default-by-variant" mechanism.
Or would I create an new xilinx-zynq/optmmusz.yml and define it there?
Or something else?

Best regards,

Jan


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

Jan Sommer

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

Re: How to set values depending on BSP options in spec files?

[Sebastian Huber]

Hello Jan,

On 26/11/2020 13:41, jan.som...@dlr.de wrote:

For 2.) I essentially only have to update the ARM_MMU_TRANSLATION_TABLE_SIZE to 
the right value.
The default value of 16kiB is set in arm/optmmusz.yml. For option 
ARM_MMU_USE_SMALL_PAGES enabled this would need to be 4MiB+16kiB.
How would I achieve to set the MMU table size dependent on the 
ARM_MMU_USE_SMALL_PAGES option?

Would it be somewhere in xilinx-zynq/grp.yml?

no, this just collects build items.

Or in the arm/optmmusz.yml somehow with the "default-by-variant" mechanism.
No, because you want to do something depending on a particular option 
value and not a BSP variant.

Or would I create an new xilinx-zynq/optmmusz.yml and define it there?


You should give the user only one option to set a thing and not several 
which may result in conflicting values. So, I would derive the value of 
ARM_MMU_TRANSLATION_TABLE_SIZE from ARM_MMU_USE_SMALL_PAGES. For this 
you can use a "script" action, see for example:


spec/build/bsps/arm/stm32h7/optvariant.yml

You could add a script to spec/build/bsps/arm/optmmusmallpages.yml:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-boolean: null
- define-condition: null

- script: |
    if value:

        ...

    else:

        

build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
default: true
default-by-variant: []
description: |
  Use MMU with small pages (4KiB)
enabled-by: true
links: []
name: ARM_MMU_USE_SMALL_PAGES
type: build


Or something else?


You could also use a script item:

spec/build/bsps/arm/stm32h7/linkcmdssdram.yml

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

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

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

Re: [PATCH] shell: Add i2c and spi commands

[Christian MAUDERER]

Anyone against this patch? Otherwise I would like to push it somewhen in 
the near future.


Best regards

Christian

Am 18.11.20 um 08:36 schrieb Christian Mauderer:

This adds some commands that are usefull for debugging simple serial
interfaces.

Even if they are a complete re-implementation, the i2c* commands use a
simmilar call like the Linux i2c tools.
---

Note: This is a resubmission of the patch. Previously I submitted it together
with the patches that add a new imxrt BSP:

https://lists.rtems.org/pipermail/devel/2020-November/063273.html

I only noted that it would have been better separate after Gedare said it.

  cpukit/Makefile.am|   4 +
  cpukit/include/rtems/shellconfig.h|  28 +
  cpukit/libmisc/shell/main_i2cdetect.c | 107 ++
  cpukit/libmisc/shell/main_i2cget.c| 145 
  cpukit/libmisc/shell/main_i2cset.c| 124 
  cpukit/libmisc/shell/main_spi.c   | 157 ++
  spec/build/cpukit/objshell.yml|   4 +
  7 files changed, 569 insertions(+)
  create mode 100644 cpukit/libmisc/shell/main_i2cdetect.c
  create mode 100644 cpukit/libmisc/shell/main_i2cget.c
  create mode 100644 cpukit/libmisc/shell/main_i2cset.c
  create mode 100644 cpukit/libmisc/shell/main_spi.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 4e370ae639..2adfcf933f 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1495,6 +1495,10 @@ librtemscpu_a_SOURCES += libmisc/shell/login_prompt.c
  librtemscpu_a_SOURCES += libmisc/shell/login_check.c
  librtemscpu_a_SOURCES += libmisc/shell/fdisk.c
  librtemscpu_a_SOURCES += libmisc/shell/main_rtc.c
+librtemscpu_a_SOURCES += libmisc/shell/main_spi.c
+librtemscpu_a_SOURCES += libmisc/shell/main_i2cdetect.c
+librtemscpu_a_SOURCES += libmisc/shell/main_i2cset.c
+librtemscpu_a_SOURCES += libmisc/shell/main_i2cget.c
  librtemscpu_a_SOURCES += libmisc/shell/dd-args.c
  librtemscpu_a_SOURCES += libmisc/shell/main_dd.c
  librtemscpu_a_SOURCES += libmisc/shell/dd-conv.c
diff --git a/cpukit/include/rtems/shellconfig.h 
b/cpukit/include/rtems/shellconfig.h
index 3e87d472d6..c5fcf4a45e 100644
--- a/cpukit/include/rtems/shellconfig.h
+++ b/cpukit/include/rtems/shellconfig.h
@@ -78,6 +78,10 @@ extern rtems_shell_cmd_t rtems_shell_DF_Command;
  extern rtems_shell_cmd_t rtems_shell_MD5_Command;
  
  extern rtems_shell_cmd_t rtems_shell_RTC_Command;

+extern rtems_shell_cmd_t rtems_shell_SPI_Command;
+extern rtems_shell_cmd_t rtems_shell_I2CDETECT_Command;
+extern rtems_shell_cmd_t rtems_shell_I2CGET_Command;
+extern rtems_shell_cmd_t rtems_shell_I2CSET_Command;
  
  extern rtems_shell_cmd_t rtems_shell_SHUTDOWN_Command;

  extern rtems_shell_cmd_t rtems_shell_CPUINFO_Command;
@@ -521,6 +525,30 @@ extern rtems_shell_alias_t * const 
rtems_shell_Initial_aliases[];
&rtems_shell_RTC_Command,
  #endif
  
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \

+  && !defined(CONFIGURE_SHELL_NO_COMMAND_SPI)) \
+|| defined(CONFIGURE_SHELL_COMMAND_SPI)
+  &rtems_shell_SPI_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CDETECT)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CDETECT)
+  &rtems_shell_I2CDETECT_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CGET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CGET)
+  &rtems_shell_I2CGET_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CSET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CSET)
+  &rtems_shell_I2CSET_Command,
+#endif
+
  /*
   *  System related commands
   */
diff --git a/cpukit/libmisc/shell/main_i2cdetect.c 
b/cpukit/libmisc/shell/main_i2cdetect.c
new file mode 100644
index 00..e953b4eaef
--- /dev/null
+++ b/cpukit/libmisc/shell/main_i2cdetect.c
@@ -0,0 +1,107 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 embedded brains GmbH.
+ *
+ * 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, INDI

[PATCH v1 1/1] bsp/xilinx_zynq: Enable support for 4kiB MMU pages

[Jan Sommer]

---
 c/src/lib/libbsp/arm/xilinx-zynq/configure.ac |  4 
 spec/build/bsps/arm/optmmusmallpages.yml  | 10 ++
 spec/build/bsps/arm/xilinx-zynq/grp.yml   |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac 
b/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac
index 6599b34292..86e50d1503 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac
@@ -70,11 +70,15 @@ 
RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[xilinx_zynq_zedboard],[512M])
 RTEMS_BSPOPTS_SET([BSP_ZYNQ_RAM_LENGTH],[*],[256M])
 RTEMS_BSPOPTS_HELP([BSP_ZYNQ_RAM_LENGTH],[override a BSP's default RAM length])
 
+RTEMS_BSPOPTS_SET([ARM_MMU_USE_SMALL_PAGES],[*],[1])
+RTEMS_BSPOPTS_HELP([ARM_MMU_USE_SMALL_PAGES],[use MMU with small pages (4KiB)])
+
 RTEMS_BSPOPTS_SET([BSP_ZYNQ_NOCACHE_LENGTH],[*],[1M])
 RTEMS_BSPOPTS_HELP([BSP_ZYNQ_NOCACHE_LENGTH],[length of nocache RAM region])
 
 ZYNQ_RAM_ORIGIN="0x0010"
 ZYNQ_RAM_MMU_LENGTH="16k"
+AS_IF([test "x${ARM_MMU_USE_SMALL_PAGES}" == x1], 
[ZYNQ_RAM_MMU_LENGTH="(16k+4M)"])
 ZYNQ_RAM_INT_0_ORIGIN="0x"
 ZYNQ_RAM_INT_0_LENGTH="64k + 64k + 64k"
 ZYNQ_RAM_INT_1_ORIGIN="0x"
diff --git a/spec/build/bsps/arm/optmmusmallpages.yml 
b/spec/build/bsps/arm/optmmusmallpages.yml
index 5ef991e7d5..18d07255c6 100644
--- a/spec/build/bsps/arm/optmmusmallpages.yml
+++ b/spec/build/bsps/arm/optmmusmallpages.yml
@@ -2,6 +2,16 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 actions:
 - get-boolean: null
 - define-condition: null
+- script: |
+if conf.is_defined('ARM_MMU_TRANSLATION_TABLE_SIZE'):
+conf.fatal("ARM_MMU_TRANSLATION_TABLE_SIZE already defined by 
conflicting spec.")
+
+tbl_sz = 16*1024
+if value:
+tbl_sz += 4*1024*1024
+
+conf.env["ARM_MMU_TRANSLATION_TABLE_SIZE"] = tbl_sz
+
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
diff --git a/spec/build/bsps/arm/xilinx-zynq/grp.yml 
b/spec/build/bsps/arm/xilinx-zynq/grp.yml
index 264308e6ad..b7efedc17b 100644
--- a/spec/build/bsps/arm/xilinx-zynq/grp.yml
+++ b/spec/build/bsps/arm/xilinx-zynq/grp.yml
@@ -42,7 +42,7 @@ links:
 - role: build-dependency
   uid: optint1ori
 - role: build-dependency
-  uid: ../optmmusz
+  uid: ../optmmusmallpages
 - role: build-dependency
   uid: optnocachelen
 - role: build-dependency
-- 
2.17.1

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

[PATCH v1 0/1] xilinx_zynq: Enable support for 4kiB MMU pages

[Jan Sommer]

Hello,

Thanks to the suggestions from Sebastian, here my first try to edit
things in the new build system.

This should enable the support for small MMU tables for the xilinx_zynq
based BSPs and enable it by default.

Would this also be something to backport to RTEMS5?
I could prepare a patch where it is not enabled by default, so that
there is no difference for users of 5.1.

Ideally, the patch here
https://lists.rtems.org/pipermail/devel/2020-November/063461.html is
merged beforehand.

Best regards,

Jan





Jan Sommer (1):
  bsp/xilinx_zynq: Enable support for 4kiB MMU pages

 c/src/lib/libbsp/arm/xilinx-zynq/configure.ac |  4 
 spec/build/bsps/arm/optmmusmallpages.yml  | 10 ++
 spec/build/bsps/arm/xilinx-zynq/grp.yml   |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

-- 
2.17.1

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

Re: Proposal for hardware configuration dependent performance limits

[Chris Johns]

On 26/11/20 7:04 pm, Sebastian Huber wrote:
> On 25/11/2020 21:37, Chris Johns wrote:
> 
>>> Maybe a configuration option for the RTEMS Tester should be added which 
>>> allows
>>> you to set the performance hash and ignore the hash provided by the test 
>>> output.
>>> This could be used to compare a custom board with values obtain from an
>>> evaluation board.
>> Why not let the tester take an alternative set of values for the same hash to
>> override the "standard" set?
> 
> Do you mean that the performance limits should be specified with a particular
> hash like this:

Yes and the hash is nothing more than a key. I had not thought much more but
what you have defined looks good and highlights how wrapping this configuration
state key is open. Your progression from values under the hash to a form of
redirection is nice. I see this evolving as we implement solutions and learn 
more.

Chris

> 
> limits:
>     sparc/gr712rc/XrY7u+Ae7tCTyyK7j1rNww==:
>   DirtyCache:
>     max-upper-bound: 0.05
>     mean-upper-bound: 0.05
> 
> In another item (for example the BSP build item) we could add a mapping from
> this hash value to a list of other hash values. For example:
> 
> performance-hash-equivalence-classes:
>   XrY7u+Ae7tCTyyK7j1rNww==:
>   - abc
>   - def
>   - ghi
> 
> We probably need also description:
> 
> performance-hash-description:
>   XrY7u+Ae7tCTyyK7j1rNww==: |
>     Description.
> 
> Taking performance limits into account for test runs requires a bit of
> maintenance. The first step is being able to do it. The next step is to 
> discuss
> if and how this could be done in the scope of the RTEMS Project.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 0/5] Add CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE

[Chris Johns]

On 25/11/20 6:12 pm, Sebastian Huber wrote:
> Currently, the Classic API initialization task is created with
> rtems_task_create(). In order to better support applications which use
> the new rtems_task_construct() directive add the
> CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE configuration option which 
> constructs
> the Classic API initialization task with rtems_task_construct().
> 
> v2:
> 
> * Do not mention rtems_task_construct() in the
>   CONFIGURE_INIT_TASK_STORAGE_SIZE documentation.
> 
> * Ensure that CONFIGURE_INIT_TASK_STACK_SIZE is greater than or equal to
>   CONFIGURE_MINIMUM_TASK_STACK_SIZE.
> 
> v3:
> 
> * Clarify use of pragmas.
> 
> * Rename CONFIGURE_INIT_TASK_STORAGE_SIZE in
>   CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE.
> 
> Sebastian Huber (5):
>   config: Clarify the use of pragmas
>   Avoid INTERNAL_ERROR_RTEMS_INIT_TASK_ENTRY_IS_NULL
>   config: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE
>   config: Check CONFIGURE_INIT_TASK_STACK_SIZE
>   Use CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE

Looks good. Thanks.

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

Re: [PATCH] eng: Add performance specification items

[Chris Johns]

On 26/11/20 4:08 am, Gedare Bloom wrote:
> 
> 
> On Wed, Nov 25, 2020 at 7:38 AM Sebastian Huber
>  >
> wrote:
> 
> Hello,
> 
> On 14/11/2020 12:59, Sebastian Huber wrote:
> > On 13/11/2020 20:03, Gedare Bloom wrote:
> >
> >>> +Generic Non-Functional Requirement Item Type
> >>> +
> >>> +
> >>> +This type refines the following types:
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >> through?
> > Nice an automatically generated typo.
> >>
> >>> +  ``non-functional-type`` attribute if the value is
> >>> ``build-configuration``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``constraint``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``design``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``documentation``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``interface``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is
> >>> ``interface-requirement``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is
> >>> ``maintainability``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``performance``
> >>> +
> >> Is there a specific kind of performance (metric) in mind? latency vs
> >> throughput? Or does it not matter
> >>
> > In the generic non-functional requirements, the requirements text is
> > in natural language. So, you can write whatever you want.
> >
> > This patch introduces a specialization for performance requirements
> > which are expressed in limits of a sample set of some measured runtime
> > of an operation.
> >
> > text: |
> >   When a partition has exactly
> > ${../val/performance:/params/buffer-count} free
> >   buffers, the ${.:limit-kind} runtime of exactly
> >   ${../val/performance:/params/sample-count} successful calls to
> >   ${../if/get-buffer:/name} in the ${.:/environment} shall be
> >   ${.:limit-condition}.
> >
> > In this item, the corresponding test code is also included.
> >
> > test-body:
> >   brief: |
> >     Get a buffer.
> >   code: |
> >     ctx->status = rtems_partition_get_buffer( ctx->part_many,
> > &ctx->buffer );
> >   description: null
> 
> I think this can be checked in independent of the open discussion how a
> particular performance limit is identified. The item just uses a string
> to identify a set of performance limits. An open issue is how this
> string is generated and what data it includes.
> 
> I already fixed the "though" -> "through" typo.
> 
> Fine with me

And me

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

Re: [PATCH v4] c-user: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE

[Chris Johns]

On 26/11/20 4:39 am, Sebastian Huber wrote:
> Document new configuration option
> CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE.

Looks good. Thanks.

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

Re: [PATCH] shell: Add i2c and spi commands

[Chris Johns]

On 27/11/20 1:12 am, Christian MAUDERER wrote:
> Anyone against this patch? Otherwise I would like to push it somewhen in the
> near future.

Looks good. Please push.

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

Re: [PATCH v4] c-user: CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE

[Sebastian Huber]

Hello Chris, Gedare, and Joel,

On 26/11/2020 22:48, Chris Johns wrote:


On 26/11/20 4:39 am, Sebastian Huber wrote:

Document new configuration option
CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE.

Looks good. Thanks.

thanks for the constructive review.

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

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

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