RE: [PATCH v2 0/1] testsuite: A description for each test added

[Gabriel.Moyano]

Hi everyone,

I am wondering why this patch was not accepted. Is there anything bad or 
missing? (I was following this 
https://www.mail-archive.com/devel@rtems.org/msg23478.html)

-Original Message-
From: Moyano Heredia, Victor Gabriel 
Sent: Freitag, 3. April 2020 09:35
To: devel@rtems.org
Cc: Moyano Heredia, Victor Gabriel
Subject: [PATCH v2 0/1] testsuite: A description for each test added

I've moved the description before the copyright header and added some brief 
tags where needed.

Moyano, Gabriel (1):
  testsuite: A description for each test added

 testsuite/arphole/test_main.c|  6 ++--
 testsuite/cdev01/test_main.c |  7 +
 testsuite/commands01/test_main.c |  7 +
 testsuite/condvar01/test_main.c  |  7 +
 testsuite/crypto01/test_main.c   |  6 
 testsuite/debugger01/test_main.c |  6 
 testsuite/dhcpcd01/test_main.c   |  8 +
 testsuite/dhcpcd02/test_main.c   |  6 
 testsuite/epoch01/test_main.c|  8 +
 testsuite/evdev01/init.c |  6 
 testsuite/foobarclient/test_main.c   | 10 ++
 testsuite/foobarserver/test_main.c   | 12 
 testsuite/ftpd01/test_main.c |  6 
 testsuite/ftpd02/test_main.c |  6 
 testsuite/init01/test_main.c |  4 ++-
 testsuite/ipsec01/test_main.c|  8 +
 testsuite/lagg01/test_main.c |  8 +
 testsuite/log01/test_main.c  |  6 
 testsuite/loopback01/test_main.c |  9 --
 testsuite/media01/test_main.c|  8 +
 testsuite/mutex01/test_main.c|  6 
 testsuite/netshell01/test_main.c | 11 ---
 testsuite/nfs01/test_main.c  |  6 
 testsuite/openssl01/test_main.c  |  6 
 testsuite/openssl02/test_main.c  |  7 +
 testsuite/pf01/test_main.c   |  6 
 testsuite/pf02/test_main.c   |  8 +
 testsuite/ping01/test_main.c |  6 
 testsuite/ppp01/test_main.c  | 26 
 testsuite/program01/test_main.c  |  6 
 testsuite/rcconf01/test_main.c   |  8 +
 testsuite/rcconf02/test_main.c   | 52 +---
 testsuite/rwlock01/test_main.c   |  6 
 testsuite/selectpollkqueue01/test_main.c |  6 
 testsuite/sleep01/test_main.c| 10 ++
 testsuite/smp01/test_main.c  |  8 +
 testsuite/swi01/init.c   |  8 +
 testsuite/syscalls01/test_main.c |  6 
 testsuite/telnetd01/test_main.c  |  6 
 testsuite/termios/test_main.c|  6 
 testsuite/termios01/test_main.c  |  8 +
 testsuite/termios02/test_main.c  |  9 +-
 testsuite/termios03/test_main.c  |  8 -
 testsuite/termios04/test_main.c  |  8 -
 testsuite/termios05/test_main.c  |  8 -
 testsuite/termios06/test_main.c  |  7 +
 testsuite/thread01/test_main.c   |  9 ++
 testsuite/timeout01/init.c   |  6 
 testsuite/unix01/test_main.c |  6 
 testsuite/usb01/init.c   |  8 +
 testsuite/usbkbd01/init.c|  8 +
 testsuite/usbmouse01/init.c  | 13 +---
 testsuite/usbserial01/init.c |  8 +
 testsuite/vlan01/test_main.c |  6 
 testsuite/zerocopy01/test_main.c |  8 +
 55 files changed, 413 insertions(+), 55 deletions(-)

-- 
2.12.3

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

Re: Use weak functions in the RTEMS core?

[Sebastian Huber]

On 09/04/2020 03:32, Chris Johns wrote:


On 2020-04-09 03:43, Sebastian Huber wrote:

On 08/04/2020 19:34, Jonathan Brandmeyer wrote:
Instead of treating weak references as a single level of 
indirection, I think you have to treat them as a single overridable 
interface.  In a dynamically-linked application, we might try to 
perform an override using the LD_PRELOAD feature. But in a 
statically-linked application we have to do it differently.  The 
overriding archive must be named in full, and it must be named as an 
object to be linked instead of a library to be searched.  
Furthermore, an interface can have only one override that ends up in 
the linked application.
Yes, you can only have one strong implementation, otherwise you get 
multiple definition errors.


I have only ever considered weak references as an overridable 
interface within a user's application and not layered within RTEMS 
itself. I am not sure about automatic indirection within an archive.
Yes, this is one use case. You could use also a normal function in a 
separate file to get something similar.


In the case of different heap allocators why not have confdefs.h 
select the one we want and manage the indirection with a const table 
of pointers?


Yes it can be done with new configuration options, however, this would 
be my least favorite choice. I created an example how I would like to 
use weak functions:


https://lists.rtems.org/pipermail/devel/2020-April/059196.html

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

[PATCH 2/2] malloc: Make deferred free support optional

[Sebastian Huber]

Only include the deferred free support if free() is actually used by the
application.
---
 cpukit/libcsupport/src/free.c| 43 
 cpukit/libcsupport/src/malloc_deferred.c | 40 +++--
 cpukit/libcsupport/src/malloc_p.h|  2 --
 cpukit/libcsupport/src/realloc.c |  8 ++
 4 files changed, 54 insertions(+), 39 deletions(-)

diff --git a/cpukit/libcsupport/src/free.c b/cpukit/libcsupport/src/free.c
index d8dd2bdb0e..b5e4214449 100644
--- a/cpukit/libcsupport/src/free.c
+++ b/cpukit/libcsupport/src/free.c
@@ -22,6 +22,49 @@
 #include "malloc_p.h"
 #include 
 
+#include 
+
+static RTEMS_CHAIN_DEFINE_EMPTY( _Malloc_GC_list );
+
+RTEMS_INTERRUPT_LOCK_DEFINE( static, _Malloc_GC_lock, "Malloc GC" )
+
+static void *_Malloc_Get_deferred_free( void )
+{
+  rtems_interrupt_lock_context lock_context;
+  void *p;
+
+  rtems_interrupt_lock_acquire( &_Malloc_GC_lock, _context );
+  p = rtems_chain_get_unprotected( &_Malloc_GC_list );
+  rtems_interrupt_lock_release( &_Malloc_GC_lock, _context );
+
+  return p;
+}
+
+void _Malloc_Process_deferred_frees( void )
+{
+  rtems_chain_node *to_be_freed;
+
+  /*
+   *  If some free's have been deferred, then do them now.
+   */
+  while ( ( to_be_freed = _Malloc_Get_deferred_free() ) != NULL ) {
+free( to_be_freed );
+  }
+}
+
+static void _Malloc_Deferred_free( void *p )
+{
+  rtems_interrupt_lock_context lock_context;
+  rtems_chain_node *node;
+
+  node = (rtems_chain_node *) p;
+
+  rtems_interrupt_lock_acquire( &_Malloc_GC_lock, _context );
+  rtems_chain_initialize_node( node );
+  rtems_chain_append_unprotected( &_Malloc_GC_list, node );
+  rtems_interrupt_lock_release( &_Malloc_GC_lock, _context );
+}
+
 void free(
   void *ptr
 )
diff --git a/cpukit/libcsupport/src/malloc_deferred.c 
b/cpukit/libcsupport/src/malloc_deferred.c
index ccb8dc3b8b..13b3266062 100644
--- a/cpukit/libcsupport/src/malloc_deferred.c
+++ b/cpukit/libcsupport/src/malloc_deferred.c
@@ -27,14 +27,9 @@
 
 #include "malloc_p.h"
 
-#include 
 #include 
 #include 
 
-static RTEMS_CHAIN_DEFINE_EMPTY( _Malloc_GC_list );
-
-RTEMS_INTERRUPT_LOCK_DEFINE( static, _Malloc_GC_lock, "Malloc GC" )
-
 Malloc_System_state _Malloc_System_state( void )
 {
   System_state_Codes state = _System_state_Get();
@@ -52,28 +47,12 @@ Malloc_System_state _Malloc_System_state( void )
   }
 }
 
