Re: RTEMS_VERSION on 5 branch

[Chris Johns]

On 26/5/21 6:47 pm, Christian MAUDERER wrote:
> thanks for the detailed response. Should we add a bit of that to the doxygen
> documentation of the rtems_version_* functions so that I don't ask it again
> because I have forgotten it in a year?

Yes we should. I also would to add a detailed section on deployment. I see that
as an important area for serious users. This is on my list that seems to only 
grow.

Chris

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

Re: [PATCH] rtems-binutils-head.cfg, rtems-gdb-head.cfg: Bump to 3b2bef8

[Chris Johns]

I am ok with this going in but 

I am becoming concerned we are building a debt around MacOS and Windows in the
tools that we need to resolve. Our ability to release when we would like to
depends on the state of the tools and the state of the tools for all archs. :)

On 22/5/21 9:20 am, Joel Sherrill wrote:
> ---
>  rtems/config/tools/rtems-binutils-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gdb-head.cfg  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-binutils-head.cfg 
> b/rtems/config/tools/rtems-binutils-head.cfg
> index 4c36865..46abb68 100644
> --- a/rtems/config/tools/rtems-binutils-head.cfg
> +++ b/rtems/config/tools/rtems-binutils-head.cfg
> @@ -1,11 +1,11 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>  
> -%define binutils_version ed29efb
> +%define binutils_version 3b2bef8
>  %define binutils_external 1
>  %define binutils_expand_name 
> sourceware-mirror-binutils-gdb-%{binutils_version}
>  %source set binutils --rsb-file=%{binutils_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{binutils_version}
> -%hash sha512 %{binutils_expand_name}.tar.gz 
> d8afdc9f5f5b73f585a1ead00500f45e7131f1bda94f0737c36f6af6ad96da220a82bab33146611c097b74abdf454d2b90ce9695320d1dfca5976da70c69c8c3
> +%hash sha512 %{binutils_expand_name}.tar.gz 
> b50bf8c83e7fb3e9654ff232df42b44b312488caa3b6ab0f53e2041e632b0f0235007866d0f191b7462a153c1c9b85a822e0ddd9c8d8a78c13e51177d9390e74
>  
>  %define with_deterministic_archives 1
>  %define with_64_bit_bfd 1
> diff --git a/rtems/config/tools/rtems-gdb-head.cfg 
> b/rtems/config/tools/rtems-gdb-head.cfg
> index 7f7fedf..65171d7 100644
> --- a/rtems/config/tools/rtems-gdb-head.cfg
> +++ b/rtems/config/tools/rtems-gdb-head.cfg
> @@ -1,10 +1,10 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>  
> -%define gdb_version ed29efb
> +%define gdb_version 3b2bef8
>  %define gdb_external 1
>  %define gdb_expand_name sourceware-mirror-binutils-gdb-%{gdb_version}
>  %source set gdb --rsb-file=%{gdb_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{gdb_version}
> -%hash sha512 %{gdb_expand_name}.tar.gz 
> d8afdc9f5f5b73f585a1ead00500f45e7131f1bda94f0737c36f6af6ad96da220a82bab33146611c097b74abdf454d2b90ce9695320d1dfca5976da70c69c8c3
> +%hash sha512 %{gdb_expand_name}.tar.gz 
> b50bf8c83e7fb3e9654ff232df42b44b312488caa3b6ab0f53e2041e632b0f0235007866d0f191b7462a153c1c9b85a822e0ddd9c8d8a78c13e51177d9390e74
>  
>  %include %{_configdir}/gdb-8-1.cfg
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] cpukit: Add description of release version numbers

[Christian Mauderer]

The release version in the git sources doesn't change. Add a note why
that is the case.
---
 cpukit/include/rtems/version.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
index a8aff732f3..2e068cd976 100644
--- a/cpukit/include/rtems/version.h
+++ b/cpukit/include/rtems/version.h
@@ -29,6 +29,18 @@ extern "C" {
  *
  * @brief The Version API provides functions to return the version or parts of
  * the version of RTEMS you are using.
+ *
+ * A branch in the version control system will always fall back to a
+ * not-released version number with a minor number of 0. Only the release
+ * archives have a VERSION file with a final release number. That means for
+ * example that the 5 development branch will still show a version 5.0.0 even
+ * after the 5.1 release.
+ *
+ * The reason for that is the following: All pre-release tests are performed 
for
+ * a specific git hash. If the VERSION file would be changed and committed
+ * afterwards for releasing a new version, the released version would have a
+ * different git hash and the test results couldn't be linked to the released
+ * version.
  */
 /**@{**/
 
-- 
2.26.2

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

Re: RTEMS_VERSION on 5 branch

[Christian MAUDERER]

Am 26.05.21 um 09:22 schrieb Chris Johns:

On 26/5/21 6:47 pm, Christian MAUDERER wrote:

thanks for the detailed response. Should we add a bit of that to the doxygen
documentation of the rtems_version_* functions so that I don't ask it again
because I have forgotten it in a year?


Yes we should. I also would to add a detailed section on deployment. I see that
as an important area for serious users. This is on my list that seems to only 
grow.

Chris



Hello Chris,

I added at least a short note:

https://lists.rtems.org/pipermail/devel/2021-May/067457.html

Can you check whether it's correct and give a comment for it. If it is 
OK, I would push it to 5 and master.


Best regards

Christian
--

embedded brains GmbH
Herr 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

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] Add CoreMark Benchmark

[Hesham Almatary]

CoreMark's primary goals are simplicity and providing a method for
testing only a processor's core features. It is used primarily here as
a performance benchmark.

Built and tested for RISC-V rv64imafdc_medany on QEMU and HW
---
 .gitmodules  |  3 +++
 benchmarks/coremark/coremark |  1 +
 benchmarks/coremark/wscript  | 50 
 benchmarks/wscript   |  2 +-
 4 files changed, 55 insertions(+), 1 deletion(-)
 create mode 16 benchmarks/coremark/coremark
 create mode 100644 benchmarks/coremark/wscript

diff --git a/.gitmodules b/.gitmodules
index ae86e49..d7e52b9 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,6 @@
 [submodule "rtems_waf"]
path = rtems_waf
url = git://git.rtems.org/rtems_waf.git
+[submodule "benchmarks/coremark/coremark"]
+   path = benchmarks/coremark/coremark
+   url = g...@github.com:eembc/coremark.git
diff --git a/benchmarks/coremark/coremark b/benchmarks/coremark/coremark
new file mode 16
index 000..1541482
--- /dev/null
+++ b/benchmarks/coremark/coremark
@@ -0,0 +1 @@
+Subproject commit 1541482bf3e6ef7f5c69f5be76b14537b60833d0
diff --git a/benchmarks/coremark/wscript b/benchmarks/coremark/wscript
new file mode 100644
index 000..2ec5f1e
--- /dev/null
+++ b/benchmarks/coremark/wscript
@@ -0,0 +1,50 @@
+#-
+# SPDX-License-Identifier: BSD-2-Clause
+#
+# Copyright (c) 2021 Hesham Almatary
+#
+# This software was developed by SRI International and the University of
+# Cambridge Computer Laboratory (Department of Computer Science and
+# Technology) under DARPA contract HR0011-18-C-0016 ("ECATS"), as part of the
+# DARPA SSITH research programme.
+#
+# 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 AUTHOR 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 AUTHOR 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.
+#
+
+import rtems_waf.rtems as rtems
+
+def build(bld):
+rtems.build(bld)
+
+bld(features = 'c cprogram',
+target = 'coremark.bin',
+includes = ['coremark/', 'coremark/posix/'],
+source = ['coremark/rtems/init.c', 'coremark/posix/core_portme.c',
+  'coremark/core_list_join.c', 'coremark/core_main.c',
+  'coremark/core_matrix.c', 'coremark/core_state.c',
+  'coremark/core_util.c'],
+
+defines = [
+# FLAGS_STR is used within CoreMark to print the compiler flags used
+'FLAGS_STR="'+' '.join([str(flag) for flag in bld.env.CFLAGS])+'"'
+]
+)
diff --git a/benchmarks/wscript b/benchmarks/wscript
index 12741e7..0947060 100644
--- a/benchmarks/wscript
+++ b/benchmarks/wscript
@@ -7,4 +7,4 @@ import rtems_waf.rtems as rtems
 
 def build(bld):
 bld.recurse('nbench')
-
+bld.recurse('coremark')
-- 
2.25.1

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

[PATCH v2] Add CoreMark Benchmark

[Hesham Almatary]

CoreMark's primary goals are simplicity and providing a method for
testing only a processor's core features. It is used primarily here as
a performance benchmark.

Built and tested for RISC-V rv64imafdc_medany on QEMU and HW
---
 .gitmodules  |  3 +++
 benchmarks/coremark/coremark |  1 +
 benchmarks/coremark/wscript  | 50 
 benchmarks/wscript   |  1 +
 4 files changed, 55 insertions(+)
 create mode 16 benchmarks/coremark/coremark
 create mode 100644 benchmarks/coremark/wscript

diff --git a/.gitmodules b/.gitmodules
index ae86e49..d7e52b9 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,6 @@
 [submodule "rtems_waf"]
path = rtems_waf
url = git://git.rtems.org/rtems_waf.git
+[submodule "benchmarks/coremark/coremark"]
+   path = benchmarks/coremark/coremark
+   url = g...@github.com:eembc/coremark.git
diff --git a/benchmarks/coremark/coremark b/benchmarks/coremark/coremark
new file mode 16
index 000..1541482
--- /dev/null
+++ b/benchmarks/coremark/coremark
@@ -0,0 +1 @@
+Subproject commit 1541482bf3e6ef7f5c69f5be76b14537b60833d0
diff --git a/benchmarks/coremark/wscript b/benchmarks/coremark/wscript
new file mode 100644
index 000..2ec5f1e
--- /dev/null
+++ b/benchmarks/coremark/wscript
@@ -0,0 +1,50 @@
+#-
+# SPDX-License-Identifier: BSD-2-Clause
+#
+# Copyright (c) 2021 Hesham Almatary
+#
+# This software was developed by SRI International and the University of
+# Cambridge Computer Laboratory (Department of Computer Science and
+# Technology) under DARPA contract HR0011-18-C-0016 ("ECATS"), as part of the
+# DARPA SSITH research programme.
+#
+# 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 AUTHOR 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 AUTHOR 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.
+#
+
+import rtems_waf.rtems as rtems
+
+def build(bld):
+rtems.build(bld)
+
+bld(features = 'c cprogram',
+target = 'coremark.bin',
+includes = ['coremark/', 'coremark/posix/'],
+source = ['coremark/rtems/init.c', 'coremark/posix/core_portme.c',
+  'coremark/core_list_join.c', 'coremark/core_main.c',
+  'coremark/core_matrix.c', 'coremark/core_state.c',
+  'coremark/core_util.c'],
+
+defines = [
+# FLAGS_STR is used within CoreMark to print the compiler flags used
+'FLAGS_STR="'+' '.join([str(flag) for flag in bld.env.CFLAGS])+'"'
+]
+)
diff --git a/benchmarks/wscript b/benchmarks/wscript
index 12741e7..807ed6e 100644
--- a/benchmarks/wscript
+++ b/benchmarks/wscript
@@ -7,4 +7,5 @@ import rtems_waf.rtems as rtems
 
 def build(bld):
 bld.recurse('nbench')
+bld.recurse('coremark')
 
-- 
2.25.1

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

Re: [PATCH v2] Add CoreMark Benchmark

[Hesham Almatary]

Submitting that again based on Joel's request. I created a ticket [1]
for future Make support as it only builds with waf.

[1] https://devel.rtems.org/ticket/4441#ticket

On Wed, 26 May 2021 at 11:23, Hesham Almatary
 wrote:
>
> CoreMark's primary goals are simplicity and providing a method for
> testing only a processor's core features. It is used primarily here as
> a performance benchmark.
>
> Built and tested for RISC-V rv64imafdc_medany on QEMU and HW
> ---
>  .gitmodules  |  3 +++
>  benchmarks/coremark/coremark |  1 +
>  benchmarks/coremark/wscript  | 50 
>  benchmarks/wscript   |  1 +
>  4 files changed, 55 insertions(+)
>  create mode 16 benchmarks/coremark/coremark
>  create mode 100644 benchmarks/coremark/wscript
>
> diff --git a/.gitmodules b/.gitmodules
> index ae86e49..d7e52b9 100644
> --- a/.gitmodules
> +++ b/.gitmodules
> @@ -1,3 +1,6 @@
>  [submodule "rtems_waf"]
> path = rtems_waf
> url = git://git.rtems.org/rtems_waf.git
> +[submodule "benchmarks/coremark/coremark"]
> +   path = benchmarks/coremark/coremark
> +   url = g...@github.com:eembc/coremark.git
> diff --git a/benchmarks/coremark/coremark b/benchmarks/coremark/coremark
> new file mode 16
> index 000..1541482
> --- /dev/null
> +++ b/benchmarks/coremark/coremark
> @@ -0,0 +1 @@
> +Subproject commit 1541482bf3e6ef7f5c69f5be76b14537b60833d0
> diff --git a/benchmarks/coremark/wscript b/benchmarks/coremark/wscript
> new file mode 100644
> index 000..2ec5f1e
> --- /dev/null
> +++ b/benchmarks/coremark/wscript
> @@ -0,0 +1,50 @@
> +#-
> +# SPDX-License-Identifier: BSD-2-Clause
> +#
> +# Copyright (c) 2021 Hesham Almatary
> +#
> +# This software was developed by SRI International and the University of
> +# Cambridge Computer Laboratory (Department of Computer Science and
> +# Technology) under DARPA contract HR0011-18-C-0016 ("ECATS"), as part of the
> +# DARPA SSITH research programme.
> +#
> +# 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 AUTHOR 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 AUTHOR 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.
> +#
> +
> +import rtems_waf.rtems as rtems
> +
> +def build(bld):
> +rtems.build(bld)
> +
> +bld(features = 'c cprogram',
> +target = 'coremark.bin',
> +includes = ['coremark/', 'coremark/posix/'],
> +source = ['coremark/rtems/init.c', 'coremark/posix/core_portme.c',
> +  'coremark/core_list_join.c', 'coremark/core_main.c',
> +  'coremark/core_matrix.c', 'coremark/core_state.c',
> +  'coremark/core_util.c'],
> +
> +defines = [
> +# FLAGS_STR is used within CoreMark to print the compiler flags used
> +'FLAGS_STR="'+' '.join([str(flag) for flag in bld.env.CFLAGS])+'"'
> +]
> +)
> diff --git a/benchmarks/wscript b/benchmarks/wscript
> index 12741e7..807ed6e 100644
> --- a/benchmarks/wscript
> +++ b/benchmarks/wscript
> @@ -7,4 +7,5 @@ import rtems_waf.rtems as rtems
>
>  def build(bld):
>  bld.recurse('nbench')
> +bld.recurse('coremark')
>
> --
> 2.25.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems] thread-API: Add rtems_*mutex_try_lock