-static void *_Malloc_Get_deferred_free( void )
-{
-  rtems_interrupt_lock_context lock_context;
-  void *p;
-
-  rtems_interrupt_lock_acquire( &_Malloc_GC_lock, _context );
-  p = rtems_chain_get_unprotected( &_Malloc_GC_list );
-  rtems_interrupt_lock_release( &_Malloc_GC_lock, _context );
-
-  return p;
-}
-
-void _Malloc_Process_deferred_frees( void )
+RTEMS_WEAK void _Malloc_Process_deferred_frees( void )
 {
-  rtems_chain_node *to_be_freed;
-
   /*
-   *  If some free's have been deferred, then do them now.
+   * Do nothing by default.  If free() is used by the application, then a
+   * strong implementation of this function will be provided.
*/
-  while ( ( to_be_freed = _Malloc_Get_deferred_free() ) != NULL ) {
-free( to_be_freed );
-  }
 }
 
 void *rtems_heap_allocate_aligned_with_boundary(
@@ -125,19 +104,6 @@ void *rtems_heap_allocate_aligned_with_boundary(
   return p;
 }
 
-void _Malloc_Deferred_free( void *p )
-{
-  rtems_interrupt_lock_context lock_context;
-  rtems_chain_node *node;
-
-  node = (rtems_chain_node *) p;
-
-  rtems_interrupt_lock_acquire( &_Malloc_GC_lock, _context );
-  rtems_chain_initialize_node( node );
-  rtems_chain_append_unprotected( &_Malloc_GC_list, node );
-  rtems_interrupt_lock_release( &_Malloc_GC_lock, _context );
-}
-
 void *rtems_malloc( size_t size )
 {
   if ( size == 0 ) {
diff --git a/cpukit/libcsupport/src/malloc_p.h 
b/cpukit/libcsupport/src/malloc_p.h
index f3715a9966..cb26050ff1 100644
--- a/cpukit/libcsupport/src/malloc_p.h
+++ b/cpukit/libcsupport/src/malloc_p.h
@@ -25,8 +25,6 @@ typedef enum {
 
 Malloc_System_state _Malloc_System_state( void );
 
-void _Malloc_Deferred_free( void * );
-
 void _Malloc_Process_deferred_frees( void );
 
 #ifdef __cplusplus
diff --git a/cpukit/libcsupport/src/realloc.c b/cpukit/libcsupport/src/realloc.c
index 7912780c09..9927b3b903 100644
--- a/cpukit/libcsupport/src/realloc.c
+++ b/cpukit/libcsupport/src/realloc.c
@@ -25,6 +25,14 @@
 
 #include "malloc_p.h"
 
+RTEMS_WEAK void _Malloc_Process_deferred_frees( void )
+{
+  /*
+   * Do nothing by default.  If free() is used by the application, then a
+   * strong implementation of this function will be provided.
+   */
+}
+
 static void *new_alloc( void *old_ptr, size_t new_size, size_t old_size )
 {
   void *new_ptr;
-- 
2.16.4

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

[PATCH 0/2] Example use case for a weak function in RTEMS

[Sebastian Huber]

This patch set is not intended for RTEMS 5. I just gives an example how
weak functions can be used in RTMES to reduce the code size for some
applications automatically (through work done by the linker).

Sebastian Huber (2):
  score: Add RTEMS_WEAK
  malloc: Make deferred free support optional

 cpukit/include/rtems/score/basedefs.h| 12 
 cpukit/libcsupport/src/free.c| 43 +++
 cpukit/libcsupport/src/malloc_deferred.c | 40 ++---
 cpukit/libcsupport/src/malloc_p.h|  2 --
 cpukit/libcsupport/src/realloc.c |  8 +
 testsuites/sptests/Makefile.am   |  2 +-
 testsuites/sptests/spmisc01/init.c   |  9 ++
 testsuites/sptests/spmisc01/spmisc01.h   | 51 
 testsuites/sptests/spmisc01/strong.c | 42 ++
 9 files changed, 169 insertions(+), 40 deletions(-)
 create mode 100644 testsuites/sptests/spmisc01/spmisc01.h
 create mode 100644 testsuites/sptests/spmisc01/strong.c

-- 
2.16.4

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

[PATCH 1/2] score: Add RTEMS_WEAK

[Sebastian Huber]

---
 cpukit/include/rtems/score/basedefs.h  | 12 
 testsuites/sptests/Makefile.am |  2 +-
 testsuites/sptests/spmisc01/init.c |  9 ++
 testsuites/sptests/spmisc01/spmisc01.h | 51 ++
 testsuites/sptests/spmisc01/strong.c   | 42 
 5 files changed, 115 insertions(+), 1 deletion(-)
 create mode 100644 testsuites/sptests/spmisc01/spmisc01.h
 create mode 100644 testsuites/sptests/spmisc01/strong.c

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 4589bea4aa..87f980ccda 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -197,6 +197,18 @@
   #define RTEMS_ALIAS( _target )
 #endif
 
+/**
+ * @brief Instructs the compiler to define a weak function.
+ *
+ * Use this attribute for function definitions.  Do not use it for function
+ * declarations.
+ */
+#if defined(__GNUC__)
+  #define RTEMS_WEAK __attribute__((__weak__))
+#else
+  #define RTEMS_WEAK
+#endif
+
 /**
  * @brief Instructs the compiler to generate a weak alias to the specified
  * target function.
diff --git a/testsuites/sptests/Makefile.am b/testsuites/sptests/Makefile.am
index 62bb1aa685..a8b9ac482a 100644
--- a/testsuites/sptests/Makefile.am
+++ b/testsuites/sptests/Makefile.am
@@ -1464,7 +1464,7 @@ if TEST_spmisc01
 sp_tests += spmisc01
 sp_screens += spmisc01/spmisc01.scn
 sp_docs += spmisc01/spmisc01.doc
-spmisc01_SOURCES = spmisc01/init.c
+spmisc01_SOURCES = spmisc01/init.c spmisc01/strong.c
 spmisc01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_spmisc01) \
$(support_includes)
 endif
diff --git a/testsuites/sptests/spmisc01/init.c 
b/testsuites/sptests/spmisc01/init.c
index 8d713c4219..d18402a13c 100644
--- a/testsuites/sptests/spmisc01/init.c
+++ b/testsuites/sptests/spmisc01/init.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#include "spmisc01.h"
+
 const char rtems_test_name[] = "SPMISC 1";
 
 RTEMS_INLINE_ROUTINE int inline_func(void)
@@ -70,6 +72,11 @@ static int alias_func(void) RTEMS_ALIAS(noinline_func);
 
 int weak_alias_func(void) RTEMS_WEAK_ALIAS(noinline_func);
 
+RTEMS_WEAK int weak_or_strong(void)
+{
+  return 99;
+}
+
 static char aligned_variable RTEMS_ALIGNED(64);
 
 typedef struct {
@@ -209,6 +216,8 @@ static void Init(rtems_task_argument arg)
   rtems_test_assert(sizeof(packed_struct) == 5);
   rtems_test_assert(alias_func() == 14);
   rtems_test_assert(weak_alias_func() == 14);
+  pull_in_strong();
+  rtems_test_assert(weak_or_strong() == 77);
   rtems_test_assert(((uintptr_t) _variable) % 64 == 0);
   rtems_test_assert(offsetof(aligned_member_struct, aligned_member) % 64 == 0);
   unreachable();
diff --git a/testsuites/sptests/spmisc01/spmisc01.h 
b/testsuites/sptests/spmisc01/spmisc01.h
new file mode 100644
index 00..0bd0fbbfca
--- /dev/null
+++ b/testsuites/sptests/spmisc01/spmisc01.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup %
+ *
+ * @brief %
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _SPMISC01_H
+#define _SPMISC01_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+int weak_or_strong(void);
+
+void pull_in_strong(void);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _SPMISC01_H */
diff --git a/testsuites/sptests/spmisc01/strong.c 
b/testsuites/sptests/spmisc01/strong.c
new file mode 100644
index 00..4a2d3b6f11
--- /dev/null
+++ b/testsuites/sptests/spmisc01/strong.c
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution 

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

[Chris Johns]

On 2020-04-09 01:48, Alan Cudmore wrote:

I definitely plan on creating a readme for the repository to help
anyone that is interested.


Thanks.


Regarding the LEON3: I am noticing something with the release that I
don't understand yet.

I am able to build and run a number of ARM BSPs including raspberrypi,
raspberrypi2, beagleboneblack, and xlinx_zynq_a9_qemu
When I build my application for the leon3, most of it appears to work,
but I have a task demo that crashes when I try to print a variable
that is on the task stack. ( task ID, similar to what ticker does )
I went back and ran a number of the testsuite programs on both my
patched QEMU and sparc-rtems5-sis with no problems.
I then cloned the latest rtems-examples git repository and built the
ticker examples using the (obsolete) Makefile. When built this way,
the ticker program crashes as well on both QEMU and SIS.


Can you see a faulting address? Can you attach a debugger to see what 
happens? QEMU and SIS can attach gdb. With the SIS use the `target 
remote :` command where `` is the port the SIS is listening 
on. Then `load` and `run` should work.



I'm trying to narrow down the differences by comparing the flags used
to build the testsuite in the build tree vs. my applications and the
rtems-examples repository.

Should I try building the examples with waf?


Sure, but I am not a LEON or SPARC user so I am not sure what is 
happening here.


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

Re: Use weak functions in the RTEMS core?

[Chris Johns]

On 2020-04-09 03:43, Sebastian Huber wrote:

On 08/04/2020 19:34, Jonathan Brandmeyer wrote:
Instead of treating weak references as a single level of indirection, 
I think you have to treat them as a single overridable interface.  In 
a dynamically-linked application, we might try to perform an override 
using the LD_PRELOAD feature. But in a statically-linked application 
we have to do it differently.  The overriding archive must be named in 
full, and it must be named as an object to be linked instead of a 
library to be searched.  Furthermore, an interface can have only one 
override that ends up in the linked application.
Yes, you can only have one strong implementation, otherwise you get 
multiple definition errors.


I have only ever considered weak references as an overridable interface 
within a user's application and not layered within RTEMS itself. I am 
not sure about automatic indirection within an archive.


In the case of different heap allocators why not have confdefs.h select 
the one we want and manage the indirection with a const table of pointers?


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

Re: AW: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

[Gedare Bloom]

On Wed, Apr 8, 2020 at 4:42 PM Chris Johns  wrote:
>
> On 2020-04-09 05:35, jan.som...@dlr.de wrote:
> > Could you give me some direction where we would add the documentation
> > and what is missing?
> >
> > The pc-run.ini is basically a copy of the xilinx_zynq_zedboard.ini with
> > just a different tester.
>
> What you have done is create a new form of running a test on target
> hardware and this is really neat. The zedboard uses TFTP just like the
> pc.ini config.
>
> > Or do you mean the change in the run.cfg?
>
> The run.cfg was a general means to execute a command and the intention
> was simulation, i.e. qemu etc, so it would be great to document how you
> have used the various commands to glue the tester to your set up.
>
> Should a new section below Simulation called Execution be added or
> should Simulation be changed to Execution and Simulation is placed under
> Execution?
>
the latter. Execution is the general form, Simulation is an instantiation

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

Re: AW: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

[Chris Johns]

On 2020-04-09 05:35, jan.som...@dlr.de wrote:
Could you give me some direction where we would add the documentation 
and what is missing?


The pc-run.ini is basically a copy of the xilinx_zynq_zedboard.ini with 
just a different tester.


What you have done is create a new form of running a test on target 
hardware and this is really neat. The zedboard uses TFTP just like the 
pc.ini config.



Or do you mean the change in the run.cfg?


The run.cfg was a general means to execute a command and the intention 
was simulation, i.e. qemu etc, so it would be great to document how you 
have used the various commands to glue the tester to your set up.


Should a new section below Simulation called Execution be added or 
should Simulation be changed to Execution and Simulation is placed under 
Execution?


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

Re: [PATCH 2/2] tester: Add configuration pc-run.ini

[Gedare Bloom]

This looks fine also.

On Wed, Apr 8, 2020 at 9:23 AM Jan Sommer  wrote:
>
> ---
>  tester/rtems/testing/bsps/pc-run.ini | 41 
> 
>  1 file changed, 41 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/pc-run.ini
>
> diff --git a/tester/rtems/testing/bsps/pc-run.ini 
> b/tester/rtems/testing/bsps/pc-run.ini
> new file mode 100644
> index 000..34ec2a4
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/pc-run.ini
> @@ -0,0 +1,41 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2010-2017 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 pc686 hardware is started via a custom command. The console
> +# is connected to a telnet tty device.
> +#
> +[pc-run]
> +bsp= pc686
> +arch   = i386
> +tester = %{_rtscripts}/run.cfg
> +jobs   = 1
> +test_restarts  = 3
> +requires   = target_on_command, target_off_command, 
> target_reset_command, bsp_tty_dev, bsp_run_cmd
> --
> 2.12.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

[Gedare Bloom]

On Wed, Apr 8, 2020 at 1:35 PM  wrote:
>
> Could you give me some direction where we would add the documentation and 
> what is missing?
>
> The pc-run.ini is basically a copy of the xilinx_zynq_zedboard.ini with just 
> a different tester.
>
> Or do you mean the change in the run.cfg?
>
Sorry this inquiry more relates to your other thread that led you to
find this solution. You mentioned that you did not find the solution
easily in the docs, so figuring out how to make it easier to
understand how to do this would be great. Not needed to apply your
patch though.

>
>
> Von: Gedare Bloom [mailto:ged...@rtems.org]
> Gesendet: Mittwoch, 8. April 2020 19:07
> An: Sommer, Jan
> Cc: devel@rtems.org
> Betreff: Re: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg
>
>
>
> These look alright to me, although I wonder if we need some bsp doc for this 
> setup?
>
>
>
> On Wed, Apr 8, 2020, 9:23 AM Jan Sommer  wrote:
>
> Here are the changes I did for our local setup.
> The first patch enableds telnet tty devices for run.cfg setups
> The second add a run configuration for the pc BSP
>
> Jan Sommer (2):
>   tester: Allow telnet tty devices for run.cfg
>   tester: Add configuration pc-run.ini
>
>  tester/rtems/testing/bsps/pc-run.ini | 41 
> 
>  tester/rtems/testing/run.cfg |  4 +++-
>  2 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 tester/rtems/testing/bsps/pc-run.ini
>
> --
> 2.12.3
>
> _
> 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

AW: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

[Jan.Sommer]

Could you give me some direction where we would add the documentation and what 
is missing?
The pc-run.ini is basically a copy of the xilinx_zynq_zedboard.ini with just a 
different tester.
Or do you mean the change in the run.cfg?

Von: Gedare Bloom [mailto:ged...@rtems.org]
Gesendet: Mittwoch, 8. April 2020 19:07
An: Sommer, Jan
Cc: devel@rtems.org
Betreff: Re: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

These look alright to me, although I wonder if we need some bsp doc for this 
setup?

On Wed, Apr 8, 2020, 9:23 AM Jan Sommer 
mailto:jan.som...@dlr.de>> wrote:
Here are the changes I did for our local setup.
The first patch enableds telnet tty devices for run.cfg setups
The second add a run configuration for the pc BSP

Jan Sommer (2):
  tester: Allow telnet tty devices for run.cfg
  tester: Add configuration pc-run.ini

 tester/rtems/testing/bsps/pc-run.ini | 41 
 tester/rtems/testing/run.cfg |  4 +++-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 tester/rtems/testing/bsps/pc-run.ini

--
2.12.3

_
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: How to test smp on leon3 build?

[Richi Dubey]

Dear Sebastian Sir,

This works. Thanks for the help.

On Wed, Apr 8, 2020 at 11:34 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/04/2020 20:02, Richi Dubey wrote:
>
> >
> > I have uploaded the screenshot of executing smpschededf.exe on sis
> > with -m 2 option(To run the exe with 2 cores) and -leon3 option. Now
> > how do I verify it was actually run on 2 cores?
> >
> > Also, on checking init.c for smpschededf01, line 134 says:
> >
> > #define CONFIGURE_MAXIMUM_PROCESSORS 1
> >
> > Does it mean core or processor? Do I need to change this value to 2 too?
> I would search for a test with CONFIGURE_MAXIMUM_PROCESSORS > 1 for
> example smpatomic01.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How to test smp on leon3 build?

[Sebastian Huber]

On 08/04/2020 20:02, Richi Dubey wrote:



I have uploaded the screenshot of executing smpschededf.exe on sis 
with -m 2 option(To run the exe with 2 cores) and -leon3 option. Now 
how do I verify it was actually run on 2 cores?


Also, on checking init.c for smpschededf01, line 134 says:

#define CONFIGURE_MAXIMUM_PROCESSORS 1

Does it mean core or processor? Do I need to change this value to 2 too?
I would search for a test with CONFIGURE_MAXIMUM_PROCESSORS > 1 for 
example smpatomic01.

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

Re: [PATCH] rtems-tester: Add rv64imafdc_medany for QEMU

[Hesham Almatary]

Hello Gedare,

I copied that file from rv64imafd which has that copyright header

On Wed, 8 Apr 2020 at 18:04, Gedare Bloom  wrote:
>
> This looks alright. I doubt EB has a copyright in this, though.
>
> On Wed, Apr 8, 2020, 4:04 AM Hesham Almatary  
> wrote:
>>
>> ---
>>  .../rtems/testing/bsps/rv64imafdc_medany.ini  | 36 +++
>>  1 file changed, 36 insertions(+)
>>  create mode 100644 tester/rtems/testing/bsps/rv64imafdc_medany.ini
>>
>> diff --git a/tester/rtems/testing/bsps/rv64imafdc_medany.ini 
>> b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
>> new file mode 100644
>> index 000..30abd50
>> --- /dev/null
>> +++ b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
>> @@ -0,0 +1,36 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2020 Hesham Almatary
>> +# Copyright 2018 embedded brains GmbH
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# 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.
>> +#
>> +
>> +[rv64imafdc_medany]
>> +bsp   = rv64imafdc_medany
>> +arch  = riscv64
>> +tester= %{_rtscripts}/qemu.cfg
>> +bsp_qemu_opts = -no-reboot -nographic %{qemu_opts_no_net} -machine virt -m 
>> 64M
>> --
>> 2.17.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: [PATCH 0/3] GCC 10 fixes for powerpc

[Gedare Bloom]

Thanks they should be ok after the release. Hard to tell what might break
in subtle ways from asm changes

On Wed, Apr 8, 2020, 11:35 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The following patch set fixes some compile time problems with GCC 10 on
> powerpc.
> I am not sure if every change is correct, especially I am not sure about
> the
> tlbie change since I had problems to figure out what is going on.  This is
> probably something for RTEMS 6.
>
> Sebastian Huber (3):
>   bsp/qoriq: Fix tlbwe sequence
>   bsps/powerpc: Fix inline assembly
>   bsps/powerpc: Fix tlbie instruction usage
>
>  bsps/powerpc/gen5200/start/start.S |  2 +-
>  bsps/powerpc/gen83xx/start/cpuinit.c   |  2 +-
>  bsps/powerpc/include/libcpu/mmu.h  |  2 +-
>  bsps/powerpc/include/libcpu/powerpc-utility.h  | 73
> ++
>  bsps/powerpc/motorola_powerpc/bootloader/head.S|  2 +-
>  bsps/powerpc/motorola_powerpc/bootloader/mm.c  |  4 +-
>  bsps/powerpc/mvme5500/start/start.S|  2 +-
>  bsps/powerpc/qoriq/start/bspstart.c|  5 +-
>  bsps/powerpc/qoriq/start/mmu.c |  7 ++-
>  .../powerpc/shared/exceptions/ppc_exc_initialize.c | 45 +++--
>  bsps/powerpc/shared/mmu/e500-mmu.c | 31 +
>  bsps/powerpc/shared/mmu/pte121.c   | 11 ++--
>  bsps/powerpc/shared/start/start.S  |  2 +-
>  13 files changed, 128 insertions(+), 60 deletions(-)
>
> --
> 2.16.4
>
> ___
> 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: Adding test for clock_getcpuclockid()

[Eshan Dhawan]

On Wed, Apr 8, 2020 at 11:17 PM Gedare Bloom  wrote:

> You should write the test according to the API specification. The test is
> expected to fail until the function is implemented (correctly).
>
Ok

>
> On Wed, Apr 8, 2020, 11:22 AM Eshan Dhawan 
> wrote:
>
>> hello,
>> how do I add a test for a function that returns -1(ENOSYS), Since isn't
>> implemented yet?
>> Though of adding test for clock_getcpuclockid in the same file of
>> psxgetcpuclockid01.
>> I wrote the test but it will always return -1.
>> should I change the rtems_test_asset( r==0 ) to r==-1 and add a print
>> statement to tell it will be returning -1 ?
>> Or there are other ways?
>>
>> thanks
>> -Eshan
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Adding test for clock_getcpuclockid()

[Gedare Bloom]

You should write the test according to the API specification. The test is
expected to fail until the function is implemented (correctly).

On Wed, Apr 8, 2020, 11:22 AM Eshan Dhawan  wrote:

> hello,
> how do I add a test for a function that returns -1(ENOSYS), Since isn't
> implemented yet?
> Though of adding test for clock_getcpuclockid in the same file of
> psxgetcpuclockid01.
> I wrote the test but it will always return -1.
> should I change the rtems_test_asset( r==0 ) to r==-1 and add a print
> statement to tell it will be returning -1 ?
> Or there are other ways?
>
> thanks
> -Eshan
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GCC 10 build status

[Sebastian Huber]

Hello,

in order to test a patch for the removal of the bsp_specs I built all 
BSPs (POSIX and tests enabled) with GCC 10 using the new build system.


http://devel.rtems.org/ticket/3937

The situation with epiphany turned out to be quite bad:

http://devel.rtems.org/ticket/3941

There is an issue on i386:

http://devel.rtems.org/ticket/3943

There are some problems on powerpc:

https://lists.rtems.org/pipermail/devel/2020-April/059176.html

Otherwise it looks good. I was able to build with bsp_specs removed from 
the sources.



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

Re: Need help to run a smp testsuite on erc32 with multi core

[Gedare Bloom]

On Wed, Apr 8, 2020, 11:17 AM Richi Dubey  wrote:

> Dear Dr. Bloom,
>
> I understand. I would be more specific from next time.
>
> When I ran sis with no multi-core option, the result came out same as when
> I ran it with -m 2 option, (To simulate the executable with 2 cores). And
> on reading sis manual, I understood it didn't support erc32
> multiprocessing, now I know the reason was because erc32 is a single core
> processor.
>
> I built erc32 on SPARC - RTEMS with --enable-smp option enabled.
>
> On trying to run the debugger, sparc-rtems5-gdb [file], It doesnt not
> support the command " tar sim -erc32" anymore(from
> https://devel.rtems.org/wiki/Debugging/sis) and I didn't know how to set
> a simulator as a target.
>
This page is outdated. It needs to be reviewed, relevant info moved to
docs, and page content replaced by a pointer to the docs.

This should be added as a SmallTask ticket.


> Thank you.
>
> On Wed, Apr 8, 2020 at 1:03 AM Gedare Bloom  wrote:
>
>> On Tue, Apr 7, 2020 at 1:30 PM Richi Dubey  wrote:
>> >
>> > Hey everyone,
>> >
>> > Can someone please help me out with running a smp testsuite on
>> erc32(which uses SPARC instruction set). I tried using sis, but the -m
>> option for multi core doesnt seem to work, as the sis readme says: "-m
>> cores : Enable the number of cores (2 - 4) in a leon3 or RISC-V
>> multi-processor system." and that sis supports:
>> >
>> What do you mean it doesn't seem to work? What was broken/how do you
>> know it was broken?
>>
>> How did you configure/build rtems?
>>
>> How did you invoke sis?
>>
>> What is the output of running sis?
>>
>> >  " sis is capable of emulating four different processor systems:
>> >  ERC32 ERC32 SPARC V7 processor
>> > LEON2 LEON2 SPARC V8 processor
>> > LEON3 LEON3 SPARC V8 processor
>> >  RISC-V RISC-V (RV32IMACFD) processor "
>> >
>> > So if sis does not support multi-core for erc32 systems, what should I
>> use to run a smp program on erc32?
>> >
>> >
>> > ___
>> > 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: Use weak functions in the RTEMS core?

[Sebastian Huber]

On 08/04/2020 19:34, Jonathan Brandmeyer wrote:


If you encounter problems like this, then
weak functions are used for the wrong thing.


Exhibit A: zynq_setup_mmu_and_cache.  It is referred to only by the 
BSP's startup sequence.  So it is a reference from librtemsbsp to 
librtemsbsp by default.  I don't think it's being used for the wrong 
thing.
You could move zynq_setup_mmu_and_cache() to a separate file and remove 
the weak. The weak function here just avoids an extra file.



I would like to use weak functions with one level of indirection. For
example an application can use two features A and B. Both use an
interface C. If only A is used, then C can be implemented via D or
E. If
B is used, then C must be implemented via E. For this you can use
a weak
implementation D of interface C in module of A and a strong
implementation E in module of B.


In the proposed case of using weak references for the heap, which 
implementation gets pulled in depends on whether or not the object 
files listed on the command line reference the heap or not.  If the 
only references are within static archives, then the application will 
have difficulty choosing exactly which implementation of the heap gets 
pulled in.  librtemsbsp both depends-on and provides implementations 
of malloc and free.


It's pretty easy to provide a definition of Init() or POSIX_Init() 
that doesn't directly call malloc or free, for example.


In my proposed use case:

We could use something like this in heapallocate.c:

RTEMS_WEAK void *_Heap_Allocate_impl(size) { /* Very simple */ }

void *_Heap_Allocate(size)

{

  return _Heap_Allocate_impl(size)

}

In heapfree.c:

void *_Heap_Allocate_impl(size) { /* Complex */ }

The application doesn't reference _Heap_Allocate_impl(). It references 
_Heap_Allocate() or _Heap_Free() or both or none.




Instead of treating weak references as a single level of indirection, 
I think you have to treat them as a single overridable interface.  In 
a dynamically-linked application, we might try to perform an override 
using the LD_PRELOAD feature. But in a statically-linked application 
we have to do it differently.  The overriding archive must be named in 
full, and it must be named as an object to be linked instead of a 
library to be searched.  Furthermore, an interface can have only one 
override that ends up in the linked application.
Yes, you can only have one strong implementation, otherwise you get 
multiple definition errors.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/3] bsp/qoriq: Fix tlbwe sequence

[Sebastian Huber]

---
 bsps/powerpc/qoriq/start/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/powerpc/qoriq/start/mmu.c b/bsps/powerpc/qoriq/start/mmu.c
index 87ffc11cc2..b912613cc4 100644
--- a/bsps/powerpc/qoriq/start/mmu.c
+++ b/bsps/powerpc/qoriq/start/mmu.c
@@ -361,7 +361,7 @@ void qoriq_mmu_change_perm(uint32_t test, uint32_t set, 
uint32_t clear)
mas3 &= ~(clear & mask);
mas3 |= set & mask;
PPC_SET_SPECIAL_PURPOSE_REGISTER(FSL_EIS_MAS3, 
mas3);
-   asm volatile ("isync; msync; tlbwe; isync" : : 
: "memory");
+   asm volatile ("msync; isync; tlbwe; isync" : : 
: "memory");
}
}
}
-- 
2.16.4

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

[PATCH 2/3] bsps/powerpc: Fix inline assembly

[Sebastian Huber]

GCC 10 no longer passes -many to the assembler.  This enables more
checks in the assembler.
---
 bsps/powerpc/include/libcpu/powerpc-utility.h  | 73 ++
 bsps/powerpc/qoriq/start/bspstart.c|  5 +-
 bsps/powerpc/qoriq/start/mmu.c |  7 ++-
 .../powerpc/shared/exceptions/ppc_exc_initialize.c | 45 +++--
 bsps/powerpc/shared/mmu/e500-mmu.c | 31 +
 5 files changed, 114 insertions(+), 47 deletions(-)

diff --git a/bsps/powerpc/include/libcpu/powerpc-utility.h 
b/bsps/powerpc/include/libcpu/powerpc-utility.h
index 60cfe85f60..2827430e13 100644
--- a/bsps/powerpc/include/libcpu/powerpc-utility.h
+++ b/bsps/powerpc/include/libcpu/powerpc-utility.h
@@ -860,6 +860,79 @@ static inline uint32_t 
ppc_fsl_system_version_mnrev(uint32_t svr)
   return (svr >> 0) & 0xf;
 }
 
+static inline void ppc_msync(void)
+{
+  __asm__ volatile (
+".machine push\n"
+".machine e500\n"
+"msync\n"
+".machine pop"
+:
+:
+: "memory"
+  );
+}
+
+static inline void ppc_tlbre(void)
+{
+  __asm__ volatile (
+".machine push\n"
+".machine e500\n"
+"tlbre\n"
+".machine pop"
+:
+:
+: "memory"
+  );
+}
+
+static inline void ppc_tlbwe(void)
+{
+  __asm__ volatile (
+".machine push\n"
+".machine e500\n"
+"tlbwe\n"
+".machine pop"
+:
+:
+: "memory"
+  );
+}
+
+static inline void ppc_tlbsx(void *addr)
+{
+  __asm__ volatile (
+".machine push\n"
+".machine e500\n"
+"tlbsx 0, %0\n"
+".machine pop"
+:
+: "r" (addr)
+: "memory"
+  );
+}
+
+static inline void ppc_mtivpr(void *prefix)
+{
+  __asm__ volatile (
+".machine push\n"
+".machine e500\n"
+"mtivpr %0\n"
+".machine pop"
+:
+: "r" (prefix)
+  );
+}
+
+#define ppc_mtivor(x, vec) __asm__ volatile ( \
+".machine push\n" \
+".machine e500\n" \
+"mtivor" RTEMS_XSTRING(x) " %0\n" \
+".machine pop" \
+: \
+: "r" (vec) \
+  )
+
 void ppc_code_copy(void *dest, const void *src, size_t n);
 
 /* FIXME: Do not use this function */
diff --git a/bsps/powerpc/qoriq/start/bspstart.c 
b/bsps/powerpc/qoriq/start/bspstart.c
index 3c75ecf020..5abd651a27 100644
--- a/bsps/powerpc/qoriq/start/bspstart.c
+++ b/bsps/powerpc/qoriq/start/bspstart.c
@@ -93,9 +93,6 @@ static void initialize_frequency_parameters(void)
   #endif
 }
 
-#define MTIVPR(base) \
-  __asm__ volatile ("mtivpr %0" : : "r" (base))
-
 #ifdef __powerpc64__
 #define VECTOR_TABLE_ENTRY_SIZE 32
 #else
@@ -117,7 +114,7 @@ void qoriq_initialize_exceptions(void 
*interrupt_stack_begin)
   );
 
   addr = (uintptr_t) bsp_exc_vector_base;
-  MTIVPR(addr);
+  ppc_mtivpr((void *) addr);
   MTIVOR(BOOKE_IVOR0,  addr);
   MTIVOR(BOOKE_IVOR1,  addr);
   MTIVOR(BOOKE_IVOR2,  addr);
diff --git a/bsps/powerpc/qoriq/start/mmu.c b/bsps/powerpc/qoriq/start/mmu.c
index b912613cc4..558c49618a 100644
--- a/bsps/powerpc/qoriq/start/mmu.c
+++ b/bsps/powerpc/qoriq/start/mmu.c
@@ -350,7 +350,7 @@ void qoriq_mmu_change_perm(uint32_t test, uint32_t set, 
uint32_t clear)
uint32_t mas1 = 0;
 