[Christian Mauderer]

This adds a rtems_mutex_try_lock and a rtems_recursive_mutex_try_lock.

Update #4440.
---
 cpukit/include/rtems/thread.h| 12 +
 testsuites/sptests/spthread01/init.c | 79 
 2 files changed, 91 insertions(+)

diff --git a/cpukit/include/rtems/thread.h b/cpukit/include/rtems/thread.h
index feee612d22..d0cb03c284 100644
--- a/cpukit/include/rtems/thread.h
+++ b/cpukit/include/rtems/thread.h
@@ -54,6 +54,11 @@ static __inline void rtems_mutex_lock( rtems_mutex *mutex )
   _Mutex_Acquire( mutex );
 }
 
+static __inline int rtems_mutex_try_lock( rtems_mutex *mutex )
+{
+  return _Mutex_Try_acquire( mutex );
+}
+
 static __inline void rtems_mutex_unlock( rtems_mutex *mutex )
 {
   _Mutex_Release( mutex );
@@ -97,6 +102,13 @@ static __inline void rtems_recursive_mutex_lock(
   _Mutex_recursive_Acquire( mutex );
 }
 
+static __inline int rtems_recursive_mutex_try_lock(
+  rtems_recursive_mutex *mutex
+)
+{
+  return _Mutex_recursive_Try_acquire( mutex );
+}
+
 static __inline void rtems_recursive_mutex_unlock(
   rtems_recursive_mutex *mutex
 )
diff --git a/testsuites/sptests/spthread01/init.c 
b/testsuites/sptests/spthread01/init.c
index 4c5bfc12e1..9044ca2601 100644
--- a/testsuites/sptests/spthread01/init.c
+++ b/testsuites/sptests/spthread01/init.c
@@ -25,10 +25,74 @@
 
 const char rtems_test_name[] = "SPTHREAD 1";
 
+#define WAKEUP_EVENT RTEMS_EVENT_0
+
+typedef struct {
+  rtems_mutex *mtx;
+  rtems_recursive_mutex *rmtx;
+  rtems_id calling_task;
+} mutex_context;
+
+static void mutex_task(rtems_task_argument arg)
+{
+  mutex_context *m;
+  int rv;
+
+  m = (mutex_context *) arg;
+
+  rtems_test_assert(m->mtx != NULL || m->rmtx != NULL);
+
+  if (m->mtx) {
+rv = rtems_mutex_try_lock(m->mtx);
+rtems_test_assert(rv == EBUSY);
+  }
+
+  if (m->rmtx) {
+rv = rtems_recursive_mutex_try_lock(m->rmtx);
+rtems_test_assert(rv == EBUSY);
+  }
+
+  rtems_event_send(m->calling_task, WAKEUP_EVENT);
+}
+
+static void test_try_lock_from_different_task(
+  rtems_mutex *m,
+  rtems_recursive_mutex *r
+)
+{
+  mutex_context ctx;
+  rtems_status_code sc;
+  rtems_event_set e;
+  rtems_id id;
+
+  ctx.mtx = m;
+  ctx.rmtx = r;
+  ctx.calling_task = rtems_task_self();
+
+  sc = rtems_task_create(
+rtems_build_name('M', 'T', 'X', ' '),
+2,
+RTEMS_MINIMUM_STACK_SIZE,
+RTEMS_DEFAULT_MODES,
+RTEMS_DEFAULT_ATTRIBUTES,
+&id
+  );
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_task_start(id, mutex_task, (rtems_task_argument) &ctx);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_event_receive(WAKEUP_EVENT, RTEMS_EVENT_ANY | RTEMS_WAIT, 10, &e);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  rtems_task_delete(id);
+}
+
 static void test_mutex(void)
 {
   rtems_mutex a = RTEMS_MUTEX_INITIALIZER("a");
   const char *name;
+  int rv;
 
   name = rtems_mutex_get_name(&a);
   rtems_test_assert(strcmp(name, "a") == 0);
@@ -47,6 +111,13 @@ static void test_mutex(void)
 
   rtems_mutex_lock(&a);
 
+  test_try_lock_from_different_task(&a, NULL);
+
+  rtems_mutex_unlock(&a);
+
+  rv = rtems_mutex_try_lock(&a);
+  rtems_test_assert(rv == 0);
+
   rtems_mutex_unlock(&a);
 
   rtems_mutex_destroy(&a);
@@ -56,6 +127,7 @@ static void test_recursive_mutex(void)
 {
   rtems_recursive_mutex a = RTEMS_RECURSIVE_MUTEX_INITIALIZER("a");
   const char *name;
+  int rv;
 
   name = rtems_recursive_mutex_get_name(&a);
   rtems_test_assert(strcmp(name, "a") == 0);
@@ -76,6 +148,13 @@ static void test_recursive_mutex(void)
 
   rtems_recursive_mutex_lock(&a);
 
+  rv = rtems_recursive_mutex_try_lock(&a);
+  rtems_test_assert(rv == 0);
+
+  test_try_lock_from_different_task(NULL, &a);
+
+  rtems_recursive_mutex_unlock(&a);
+
   rtems_recursive_mutex_unlock(&a);
 
   rtems_recursive_mutex_unlock(&a);
-- 
2.26.2

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

[PATCH] c-users: Add rtems_*mutex_try_lock

[Christian Mauderer]

---
 c-user/self_contained_objects.rst | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/c-user/self_contained_objects.rst 
b/c-user/self_contained_objects.rst
index 0be1423..3351b98 100644
--- a/c-user/self_contained_objects.rst
+++ b/c-user/self_contained_objects.rst
@@ -132,6 +132,10 @@ copies of the object in calls to
 
 * :c:func:`rtems_recursive_mutex_lock`,
 
+* :c:func:`rtems_mutex_try_lock`,
+
+* :c:func:`rtems_recursive_mutex_try_lock`,
+
 * :c:func:`rtems_mutex_unlock`,
 
 * :c:func:`rtems_recursive_mutex_unlock`,
@@ -262,6 +266,37 @@ NOTES:
 
 \clearpage
 
+Try to lock the mutex
+-
+
+CALLING SEQUENCE:
+.. code-block:: c
+
+void rtems_mutex_try_lock(
+  rtems_mutex *mutex
+);
+
+void rtems_recursive_mutex_try_lock(
+  rtems_recursive_mutex *mutex
+);
+
+DESCRIPTION:
+Tries to lock the ``mutex``. In case the mutex is not locked, it will be
+locked and the function returns with a return value of ``0``. If the mutex
+is already locked, the function will return with a value of ``EBUSY``.
+
+NOTES:
+This function must be called from thread context with interrupts enabled.
+
+For recursively locking a mutex, please also see the notes for
+:c:func:`rtems_mutex_lock` and :c:func:`rtems_recursive_mutex_lock`.
+
+Each mutex lock operation must have a corresponding unlock operation.
+
+.. raw:: latex
+
+\clearpage
+
 Unlock the mutex
 
 
-- 
2.26.2

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

RE: Building llvm toolchain for RTEMS

[Jan.Sommer]

Ok, I build the llvm buildset with RSB and then tried to set the COMPILER 
option in the ini file for the BSP, but that did not work.
Is it only available for certain BSPs or am I completely of the track?

Best regards,

Jan

> -Original Message-
> From: devel  On Behalf Of jan.som...@dlr.de
> Sent: Friday, May 21, 2021 12:25 PM
> To: devel@rtems.org
> Subject: Building llvm toolchain for RTEMS
> 
> Hello,
> 
> I see some references to llvm toolchains for RTEMS from time to time, but
> haven't really looked into it.
> Is it possible to let RSB build a clang C/C++ compiler and kernel for e.g. the
> Zedboard BSP?
> If yes, how would I build such a toolchain? I see that there is a llvm 
> buildset in
> RSB, but it doesn't seem architecture specific.
> 
> 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
> Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
> DLR.de/SC
> 
> ___
> 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: Building llvm toolchain for RTEMS

[Hesham Almatary]

Hello Jan,

Unlike GCC, LLVM/Clang only gives you one toolchain for all backend
architectures (depending on how you configured it). You'll also need
to tell LLVM/Clang where to find the sysroot to pick newlib and
builtins headers/libs. GCC does that automatically for you, but
LLVM/Clang does not. You can either point LLVM/Clang to the
GCC-installed sysroot/multilib, or to manually/separately build newlib
(libc) and compiler-rt (which corresponds to libgcc) on your own.

I have only tested building RTEMS with LLVM/Clang on RISC-V platforms,
but I build my own LLVM/Clang, newlib, compiler-rt toolchain/sysroot,
not from RSB.

On Wed, 26 May 2021 at 11:57,  wrote:
>
> Ok, I build the llvm buildset with RSB and then tried to set the COMPILER 
> option in the ini file for the BSP, but that did not work.
> Is it only available for certain BSPs or am I completely of the track?
>
> Best regards,
>
> Jan
>
> > -Original Message-
> > From: devel  On Behalf Of jan.som...@dlr.de
> > Sent: Friday, May 21, 2021 12:25 PM
> > To: devel@rtems.org
> > Subject: Building llvm toolchain for RTEMS
> >
> > Hello,
> >
> > I see some references to llvm toolchains for RTEMS from time to time, but
> > haven't really looked into it.
> > Is it possible to let RSB build a clang C/C++ compiler and kernel for e.g. 
> > the
> > Zedboard BSP?
> > If yes, how would I build such a toolchain? I see that there is a llvm 
> > buildset in
> > RSB, but it doesn't seem architecture specific.
> >
> > 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
> > Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
> > DLR.de/SC
> >
> > ___
> > 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: [PATCH rtems] thread-API: Add rtems_*mutex_try_lock

[Sebastian Huber]

On 26/05/2021 11:33, Christian Mauderer wrote:

This adds a rtems_mutex_try_lock and a rtems_recursive_mutex_try_lock.

Update #4440.


Looks good.

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

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

Re: Minimum.exe Text Size Outliers

[Sebastian Huber]

On 25/05/2021 20:33, Christian Mauderer wrote:




I thought Sebastian added a "malloc" for the BSP to use before the 
heap was initialized. But I don't remember the name. Am I remembering 
correctly?


I don't really know that malloc. But I doubt that it works that early. 
Again: Copying the FDT is one of the first things that these BSPs do. If 
you want to know the exact location: For ARM it's here:


https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325

So it's really basic setup before that. It's interrupt stack, switching 
modes, setup stack pointer and then it's already copy FDT.


Yes, there is an early "malloc". This is _Memory_Allocate() using 
_Memory_Get(). However, for the device tree copy this is not early 
enough. We don't know the device tree location provided by the boot 
loader. It could be somewhere in the memory area used by the 
application. So, it is important to copy this very early into a fixed 
location. Also, the device tree may be used to get the size of the 
memory provided by _Memory_Get().


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

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

[PATCH] score: Get current priority with proper locking

[Sebastian Huber]

The current priority is a 64-bit integer which should be read under
protection of the right ISR lock to avoid potential issues with
non-atomic loads on 32-bit architectures.

Update #4411.
---
 cpukit/score/src/threadrestart.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/cpukit/score/src/threadrestart.c b/cpukit/score/src/threadrestart.c
index 1e91ad7249..93e52876d7 100644
--- a/cpukit/score/src/threadrestart.c
+++ b/cpukit/score/src/threadrestart.c
@@ -54,17 +54,17 @@ static Thread_Zombie_control _Thread_Zombies = {
   .Lock = ISR_LOCK_INITIALIZER( "thread zombies" )
 };
 
-static void _Thread_Raise_real_priority(
-  Thread_Control   *the_thread,
-  Priority_Control  priority
-)
+static void _Thread_Raise_real_priority( Thread_Control *the_thread )
 {
   Thread_queue_Context queue_context;
+  Priority_Control priority;
 
   _Thread_queue_Context_initialize( &queue_context );
   _Thread_queue_Context_clear_priority_updates( &queue_context );
   _Thread_Wait_acquire( the_thread, &queue_context );
 
+  priority = _Thread_Get_priority( executing );
+
   if ( priority < the_thread->Real_priority.priority ) {
 _Thread_Priority_change(
   the_thread,
@@ -428,11 +428,8 @@ void _Thread_Cancel(
 _Thread_State_release( the_thread, &lock_context );
 _Thread_Make_zombie( the_thread );
   } else {
-Priority_Control priority;
-
 _Thread_Try_life_change_request( the_thread, previous, &lock_context );
-priority = _Thread_Get_priority( executing );
-_Thread_Raise_real_priority( the_thread, priority );
+_Thread_Raise_real_priority( the_thread );
   }
 
   _Thread_Dispatch_enable( cpu_self );
-- 
2.26.2

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

Re: [PATCH] score: Get current priority with proper locking

[Sebastian Huber]

On 26/05/2021 14:10, Sebastian Huber wrote:

The current priority is a 64-bit integer which should be read under
protection of the right ISR lock to avoid potential issues with
non-atomic loads on 32-bit architectures.


Please ignore this patch. It doesn't work. There is a strange priority 
boosting mechanism at work in _Thread_Cancel() and thus also 
rtems_task_delete().


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

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

[PATCH] tester: Expand special case for minimum.exe

[Kinsey Moore]

The minimum.exe test case is expected to fail as an "invalid" test in
the tester since it is completely stripped down and does not output the
normal test header and footer. When fatal error detection support was
added, this caught minimum.exe and started flagging it as "fatal"
instead of "invalid". The special-case detection of minimum.exe only
matched on "invalid" results and not "fatal" results and so began
flagging minimum.exe as an actual failure.

This change adds the special-case handling to the "fatal" test state
handling.
---
 tester/rt/report.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tester/rt/report.py b/tester/rt/report.py
index 0e19edc..1341f4f 100644
--- a/tester/rt/report.py
+++ b/tester/rt/report.py
@@ -194,8 +194,13 @@ class report(object):
 status = 'passed'
 self.passed += 1
 elif fatal:
-status = 'fatal-error'
-self.failed += 1
+exe_name = path.basename(name).split('.')[0]
+if exe_name in test_fail_excludes:
+status = 'passed'
+self.passed += 1
+else:
+status = 'fatal-error'
+self.failed += 1
 elif timeout:
 status = 'timeout'
 self.timeouts += 1
-- 
2.20.1

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

[PATCH rtems] i2c: Add non blocking read / write

[Christian Mauderer]

This adds the possibility to open an I2C bus with O_NONBLOCK (or set it
later via fcntl) to get non-blocking transmissions. This means that if
the bus is busy, a read, write or transfer ioctl will return with a
EAGAIN errno.
---
NOTE: This patch needs
https://lists.rtems.org/pipermail/devel/2021-May/067462.html applied too.

 cpukit/dev/i2c/i2c-bus.c |  45 ++--
 cpukit/include/dev/i2c/i2c.h |  44 ++-
 testsuites/libtests/i2c01/init.c | 121 ++-
 3 files changed, 203 insertions(+), 7 deletions(-)

diff --git a/cpukit/dev/i2c/i2c-bus.c b/cpukit/dev/i2c/i2c-bus.c
index 47c4ab..618a817b1a 100644
--- a/cpukit/dev/i2c/i2c-bus.c
+++ b/cpukit/dev/i2c/i2c-bus.c
@@ -31,6 +31,11 @@
 #include 
 #include 
 
+int i2c_bus_try_obtain(i2c_bus *bus)
+{
+  return rtems_recursive_mutex_try_lock(&bus->mutex);
+}
+
 void i2c_bus_obtain(i2c_bus *bus)
 {
   rtems_recursive_mutex_lock(&bus->mutex);
@@ -41,7 +46,12 @@ void i2c_bus_release(i2c_bus *bus)
   rtems_recursive_mutex_unlock(&bus->mutex);
 }
 
-int i2c_bus_transfer(i2c_bus *bus, i2c_msg *msgs, uint32_t msg_count)
+int i2c_bus_do_transfer(
+  i2c_bus *bus,
+  i2c_msg *msgs,
+  uint32_t msg_count,
+  uint32_t flags
+)
 {
   int err;
   uint32_t i;
@@ -63,13 +73,24 @@ int i2c_bus_transfer(i2c_bus *bus, i2c_msg *msgs, uint32_t 
msg_count)
 }
   }
 
-  i2c_bus_obtain(bus);
+  if ((flags & I2C_BUS_NOBLOCK) != 0) {
+if (i2c_bus_try_obtain(bus) != 0) {
+  return -EAGAIN;
+}
+  } else {
+i2c_bus_obtain(bus);
+  }
   err = (*bus->transfer)(bus, msgs, msg_count);
   i2c_bus_release(bus);
 
   return err;
 }
 
+int i2c_bus_transfer(i2c_bus *bus, i2c_msg *msgs, uint32_t msg_count)
+{
+  return i2c_bus_do_transfer(bus, msgs, msg_count, 0);
+}
+
 static ssize_t i2c_bus_read(
   rtems_libio_t *iop,
   void *buffer,
@@ -84,12 +105,17 @@ static ssize_t i2c_bus_read(
 .buf = buffer
   };
   int err;
+  unsigned flags = 0;
 
   if (bus->ten_bit_address) {
 msg.flags |= I2C_M_TEN;
   }
 
-  err = i2c_bus_transfer(bus, &msg, 1);
+  if (rtems_libio_iop_is_no_delay(iop)) {
+flags |= I2C_BUS_NOBLOCK;
+  }
+
+  err = i2c_bus_do_transfer(bus, &msg, 1, flags);
   if (err == 0) {
 return msg.len;
   } else {
@@ -111,12 +137,17 @@ static ssize_t i2c_bus_write(
 .buf = RTEMS_DECONST(void *, buffer)
   };
   int err;
+  unsigned flags = 0;
 
   if (bus->ten_bit_address) {
 msg.flags |= I2C_M_TEN;
   }
 
-  err = i2c_bus_transfer(bus, &msg, 1);
+  if (rtems_libio_iop_is_no_delay(iop)) {
+flags |= I2C_BUS_NOBLOCK;
+  }
+
+  err = i2c_bus_do_transfer(bus, &msg, 1, flags);
   if (err == 0) {
 return msg.len;
   } else {
@@ -133,12 +164,16 @@ static int i2c_bus_ioctl(
   i2c_bus *bus = IMFS_generic_get_context_by_iop(iop);
   i2c_rdwr_ioctl_data *rdwr;
   int err;
+  unsigned flags = 0;
 
   switch (command) {
 case I2C_RDWR:
   rdwr = arg;
   if (rdwr->nmsgs > 0) {
-err = i2c_bus_transfer(bus, rdwr->msgs, rdwr->nmsgs);
+if (rtems_libio_iop_is_no_delay(iop)) {
+  flags |= I2C_BUS_NOBLOCK;
+}
+err = i2c_bus_do_transfer(bus, rdwr->msgs, rdwr->nmsgs, flags);
   } else {
 err = 0;
   }
diff --git a/cpukit/include/dev/i2c/i2c.h b/cpukit/include/dev/i2c/i2c.h
index ac2c369785..5aa45e390c 100644
--- a/cpukit/include/dev/i2c/i2c.h
+++ b/cpukit/include/dev/i2c/i2c.h
@@ -242,6 +242,16 @@ int i2c_bus_register(
   const char *bus_path
 );
 
+/**
+ * @brief Try to obtain the bus.
+ *
+ * @param[in] bus The bus control.
+ *
+ * @retval 0 Successful operation.
+ * @retval EBUSY if mutex is already locked.
+ */
+int i2c_bus_try_obtain(i2c_bus *bus);
+
 /**
  * @brief Obtains the bus.
  *
@@ -259,7 +269,8 @@ void i2c_bus_release(i2c_bus *bus);
 /**
  * @brief Transfers I2C messages.
  *
- * The bus is obtained before the transfer and released afterwards.
+ * The bus is obtained before the transfer and released afterwards. This is the
+ * same like calling @ref i2c_bus_do_transfer with flags set to 0.
  *
  * @param[in] bus The bus control.
  * @param[in] msgs The messages to transfer.
@@ -271,6 +282,37 @@ void i2c_bus_release(i2c_bus *bus);
  */
 int i2c_bus_transfer(i2c_bus *bus, i2c_msg *msgs, uint32_t msg_count);
 
+/**
+ * @brief Transfers I2C messages with optional flags.
+ *
+ * The bus is obtained before the transfer and released afterwards. If the flag
+ * I2C_BUS_NOBLOCK is set and the bus is already obtained, nothing will be
+ * transfered and the function returns with an -EAGAIN.
+ *
+ * @param[in] bus The bus control.
+ * @param[in] msgs The messages to transfer.
+ * @param[in] msg_count The count of messages to transfer.  It must be
+ * positive.
+ * @param[in] flags Options for the whole transfer.
+ *
+ * @retval 0 Successful operation.
+ * @retval -EAGAIN if @ref I2C_BUS_NOBLOCK is set and the bus is already
+ * obtained.
+ * @retval negative Negative error number in case of an error.
+ */
+int i2c_bus_do_transfer(
+  i2c_bus *bus,
+  

Re: Minimum.exe Text Size Outliers

[Joel Sherrill]

On Wed, May 26, 2021 at 6:02 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25/05/2021 20:33, Christian Mauderer wrote:
> >
> >>
> >> I thought Sebastian added a "malloc" for the BSP to use before the
> >> heap was initialized. But I don't remember the name. Am I remembering
> >> correctly?
> >
> > I don't really know that malloc. But I doubt that it works that early.
> > Again: Copying the FDT is one of the first things that these BSPs do. If
> > you want to know the exact location: For ARM it's here:
> >
> > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325
> >
> > So it's really basic setup before that. It's interrupt stack, switching
> > modes, setup stack pointer and then it's already copy FDT.
>
> Yes, there is an early "malloc". This is _Memory_Allocate() using
> _Memory_Get(). However, for the device tree copy this is not early
> enough. We don't know the device tree location provided by the boot
> loader. It could be somewhere in the memory area used by the
> application. So, it is important to copy this very early into a fixed
> location. Also, the device tree may be used to get the size of the
> memory provided by _Memory_Get().
>

I assume read-only is only from the perspective of higher level
language code. Is it possible that being read-only it could be
mapped to Flash?

For the purposes of minimum size analysis, I will subtract the
size of the FDT block from the minimum .text size and if it
is still over 64, flag it.

--joel

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

Re: Minimum.exe Text Size Outliers

[Christian Mauderer]

On 26/05/2021 19:23, Joel Sherrill wrote:



On Wed, May 26, 2021 at 6:02 AM Sebastian Huber 
> wrote:


On 25/05/2021 20:33, Christian Mauderer wrote:
 >
 >>
 >> I thought Sebastian added a "malloc" for the BSP to use before the
 >> heap was initialized. But I don't remember the name. Am I
remembering
 >> correctly?
 >
 > I don't really know that malloc. But I doubt that it works that
early.
 > Again: Copying the FDT is one of the first things that these BSPs
do. If
 > you want to know the exact location: For ARM it's here:
 >
 >
https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325

 >
 > So it's really basic setup before that. It's interrupt stack,
switching
 > modes, setup stack pointer and then it's already copy FDT.

Yes, there is an early "malloc". This is _Memory_Allocate() using
_Memory_Get(). However, for the device tree copy this is not early
enough. We don't know the device tree location provided by the boot
loader. It could be somewhere in the memory area used by the
application. So, it is important to copy this very early into a fixed
location. Also, the device tree may be used to get the size of the
memory provided by _Memory_Get().


I assume read-only is only from the perspective of higher level
language code. Is it possible that being read-only it could be
mapped to Flash?


If the code is mapped to flash, the BSP is broken. I think there are 
options for such a case so that the FDT is placed in another section. 
Not sure whether any BSP is using them.


This kind of copy should be only done on BSPs that run out of RAM. Like 
I said earlier: Normally that's the case for BSPs that are loaded by U-Boot.




For the purposes of minimum size analysis, I will subtract the
size of the FDT block from the minimum .text size and if it
is still over 64, flag it.


Sounds reasonable.

Best regards

Christian



--joel


-- 
embedded brains GmbH

Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de

phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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



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

[PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c

[Harrison Edward Gerber]

See also CID 1399721
Closes #4442
---
 cpukit/libpci/pci_cfg_print_code.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/libpci/pci_cfg_print_code.c 
b/cpukit/libpci/pci_cfg_print_code.c
index e758fa661a..e0979db74a 100644
--- a/cpukit/libpci/pci_cfg_print_code.c
+++ b/cpukit/libpci/pci_cfg_print_code.c
@@ -65,8 +65,8 @@ static void pci_cfg_print_device(struct pci_dev *dev, char 
*prefix)
char name[32];
char buf[8];
printf("%s.resources = {\n", prefix);
-   strcpy(buf, prefix);
-   strcat(buf, "\t");
+   strlcpy(buf, prefix, sizeof(buf));
+   strlcat(buf, "\t", sizeof(buf));
pci_cfg_print_resources(dev->resources, buf);
printf("%s},\n", prefix);
if (dev->next == NULL) {
-- 
2.25.1

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

Re: [PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c

[Joel Sherrill]

On Wed, May 26, 2021 at 1:58 PM Harrison Edward Gerber 
wrote:

> See also CID 1399721
> Closes #4442
>

Blank line between these.

But otherwise I think this looks good.

Gedare... this looks like a good paper on this family of methods for
advice on safe programming:

https://www.sudo.ws/todd/papers/strlcpy.html

Should we put a discussion of this type of issue in the Coding Style
and reference it?


> ---
>  cpukit/libpci/pci_cfg_print_code.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libpci/pci_cfg_print_code.c
> b/cpukit/libpci/pci_cfg_print_code.c
> index e758fa661a..e0979db74a 100644
> --- a/cpukit/libpci/pci_cfg_print_code.c
> +++ b/cpukit/libpci/pci_cfg_print_code.c
> @@ -65,8 +65,8 @@ static void pci_cfg_print_device(struct pci_dev *dev,
> char *prefix)
> char name[32];
> char buf[8];
> printf("%s.resources = {\n", prefix);
> -   strcpy(buf, prefix);
> -   strcat(buf, "\t");
> +   strlcpy(buf, prefix, sizeof(buf));
> +   strlcat(buf, "\t", sizeof(buf));
> pci_cfg_print_resources(dev->resources, buf);
> printf("%s},\n", prefix);
> if (dev->next == NULL) {
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Minimum.exe Text Size Outliers

[Joel Sherrill]

Another minimum size report. If the text size after
subtracting the FDT blob is below 64K, the BSP is not
in the report. The adjusted size is reported.

It looks like some significant percentage of those over 64k
are managing to pull in printf or something in the family. I
wonder if we should ban printf() from BSPs and drivers in favor
of printk?

--joel

On Wed, May 26, 2021 at 1:14 PM Christian Mauderer 
wrote:

>
>
> On 26/05/2021 19:23, Joel Sherrill wrote:
> >
> >
> > On Wed, May 26, 2021 at 6:02 AM Sebastian Huber
> >  > > wrote:
> >
> > On 25/05/2021 20:33, Christian Mauderer wrote:
> >  >
> >  >>
> >  >> I thought Sebastian added a "malloc" for the BSP to use before
> the
> >  >> heap was initialized. But I don't remember the name. Am I
> > remembering
> >  >> correctly?
> >  >
> >  > I don't really know that malloc. But I doubt that it works that
> > early.
> >  > Again: Copying the FDT is one of the first things that these BSPs
> > do. If
> >  > you want to know the exact location: For ARM it's here:
> >  >
> >  >
> > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325
> >  >
> >  >
> >  > So it's really basic setup before that. It's interrupt stack,
> > switching
> >  > modes, setup stack pointer and then it's already copy FDT.
> >
> > Yes, there is an early "malloc". This is _Memory_Allocate() using
> > _Memory_Get(). However, for the device tree copy this is not early
> > enough. We don't know the device tree location provided by the boot
> > loader. It could be somewhere in the memory area used by the
> > application. So, it is important to copy this very early into a fixed
> > location. Also, the device tree may be used to get the size of the
> > memory provided by _Memory_Get().
> >
> >
> > I assume read-only is only from the perspective of higher level
> > language code. Is it possible that being read-only it could be
> > mapped to Flash?
>
> If the code is mapped to flash, the BSP is broken. I think there are
> options for such a case so that the FDT is placed in another section.
> Not sure whether any BSP is using them.
>
> This kind of copy should be only done on BSPs that run out of RAM. Like
> I said earlier: Normally that's the case for BSPs that are loaded by
> U-Boot.
>
> >
> > For the purposes of minimum size analysis, I will subtract the
> > size of the FDT block from the minimum .text size and if it
> > is still over 64, flag it.
>
> Sounds reasonable.
>
> Best regards
>
> Christian
>
> >
> > --joel
> >
> >
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > 
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
> Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > 
> >
>
=== arm-beagleboardorig-minimum.exe  354960 in text =
   textdata bss dec hex filename
 3549601368 263884740   264241068   fbfffac 
arm-beagleboardorig-minimum.exe
Text Size Adjusted for bsp_fdt_blob:  92816
80006b94 0d2c T _IO_Vprintf
801016c0 1000 B _ISR_Stack_area_begin
800543a8 157c r ti_padconf_devmap
8000e688 170c T _dtoa_r
8000bdbc 270c T _svfprintf_r
=== arm-beagleboardxm-minimum.exe  354960 in text =
   textdata bss dec hex filename
 3549601368 263884740   264241068   fbfffac 
arm-beagleboardxm-minimum.exe
Text Size Adjusted for bsp_fdt_blob:  92816
80006b94 0d2c T _IO_Vprintf
801016c0 1000 B _ISR_Stack_area_begin
800543a8 157c r ti_padconf_devmap
8000e688 170c T _dtoa_r
8000bdbc 270c T _svfprintf_r
=== arm-beagleboneblack-minimum.exe  354960 in text =
   textdata bss dec hex filename
 3549601368 263884740   264241068   fbfffac 
arm-beagleboneblack-minimum.exe
Text Size Adjusted for bsp_fdt_blob:  92816
80006b94 0d2c T _IO_Vprintf
801016c0 1000 B _ISR_Stack_area_begin
800543a8 157c r ti_padconf_devmap
8000e688 170c T _dtoa_r
8000bdbc 270c T _svfprintf_r
=== arm-beaglebonewhite-minimum.exe  354960 in text =
   textdata bss dec hex filename
 3549601368 263884740   264241068   fbfffac 
arm-beaglebonewhite-minimum.exe
Text Size Adjusted for bsp_fdt_blob:  92816
80006b94 0d2c T _IO_Vprintf
801016c0 1000 B _ISR_Stack_area_begin
800543a8 157c r ti_padconf_devmap
8000e688 170c T _dtoa_r

[PATCH v2 2/6] bsps/aarch64: Align MVAs consistently

[Kinsey Moore]

This fixes a bug where addresses were not being aligned correctly.
Addresses used in cache functions are now aligned consistently using
RTEMS_ALIGN_DOWN.
---
 bsps/aarch64/shared/cache/cache.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/bsps/aarch64/shared/cache/cache.c 
b/bsps/aarch64/shared/cache/cache.c
index ce2e130abe..47722c21e4 100644
--- a/bsps/aarch64/shared/cache/cache.c
+++ b/bsps/aarch64/shared/cache/cache.c
@@ -39,11 +39,9 @@
 #include 
 #include 
 
-#define AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT ((size_t)64)
-#define AARCH64_CACHE_L1_DATA_LINE_MASK \
-  ( AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT - 1 )
-#define AARCH64_CACHE_PREPARE_MVA(mva) \
-  ((const void *) (((size_t) (mva)) & AARCH64_CACHE_L1_DATA_LINE_MASK))
+#define AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT ( (size_t) 64 )
+#define AARCH64_CACHE_PREPARE_MVA(mva) (const void *) \
+  RTEMS_ALIGN_DOWN ( (size_t) mva, AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT )
 
 static inline
 void AArch64_data_cache_clean_and_invalidate_line(const void *d_addr)
@@ -75,7 +73,7 @@ _CPU_cache_flush_data_range(
 {
   _AARCH64_Data_synchronization_barrier();
   if ( n_bytes != 0 ) {
-size_t adx = (size_t) d_addr & ~AARCH64_CACHE_L1_DATA_LINE_MASK;
+size_t adx = (size_t) AARCH64_CACHE_PREPARE_MVA ( d_addr );
 const size_t ADDR_LAST = (size_t) d_addr + n_bytes - 1;
 
 for (; adx <= ADDR_LAST; adx += AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT ) {
@@ -116,8 +114,7 @@ _CPU_cache_invalidate_data_range(
 )
 {
   if ( n_bytes != 0 ) {
-size_t adx = (size_t) d_addr
- & ~AARCH64_CACHE_L1_DATA_LINE_MASK;
+size_t adx = (size_t) AARCH64_CACHE_PREPARE_MVA ( d_addr );
 const size_t end = (size_t)d_addr + n_bytes -1;
 
 /* Back starting address up to start of a line and invalidate until end */
-- 
2.20.1

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

[PATCH v2 4/6] bsps/a53: Increase available RAM

[Kinsey Moore]

The default available RAM on the A53 BSP is quite small at 8MB. This
bumps that to 128MB to avoid allocation failures in tmcontext01 caused
by large allocations on a cache size of 16MB reported by the system
registers in QEMU.
---
 spec/build/bsps/aarch64/a53/optramlen.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/build/bsps/aarch64/a53/optramlen.yml 
b/spec/build/bsps/aarch64/a53/optramlen.yml
index 95cd6657ee..b67c427b1d 100644
--- a/spec/build/bsps/aarch64/a53/optramlen.yml
+++ b/spec/build/bsps/aarch64/a53/optramlen.yml
@@ -7,7 +7,7 @@ actions:
 build-type: option
 copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
-default: 8388608
+default: 0x800
 default-by-variant: []
 description: |
   length of memory area available to the BSP
-- 
2.20.1

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

[PATCH v2 6/6] spec/aarch64: Add BSPs for real ZynqMP hardware

[Kinsey Moore]

Add the BSPs for running on the ZU3EG Ultrascale+ Zynq MPSoC and alter
the option defaults necessary for them to run properly using the
standard BOOT.BIN configured for PetaLinux that comes in the Out-of-Box
package.
---
 spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml |  1 +
 .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   | 19 +++
 .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml| 19 +++
 .../bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml  | 18 ++
 .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  6 +-
 .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  6 +-
 .../bsps/aarch64/xilinx-zynqmp/tstzu3eg.yml   | 18 ++
 7 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3egilp32.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3eglp64.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/tstzu3eg.yml

diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
index c723b5f252..56c7694f35 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml
@@ -14,6 +14,7 @@ default-by-variant:
   - -mabi=ilp32
   variants:
   - aarch64/xilinx_zynqmp_ilp32_qemu
+  - aarch64/xilinx_zynqmp_ilp32_zu3eg
 description: |
   ABI flags
 enabled-by: true
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3egilp32.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3egilp32.yml
new file mode 100644
index 00..dd7d39fb94
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3egilp32.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: aarch64
+bsp: xilinx_zynqmp_ilp32_zu3eg
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2020 On-Line Applications Research (OAR)
+cppflags: []
+enabled-by: true
+family: xilinx-zynqmp
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp_zu3eg
+- role: build-dependency
+  uid: linkcmds_ilp32
+source: []
+type: build
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3eglp64.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3eglp64.yml
new file mode 100644
index 00..073e91175b
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspzu3eglp64.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: aarch64
+bsp: xilinx_zynqmp_lp64_zu3eg
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2020 On-Line Applications Research (OAR)
+cppflags: []
+enabled-by: true
+family: xilinx-zynqmp
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp_zu3eg
+- role: build-dependency
+  uid: linkcmds_lp64
+source: []
+type: build
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml
new file mode 100644
index 00..801195cdf5
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: group
+copyrights:
+- Copyright (C) 2021 On-Line Applications Research (OAR)
+enabled-by: true
+includes: []
+install: []
+ldflags: []
+links:
+- role: build-dependency
+  uid: grp
+- role: build-dependency
+  uid: ../../optstarthyp
+- role: build-dependency
+  uid: tstzu3eg
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
index 4546006c7e..0bdc2d61df 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
@@ -8,7 +8,11 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
 default: 32768
-default-by-variant: []
+default-by-variant:
+- value: 0x0
+  variants:
+  - aarch64/xilinx_zynqmp_lp64_zu3eg
+  - aarch64/xilinx_zynqmp_ilp32_zu3eg
 description: |
   offset of RAM region from memory area base
 enabled-by: true
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
index 73c89995ba..c17febe288 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
@@ -8,7 +8,11 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
 default: 0x40018000
-default-by-variant: []
+default-by-variant:
+- value: 0x1000
+  variants:
+  - aarch64/xilinx_zynqmp_lp64_zu3eg
+  - aarch64/xilinx_zynqmp_ilp32_zu3eg
 description: |
   base address of memory area available to the BSP
 enabled-by: true
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/tstzu3eg.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/tstzu3eg.yml
new file mode 100644
index 00..8bf646b1d4
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/tstzu3eg.yml
@@ -0,0 +1,18 @@
+SPD

[PATCH v2 3/6] bsps/aarch64: Advertise cache function support

[Kinsey Moore]

Ensure that cache functions are flagged as usable by the generic cache
implementation code.
---
 bsps/aarch64/shared/cache/cache.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/bsps/aarch64/shared/cache/cache.c 
b/bsps/aarch64/shared/cache/cache.c
index 47722c21e4..9e7446a077 100644
--- a/bsps/aarch64/shared/cache/cache.c
+++ b/bsps/aarch64/shared/cache/cache.c
@@ -39,6 +39,16 @@
 #include 
 #include 
 
+#define CPU_DATA_CACHE_ALIGNMENT 64
+
+#define CPU_INSTRUCTION_CACHE_ALIGNMENT 64
+
+#define CPU_CACHE_SUPPORT_PROVIDES_RANGE_FUNCTIONS
+
+#define CPU_CACHE_SUPPORT_PROVIDES_CACHE_SIZE_FUNCTIONS
+
+#define CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA
+
 #define AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT ( (size_t) 64 )
 #define AARCH64_CACHE_PREPARE_MVA(mva) (const void *) \
   RTEMS_ALIGN_DOWN ( (size_t) mva, AARCH64_CACHE_L1_CPU_DATA_ALIGNMENT )
-- 
2.20.1

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

[PATCH v2 5/6] bsps/aarch64: Add MMU driver to relax alignment

[Kinsey Moore]

Currently, the AArch64 BSPs have a hard time running on real hardware
without building the toolchain and the bsps with -mstrict-align in
multiple places. Configuring the MMU on these chips allows for unaligned
memory accesses for non-device memory which avoids requiring strict
alignment in the toolchain and in the BSPs themselves.

In writing this driver, it was found that the synchronous exception
handling code needed to be rewritten since it relied on clearing SCTLR_EL1 to
avoid thread stack misalignments in RTEMS_DEBUG mode. This is now
avoided by exactly preserving thread mode stack and flags and the new
implementation is compatible with the draft information provided on the
mailing list covering the Exception Management API.
---
 bsps/aarch64/include/bsp/aarch64-mmu.h| 426 ++
 bsps/aarch64/include/bsp/linker-symbols.h |   7 +
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  |   7 +
 .../xilinx-zynqmp/start/bspstarthooks.c   |   1 +
 .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |  77 
 .../cpu/aarch64/aarch64-exception-default.S   |  66 ++-
 spec/build/bsps/aarch64/optmmupages.yml   |  19 +
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
 .../aarch64/xilinx-zynqmp/linkcmds_ilp32.yml  |   8 +-
 .../aarch64/xilinx-zynqmp/linkcmds_lp64.yml   |   8 +-
 spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   2 +
 11 files changed, 603 insertions(+), 20 deletions(-)
 create mode 100644 bsps/aarch64/include/bsp/aarch64-mmu.h
 create mode 100644 bsps/aarch64/xilinx-zynqmp/start/bspstartmmu.c
 create mode 100644 spec/build/bsps/aarch64/optmmupages.yml

diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h 
b/bsps/aarch64/include/bsp/aarch64-mmu.h
new file mode 100644
index 00..e82012576f
--- /dev/null
+++ b/bsps/aarch64/include/bsp/aarch64-mmu.h
@@ -0,0 +1,426 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup aarch64_start
+ *
+ * @brief AArch64 MMU configuration.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef LIBBSP_AARCH64_SHARED_AARCH64_MMU_H
+#define LIBBSP_AARCH64_SHARED_AARCH64_MMU_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/* VMSAv8 Long-descriptor fields */
+#define MMU_DESC_AFBSP_BIT64( 10 )
+#define MMU_DESC_SH_INNER  ( BSP_BIT64( 9 ) | BSP_BIT64( 8 ) )
+#define MMU_DESC_WRITE_DISABLE BSP_BIT64( 7 )
+/* PAGE and TABLE flags are the same bit, but only apply on certain levels */
+#define MMU_DESC_TYPE_TABLEBSP_BIT64( 1 )
+#define MMU_DESC_TYPE_PAGE BSP_BIT64( 1 )
+#define MMU_DESC_VALID BSP_BIT64( 0 )
+#define MMU_DESC_MAIR_ATTR( val )  BSP_FLD64( val, 2, 3 )
+#define MMU_DESC_MAIR_ATTR_GET( reg )  BSP_FLD64GET( reg, 2, 3 )
+#define MMU_DESC_MAIR_ATTR_SET( reg, val ) BSP_FLD64SET( reg, val, 2, 3 )
+#define MMU_DESC_PAGE_TABLE_MASK   0xF000LL
+
+/* Page table configuration */
+#define MMU_PAGE_BITS   12
+#define MMU_PAGE_SIZE   ( 1 << MMU_PAGE_BITS )
+#define MMU_BITS_PER_LEVEL  9
+#define MMU_TOP_LEVEL_PAGE_BITS ( 2 * MMU_BITS_PER_LEVEL + MMU_PAGE_BITS )
+
+#define AARCH64_MMU_FLAGS_BASE \
+  ( MMU_DESC_VALID | MMU_DESC_SH_INNER | MMU_DESC_AF )
+
+#define AARCH64_MMU_DATA_RO_CACHED \
+  ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 3 ) | MMU_DESC_WRITE_DISABLE )
+#define AARCH64_MMU_CODE_CACHED AARCH64_MMU_DATA_RO_CACHED
+#define AARCH64_MMU_CODE_RW_CACHED AARCH64_MMU_DATA_RW_CACHED
+
+#define AARCH64_MMU_DATA_RO \
+  (

[PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

[Harrison Edward Gerber]

See also CID 1399727

Closes #
---
 cpukit/libmisc/monitor/mon-editor.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/monitor/mon-editor.c 
b/cpukit/libmisc/monitor/mon-editor.c
index dcea9fcc69..1392be51f1 100644
--- a/cpukit/libmisc/monitor/mon-editor.c
+++ b/cpukit/libmisc/monitor/mon-editor.c
@@ -360,7 +360,8 @@ rtems_monitor_line_editor (
 {
   int bs;
   pos--;
-  strcpy (buffer + pos, buffer + pos + 1);
+  memmove(buffer + pos, buffer + pos + 1, 
RTEMS_COMMAND_BUFFER_SIZE - pos - 1);
+  buffer[RTEMS_COMMAND_BUFFER_SIZE - 1] = "\0";
   fprintf(stdout,"\b%s \b", buffer + pos);
   for (bs = 0; bs < ((int) strlen (buffer) - pos); bs++)
 putchar ('\b');
-- 
2.25.1

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

Re: [PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c

[Vijay Kumar Banerjee]

Hi,

On Wed, May 26, 2021 at 2:45 PM Joel Sherrill  wrote:
>
>
>
> On Wed, May 26, 2021 at 1:58 PM Harrison Edward Gerber  
> wrote:
>>
>> See also CID 1399721
>> Closes #4442
>
>
> Blank line between these.
>
> But otherwise I think this looks good.
>

I pushed it with the added blank line in the commit message.

Thanks.

> Gedare... this looks like a good paper on this family of methods for
> advice on safe programming:
>
> https://www.sudo.ws/todd/papers/strlcpy.html
>
> Should we put a discussion of this type of issue in the Coding Style
> and reference it?
>
>>
>> ---
>>  cpukit/libpci/pci_cfg_print_code.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/cpukit/libpci/pci_cfg_print_code.c 
>> b/cpukit/libpci/pci_cfg_print_code.c
>> index e758fa661a..e0979db74a 100644
>> --- a/cpukit/libpci/pci_cfg_print_code.c
>> +++ b/cpukit/libpci/pci_cfg_print_code.c
>> @@ -65,8 +65,8 @@ static void pci_cfg_print_device(struct pci_dev *dev, char 
>> *prefix)
>> char name[32];
>> char buf[8];
>> printf("%s.resources = {\n", prefix);
>> -   strcpy(buf, prefix);
>> -   strcat(buf, "\t");
>> +   strlcpy(buf, prefix, sizeof(buf));
>> +   strlcat(buf, "\t", sizeof(buf));
>> pci_cfg_print_resources(dev->resources, buf);
>> printf("%s},\n", prefix);
>> if (dev->next == NULL) {
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit: Add description of release version numbers

[Chris Johns]

Thank you for this.

On 26/5/21 7:41 pm, Christian Mauderer wrote:
> The release version in the git sources doesn't change. Add a note why
> that is the case.
> ---
>  cpukit/include/rtems/version.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
> index a8aff732f3..2e068cd976 100644
> --- a/cpukit/include/rtems/version.h
> +++ b/cpukit/include/rtems/version.h
> @@ -29,6 +29,18 @@ extern "C" {
>   *
>   * @brief The Version API provides functions to return the version or parts 
> of
>   * the version of RTEMS you are using.
> + *
> + * A branch in the version control system will always fall back to a
> + * not-released version number with a minor number of 0. Only the release

I would use `NOT-RELEASED`.

> + * archives have a VERSION file with a final release number. That means for
> + * example that the 5 development branch will still show a version 5.0.0 even
> + * after the 5.1 release.
> + *
> + * The reason for that is the following: All pre-release tests are performed 
> for
> + * a specific git hash. If the VERSION file would be changed and committed
> + * afterwards for releasing a new version, the released version would have a
> + * different git hash and the test results couldn't be linked to the released
> + * version.

Close  what about :

The reason for that are the following:

1. All pre-release tests are performed with a specific git hash. A committed
VERSION file would need to be changed and committed afterwards for releasing
with the required release version causing the released version to have a
different git hash and the test results couldn't be linked to the released 
version.

2. Users deploying RTEMS would need to commit a local change to a committed
VERSION file and that would clash with the project changes. Deployment can use
the project repos directly.

3. The VERSION file management and generation is the responsibility of the
release manager and the release process.

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

Re: [PATCH] tester: Expand special case for minimum.exe

[Chris Johns]

On 26/5/21 1:52 am, Kinsey Moore wrote:
> The minimum.exe test case is expected to fail as an "invalid" test in
> the tester since it is completely stripped down and does not output the
> normal test header and footer. When fatal error detection support was
> added, this caught minimum.exe and started flagging it as "fatal"
> instead of "invalid". The special-case detection of minimum.exe only
> matched on "invalid" results and not "fatal" results and so began
> flagging minimum.exe as an actual failure.>
> This change adds the special-case handling to the "fatal" test state
> handling.

Is this the right solution?

Is minimum.exe suppose to run and not fail? It would seem easy to make a
minimum.exe with nothing in it, ie minimal, that seems to pass. It would make
great marketing material.

What happens if minimum fails? I feel minimum needs to be able to run and not
fail to be a valid minimum.

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

Re: [PATCH] tester: Expand special case for minimum.exe

[Joel Sherrill]

On Wed, May 26, 2021, 7:03 PM Chris Johns  wrote:

> On 26/5/21 1:52 am, Kinsey Moore wrote:
> > The minimum.exe test case is expected to fail as an "invalid" test in
> > the tester since it is completely stripped down and does not output the
> > normal test header and footer. When fatal error detection support was
> > added, this caught minimum.exe and started flagging it as "fatal"
> > instead of "invalid". The special-case detection of minimum.exe only
> > matched on "invalid" results and not "fatal" results and so began
> > flagging minimum.exe as an actual failure.>
> > This change adds the special-case handling to the "fatal" test state
> > handling.
>
> Is this the right solution?
>
> Is minimum.exe suppose to run and not fail? It would seem easy to make a
> minimum.exe with nothing in it, ie minimal, that seems to pass. It would
> make
> great marketing material.
>
> What happens if minimum fails? I feel minimum needs to be able to run and
> not
> fail to be a valid minimum.
>

It is an empty thread body that doesn't print. I suppose we could add
rtems_shutdown_executive(0) if that helps

>
> Chris
> ___
> 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] tester: Expand special case for minimum.exe

[Chris Johns]

On 27/5/21 12:06 pm, Joel Sherrill wrote:
> On Wed, May 26, 2021, 7:03 PM Chris Johns  > wrote:
> 
> On 26/5/21 1:52 am, Kinsey Moore wrote:
> > The minimum.exe test case is expected to fail as an "invalid" test in
> > the tester since it is completely stripped down and does not output the
> > normal test header and footer. When fatal error detection support was
> > added, this caught minimum.exe and started flagging it as "fatal"
> > instead of "invalid". The special-case detection of minimum.exe only
> > matched on "invalid" results and not "fatal" results and so began
> > flagging minimum.exe as an actual failure.>
> > This change adds the special-case handling to the "fatal" test state
> > handling.
> 
> Is this the right solution?
> 
> Is minimum.exe suppose to run and not fail? It would seem easy to make a
> minimum.exe with nothing in it, ie minimal, that seems to pass. It would 
> make
> great marketing material.
> 
> What happens if minimum fails? I feel minimum needs to be able to run and 
> not
> fail to be a valid minimum.
> 
> 
> It is an empty thread body that doesn't print. I suppose we could add
> rtems_shutdown_executive(0) if that helps

What if the work to make it small removes something that is needed? Is minimum
suppose to be run and if it is how do we know it was successfull?

My point is about the purpose of minimum. If we can never tell a run failed
should it be run? If we cannot tell then excluding it as a test to run for all
BSPs may be a simpler option that this change.

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

Re: AW: question about posix timer expiration

[Chris Johns]

On 21/5/21 9:44 pm, gabriel.moy...@dlr.de wrote:
> Did you compile ptpd with kqueue only? I’ve tried with posix timer, which are
> implemented in rtems, but it seems that the handler with siginfo_t is not 
> called
> correctly. I’ve managed to get it working using a workaround but I’ll continue
> with kqueue, thx!.

Yes I did build with kqueue. I added the kqueue support to ptpdv2 because libbsd
does not support signal type events. I found this out the hard why when getting
ptpdv2 to run. I had posix timers running but libbsd threads did not wake. I
chased this down to code like ...

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-muteximpl.c#n45

The state set does not include signals so the kernel does not wake the thread.

I discussed this with Sebastian at the time and agreed supporting signals in
libbsd was a lot of work and open a range of possible issues so it was simpler
to add kqueue support to ptpdv2.

I also agree with Sebastian that kqueue is a better interface than select etc
and we should encourage its use. I think ptpdv2 benefits from using kqueue over
select and posix timers.

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

Re: [PATCH v4] sb: Merge mailer changes from rtems-tools

[Chris Johns]

On 12/5/21 3:19 am, Alex White wrote:
> This adds the improved mailer.py script from rtems-tools.
> 
> Closes #4388
> ---
>  source-builder/sb/mailer.py | 194 ++--
>  source-builder/sb/options.py|  26 -
>  source-builder/sb/setbuilder.py |   2 +
>  3 files changed, 189 insertions(+), 33 deletions(-)
> 
> diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
> index ff25df5..aafe6d6 100644
> --- a/source-builder/sb/mailer.py
> +++ b/source-builder/sb/mailer.py
> @@ -1,21 +1,33 @@
>  #
>  # RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2013 Chris Johns (chr...@rtems.org)
> +# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
> +# Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
>  # All rights reserved.
>  #
>  # This file is part of the RTEMS Tools package in 'rtems-tools'.
>  #
> -# Permission to use, copy, modify, and/or distribute this software for any
> -# purpose with or without fee is hereby granted, provided that the above
> -# copyright notice and this permission notice appear in all copies.
> +# 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 HOLDER 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.
>  #
> -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  
>  #
>  # Manage emailing results or reports.
> @@ -28,18 +40,72 @@ import smtplib
>  import socket
>  
>  from . import error
> +from . import execute
>  from . import options
>  from . import path
>  
> +_options = {
> +'--mail' : 'Send email report or results.',
> +'--use-gitconfig': 'Use mail configuration from git config.',
> +'--mail-to'  : 'Email address to send the email to.',
> +'--mail-from': 'Email address the report is from.',
> +'--smtp-host': 'SMTP host to send via.',
> +'--smtp-port': 'SMTP port to send via.',
> +'--smtp-user': 'User for SMTP authentication.',
> +'--smtp-password': 'Password for SMTP authentication.'
> +}
> +
>  def append_options(opts):
> -opts['--mail'] = 'Send email report or results.'
> -opts['--smtp-host'] = 'SMTP host to send via.'
> -opts['--mail-to'] = 'Email address to send the email too.'
> -opts['--mail-from'] = 'Email address the report is from.'
> +for o in _options:
> +opts[o] = _options[o]
> +
> +def add_arguments(argsp):
> +argsp.add_argument('--mail', help = _options['--mail'], action = 
> 'store_true')
> +argsp.add_argument('--use-gitconfig', help = 
> _options['--use-gitconfig'], action = 'store_true')
> +no_add = ['--mail', '--use-gitconfig']
> +for o in [opt for opt in list(_options) if opt not in no_add]:
> +argsp.add_argument(o, help = _options[o], type = str)
>  
>  class mail:
>  def __init__(self, opts):
>  self.opts = opts
> +self.gitconfig_lines = None
> +if opts.find_arg('--use-gitconfig') is not None:
> +# Read the output of `git config --list` instead of reading the
> +# .gitconfig file directly because Python 2 ConfigParser does not
> +# accept tabs at the beginning of lines.
> +e = execute.capture_execution()
> +exit_code, proc, output = e.open('git config --list', shell=True)
> +if exit_code == 0:
> +s

Re: RTEMS source builder: can't find RTEMS include files but then can?

[Chris Johns]

On 30/4/21 1:15 am, dufa...@hda.com wrote:
> 
> 
>> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote:
>>
>> Can I override what to use as "cmake" in RSB to specify "cmake3"?
>>
>>> On Apr 30, 2021, at 04:41 , Peter Dufault  wrote:
>>>
>>> I verified my environment is squeaky-clean with a simple path and no 
>>> environment variables set that affect RTEMS or "make".
>>
> 
> I need help figuring out how to setup rtems-source-builder, SOEM, and cmake.  
> I got it to "work" but it's mis-configured.  At first it is not finding 
> header files (is it looking at the Linux headers?), then it installs SOEM in 
> the wrong place, etc.  I can get the build and install to "work" by 
> re-running commands in a shell script - the second time a command is run it 
> behaves differently.
> 
> - *Notes*
> -- This started when I updated SOEM and needed to change to "cmake3".
> -- After the following convoluted process the testing I've done on the 
> results are OK.
> 
> - To simplify my path I make it simple except I add a directory with only a 
> "cmake" bash script: "cmake3 $*" in order to pick up cmake3.

Maybe the --macros argument can help. Create a file `xyz.txt` containing ...

__cmake: exe, optional, 'cmake3'

then try running with `--macros=xyz.txt` If the recipe for the build using cmake
uses `%{__cmake}` then this may work. I have not tested any of this. :)


Chris

> 
> - The first time I run "sb-set-builder" the SOEM build fails because it can't 
> find . This is just after it compiled a C file that includes 
> .  I'm not sure where it is looking for the headers, I'd expect it 
> would fail earlier if it was trying to use Linux headers, it's all the way to 
> the last file.
> 
> - I then run the do-build script sb-set-builder created and it builds SOEM 
> *but it installs it in the wrong place*.
> -- The do-build script is in 
> "${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/do-build"
> -- "do-build" installs SOEM in in 
> "${GITDIR}/rtems-source-builder/rtems/build/tmp/soem-powerpc-rtems6-1-root-dufault/opt/flatland/opt/rtems-6"
>  instead of "/opt/flatland/opt/rtems-6".
> 
> - I then go to the generated directory 
> "${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/build-xc"
>  and type "make install" The make succeeds, and *it installs SOEM in the 
> correct place* and SOEM is "successfully" built and installed.
> 
> - The last nit is that when I try to build the SOEM examples I need to export 
> LDFLAGS="-lrtemsdefaultconfig -lm" to get the SOEM examples to configure. 
> *Note* this was an issue before I switched to cmake3, this one is not new.
> 
> 
> I hope this gives someone enough clues to suggest what must be done to set 
> source builder up correctly.  For reference here's the script.
> 
> #!/bin/sh
> set -e
> # Script to get SOEM to build and install "properly".  I just need to be 
> insistent.
> 
> HERE=$(pwd)
> # Clean up environment  rsb-overrides only has a cmake shell script that is 
> "cmake $*".
> export PATH=${HOME}/bin/rsb-overrides:/usr/bin:/usr/sbin:/bin:/sbin
> unset LD_IBRARY_PATH
> 
> export RTEMS_GIT=/home/dufault/development/rtems
> export RTEMS_VER=6
> export RTEMS_SB=${RTEMS_GIT}/rtems-source-builder
> export RTEMS_SB_BUILD=${RTEMS_SB}/rtems/build
> export RTEMS_TOOLS=/opt/flatland/opt/rtems-${RTEMS_VER}
> export RTEMS_ARCH=powerpc
> export RTEMS_BSP=beatnik
> # "soem-rtems" fetches waf-2.0.4.
> SOEM_WAF=waf-2.0.4
> 
> SOEM_TIDY_UP="\
> ${RTEMS_TOOLS}/share/rtems/rsb/soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1.txt 
> \
> ${RTEMS_TOOLS}/share/rtems/rsb/soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1.xml 
> \
> 
> ${RTEMS_TOOLS}/${RTEMS_ARCH}-rtems${RTEMS_VER}/${RTEMS_BSP}/lib/share/soem \
> 
> ${RTEMS_TOOLS}/${RTEMS_ARCH}-rtems${RTEMS_VER}/${RTEMS_BSP}/lib/include/soem"
> 
> 
> # We have this setup: ${RTEMS_GIT}
> #|-- soem-rtems
> #|-- rtems
> #|-- rtems-source-builder
> 
> # First tidy-up so we always start in the same state.
> rm -rf ${RTEMS_SB_BUILD} ${SOEM_TIDY_UP}
> cd ${RTEMS_GIT}/soem-rtems
> if [ ! -e ${SOEM_WAF} ]; then
> wget -P . https://waf.io/${SOEM_WAF}
> chmod u+x ${SOEM_WAF}
> git submodule init
> git submodule update
> else
> ./${SOEM_WAF} distclean
> fi
> 
> cd ${RTEMS_SB}/rtems
> 
> RTEMS_SB_DEBUG="--no-clean --jobs=1"
> 
> # Now configure to build SOEM.
> # This will fail with:
> # 
> ${RTEMS_SB_BUILD}soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1/soem/oshw/rtems/nicdrv.c:37:10:
> #  fatal error: net/bpf.h: No such file or directory
> 
> if ${RTEMS_SB}/source-builder/sb-set-builder \
> --log=log_${RTEMS_ARCH}_soem \
> --prefix=${RTEMS_TOOLS} \
> --with-tools=${RTEMS_TOOLS} \
> --host=${RTEMS_ARCH}-rtems${RTEMS_VER} \
> --with-rtems-bsp=${RTEMS_BSP} \
> ${RTEMS_SB_DEBUG} \
> net/soem ; \
> then
> echo 2>&1 "*"
> echo 2>&1 "***

Re: [PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

[Gedare Bloom]

On Wed, May 26, 2021 at 4:35 PM Harrison Edward Gerber
 wrote:
>
> See also CID 1399727
>
> Closes #
> ---
>  cpukit/libmisc/monitor/mon-editor.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/libmisc/monitor/mon-editor.c 
> b/cpukit/libmisc/monitor/mon-editor.c
> index dcea9fcc69..1392be51f1 100644
> --- a/cpukit/libmisc/monitor/mon-editor.c
> +++ b/cpukit/libmisc/monitor/mon-editor.c
> @@ -360,7 +360,8 @@ rtems_monitor_line_editor (
>  {
>int bs;
>pos--;
> -  strcpy (buffer + pos, buffer + pos + 1);
> +  memmove(buffer + pos, buffer + pos + 1, 
> RTEMS_COMMAND_BUFFER_SIZE - pos - 1);
This exceeds 80 character line limit, please break the line length as
directed by
https://docs.rtems.org/branches/master/eng/coding-formatting.html#eighty-character-line-limit

> +  buffer[RTEMS_COMMAND_BUFFER_SIZE - 1] = "\0";
This should be '\0' not "\0". I don't know if the compiler would
correct that for you or not.

>fprintf(stdout,"\b%s \b", buffer + pos);
>for (bs = 0; bs < ((int) strlen (buffer) - pos); bs++)
>  putchar ('\b');
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS source builder: can't find RTEMS include files but then can?

[Joel Sherrill]

On Wed, May 26, 2021, 7:54 PM Chris Johns  wrote:

> On 30/4/21 1:15 am, dufa...@hda.com wrote:
> >
> >
> >> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote:
> >>
> >> Can I override what to use as "cmake" in RSB to specify "cmake3"?
> >>
> >>> On Apr 30, 2021, at 04:41 , Peter Dufault  wrote:
> >>>
> >>> I verified my environment is squeaky-clean with a simple path and no
> environment variables set that affect RTEMS or "make".
> >>
> >
> > I need help figuring out how to setup rtems-source-builder, SOEM, and
> cmake.  I got it to "work" but it's mis-configured.  At first it is not
> finding header files (is it looking at the Linux headers?), then it
> installs SOEM in the wrong place, etc.  I can get the build and install to
> "work" by re-running commands in a shell script - the second time a command
> is run it behaves differently.
> >
> > - *Notes*
> > -- This started when I updated SOEM and needed to change to "cmake3".
> > -- After the following convoluted process the testing I've done on the
> results are OK.
> >
> > - To simplify my path I make it simple except I add a directory with
> only a "cmake" bash script: "cmake3 $*" in order to pick up cmake3.
>
> Maybe the --macros argument can help. Create a file `xyz.txt` containing
> ...
>
> __cmake: exe, optional, 'cmake3'
>
> then try running with `--macros=xyz.txt` If the recipe for the build using
> cmake
> uses `%{__cmake}` then this may work. I have not tested any of this. :)
>

This may be a stupid question but can you build it by hand?

--joel

>
>
> Chris
>
> >
> > - The first time I run "sb-set-builder" the SOEM build fails because it
> can't find . This is just after it compiled a C file that
> includes .  I'm not sure where it is looking for the headers, I'd
> expect it would fail earlier if it was trying to use Linux headers, it's
> all the way to the last file.
> >
> > - I then run the do-build script sb-set-builder created and it builds
> SOEM *but it installs it in the wrong place*.
> > -- The do-build script is in
> "${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/do-build"
> > -- "do-build" installs SOEM in in
> "${GITDIR}/rtems-source-builder/rtems/build/tmp/soem-powerpc-rtems6-1-root-dufault/opt/flatland/opt/rtems-6"
> instead of "/opt/flatland/opt/rtems-6".
> >
> > - I then go to the generated directory
> "${GITDIR}/rtems/rtems-source-builder/rtems/build/soem-powerpc-rtems6-1/build-xc"
> and type "make install" The make succeeds, and *it installs SOEM in the
> correct place* and SOEM is "successfully" built and installed.
> >
> > - The last nit is that when I try to build the SOEM examples I need to
> export LDFLAGS="-lrtemsdefaultconfig -lm" to get the SOEM examples to
> configure. *Note* this was an issue before I switched to cmake3, this one
> is not new.
> >
> >
> > I hope this gives someone enough clues to suggest what must be done to
> set source builder up correctly.  For reference here's the script.
> >
> > #!/bin/sh
> > set -e
> > # Script to get SOEM to build and install "properly".  I just need to be
> insistent.
> >
> > HERE=$(pwd)
> > # Clean up environment  rsb-overrides only has a cmake shell script that
> is "cmake $*".
> > export PATH=${HOME}/bin/rsb-overrides:/usr/bin:/usr/sbin:/bin:/sbin
> > unset LD_IBRARY_PATH
> >
> > export RTEMS_GIT=/home/dufault/development/rtems
> > export RTEMS_VER=6
> > export RTEMS_SB=${RTEMS_GIT}/rtems-source-builder
> > export RTEMS_SB_BUILD=${RTEMS_SB}/rtems/build
> > export RTEMS_TOOLS=/opt/flatland/opt/rtems-${RTEMS_VER}
> > export RTEMS_ARCH=powerpc
> > export RTEMS_BSP=beatnik
> > # "soem-rtems" fetches waf-2.0.4.
> > SOEM_WAF=waf-2.0.4
> >
> > SOEM_TIDY_UP="\
> >
>  ${RTEMS_TOOLS}/share/rtems/rsb/soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1.txt \
> >
>  ${RTEMS_TOOLS}/share/rtems/rsb/soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1.xml \
> >
>  ${RTEMS_TOOLS}/${RTEMS_ARCH}-rtems${RTEMS_VER}/${RTEMS_BSP}/lib/share/soem
> \
> >
>  ${RTEMS_TOOLS}/${RTEMS_ARCH}-rtems${RTEMS_VER}/${RTEMS_BSP}/lib/include/soem"
> >
> >
> > # We have this setup: ${RTEMS_GIT}
> > #|-- soem-rtems
> > #|-- rtems
> > #|-- rtems-source-builder
> >
> > # First tidy-up so we always start in the same state.
> > rm -rf ${RTEMS_SB_BUILD} ${SOEM_TIDY_UP}
> > cd ${RTEMS_GIT}/soem-rtems
> > if [ ! -e ${SOEM_WAF} ]; then
> > wget -P . https://waf.io/${SOEM_WAF}
> > chmod u+x ${SOEM_WAF}
> > git submodule init
> > git submodule update
> > else
> > ./${SOEM_WAF} distclean
> > fi
> >
> > cd ${RTEMS_SB}/rtems
> >
> > RTEMS_SB_DEBUG="--no-clean --jobs=1"
> >
> > # Now configure to build SOEM.
> > # This will fail with:
> > #
> ${RTEMS_SB_BUILD}soem-${RTEMS_ARCH}-rtems${RTEMS_VER}-1/soem/oshw/rtems/nicdrv.c:37:10:
> > #  fatal error: net/bpf.h: No such file or directory
> >
> > if ${RTEMS_SB}/source-builder/sb-set-builder \
> > --log=log_${RTEMS_ARCH}_soem \
> > --prefix=${RT

Re: [PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

[Joel Sherrill]

On Wed, May 26, 2021, 8:46 PM Gedare Bloom  wrote:

> On Wed, May 26, 2021 at 4:35 PM Harrison Edward Gerber
>  wrote:
> >
> > See also CID 1399727
> >
> > Closes #
> > ---
> >  cpukit/libmisc/monitor/mon-editor.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/cpukit/libmisc/monitor/mon-editor.c
> b/cpukit/libmisc/monitor/mon-editor.c
> > index dcea9fcc69..1392be51f1 100644
> > --- a/cpukit/libmisc/monitor/mon-editor.c
> > +++ b/cpukit/libmisc/monitor/mon-editor.c
> > @@ -360,7 +360,8 @@ rtems_monitor_line_editor (
> >  {
> >int bs;
> >pos--;
> > -  strcpy (buffer + pos, buffer + pos + 1);
> > +  memmove(buffer + pos, buffer + pos + 1,
> RTEMS_COMMAND_BUFFER_SIZE - pos - 1);
>

My first thought was to ask if strlcpy would be more correct because it
should avoid copying as many bytes. But the source and destination could
overlap as they are close to it just by visual inspection.

I think it would be worth a comment in the code explaining why a string
method wasn't used.

This exceeds 80 character line limit, please break the line length as
> directed by
>
> https://docs.rtems.org/branches/master/eng/coding-formatting.html#eighty-character-line-limit
>
> > +  buffer[RTEMS_COMMAND_BUFFER_SIZE - 1] = "\0";
> This should be '\0' not "\0". I don't know if the compiler would
> correct that for you or not.
>
> >fprintf(stdout,"\b%s \b", buffer + pos);
> >for (bs = 0; bs < ((int) strlen (buffer) - pos); bs++)
> >  putchar ('\b');
> > --
> > 2.25.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit/libmisc/monitor: Fixed src/dest overlap in strcpy in mon-editor.c

[Gedare Bloom]

On Wed, May 26, 2021 at 7:56 PM Joel Sherrill  wrote:
>
>
>
> On Wed, May 26, 2021, 8:46 PM Gedare Bloom  wrote:
>>
>> On Wed, May 26, 2021 at 4:35 PM Harrison Edward Gerber
>>  wrote:
>> >
>> > See also CID 1399727
>> >
>> > Closes #
>> > ---
>> >  cpukit/libmisc/monitor/mon-editor.c | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/cpukit/libmisc/monitor/mon-editor.c 
>> > b/cpukit/libmisc/monitor/mon-editor.c
>> > index dcea9fcc69..1392be51f1 100644
>> > --- a/cpukit/libmisc/monitor/mon-editor.c
>> > +++ b/cpukit/libmisc/monitor/mon-editor.c
>> > @@ -360,7 +360,8 @@ rtems_monitor_line_editor (
>> >  {
>> >int bs;
>> >pos--;
>> > -  strcpy (buffer + pos, buffer + pos + 1);
>> > +  memmove(buffer + pos, buffer + pos + 1, 
>> > RTEMS_COMMAND_BUFFER_SIZE - pos - 1);
>
>
> My first thought was to ask if strlcpy would be more correct because it 
> should avoid copying as many bytes. But the source and destination could 
> overlap as they are close to it just by visual inspection.
>
> I think it would be worth a comment in the code explaining why a string 
> method wasn't used.
>
Good idea. BTW: it is guaranteed that the source and dest overlap in
this particular case.

>> This exceeds 80 character line limit, please break the line length as
>> directed by
>> https://docs.rtems.org/branches/master/eng/coding-formatting.html#eighty-character-line-limit
>>
>> > +  buffer[RTEMS_COMMAND_BUFFER_SIZE - 1] = "\0";
>> This should be '\0' not "\0". I don't know if the compiler would
>> correct that for you or not.
>>
>> >fprintf(stdout,"\b%s \b", buffer + pos);
>> >for (bs = 0; bs < ((int) strlen (buffer) - pos); bs++)
>> >  putchar ('\b');
>> > --
>> > 2.25.1
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] tester: Expand special case for minimum.exe

[Kinsey Moore]

On 5/26/2021 19:22, Chris Johns wrote:

On 27/5/21 12:06 pm, Joel Sherrill wrote:

On Wed, May 26, 2021, 7:03 PM Chris Johns mailto:chr...@rtems.org>> wrote:

 On 26/5/21 1:52 am, Kinsey Moore wrote:
 > The minimum.exe test case is expected to fail as an "invalid" test in
 > the tester since it is completely stripped down and does not output the
 > normal test header and footer. When fatal error detection support was
 > added, this caught minimum.exe and started flagging it as "fatal"
 > instead of "invalid". The special-case detection of minimum.exe only
 > matched on "invalid" results and not "fatal" results and so began
 > flagging minimum.exe as an actual failure.>
 > This change adds the special-case handling to the "fatal" test state
 > handling.

 Is this the right solution?

 Is minimum.exe suppose to run and not fail? It would seem easy to make a
 minimum.exe with nothing in it, ie minimal, that seems to pass. It would 
make
 great marketing material.

 What happens if minimum fails? I feel minimum needs to be able to run and 
not
 fail to be a valid minimum.


It is an empty thread body that doesn't print. I suppose we could add
rtems_shutdown_executive(0) if that helps

What if the work to make it small removes something that is needed? Is minimum
suppose to be run and if it is how do we know it was successfull?

My point is about the purpose of minimum. If we can never tell a run failed
should it be run? If we cannot tell then excluding it as a test to run for all
BSPs may be a simpler option that this change.


hello.exe already provides a minimum test case for something that can be 
verified to be functional, so I'd lean toward excluding minimum.exe from 
test runs of all BSPs. If minimum.exe is kept in, it needs its expected 
test state to be set to fatal-error by default for all BSPs. 
Unfortunately, fatal-error is currently bundled in as a more generic 
failure when being reported.



Kinsey

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

Re: [PATCH] tester: Expand special case for minimum.exe

[Chris Johns]

On 27/5/21 2:04 pm, Kinsey Moore wrote:
> On 5/26/2021 19:22, Chris Johns wrote:
>> On 27/5/21 12:06 pm, Joel Sherrill wrote:
>>> On Wed, May 26, 2021, 7:03 PM Chris Johns >> > wrote:
>>>
>>>  On 26/5/21 1:52 am, Kinsey Moore wrote:
>>>  > The minimum.exe test case is expected to fail as an "invalid" test in
>>>  > the tester since it is completely stripped down and does not output 
>>> the
>>>  > normal test header and footer. When fatal error detection support was
>>>  > added, this caught minimum.exe and started flagging it as "fatal"
>>>  > instead of "invalid". The special-case detection of minimum.exe only
>>>  > matched on "invalid" results and not "fatal" results and so began
>>>  > flagging minimum.exe as an actual failure.>
>>>  > This change adds the special-case handling to the "fatal" test state
>>>  > handling.
>>>
>>>  Is this the right solution?
>>>
>>>  Is minimum.exe suppose to run and not fail? It would seem easy to make 
>>> a
>>>  minimum.exe with nothing in it, ie minimal, that seems to pass. It 
>>> would
>>> make
>>>  great marketing material.
>>>
>>>  What happens if minimum fails? I feel minimum needs to be able to run
>>> and not
>>>  fail to be a valid minimum.
>>>
>>>
>>> It is an empty thread body that doesn't print. I suppose we could add
>>> rtems_shutdown_executive(0) if that helps
>> What if the work to make it small removes something that is needed? Is 
>> minimum
>> suppose to be run and if it is how do we know it was successfull?
>>
>> My point is about the purpose of minimum. If we can never tell a run failed
>> should it be run? If we cannot tell then excluding it as a test to run for 
>> all
>> BSPs may be a simpler option that this change.
> 
> hello.exe already provides a minimum test case for something that can be
> verified to be functional, so I'd lean toward excluding minimum.exe from test
> runs of all BSPs. If minimum.exe is kept in, it needs its expected test state 
> to
> be set to fatal-error by default for all BSPs. Unfortunately, fatal-error is
> currently bundled in as a more generic failure when being reported.

Or minimum.exe is created as a no-run executable? See the various API link only
tests for an example.

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

Re: RFS and 2038

[Chris Johns]

On 1/5/21 6:19 am, Joel Sherrill wrote:
> Hi
> 
> Ryan has been working to add support for the new (not obsolete) nanosecond
> granularity variants of utime. In changing the utime_h file system handler to
> utimens_h and propagating the changes, Ryan tripped across this.
> 
> rtems/rfs/rtems-rfs-inode.h:typedef uint32_t rtems_rfs_time;
> 
> Our first inclination was to change this to time_t but I remembered that 
> time_t
> was 64-bits and that changing this could ripple to on-media structures. 
> 
> Ignoring that there is no sub-second granularity on the utime family of
> timestamps for the RFS (and other filesystems), how can this year 2038 problem
> be addressed?
> 
> I am pretty sure a ticket is needed but I wanted to discuss this and 
> understand
> the scope.
> 
> We may also have similar issues in other file systems that we didn't spot.

Did this get resolved?

Chris
  (still under his rock)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] riscv/console: console-config.c update

[somesh deshmukh]

Hi Hesham/Sebastian,

Please find the attached device tree source file which I used for rtems
testing on PolarFire SoC ICICLE Kit.


On Wed, May 19, 2021 at 2:43 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> Hello Somesh,
>
> This patch will break other existing BSPs that don't have
> "stdout-path" (in your case serial@x) node part of "/soc" node.
> You can either 1) Modify your DTS to have /serial node outside /soc,
> or 2) Add a new config for your BSP such as
> RISCV_ENABLE_FRDME310ARTY_SUPPORT and use it instead. I am not sure if
>  DTS allows having something like /soc/serial@ in the stdout-path.
>
Thanks for the suggestion Hesham. We are discussing internally whether to
go with a variant of the existing riscv BSP or introduce a new riscv BSP
altogether.


> On Tue, 18 May 2021 at 20:43, Sebastian Huber
>  wrote:
> >
> > On 05/05/2021 19:55, Somesh Deshmukh wrote:
> > > - Parsing the sub-node should be available generic not specific to
> Freedom
> > >Arty310 board. If we remove the Freedom Arty macro now, it will lose
> > >backward compatibility.The proposed change will retain the backward
> > >compatibility and also adds the necessary fix for parsing sub-node.
> > > ---
> > >   bsps/riscv/riscv/console/console-config.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> > > index d962a5a418..797506a31b 100644
> > > --- a/bsps/riscv/riscv/console/console-config.c
> > > +++ b/bsps/riscv/riscv/console/console-config.c
> > > @@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt)
> > >   stdout_path = "";
> > > }
> > >
> > > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > > +#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) ||
> (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
> > > int root;
> > > int soc;
> > > root = fdt_path_offset(fdt, "/");
> >
> > What is the purpose of this subnode stuff here:
> >
> > static int riscv_get_console_node(const void *fdt)
> > {
> >const char *stdout_path;
> >int node;
> >
> >node = fdt_path_offset(fdt, "/chosen");
> >
> >stdout_path = fdt_getprop(fdt, node, "stdout-path", NULL);
> >if (stdout_path == NULL) {
> >  stdout_path = "";
> >}
> >
> > #if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) ||
> > (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
> >int root;
> >int soc;
> >root = fdt_path_offset(fdt, "/");
> >soc = fdt_subnode_offset(fdt, root, "soc");
> >
> >int offset=fdt_subnode_offset(fdt, soc,stdout_path);
> >
> >return offset;
> > #else
> >return fdt_path_offset(fdt, stdout_path);
> > #endif
> > }
> >
> > What is the value of stdout_path in your setup? Can you show the
> > relevant parts of the device tree sources?
> >
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>


icicle.dts
Description: audio/vnd.dts
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 6/6] spec/aarch64: Add BSPs for real ZynqMP hardware

[Sebastian Huber]

On 26/05/2021 23:01, Kinsey Moore wrote:

Add the BSPs for running on the ZU3EG Ultrascale+ Zynq MPSoC and alter
the option defaults necessary for them to run properly using the
standard BOOT.BIN configured for PetaLinux that comes in the Out-of-Box
package.


Thanks for the update, this patch looks good.

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

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

Re: Minimum.exe Text Size Outliers

[Christian MAUDERER]

Hello Joel,

Am 26.05.21 um 22:47 schrieb Joel Sherrill:

Another minimum size report. If the text size after
subtracting the FDT blob is below 64K, the BSP is not
in the report. The adjusted size is reported.

It looks like some significant percentage of those over 64k
are managing to pull in printf or something in the family. I
wonder if we should ban printf() from BSPs and drivers in favor
of printk?


I think it depends on the use case.

I'm not sure why a driver should print anything (except for errors where 
printk is most likely the better choice). But there might can be good 
reasons. And I wouldn't even guarantee that I didn't add some myself. So 
it will be a case by case decision.


Best regards

Christian



--joel

On Wed, May 26, 2021 at 1:14 PM Christian Mauderer > wrote:




On 26/05/2021 19:23, Joel Sherrill wrote:
 >
 >
 > On Wed, May 26, 2021 at 6:02 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 25/05/2021 20:33, Christian Mauderer wrote:
 >      >
 >      >>
 >      >> I thought Sebastian added a "malloc" for the BSP to use
before the
 >      >> heap was initialized. But I don't remember the name. Am I
 >     remembering
 >      >> correctly?
 >      >
 >      > I don't really know that malloc. But I doubt that it works
that
 >     early.
 >      > Again: Copying the FDT is one of the first things that
these BSPs
 >     do. If
 >      > you want to know the exact location: For ARM it's here:
 >      >
 >      >
 >
https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n325

 >   
  >

 >      >
 >      > So it's really basic setup before that. It's interrupt stack,
 >     switching
 >      > modes, setup stack pointer and then it's already copy FDT.
 >
 >     Yes, there is an early "malloc". This is _Memory_Allocate() using
 >     _Memory_Get(). However, for the device tree copy this is not
early
 >     enough. We don't know the device tree location provided by
the boot
 >     loader. It could be somewhere in the memory area used by the
 >     application. So, it is important to copy this very early into
a fixed
 >     location. Also, the device tree may be used to get the size
of the
 >     memory provided by _Memory_Get().
 >
 >
 > I assume read-only is only from the perspective of higher level
 > language code. Is it possible that being read-only it could be
 > mapped to Flash?

If the code is mapped to flash, the BSP is broken. I think there are
options for such a case so that the FDT is placed in another section.
Not sure whether any BSP is using them.

This kind of copy should be only done on BSPs that run out of RAM. Like
I said earlier: Normally that's the case for BSPs that are loaded by
U-Boot.

 >
 > For the purposes of minimum size analysis, I will subtract the
 > size of the FDT block from the minimum .text size and if it
 > is still over 64, flag it.

Sounds reasonable.

Best regards

Christian

 >
 > --joel
 >
 >
 >     --
 >     embedded brains GmbH
 >     Herr Sebastian HUBER
 >     Dornierstr. 4
 >     82178 Puchheim
 >     Germany
 >     email: sebastian.hu...@embedded-brains.de

 >     >
 >     phone: +49-89-18 94 741 - 16
 >     fax:   +49-89-18 94 741 - 08
 >
 >     Registergericht: Amtsgericht München
 >     Registernummer: HRB 157899
 >     Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,
Thomas Dörfler
 >     Unsere Datenschutzerklärung finden Sie hier:
 > https://embedded-brains.de/datenschutzerklaerung/

 >     >
 >



--

embedded brains GmbH
Herr 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

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@r

[PATCH rtems v2] cpukit: Add description of release version numbers

[Christian Mauderer]

The release version in the git sources doesn't change. Add a note why
that is the case.
---
v2: Integrate suggestions from Chris Johns.

 cpukit/include/rtems/version.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
index 87d5e1492c..cdd8905735 100644
--- a/cpukit/include/rtems/version.h
+++ b/cpukit/include/rtems/version.h
@@ -32,6 +32,27 @@ extern "C" {
  * @brief The Version API provides functions to return the version or parts of
  * the version of RTEMS you are using.
  *
+ * A branch in the version control system will always fall back to a
+ * NOT-RELEASED version number with a minor number of 0. Only the release
+ * archives have a VERSION file with a final release number. That means for
+ * example that the 5 development branch will still show a version 5.0.0 even
+ * after the 5.1 release.
+ *
+ * The reason for that are the following:
+ *
+ * 1. All pre-release tests are performed with a specific git hash. A committed
+ * VERSION file would need to be changed and committed afterwards for releasing
+ * with the required release version causing the released version to have a
+ * different git hash and the test results couldn't be linked to the released
+ * version.
+ *
+ * 2. Users deploying RTEMS would need to commit a local change to a committed
+ * VERSION file and that would clash with the project changes. Deployment can
+ * use the project repos directly.
+ *
+ * 3. The VERSION file management and generation is the responsibility of the
+ * release manager and the release process.
+ *
  * @{
  */
 
-- 
2.26.2

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