PPC_SET_SPECIAL_PURPOSE_REGISTER(FSL_EIS_MAS0, mas0);
-   asm volatile ("tlbre");
+   ppc_tlbre();
 
mas1 = PPC_SPECIAL_PURPOSE_REGISTER(FSL_EIS_MAS1);
if ((mas1 & FSL_EIS_MAS1_V) != 0) {
@@ -361,7 +361,10 @@ void qoriq_mmu_change_perm(uint32_t test, uint32_t set, 
uint32_t clear)
mas3 &= ~(clear & mask);
mas3 |= set & mask;
PPC_SET_SPECIAL_PURPOSE_REGISTER(FSL_EIS_MAS3, 
mas3);
-   asm volatile ("msync; isync; tlbwe; isync" : : 
: "memory");
+   ppc_msync();
+   ppc_synchronize_instructions();
+   ppc_tlbwe();
+   ppc_synchronize_instructions();
}
}
}
diff --git a/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c 
b/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c
index 215918ac44..46b72524ea 100644
--- a/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c
+++ b/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c
@@ -29,13 +29,10 @@
 
 uint32_t ppc_exc_cache_wb_check = 1;
 
-#define MTIVPR(prefix) __asm__ volatile ("mtivpr %0" : : "r" (prefix))
-#define MTIVOR(x, vec) __asm__ volatile ("mtivor"#x" %0" : : "r" (vec))
-
 static void ppc_exc_initialize_booke(void *vector_base)
 {
   /* Interrupt vector prefix register */
-  MTIVPR((uintptr_t) vector_base);
+  ppc_mtivpr(vector_base);
 
   if (
 ppc_cpu_is_specific_e200(PPC_e200z0)
@@ -49,29 +46,29 @@ static void ppc_exc_initialize_booke(void *vector_base)
   }
 
   /* Interupt vector offset registers */
-  MTIVOR(0,  ppc_exc_vector_address(ASM_BOOKE_CRIT_VECTOR, vector_base));
-  MTIVOR(1,  ppc_exc_vector_address(ASM_MACH_VECTOR, 

[PATCH 3/3] bsps/powerpc: Fix tlbie instruction usage

[Sebastian Huber]

GCC 10 no longer passes -many to the assembler.  This enables more
checks in the assembler.

The 0 in the tlbie instruction is the L operand which selects a 4KiB
page size.
---
 bsps/powerpc/gen5200/start/start.S  |  2 +-
 bsps/powerpc/gen83xx/start/cpuinit.c|  2 +-
 bsps/powerpc/include/libcpu/mmu.h   |  2 +-
 bsps/powerpc/motorola_powerpc/bootloader/head.S |  2 +-
 bsps/powerpc/motorola_powerpc/bootloader/mm.c   |  4 ++--
 bsps/powerpc/mvme5500/start/start.S |  2 +-
 bsps/powerpc/shared/mmu/pte121.c| 11 ++-
 bsps/powerpc/shared/start/start.S   |  2 +-
 8 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/bsps/powerpc/gen5200/start/start.S 
b/bsps/powerpc/gen5200/start/start.S
index 9e9e504861..fbb58cdfb1 100644
--- a/bsps/powerpc/gen5200/start/start.S
+++ b/bsps/powerpc/gen5200/start/start.S
@@ -775,7 +775,7 @@ TLB_init:   /* Initialize 
translation lookaside buffers (TLBs) */
xor r29, r29, r29
 
 TLB_init_loop:
-   tlbie   r29
+   tlbie   r29, 0
tlbsync
addir29, r29, 0x1000
addir30, r30, 0x01
diff --git a/bsps/powerpc/gen83xx/start/cpuinit.c 
b/bsps/powerpc/gen83xx/start/cpuinit.c
index 1b0fd1efef..ad8fe98456 100644
--- a/bsps/powerpc/gen83xx/start/cpuinit.c
+++ b/bsps/powerpc/gen83xx/start/cpuinit.c
@@ -133,7 +133,7 @@ static void clear_mmu_regs( void)
 
   /* Clear TLBs */
   for (i = 0;i < 32;i++) {
-__asm__ volatile( "tlbie %0\n" : : "r" (i << (31 - 19)));
+__asm__ volatile( "tlbie %0, 0\n" : : "r" (i << (31 - 19)));
   }
 }
 
diff --git a/bsps/powerpc/include/libcpu/mmu.h 
b/bsps/powerpc/include/libcpu/mmu.h
index d3081316eb..6e7abb15da 100644
--- a/bsps/powerpc/include/libcpu/mmu.h
+++ b/bsps/powerpc/include/libcpu/mmu.h
@@ -165,7 +165,7 @@ typedef struct _MMU_context {
 /* invalidate a TLB entry */
 static inline void _tlbie(unsigned long va)
 {
-   asm volatile ("tlbie %0" : : "r"(va));
+   asm volatile ("tlbie %0, 0" : : "r"(va));
 }
 
 extern void _tlbia(void);  /* invalidate all TLB entries */
diff --git a/bsps/powerpc/motorola_powerpc/bootloader/head.S 
b/bsps/powerpc/motorola_powerpc/bootloader/head.S
index 974b78a51c..b7e423e75d 100644
--- a/bsps/powerpc/motorola_powerpc/bootloader/head.S
+++ b/bsps/powerpc/motorola_powerpc/bootloader/head.S
@@ -383,7 +383,7 @@ MMUoff: blr
 flush_tlb:
lis r11,0x1000
 1: addic.  r11,r11,-0x1000
-   tlbie   r11
+   tlbie   r11, 0
bnl 1b
 /* tlbsync is not implemented on 601, so use sync which seems to be a superset
  * of tlbsync in all cases and do not bother with CPU dependant code
diff --git a/bsps/powerpc/motorola_powerpc/bootloader/mm.c 
b/bsps/powerpc/motorola_powerpc/bootloader/mm.c
index 1b3df41d49..2675396145 100644
--- a/bsps/powerpc/motorola_powerpc/bootloader/mm.c
+++ b/bsps/powerpc/motorola_powerpc/bootloader/mm.c
@@ -199,7 +199,7 @@ void _handler(int vec, ctxt *p) {
flushva |= ((hte[i].key<<21)&0xf000)
  | ((hte[i].key<<22)&0x0fc0);
hte[i].key=0;
-   asm volatile("sync; tlbie %0; sync" : : "r" (flushva));
+   asm volatile("sync; tlbie %0, 0; sync" : : "r" 
(flushva));
found:
hte[i].rpn = rpn;
asm volatile("eieio": : );
@@ -583,7 +583,7 @@ void vflush(map *virtmap) {
  | ((p[i].key<<22)&0x0fc0);
if (va>=virtmap->base && va<=virtmap->end) {
p[i].key=0;
-   asm volatile("sync; tlbie %0; sync" : :
+   asm volatile("sync; tlbie %0, 0; sync" : :
 "r" (va));
}
}
diff --git a/bsps/powerpc/mvme5500/start/start.S 
b/bsps/powerpc/mvme5500/start/start.S
index c948c9c1ef..7e339147fa 100644
--- a/bsps/powerpc/mvme5500/start/start.S
+++ b/bsps/powerpc/mvme5500/start/start.S
@@ -193,7 +193,7 @@ _return_to_ppcbug:
 flush_tlbs:
lis r20, 0x1000
 1: addic.  r20, r20, -0x1000
-   tlbie   r20
+   tlbie   r20, 0
bgt 1b
sync
blr
diff --git a/bsps/powerpc/shared/mmu/pte121.c b/bsps/powerpc/shared/mmu/pte121.c
index 93ef909776..778d6353a9 100644
--- a/bsps/powerpc/shared/mmu/pte121.c
+++ b/bsps/powerpc/shared/mmu/pte121.c
@@ -122,9 +122,10 @@
  * instructions in order to flush all TLBs.
  * On the 750 and 7400, there are 128 two way I and D TLBs,
  * indexed by EA[14:19]. Hence calling
- *   tlbie rx
+ *   tlbie rx, 0
  * where rx scans 0x0, 0x01000, 0x02000, ... 0x3f000
- * is sufficient to do the job
+ * is sufficient to do the job. The 0 in the tlbie instruction is the L operand
+ * which selects a 4KiB page size.
  */
 #define NUM_TLB_PER_WAY 64  /* 750 and 7400 

[PATCH 0/3] GCC 10 fixes for powerpc

[Sebastian Huber]

The following patch set fixes some compile time problems with GCC 10 on powerpc.
I am not sure if every change is correct, especially I am not sure about the
tlbie change since I had problems to figure out what is going on.  This is
probably something for RTEMS 6.

Sebastian Huber (3):
  bsp/qoriq: Fix tlbwe sequence
  bsps/powerpc: Fix inline assembly
  bsps/powerpc: Fix tlbie instruction usage

 bsps/powerpc/gen5200/start/start.S |  2 +-
 bsps/powerpc/gen83xx/start/cpuinit.c   |  2 +-
 bsps/powerpc/include/libcpu/mmu.h  |  2 +-
 bsps/powerpc/include/libcpu/powerpc-utility.h  | 73 ++
 bsps/powerpc/motorola_powerpc/bootloader/head.S|  2 +-
 bsps/powerpc/motorola_powerpc/bootloader/mm.c  |  4 +-
 bsps/powerpc/mvme5500/start/start.S|  2 +-
 bsps/powerpc/qoriq/start/bspstart.c|  5 +-
 bsps/powerpc/qoriq/start/mmu.c |  7 ++-
 .../powerpc/shared/exceptions/ppc_exc_initialize.c | 45 +++--
 bsps/powerpc/shared/mmu/e500-mmu.c | 31 +
 bsps/powerpc/shared/mmu/pte121.c   | 11 ++--
 bsps/powerpc/shared/start/start.S  |  2 +-
 13 files changed, 128 insertions(+), 60 deletions(-)

-- 
2.16.4

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

Re: Use weak functions in the RTEMS core?

[Jonathan Brandmeyer]

On Wed, Apr 8, 2020 at 10:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/04/2020 17:57, Jonathan Brandmeyer wrote:
>
> > There are a couple more disadvantages.
> >
> > Which definition is pulled into the final link depends on the order
> > that the object files are listed on the command-line.  If the weak one
> > is seen first, then the linker will resolve the symbol against the
> > weak definition and it won't even search into subsequent archives for
> > the strong one.  It will merely suppress multiple-definition errors at
> > link time.
> >
> > We ran into this issue in our project when we over-rode some RTEMS
> > weak symbols in one of our static archives.  Since the dependency
> > graph seen by the linker was from one object in librtems.a to another
> > object in librtems.a, the only way we could reliably pull in our
> > override was by listing our archive as an object to be linked instead
> > of as an archive to be searched (ie, named as libour_runtime.a instead
> > of -lour_runtime on the link step command).
>
> For the linker weak functions are like ordinary functions during the
> symbol resolving phase. If the linker finds the weak one first, then it
> is happy and stops searching.


Correct, that's why it behaves this way.


> If you encounter problems like this, then
> weak functions are used for the wrong thing.
>

Exhibit A: zynq_setup_mmu_and_cache.  It is referred to only by the BSP's
startup sequence.  So it is a reference from librtemsbsp to librtemsbsp by
default.  I don't think it's being used for the wrong thing.


>
> I would like to use weak functions with one level of indirection. For
> example an application can use two features A and B. Both use an
> interface C. If only A is used, then C can be implemented via D or E. If
> B is used, then C must be implemented via E. For this you can use a weak
> implementation D of interface C in module of A and a strong
> implementation E in module of B.
>

In the proposed case of using weak references for the heap, which
implementation gets pulled in depends on whether or not the object files
listed on the command line reference the heap or not.  If the only
references are within static archives, then the application will have
difficulty choosing exactly which implementation of the heap gets pulled
in.  librtemsbsp both depends-on and provides implementations of malloc and
free.

It's pretty easy to provide a definition of Init() or POSIX_Init() that
doesn't directly call malloc or free, for example.

Instead of treating weak references as a single level of indirection, I
think you have to treat them as a single overridable interface.  In a
dynamically-linked application, we might try to perform an override using
the LD_PRELOAD feature.  But in a statically-linked application we have to
do it differently.  The overriding archive must be named in full, and it
must be named as an object to be linked instead of a library to be
searched.  Furthermore, an interface can have only one override that ends
up in the linked application.

-- 
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Adding test for clock_getcpuclockid()

[Eshan Dhawan]

hello,
how do I add a test for a function that returns -1(ENOSYS), Since isn't
implemented yet?
Though of adding test for clock_getcpuclockid in the same file of
psxgetcpuclockid01.
I wrote the test but it will always return -1.
should I change the rtems_test_asset( r==0 ) to r==-1 and add a print
statement to tell it will be returning -1 ?
Or there are other ways?

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

Re: Need help to run a smp testsuite on erc32 with multi core

[Richi Dubey]

Dear Dr. Bloom,

I understand. I would be more specific from next time.

When I ran sis with no multi-core option, the result came out same as when
I ran it with -m 2 option, (To simulate the executable with 2 cores). And
on reading sis manual, I understood it didn't support erc32
multiprocessing, now I know the reason was because erc32 is a single core
processor.

I built erc32 on SPARC - RTEMS with --enable-smp option enabled.

On trying to run the debugger, sparc-rtems5-gdb [file], It doesnt not
support the command " tar sim -erc32" anymore(from
https://devel.rtems.org/wiki/Debugging/sis) and I didn't know how to set a
simulator as a target.

Thank you.

On Wed, Apr 8, 2020 at 1:03 AM Gedare Bloom  wrote:

> On Tue, Apr 7, 2020 at 1:30 PM Richi Dubey  wrote:
> >
> > Hey everyone,
> >
> > Can someone please help me out with running a smp testsuite on
> erc32(which uses SPARC instruction set). I tried using sis, but the -m
> option for multi core doesnt seem to work, as the sis readme says: "-m
> cores : Enable the number of cores (2 - 4) in a leon3 or RISC-V
> multi-processor system." and that sis supports:
> >
> What do you mean it doesn't seem to work? What was broken/how do you
> know it was broken?
>
> How did you configure/build rtems?
>
> How did you invoke sis?
>
> What is the output of running sis?
>
> >  " sis is capable of emulating four different processor systems:
> >  ERC32 ERC32 SPARC V7 processor
> > LEON2 LEON2 SPARC V8 processor
> > LEON3 LEON3 SPARC V8 processor
> >  RISC-V RISC-V (RV32IMACFD) processor "
> >
> > So if sis does not support multi-core for erc32 systems, what should I
> use to run a smp program on erc32?
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

[Gedare Bloom]

These look alright to me, although I wonder if we need some bsp doc for
this setup?

On Wed, Apr 8, 2020, 9:23 AM Jan Sommer  wrote:

> Here are the changes I did for our local setup.
> The first patch enableds telnet tty devices for run.cfg setups
> The second add a run configuration for the pc BSP
>
> Jan Sommer (2):
>   tester: Allow telnet tty devices for run.cfg
>   tester: Add configuration pc-run.ini
>
>  tester/rtems/testing/bsps/pc-run.ini | 41
> 
>  tester/rtems/testing/run.cfg |  4 +++-
>  2 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 tester/rtems/testing/bsps/pc-run.ini
>
> --
> 2.12.3
>
> ___
> 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-tester: Add rv64imafdc_medany for QEMU

[Gedare Bloom]

This looks alright. I doubt EB has a copyright in this, though.

On Wed, Apr 8, 2020, 4:04 AM Hesham Almatary 
wrote:

> ---
>  .../rtems/testing/bsps/rv64imafdc_medany.ini  | 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/rv64imafdc_medany.ini
>
> diff --git a/tester/rtems/testing/bsps/rv64imafdc_medany.ini
> b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
> new file mode 100644
> index 000..30abd50
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
> @@ -0,0 +1,36 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2020 Hesham Almatary
> +# Copyright 2018 embedded brains GmbH
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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.
> +#
> +
> +[rv64imafdc_medany]
> +bsp   = rv64imafdc_medany
> +arch  = riscv64
> +tester= %{_rtscripts}/qemu.cfg
> +bsp_qemu_opts = -no-reboot -nographic %{qemu_opts_no_net} -machine virt
> -m 64M
> --
> 2.17.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: [PATCH 2/2] rsb: Bump DTC to 1.4 version

[Gedare Bloom]

Push both of these and if needed change spike to this as indicated in other
thread.

On Wed, Apr 8, 2020, 4:00 AM Hesham Almatary 
wrote:

> ---
>  bare/config/devel/dtc.bset | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
> index d701f93..54521f6 100644
> --- a/bare/config/devel/dtc.bset
> +++ b/bare/config/devel/dtc.bset
> @@ -4,4 +4,4 @@
>
>  %define release 1
>
> -devel/dtc-1.2.0
> +devel/dtc-1.4.1-1
> --
> 2.17.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: [PATCH] rsb: Fix Spike build

[Gedare Bloom]

Is the dtc version in spike hardcoded? If so would you update it to use the
dtc redirect instead?

On Wed, Apr 8, 2020, 4:18 AM Hesham Almatary 
wrote:

> Joel and Christian,
>
> Thanks for your review.
>
> Spike bset was already using dtc-1.4.1. I submitted patches to bump
> dtc.bset itself. Are there any other patches I should apply?
>
> Cheers,
> Hesham
>
> On Wed, 8 Apr 2020 at 10:18, Christian Mauderer  wrote:
> >
> > Hello Hesham and Joel,
> >
> > On 07/04/2020 16:01, Joel Sherrill wrote:
> > > Please apply your Christian's and your patch.
> >
> > I haven't created a patch for 1.4 yet. But it's quite straightforward.
> > So maybe just create one instead of applying mine.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > Also bump the dtc base package version number.
> > >
> > > I thought we settled on 1.4.
> > >
> > > --joel
> > >
> > > On Tue, Apr 7, 2020 at 3:56 AM Hesham Almatary
> > > mailto:hesham.almat...@cl.cam.ac.uk>>
> wrote:
> > >
> > > * There is no all$ target in Spike
> > > * There is no longer --with-fesvr flag since fesvr is
> source-inlined
> > > by default
> > > ---
> > >  source-builder/config/spike-1-1.cfg | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/source-builder/config/spike-1-1.cfg
> > > b/source-builder/config/spike-1-1.cfg
> > > index 760e1cc..e731348 100644
> > > --- a/source-builder/config/spike-1-1.cfg
> > > +++ b/source-builder/config/spike-1-1.cfg
> > > @@ -37,10 +37,9 @@ URL:
> > > https://github.com/riscv/riscv-isa-sim/
> > >cd ${source_dir_spike}
> > >
> > >./configure \
> > > ---prefix=%{_prefix} \
> > > ---with-fesvr=%{_prefix}
> > > +--prefix=%{_prefix}
> > >
> > > -  %{__make} %{?_smp_mflags} all$
> > > +  %{__make} %{?_smp_mflags}
> > >
> > >cd ${build_top}
> > >
> > > --
> > > 2.17.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
> ___
> 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

[PATCH 0/1] user/rsb/configuration.rst: Complete review on the text

[clrrm]

From: Cláudio Maia 

This patch proposes several fixes in the rsb/configuration.rst file.
The document was reviewed from top to bottom with the following
modifications being proposed:

- moved the paragraph describing the %source directive closer to where
  the directive is introduced in the text, for readability purposes;
- corrected several typos;
- added two cross-references _bsets and _new-configs;
- restructured several sentences.

There are still some changes to be made concerning the DTC example as
the ones described in the following ticket (submitted as suggested by
Gedare Bloom):

- https://devel.rtems.org/ticket/3945

Cláudio Maia (1):
  user/rsb/configuration.rst: Complete review on the text

 user/rsb/configuration.rst | 424 +++--
 1 file changed, 215 insertions(+), 209 deletions(-)

-- 
2.17.1

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

[PATCH 1/1] user/rsb/configuration.rst: Complete review on the text

[clrrm]

From: Cláudio Maia 

---
 user/rsb/configuration.rst | 424 +++--
 1 file changed, 215 insertions(+), 209 deletions(-)

diff --git a/user/rsb/configuration.rst b/user/rsb/configuration.rst
index 4b21dee..561ae60 100644
--- a/user/rsb/configuration.rst
+++ b/user/rsb/configuration.rst
@@ -8,23 +8,25 @@
 Configuration
 -
 
-The RTEMS Source Builder has two types of configuration data:
+The RTEMS Source Builder (RSB) has two types of configuration data:
 
-- Build Sets
+- Build Sets (see :ref:`bsets` for more info)
 
 - Package Build Configurations
 
-By default these files can be located in two separate directories and
-searched. The first directory is ``config`` in your current working directory
-(``_topdir``) and the second is ``config`` located in the base directory of the
-RTEMS Source Builder command you run (``_sbdir``). The RTEMS directory
-``rtems``` located at the top of the RTEMS Source Builder source code is an
-example of a specific build configuration directory. You can create custom or
-private build configurations and if you run the RTEMS Source Builder command
-from that directory your configurations will be used.
+By default this type of files can be located and searched in two separate
+directories. The first directory is the ``config`` directory existing inside
+your current working directory (``_topdir``) and the second is the ``config``
+directory located inside the base directory of the RTEMS Source Builder command
+you run (``_sbdir``).
 
-The configuration search path is a macro variable and is reference as
-``%{_configdir}``. It's default is defined as:
+The ``rtems`` directory located at the top of the RTEMS Source Builder source
+code is an example of a specific build configuration directory. You can create
+custom or private build configurations and if you run the RTEMS Source Builder
+command from that directory your configurations will be used.
+
+The configuration search path is a macro variable and is referenced as
+``%{_configdir}``. Its default is defined as:
 
 .. code-block:: spec
 
@@ -39,8 +41,8 @@ The configuration search path is a macro variable and is 
reference as
  constraint and the definition.
 
 Build set files have the file extension ``.bset`` and the package build
-configuration files have the file extension of ``.cfg``. The ``sb-set-builder``
-command will search for *build sets* and the ``sb-builder`` commands works with
+configuration files have the file extension ``.cfg``. The ``sb-set-builder``
+command will search for *build sets* and the ``sb-builder`` command works with
 package build configuration files.
 
 Both types of configuration files use the ``#`` character as a comment
@@ -50,13 +52,13 @@ block comment.
 Source and Patches
 ^^
 
-The RTEMS Source Builder provides a flexible way to manage source. Source and
-patches are declare in configurations file using the ``source`` and ``patch``
-directives. These are a single line containing a Universal Resource Location or
-URL and can contain macros and shell expansions. The :ref:`prep` section
-details the *source* and *patch* directives
+The RTEMS Source Builder provides a flexible way to manage the files source.
+Source and patches are declared in configuration files using the ``source`` and
+``patch`` directives. These are defined in a single line containing a Uniform
+Resource Locator (URL) and can contain macros and shell expansions. The
+:ref:`prep` section details the ``source`` and ``patch`` directives.
 
-The URL can reference remote and local source and patch resources. The
+The URL can reference remote and local sources and patch resources. The
 following schemes are provided:
 
 ``http``:
@@ -75,21 +77,22 @@ following schemes are provided:
   Remote access to a patch management repository.
 
 ``file``:
- Local access to an existing source directory.
+  Local access to an existing source directory.
 
 HTTP, HTTPS, and FTP
 
 
-Remote access to TAR or ZIP files is provided using HTTP, HTTPS and FTP
+Remote access to TAR or ZIP files is provided using HTTP, HTTPS or FTP
 protocols. The full URL provided is used to access the remote file including
 any query components. The URL is parsed to extract the file component and the
-local source directory is checked for that file. If the file is located locally
-the remote file is not downloaded. Currently no other checks are made. If a
-download fails you need to manually remove the file from the source directory
+local source directory is checked for that file. If the file exists locally
+then the remote file is not downloaded. Currently, no other checks are made. If
+a download fails you need to manually remove the file from the source directory
 and start the build process again.
 
 The URL can contain macros. These are expanded before issuing the request to
-download the file. The standard GNU GCC compiler source URL is:
+download the file. As an example of the 

Re: Use weak functions in the RTEMS core?

[Sebastian Huber]

On 08/04/2020 17:57, Jonathan Brandmeyer wrote:


There are a couple more disadvantages.

Which definition is pulled into the final link depends on the order 
that the object files are listed on the command-line.  If the weak one 
is seen first, then the linker will resolve the symbol against the 
weak definition and it won't even search into subsequent archives for 
the strong one.  It will merely suppress multiple-definition errors at 
link time.


We ran into this issue in our project when we over-rode some RTEMS 
weak symbols in one of our static archives.  Since the dependency 
graph seen by the linker was from one object in librtems.a to another 
object in librtems.a, the only way we could reliably pull in our 
override was by listing our archive as an object to be linked instead 
of as an archive to be searched (ie, named as libour_runtime.a instead 
of -lour_runtime on the link step command).


For the linker weak functions are like ordinary functions during the 
symbol resolving phase. If the linker finds the weak one first, then it 
is happy and stops searching. If you encounter problems like this, then 
weak functions are used for the wrong thing.


I would like to use weak functions with one level of indirection. For 
example an application can use two features A and B. Both use an 
interface C. If only A is used, then C can be implemented via D or E. If 
B is used, then C must be implemented via E. For this you can use a weak 
implementation D of interface C in module of A and a strong 
implementation E in module of B.




Additionally, it is not trivial to verify which implementation was 
actually pulled into the linked object. Tools like `nm` and `objdump` 
just list the symbol name that ends up in the final ELF.  You have to 
generate a map file and then examine it to establish which object file 
provided the resolved symbol.  Maybe this difficulty can be reduced a 
little with symbol versioning.
Yes, it is a bit more difficult, however, you can resolve it without 
running the application. With global function pointers which change 
values during runtime it is even more complicated to verify.

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

Re: Use weak functions in the RTEMS core?

[Jonathan Brandmeyer]

There are a couple more disadvantages.

Which definition is pulled into the final link depends on the order that
the object files are listed on the command-line.  If the weak one is seen
first, then the linker will resolve the symbol against the weak definition
and it won't even search into subsequent archives for the strong one.  It
will merely suppress multiple-definition errors at link time.

We ran into this issue in our project when we over-rode some RTEMS weak
symbols in one of our static archives.  Since the dependency graph seen by
the linker was from one object in librtems.a to another object in
librtems.a, the only way we could reliably pull in our override was by
listing our archive as an object to be linked instead of as an archive to
be searched (ie, named as libour_runtime.a instead of -lour_runtime on the
link step command).

Additionally, it is not trivial to verify which implementation was actually
pulled into the linked object.  Tools like `nm` and `objdump` just list the
symbol name that ends up in the final ELF.  You have to generate a map file
and then examine it to establish which object file provided the resolved
symbol.  Maybe this difficulty can be reduced a little with symbol
versioning.

On Wed, Apr 8, 2020 at 9:28 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> another use case for a weak function could be the heap. If you only
> allocate memory and never free it, then the implementation can be very
> simple:
>
> https://git.rtems.org/rtems/tree/cpukit/score/src/memoryallocate.c#n49
>
> We could use something like this in heapallocate.c:
>
> RTEMS_WEAK void *_Heap_Allocate_impl(size) { /* Very simple */ }
>
> void *_Heap_Allocate(size)
>
> {
>
>return _Heap_Allocate_impl(size)
>
> }
>
> In heapfree.c:
>
> void *_Heap_Allocate_impl(size) { /* Complex */ }
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

[Alan Cudmore]

Hi Chris,
I definitely plan on creating a readme for the repository to help
anyone that is interested.

Regarding the LEON3: I am noticing something with the release that I
don't understand yet.

I am able to build and run a number of ARM BSPs including raspberrypi,
raspberrypi2, beagleboneblack, and xlinx_zynq_a9_qemu
When I build my application for the leon3, most of it appears to work,
but I have a task demo that crashes when I try to print a variable
that is on the task stack. ( task ID, similar to what ticker does )
I went back and ran a number of the testsuite programs on both my
patched QEMU and sparc-rtems5-sis with no problems.
I then cloned the latest rtems-examples git repository and built the
ticker examples using the (obsolete) Makefile. When built this way,
the ticker program crashes as well on both QEMU and SIS.

I'm trying to narrow down the differences by comparing the flags used
to build the testsuite in the build tree vs. my applications and the
rtems-examples repository.

Should I try building the examples with waf?

Thanks,
Alan

On Tue, Apr 7, 2020 at 2:35 AM Chris Johns  wrote:
>
> Hi Alan,
>
> This is awesome. I welcome deployment stories and support for them. I
> wonder if we need a way to assist capturing this for our users.
>
> You may need to add something to the site's README to provide beginner
> steps.
>
> Chris
>
> On 2020-04-07 11:44, Alan Cudmore wrote:
> > Chris,
> > I tested this release on the Raspberry Pi (Zero), Raspberry Pi 2,
> > Beaglebone Black with LibBSD, xilinx_zynq_a9_qemu, and partially on
> > the leon3. ( samples all work on Leon3 QEMU, but I'm still configuring
> > my application )
> >
> > To help generate tools and BSPs for releases like this, I created a
> > series of Dockerfiles to generate a base system, Add tools, then build
> > BSPs. I was learning docker, and I thought generating release
> > candidate images might be a good exercise :)
> >
> > Here are the Dockerfiles in case anyone is interested:
> > https://github.com/alanc98/rtems-release-docker
> >
> > To use these, create the "rtems5-m2004-base" image first, then for the
> > ARM tools, the "rtems5-m2004-arm-tools" image. Finally, you can create
> > an image like "rtems5-m2004-arm-bbb" to build the RTEMS BSP and
> > rtems-libbsd for the Beaglebone Black.
> >
> > The resulting Docker image will allow you to build RTEMS applications
> > that are shared through the "/host" directory in the container.
> >
> > With these, I hope to be able to crank out a series of builds for the
> > targets I'm interested in for future releases.
> >
> > I'm also working on integration of my RTEMS Kernel Image (RKI) with
> > rtems-libbsd. I have it working on the Beaglebone black and the
> > zynq_a9_qemu target. That is a work in progress here:
> > https://github.com/alanc98/rki2
> > All of the above targets work except for the leon3 right now. (
> > Raspberry Pi targets are not libbsd)
> >
> > Alan
> >
> > On Thu, Apr 2, 2020 at 6:13 AM  wrote:
> >>
> >> RTEMS Release Build - 5.0.0-m2004
> >>
> >> RTEMS 5 Release snapshot m2004 is avaliable for testing.
> >> It can be found at:
> >>
> >>   https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2004
> >>
> >> Please test and report any issues to the u...@rtems.org or devel@rtems.org
> >> mailing lists or please raise a ticket.
> >>
> >> If you are part of the RTEMS testing program please build on your preferred
> >> host posting build and BSP test results to bu...@rtems.org.
> >>
> >> This is a development release and may have errors and be unstable.
> >>
> >> Thanks
> >> 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: Use weak functions in the RTEMS core?

[Sebastian Huber]

Hello,

another use case for a weak function could be the heap. If you only 
allocate memory and never free it, then the implementation can be very 
simple:


https://git.rtems.org/rtems/tree/cpukit/score/src/memoryallocate.c#n49

We could use something like this in heapallocate.c:

RTEMS_WEAK void *_Heap_Allocate_impl(size) { /* Very simple */ }

void *_Heap_Allocate(size)

{

  return _Heap_Allocate_impl(size)

}

In heapfree.c:

void *_Heap_Allocate_impl(size) { /* Complex */ }

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

[PATCH 1/2] tester: Allow telnet tty devices for run.cfg

[Jan Sommer]

- Only set console_stdio as default if no bsp_tty_dev has been defined
---
 tester/rtems/testing/run.cfg | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tester/rtems/testing/run.cfg b/tester/rtems/testing/run.cfg
index f7b21d7..e472ba8 100644
--- a/tester/rtems/testing/run.cfg
+++ b/tester/rtems/testing/run.cfg
@@ -41,7 +41,9 @@
 #
 # Console.
 #
-%define console_stdio
+%ifn %{defined bsp_tty_dev}
+ %define console_stdio
+%endif
 %include %{_configdir}/console.cfg
 
 #
-- 
2.12.3

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

[PATCH 2/2] tester: Add configuration pc-run.ini

[Jan Sommer]

---
 tester/rtems/testing/bsps/pc-run.ini | 41 
 1 file changed, 41 insertions(+)
 create mode 100644 tester/rtems/testing/bsps/pc-run.ini

diff --git a/tester/rtems/testing/bsps/pc-run.ini 
b/tester/rtems/testing/bsps/pc-run.ini
new file mode 100644
index 000..34ec2a4
--- /dev/null
+++ b/tester/rtems/testing/bsps/pc-run.ini
@@ -0,0 +1,41 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2010-2017 Chris Johns (chr...@rtems.org)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 pc686 hardware is started via a custom command. The console
+# is connected to a telnet tty device.
+#
+[pc-run]
+bsp= pc686
+arch   = i386
+tester = %{_rtscripts}/run.cfg
+jobs   = 1
+test_restarts  = 3
+requires   = target_on_command, target_off_command, 
target_reset_command, bsp_tty_dev, bsp_run_cmd
-- 
2.12.3

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

[PATCH 0/2] [rtems-tools] Allow telnet tty devices for run.cfg

[Jan Sommer]

Here are the changes I did for our local setup.
The first patch enableds telnet tty devices for run.cfg setups
The second add a run configuration for the pc BSP

Jan Sommer (2):
  tester: Allow telnet tty devices for run.cfg
  tester: Add configuration pc-run.ini

 tester/rtems/testing/bsps/pc-run.ini | 41 
 tester/rtems/testing/run.cfg |  4 +++-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 tester/rtems/testing/bsps/pc-run.ini

-- 
2.12.3

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

Re: Use weak functions in the RTEMS core?

[Sebastian Huber]

On 08/04/2020 14:06, Andrew Butterfield wrote:

 from my perspective as part of the qualification effort I suspect 
that weak functions are easier to reason about and verify than global 
pointers? Is my suspicion reasonable - I am more familiar with 
pointers (global or otherwise) than I am with how weak functions are 
implemented.
The problem with weak functions is that they need support from the 
object format and linkers. I guess nowadays this is not really an issue 
since every architecture relevant to RTEMS uses ELF.

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

i386: unknown register name 'fpcr' in 'asm'

[Sebastian Huber]

Hello,

if someone cares about i386 support, please have a look at this:

https://devel.rtems.org/ticket/3943

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

Re: [PATCH] rsb: Fix Spike build

[Hesham Almatary]

Joel and Christian,

Thanks for your review.

Spike bset was already using dtc-1.4.1. I submitted patches to bump
dtc.bset itself. Are there any other patches I should apply?

Cheers,
Hesham

On Wed, 8 Apr 2020 at 10:18, Christian Mauderer  wrote:
>
> Hello Hesham and Joel,
>
> On 07/04/2020 16:01, Joel Sherrill wrote:
> > Please apply your Christian's and your patch.
>
> I haven't created a patch for 1.4 yet. But it's quite straightforward.
> So maybe just create one instead of applying mine.
>
> Best regards
>
> Christian
>
> >
> > Also bump the dtc base package version number.
> >
> > I thought we settled on 1.4.
> >
> > --joel
> >
> > On Tue, Apr 7, 2020 at 3:56 AM Hesham Almatary
> > mailto:hesham.almat...@cl.cam.ac.uk>> wrote:
> >
> > * There is no all$ target in Spike
> > * There is no longer --with-fesvr flag since fesvr is source-inlined
> > by default
> > ---
> >  source-builder/config/spike-1-1.cfg | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/source-builder/config/spike-1-1.cfg
> > b/source-builder/config/spike-1-1.cfg
> > index 760e1cc..e731348 100644
> > --- a/source-builder/config/spike-1-1.cfg
> > +++ b/source-builder/config/spike-1-1.cfg
> > @@ -37,10 +37,9 @@ URL:
> > https://github.com/riscv/riscv-isa-sim/
> >cd ${source_dir_spike}
> >
> >./configure \
> > ---prefix=%{_prefix} \
> > ---with-fesvr=%{_prefix}
> > +--prefix=%{_prefix}
> >
> > -  %{__make} %{?_smp_mflags} all$
> > +  %{__make} %{?_smp_mflags}
> >
> >cd ${build_top}
> >
> > --
> > 2.17.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems-tester: Add rv64imafdc_medany for QEMU

[Hesham Almatary]

---
 .../rtems/testing/bsps/rv64imafdc_medany.ini  | 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 tester/rtems/testing/bsps/rv64imafdc_medany.ini

diff --git a/tester/rtems/testing/bsps/rv64imafdc_medany.ini 
b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
new file mode 100644
index 000..30abd50
--- /dev/null
+++ b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
@@ -0,0 +1,36 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Hesham Almatary
+# Copyright 2018 embedded brains GmbH
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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.
+#
+
+[rv64imafdc_medany]
+bsp   = rv64imafdc_medany
+arch  = riscv64
+tester= %{_rtscripts}/qemu.cfg
+bsp_qemu_opts = -no-reboot -nographic %{qemu_opts_no_net} -machine virt -m 64M
-- 
2.17.1

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

[PATCH 1/2] rsb: Fix Spike build

[Hesham Almatary]

* There is no all$ target in Spike
* There is no longer --with-fesvr flag since fesvr is source-inlined
by default
---
 source-builder/config/spike-1-1.cfg | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/source-builder/config/spike-1-1.cfg 
b/source-builder/config/spike-1-1.cfg
index 760e1cc..e731348 100644
--- a/source-builder/config/spike-1-1.cfg
+++ b/source-builder/config/spike-1-1.cfg
@@ -37,10 +37,9 @@ URL:https://github.com/riscv/riscv-isa-sim/
   cd ${source_dir_spike}
 
   ./configure \
---prefix=%{_prefix} \
---with-fesvr=%{_prefix}
+--prefix=%{_prefix}
 
-  %{__make} %{?_smp_mflags} all$
+  %{__make} %{?_smp_mflags}
 
   cd ${build_top}
 
-- 
2.17.1

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

[PATCH 2/2] rsb: Bump DTC to 1.4 version

[Hesham Almatary]

---
 bare/config/devel/dtc.bset | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
index d701f93..54521f6 100644
--- a/bare/config/devel/dtc.bset
+++ b/bare/config/devel/dtc.bset
@@ -4,4 +4,4 @@
 
 %define release 1
 
-devel/dtc-1.2.0
+devel/dtc-1.4.1-1
-- 
2.17.1

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

[PATCH] bsps/riscv: Fix multiple definition

[Sebastian Huber]

---
 bsps/riscv/griscv/irq/irq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/bsps/riscv/griscv/irq/irq.c b/bsps/riscv/griscv/irq/irq.c
index e3fc8c310f..e68e69e393 100644
--- a/bsps/riscv/griscv/irq/irq.c
+++ b/bsps/riscv/griscv/irq/irq.c
@@ -43,8 +43,6 @@
 #include 
 #include 
 
-rtems_interrupt_lock GRLIB_IrqCtrl_Lock;
-
 #if defined(RTEMS_SMP)
 /* Interrupt to CPU map. Default to CPU0 since in BSS. */
 const unsigned char GRLIB_irq_to_cpu[32] __attribute__((weak));
-- 
2.16.4

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

Re: [PATCH] rsb: Fix Spike build

[Christian Mauderer]

Hello Hesham and Joel,

On 07/04/2020 16:01, Joel Sherrill wrote:
> Please apply your Christian's and your patch. 

I haven't created a patch for 1.4 yet. But it's quite straightforward.
So maybe just create one instead of applying mine.

Best regards

Christian

> 
> Also bump the dtc base package version number.
> 
> I thought we settled on 1.4.
> 
> --joel
> 
> On Tue, Apr 7, 2020 at 3:56 AM Hesham Almatary
> mailto:hesham.almat...@cl.cam.ac.uk>> wrote:
> 
> * There is no all$ target in Spike
> * There is no longer --with-fesvr flag since fesvr is source-inlined
> by default
> ---
>  source-builder/config/spike-1-1.cfg | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/source-builder/config/spike-1-1.cfg
> b/source-builder/config/spike-1-1.cfg
> index 760e1cc..e731348 100644
> --- a/source-builder/config/spike-1-1.cfg
> +++ b/source-builder/config/spike-1-1.cfg
> @@ -37,10 +37,9 @@ URL:           
> https://github.com/riscv/riscv-isa-sim/
>    cd ${source_dir_spike}
> 
>    ./configure \
> -    --prefix=%{_prefix} \
> -    --with-fesvr=%{_prefix}
> +    --prefix=%{_prefix}
> 
> -  %{__make} %{?_smp_mflags} all$
> +  %{__make} %{?_smp_mflags}
> 
>    cd ${build_top}
> 
> -- 
> 2.17.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: Use weak functions in the RTEMS core?

[Sebastian Huber]

On 08/04/2020 10:16, Sebastian Huber wrote:


Hello,

weak functions are already used in several places in RTEMS, but not in 
RTEMS core components. In  we have currently 
only a RTEMS_WEAK_ALIAS() macro:


testsuites/sptests/spmisc01/init.c:int weak_alias_func(void) 
RTEMS_WEAK_ALIAS(noinline_func);
cpukit/libfs/src/defaults/default_mmap.c:) RTEMS_WEAK_ALIAS( 
rtems_filesystem_default_mmap );
cpukit/libfs/src/defaults/default_poll.c:) RTEMS_WEAK_ALIAS( 
rtems_filesystem_default_poll );
cpukit/libfs/src/defaults/default_kqfilter.c:) RTEMS_WEAK_ALIAS( 
rtems_filesystem_default_kqfilter );
cpukit/include/rtems/score/basedefs.h:  #define RTEMS_WEAK_ALIAS( 
_target ) __attribute__((__weak__, __alias__(#_target)))
cpukit/include/rtems/score/basedefs.h:  #define RTEMS_WEAK_ALIAS( 
_target )


It was introduced to allow libbsd to override implementations.

I would like to use weak functions in two places. Firstly, the thread 
creation which has a dependency on thread deletion. Secondly, the C 
Program Heap allocation which has a dependency on deallocation (free). 
These dependencies could be satisfied by weak default implementations 
which do nothing. In case the application actually deletes threads or 
deallocates memory, then the dependencies can be satisfy by a strong 
implementation which actually performs the necessary work.


An alternative to weak functions would be to use a global function 
pointer which is initialized to the default implementation (or NULL). 
In case the application actually deletes threads or deallocates 
memory, then a system initialization handler could set the function 
pointer to the proper implementations.


What do you think about adding this to basedefs.h?


/**
 * @brief Instructs the compiler to define a weak function.
 *
 * Use this attribute for function definitions.  Do not use it for 
function

 * declarations.
 */
#if defined(__GNUC__)
  #define RTEMS_WEAK __attribute__((__weak__))
#else
  #define RTEMS_WEAK
#endif


The benefit of using weak functions is that

* the linker can garbage collect the weak functions if a strong 
implementation is provided and


* there is no global function pointer which must be changed and which 
can be overwritten.


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

Use weak functions in the RTEMS core?

[Sebastian Huber]

Hello,

weak functions are already used in several places in RTEMS, but not in 
RTEMS core components. In  we have currently 
only a RTEMS_WEAK_ALIAS() macro:


testsuites/sptests/spmisc01/init.c:int weak_alias_func(void) 
RTEMS_WEAK_ALIAS(noinline_func);
cpukit/libfs/src/defaults/default_mmap.c:) RTEMS_WEAK_ALIAS( 
rtems_filesystem_default_mmap );
cpukit/libfs/src/defaults/default_poll.c:) RTEMS_WEAK_ALIAS( 
rtems_filesystem_default_poll );
cpukit/libfs/src/defaults/default_kqfilter.c:) RTEMS_WEAK_ALIAS( 
rtems_filesystem_default_kqfilter );
cpukit/include/rtems/score/basedefs.h:  #define RTEMS_WEAK_ALIAS( 
_target ) __attribute__((__weak__, __alias__(#_target)))

cpukit/include/rtems/score/basedefs.h:  #define RTEMS_WEAK_ALIAS( _target )

It was introduced to allow libbsd to override implementations.

I would like to use weak functions in two places. Firstly, the thread 
creation which has a dependency on thread deletion. Secondly, the C 
Program Heap allocation which has a dependency on deallocation (free). 
These dependencies could be satisfied by weak default implementations 
which do nothing. In case the application actually deletes threads or 
deallocates memory, then the dependencies can be satisfy by a strong 
implementation which actually performs the necessary work.


An alternative to weak functions would be to use a global function 
pointer which is initialized to the default implementation (or NULL). In 
case the application actually deletes threads or deallocates memory, 
then a system initialization handler could set the function pointer to 
the proper implementations.


What do you think about adding this to basedefs.h?


/**
 * @brief Instructs the compiler to define a weak function.
 *
 * Use this attribute for function definitions.  Do not use it for function
 * declarations.
 */
#if defined(__GNUC__)
  #define RTEMS_WEAK __attribute__((__weak__))
#else
  #define RTEMS_WEAK
#endif


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