[PATCH] tester: Add Versal VCK190 eval board TFTP support

[chrisj]

From: Chris Johns 

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

diff --git a/tester/rtems/testing/bsps/xilinx_versal_vck190.ini 
b/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
new file mode 100644
index 000..3bdd6be
--- /dev/null
+++ b/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
@@ -0,0 +1,43 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2021 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 Xilinx Zynq Zedboard and Microzed board connected via TFTP. The console
+# is connected to a telnet tty device.
+#
+[xilinx_versal_vck190]
+bsp= xilinx_versal_vck190
+arch   = aarch64
+tester = %{_rtscripts}/tftp.cfg
+jobs   = 1
+test_restarts  = 3
+target_reset_regex = ^No ethernet found.*|^BOOTP broadcast 6.*|^.+complete\.+ 
TIMEOUT.*
+target_start_regex = .* PSCI Power Domain Map:$|^U-Boot .*
+requires   = target_on_command, target_off_command, 
target_reset_command, bsp_tty_dev
-- 
2.24.1

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

[PATCH] covoar: Fix errors building on FreeBSD and clang

[chrisj]

From: Chris Johns 

- The member variable `path_` cannot be a reference and initialised to
  a const char* type input. To do so would require there is a temporary with
  an unspecified life time.
---
 tester/covoar/AddressToLineMapper.h | 2 +-
 tester/covoar/Target_aarch64.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/covoar/AddressToLineMapper.h 
b/tester/covoar/AddressToLineMapper.h
index 88bf475..c78aef7 100644
--- a/tester/covoar/AddressToLineMapper.h
+++ b/tester/covoar/AddressToLineMapper.h
@@ -84,7 +84,7 @@ namespace Coverage {
  *  An iterator pointing to the location in the set that contains the
  *  source file path of the address.
  */
-const std::string& path_;
+const std::string path_;
 
 /*!
  *  The source line number of the address.
diff --git a/tester/covoar/Target_aarch64.h b/tester/covoar/Target_aarch64.h
index 08bd1fb..1502df4 100644
--- a/tester/covoar/Target_aarch64.h
+++ b/tester/covoar/Target_aarch64.h
@@ -44,7 +44,7 @@ namespace Target {
 bool isNopLine(
   const char* const line,
   int&  size
-);
+) override;
 
 /*!
  *  This method determines if the specified line from an
-- 
2.24.1

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

Re: [PATCH] Addded test for timer_create with clock_monotonic

[zack leung]

> +  remaining = (uint32_t)result->tv_nsec + result->tv_sec;
What does "remaining" mean here?  What do you get if you add a
(truncated) nanoseconds value to a seconds value? (Hint: the units
aren't the same, so the arithmetic is meaningless.)

I thought I could convert it back into the uint32_t. I thought Adding will
give me the remaining time.

 remaining = (uint32_t) ( ptimer->Timer.expire - now );

something similar to what was done there.



> -_Timespec_From_ticks( remaining, &value->it_value );

> +_Timespec_From_ticks(remaining, &value->it_value);

Why convert back and forth between timespec and ticks? why not just

update this function to use timespec values?


Do you want me to change remaining to be a timespec? change the field
it_value to a timespec?

Zack

Ps: thanks for being so patient with my patch. I'm still learning !


On Tue, 29 Jun 2021 at 16:44, Gedare Bloom  wrote:

> Hi Zack,
>
> Please provide a full name in your git-commit author metadata
> (git-config.user)
>
> Please use a short tag at the start of your commit to identify the
> scope, in this case, it will be "posix/timer"
>
> Check typo "addded" in your commit message. I think this commit is
> related to a ticket? if it finishes it, please use
> Closes #.
> where  is the ticket number, or
> Updates #.
> If the patch does not close the ticket out.
>
> On Tue, Jun 29, 2021 at 9:19 AM Zack  wrote:
> >
> > ---
> >  cpukit/include/rtems/posix/timer.h|  1 +
> >  cpukit/posix/src/psxtimercreate.c |  5 +-
> >  cpukit/posix/src/timergettime.c   | 79 ---
> >  testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
> >  4 files changed, 98 insertions(+), 25 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> > index bcbf07a65a..839fe3293c 100644
> > --- a/cpukit/include/rtems/posix/timer.h
> > +++ b/cpukit/include/rtems/posix/timer.h
> > @@ -48,6 +48,7 @@ typedef struct {
> >uint32_t  ticks;  /* Number of ticks of the
> initialization */
> >uint32_t  overrun;/* Number of expirations of the timer
>   */
> >struct timespec   time;   /* Time at which the timer was started
>  */
> > +clockid_t clock_type;
> To be consistent, add a comment like the lines above.
>
> >  } POSIX_Timer_Control;
> >
> >  /**
> > diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> > index a63cf1d100..b60be3f229 100644
> > --- a/cpukit/posix/src/psxtimercreate.c
> > +++ b/cpukit/posix/src/psxtimercreate.c
> > @@ -40,7 +40,7 @@ int timer_create(
> >  {
> >POSIX_Timer_Control *ptimer;
> >
> > -  if ( clock_id != CLOCK_REALTIME )
> > +  if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC  )
> >  rtems_set_errno_and_return_minus_one( EINVAL );
> >
> >if ( !timerid )
> > @@ -91,7 +91,8 @@ int timer_create(
> >ptimer->timer_data.it_value.tv_nsec= 0;
> >ptimer->timer_data.it_interval.tv_sec  = 0;
> >ptimer->timer_data.it_interval.tv_nsec = 0;
> > -
> > +  ptimer->clock_type=clock_id;
> add spaces around =. Here, the lines above are aligned on the =, so
> you should also align. Write code that uses a consistent style as
> surrounding code / as the RTEMS Style.
>
> > +
> This blank line adds a lot of whitespace characters (spaces). Blank
> lines should be empty.
>
> >_Watchdog_Preinitialize( &ptimer->Timer, _Per_CPU_Get_snapshot() );
> >_Watchdog_Initialize( &ptimer->Timer, _POSIX_Timer_TSR );
> >_Objects_Open_u32(&_POSIX_Timer_Information, &ptimer->Object, 0);
> > diff --git a/cpukit/posix/src/timergettime.c
> b/cpukit/posix/src/timergettime.c
> > index ee2a566f0e..57b0ab4918 100644
> > --- a/cpukit/posix/src/timergettime.c
> > +++ b/cpukit/posix/src/timergettime.c
> > @@ -6,6 +6,14 @@
> >   * @brief Function Fetches State of POSIX Per-Process Timers
> >   */
> >
> > +/**
> > + * @file
> > + *
> > + * @ingroup POSIXAPI
> > + *
> > + * @brief Function Fetches State of POSIX Per-Process Timers
>
> A file isn't a function
>
> > + */
> > +
> >  /*
> >   *  14.2.4 Per-Process Timers, P1003.1b-1993, p. 267
> >   *
> > @@ -21,13 +29,13 @@
> >  #include "config.h"
> >  #endif
> >
> > -#include 
> >  #include 
> > -
> Why delete the space separating the two groups of includes, system
> includes and rtems includes?
>
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> Why do you reorder the includes?
>
> >
> >  /*
> >   *  - When a timer is initialized, the value of the time in
> > @@ -36,38 +44,65 @@
> >   *between the current time and the initialization time.
> >   */
> >
> > -int timer_gettime(
> > -  timer_ttimerid,
> > -  struct itimerspec *value
> > -)
> > -{
> > +int timer_gettime(timer_t timerid, struct itimerspec *value) {
> Why do you reformat the style of the function declaration? I shouldn't
> need to spend time reviewing your style changes, foc

Re: [PATCH rtems-libbsd] rtembsd: Use config.inc to control ZynqMP ethernet

[Chris Johns]

Looks good and thanks.

Chris

On 1/7/21 6:11 am, Kinsey Moore wrote:
> This alters the selection of the 4 Cadence GEM interfaces on the Zynq
> Ultrascale+ MPSoC BSP to be provided by config.inc instead of being
> provided by options in the RTEMS BSP itself since those options appear
> to be dead code when not used in conjunction with LibBSD.
> ---
>  rtemsbsd/include/bsp/nexus-devices.h | 9 +
>  testsuite/include/rtems/bsd/test/network-config.h.in | 8 
>  waf_libbsd.py| 4 +++-
>  3 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 5c1bab42..cbb3f48b 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -38,6 +38,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  
> @@ -115,16 +116,16 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
>   * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards 
> treat
>   * the highest-mapped CGEM as the primary interface.
>   */
> -#if BSP_XILINX_ZYNQMP_USE_CGEM0
> +#if NET_CFG_ZYNQMP_USE_CGEM0 == '1'
>  RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
>  #endif
> -#if BSP_XILINX_ZYNQMP_USE_CGEM1
> +#if NET_CFG_ZYNQMP_USE_CGEM1 == '1'
>  RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
>  #endif
> -#if BSP_XILINX_ZYNQMP_USE_CGEM2
> +#if NET_CFG_ZYNQMP_USE_CGEM2 == '1'
>  RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
>  #endif
> -#if BSP_XILINX_ZYNQMP_USE_CGEM3
> +#if NET_CFG_ZYNQMP_USE_CGEM3 == '1'
>  RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
>  #endif
>  RTEMS_BSD_DRIVER_E1000PHY;
> diff --git a/testsuite/include/rtems/bsd/test/network-config.h.in 
> b/testsuite/include/rtems/bsd/test/network-config.h.in
> index 39bb5388..da316e15 100755
> --- a/testsuite/include/rtems/bsd/test/network-config.h.in
> +++ b/testsuite/include/rtems/bsd/test/network-config.h.in
> @@ -64,4 +64,12 @@
>  
>  #define NET_CFG_GATEWAY_IP "@NET_CFG_GATEWAY_IP@"
>  
> +#define NET_CFG_ZYNQMP_USE_CGEM0 '@NET_CFG_ZYNQMP_USE_CGEM0@'
> +
> +#define NET_CFG_ZYNQMP_USE_CGEM1 '@NET_CFG_ZYNQMP_USE_CGEM1@'
> +
> +#define NET_CFG_ZYNQMP_USE_CGEM2 '@NET_CFG_ZYNQMP_USE_CGEM2@'
> +
> +#define NET_CFG_ZYNQMP_USE_CGEM3 '@NET_CFG_ZYNQMP_USE_CGEM3@'
> +
>  #endif /* _RTEMS_BSD_TEST_NETWORK_CONFIG_H_ */
> diff --git a/waf_libbsd.py b/waf_libbsd.py
> index e7222a03..bb4182e3 100644
> --- a/waf_libbsd.py
> +++ b/waf_libbsd.py
> @@ -289,7 +289,9 @@ class Builder(builder.ModuleManager):
>(bld.env.NET_CONFIG))
>  tags = [
>  'NET_CFG_INTERFACE_0', 'NET_CFG_SELF_IP', 'NET_CFG_NETMASK',
> -'NET_CFG_PEER_IP', 'NET_CFG_GATEWAY_IP'
> +'NET_CFG_PEER_IP', 'NET_CFG_GATEWAY_IP',
> +'NET_CFG_ZYNQMP_USE_CGEM0', 'NET_CFG_ZYNQMP_USE_CGEM1',
> +'NET_CFG_ZYNQMP_USE_CGEM2', 'NET_CFG_ZYNQMP_USE_CGEM3'
>  ]
>  try:
>  net_cfg_lines = open(bld.env.NET_CONFIG).readlines()
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] defaults.mc: Remove any checks for objdump and objcopy

[Chris Johns]

On 1/7/21 12:31 am, Joel Sherrill wrote:
> On Wed, Jun 30, 2021 at 3:28 AM  wrote:
>>
>> From: Chris Johns 
>>
>> - FreeBSD is removing any dependence on binutils and release 13
>>   has remove objdump. This is fine as we build our own version.
> 
> removed. :)

Thanks.

> 
>> ---
>>  source-builder/defaults.mc | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/source-builder/defaults.mc b/source-builder/defaults.mc
>> index 8ed7003..98775e8 100644
>> --- a/source-builder/defaults.mc
>> +++ b/source-builder/defaults.mc
>> @@ -184,13 +184,12 @@ __mkdir: exe, required, '/bin/mkdir'
>>  __mkdir_p:   exe, none, '/bin/mkdir -p'
>>  __mv:exe, required, '/bin/mv'
>>  __nm:exe, required, '/usr/bin/nm'
>> -__objcopy:   exe, optional, '/usr/bin/objcopy'
>> -__objdump:   exe, optional, '/usr/bin/objdump'
>> +__objcopy:   exe, none, '/usr/bin/objcopy'
>> +__objdump:   exe, none, '/usr/bin/objdump'
> 
> Looks like you are also removing objcopy.
> 
> Why would we have ever needed the native versions of either?

We should not. It is hang over from the very start of the RSB when I translated
across the spec file defaults and that is focused on native build.

> And what's the alternative on FreeBSD if someone did need that
> functionality?

The maintainer doing the work put in the 13 release notes you use readelf and/or
llvm-objdump. I should point out this is removed from base so you can still
install binutils as a package using pkg.

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

CPU Context Switch Confusion

[gerberhe11]

Hello,

 

I am working on re-implementing support for the uC5282 board in Qemu for use
with RTEMS. I think I am getting close, but am running into some debugging
issues in regards to context switching. I am using the RTEMS 'hello'
application for uC5282 to work on and debug my modifications. Currently, at
some point during execution, the context of RTEMS goes to the idle thread
instead of the init thread. I am struggling somewhat with finding a way to
debug this context switch, and would really appreciate any advice or help if
anyone may have some to give! I can also explain more thoroughly what is
happening, along with providing debugging info, if anyone would like to help
or has any ideas!

 

Thanks so much, 

 

Harrison Gerber

  gerberh...@gmail.com

720-288-7308

 



-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd] rtembsd: Use config.inc to control ZynqMP ethernet

[Kinsey Moore]

This alters the selection of the 4 Cadence GEM interfaces on the Zynq
Ultrascale+ MPSoC BSP to be provided by config.inc instead of being
provided by options in the RTEMS BSP itself since those options appear
to be dead code when not used in conjunction with LibBSD.
---
 rtemsbsd/include/bsp/nexus-devices.h | 9 +
 testsuite/include/rtems/bsd/test/network-config.h.in | 8 
 waf_libbsd.py| 4 +++-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 5c1bab42..cbb3f48b 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -38,6 +38,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -115,16 +116,16 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
  * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
  * the highest-mapped CGEM as the primary interface.
  */
-#if BSP_XILINX_ZYNQMP_USE_CGEM0
+#if NET_CFG_ZYNQMP_USE_CGEM0 == '1'
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
 #endif
-#if BSP_XILINX_ZYNQMP_USE_CGEM1
+#if NET_CFG_ZYNQMP_USE_CGEM1 == '1'
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
 #endif
-#if BSP_XILINX_ZYNQMP_USE_CGEM2
+#if NET_CFG_ZYNQMP_USE_CGEM2 == '1'
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
 #endif
-#if BSP_XILINX_ZYNQMP_USE_CGEM3
+#if NET_CFG_ZYNQMP_USE_CGEM3 == '1'
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
 #endif
 RTEMS_BSD_DRIVER_E1000PHY;
diff --git a/testsuite/include/rtems/bsd/test/network-config.h.in 
b/testsuite/include/rtems/bsd/test/network-config.h.in
index 39bb5388..da316e15 100755
--- a/testsuite/include/rtems/bsd/test/network-config.h.in
+++ b/testsuite/include/rtems/bsd/test/network-config.h.in
@@ -64,4 +64,12 @@
 
 #define NET_CFG_GATEWAY_IP "@NET_CFG_GATEWAY_IP@"
 
+#define NET_CFG_ZYNQMP_USE_CGEM0 '@NET_CFG_ZYNQMP_USE_CGEM0@'
+
+#define NET_CFG_ZYNQMP_USE_CGEM1 '@NET_CFG_ZYNQMP_USE_CGEM1@'
+
+#define NET_CFG_ZYNQMP_USE_CGEM2 '@NET_CFG_ZYNQMP_USE_CGEM2@'
+
+#define NET_CFG_ZYNQMP_USE_CGEM3 '@NET_CFG_ZYNQMP_USE_CGEM3@'
+
 #endif /* _RTEMS_BSD_TEST_NETWORK_CONFIG_H_ */
diff --git a/waf_libbsd.py b/waf_libbsd.py
index e7222a03..bb4182e3 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -289,7 +289,9 @@ class Builder(builder.ModuleManager):
   (bld.env.NET_CONFIG))
 tags = [
 'NET_CFG_INTERFACE_0', 'NET_CFG_SELF_IP', 'NET_CFG_NETMASK',
-'NET_CFG_PEER_IP', 'NET_CFG_GATEWAY_IP'
+'NET_CFG_PEER_IP', 'NET_CFG_GATEWAY_IP',
+'NET_CFG_ZYNQMP_USE_CGEM0', 'NET_CFG_ZYNQMP_USE_CGEM1',
+'NET_CFG_ZYNQMP_USE_CGEM2', 'NET_CFG_ZYNQMP_USE_CGEM3'
 ]
 try:
 net_cfg_lines = open(bld.env.NET_CONFIG).readlines()
-- 
2.20.1

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

[PATCH rtems-libbsd 0/1] rtembsd: Use config.inc to control ZynqMP ethernet

[Kinsey Moore]

This patch replaces the previous patch that pulled ethernet
configuration from the BSP with configuration via config.inc. Commit of
this patch will be accompanied by reversion of RTEMS commit
10041a4cfc00d5f6876d3d6cfc30c23347b4cf42

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

Re: [rtems commit] Update Strong APA Scheduler

[Sebastian Huber]

This patch introduced new warnings:

../../../cpukit/score/src/schedulerstrongapa.c: In function 
'_Scheduler_strong_APA_Get_highest_ready':
../../../cpukit/score/src/schedulerstrongapa.c:394:10: warning: 
'highest_ready' may be used uninitialized in this function 
[-Wmaybe-uninitialized]

  394 |   if ( curr_node == highest_ready ) {
  |  ^
../../../cpukit/score/src/schedulerstrongapa.c: In function 
'_Scheduler_strong_APA_Enqueue':
../../../cpukit/score/src/schedulerstrongapa.c:600:38: warning: 
'cpu_to_preempt' may be used uninitialized in this function 
[-Wmaybe-uninitialized]

  600 | curr_strong_node->cpu_to_preempt = cpu_to_preempt;
  | ~^~~~
../../../cpukit/score/src/schedulerstrongapa.c:676:33: note: 
'cpu_to_preempt' was declared here

  676 |   Per_CPU_Control  *cpu_to_preempt;
  | ^~
In file included from ../../../cpukit/include/rtems/score/objectdata.h:25,
 from ../../../cpukit/include/rtems/score/thread.h:32,
 from ../../../cpukit/include/rtems/score/scheduler.h:23,
 from 
../../../cpukit/include/rtems/score/schedulerstrongapa.h:41,

 from ../../../cpukit/score/src/schedulerstrongapa.c:67:
../../../cpukit/include/rtems/score/chainimpl.h:677:18: warning: 
'lowest_reachable' may be used uninitialized in this function 
[-Wmaybe-uninitialized]

  677 |   the_node->next = tail;
  |   ~~~^~
../../../cpukit/score/src/schedulerstrongapa.c:497:32: note: 
'lowest_reachable' was declared here

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

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

Re: [PATCH] defaults.mc: Remove any checks for objdump and objcopy

[Joel Sherrill]

On Wed, Jun 30, 2021 at 3:28 AM  wrote:
>
> From: Chris Johns 
>
> - FreeBSD is removing any dependence on binutils and release 13
>   has remove objdump. This is fine as we build our own version.

removed. :)

> ---
>  source-builder/defaults.mc | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/source-builder/defaults.mc b/source-builder/defaults.mc
> index 8ed7003..98775e8 100644
> --- a/source-builder/defaults.mc
> +++ b/source-builder/defaults.mc
> @@ -184,13 +184,12 @@ __mkdir: exe, required, '/bin/mkdir'
>  __mkdir_p:   exe, none, '/bin/mkdir -p'
>  __mv:exe, required, '/bin/mv'
>  __nm:exe, required, '/usr/bin/nm'
> -__objcopy:   exe, optional, '/usr/bin/objcopy'
> -__objdump:   exe, optional, '/usr/bin/objdump'
> +__objcopy:   exe, none, '/usr/bin/objcopy'
> +__objdump:   exe, none, '/usr/bin/objdump'

Looks like you are also removing objcopy.

Why would we have ever needed the native versions of either?

And what's the alternative on FreeBSD if someone did need that
functionality?

>  __patch_bin: exe, required, '/usr/bin/patch'
>  __patch_opts:none,none, '%{nil}'
>  __patch: exe, none, '%{__patch_bin} %{__patch_opts}'
>  __perl:  exe, optional, 'perl'
> -__svn:   exe, optional, '/usr/bin/svn'
>  __ranlib:exe, required, 'ranlib'
>  __rm:exe, required, '/bin/rm'
>  __rmfile:exe, none, '%{__rm} -f'
> --
> 2.31.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] bsps: Fix GICv3 support for AArch32

[Gedare Bloom]

Thanks, that makes sense.

On Wed, Jun 30, 2021 at 7:38 AM Sebastian Huber
 wrote:
>
> The GICv3 support is shared between AArch32 and AArch64.  For AArch32,
> the new AARCH64_IS_NONSECURE is never defined.  Use ARM_MULTILIB_ARCH_V4
> instead.
>
> This issue was introduced by 76c6caad52244ab9a14151620a80ff0f71035b6c.
>
> There is still a change in bsp_interrupt_vector_enable() for AArch32
> compared to the version before 76c6caad52244ab9a14151620a80ff0f71035b6c.
> ---
>  bsps/shared/dev/irq/arm-gicv3.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
> index d216f4f5f7..75b089b6b5 100644
> --- a/bsps/shared/dev/irq/arm-gicv3.c
> +++ b/bsps/shared/dev/irq/arm-gicv3.c
> @@ -176,7 +176,7 @@ void bsp_interrupt_vector_enable(rtems_vector_number 
> vector)
>  volatile gic_sgi_ppi *sgi_ppi =
>gicv3_get_sgi_ppi(_SMP_Get_current_processor());
>  /* Set interrupt group to 1 in the current security mode */
> -#if defined(AARCH64_IS_NONSECURE)
> +#if defined(ARM_MULTILIB_ARCH_V4) || defined(AARCH64_IS_NONSECURE)
>  sgi_ppi->icspigrpr[0] |= 1 << (vector % 32);
>  sgi_ppi->icspigrpmodr[0] &= ~(1 << (vector % 32));
>  #else
> @@ -228,7 +228,7 @@ static void gicv3_init_cpu_interface(void)
>
>volatile gic_sgi_ppi *sgi_ppi = gicv3_get_sgi_ppi(cpu_index);
>/* Set interrupt group to 1 in the current security mode */
> -#if defined(AARCH64_IS_NONSECURE)
> +#if defined(ARM_MULTILIB_ARCH_V4) || defined(AARCH64_IS_NONSECURE)
>sgi_ppi->icspigrpr[0] = 0x;
>sgi_ppi->icspigrpmodr[0] = 0;
>  #else
> @@ -262,7 +262,7 @@ rtems_status_code bsp_interrupt_facility_initialize(void)
>  dist->icdicer[id / 32] = 0x;
>
>  /* Set interrupt group to 1 in the current security mode */
> -#if defined(AARCH64_IS_NONSECURE)
> +#if defined(ARM_MULTILIB_ARCH_V4) || defined(AARCH64_IS_NONSECURE)
>  dist->icdigr[id / 32] = 0x;
>  dist->icdigmr[id / 32] = 0;
>  #else
> --
> 2.26.2
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps: Fix GICv3 support for AArch32

[Sebastian Huber]

The GICv3 support is shared between AArch32 and AArch64.  For AArch32,
the new AARCH64_IS_NONSECURE is never defined.  Use ARM_MULTILIB_ARCH_V4
instead.

This issue was introduced by 76c6caad52244ab9a14151620a80ff0f71035b6c.

There is still a change in bsp_interrupt_vector_enable() for AArch32
compared to the version before 76c6caad52244ab9a14151620a80ff0f71035b6c.
---
 bsps/shared/dev/irq/arm-gicv3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index d216f4f5f7..75b089b6b5 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -176,7 +176,7 @@ void bsp_interrupt_vector_enable(rtems_vector_number vector)
 volatile gic_sgi_ppi *sgi_ppi =
   gicv3_get_sgi_ppi(_SMP_Get_current_processor());
 /* Set interrupt group to 1 in the current security mode */
-#if defined(AARCH64_IS_NONSECURE)
+#if defined(ARM_MULTILIB_ARCH_V4) || defined(AARCH64_IS_NONSECURE)
 sgi_ppi->icspigrpr[0] |= 1 << (vector % 32);
 sgi_ppi->icspigrpmodr[0] &= ~(1 << (vector % 32));
 #else
@@ -228,7 +228,7 @@ static void gicv3_init_cpu_interface(void)
 
   volatile gic_sgi_ppi *sgi_ppi = gicv3_get_sgi_ppi(cpu_index);
   /* Set interrupt group to 1 in the current security mode */
-#if defined(AARCH64_IS_NONSECURE)
+#if defined(ARM_MULTILIB_ARCH_V4) || defined(AARCH64_IS_NONSECURE)
   sgi_ppi->icspigrpr[0] = 0x;
   sgi_ppi->icspigrpmodr[0] = 0;
 #else
@@ -262,7 +262,7 @@ rtems_status_code bsp_interrupt_facility_initialize(void)
 dist->icdicer[id / 32] = 0x;
 
 /* Set interrupt group to 1 in the current security mode */
-#if defined(AARCH64_IS_NONSECURE)
+#if defined(ARM_MULTILIB_ARCH_V4) || defined(AARCH64_IS_NONSECURE)
 dist->icdigr[id / 32] = 0x;
 dist->icdigmr[id / 32] = 0;
 #else
-- 
2.26.2

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

Re: stm32h7 on libbsd?

[Sebastian Huber]

Hello Gedare,

On 29/06/2021 20:04, Christian Mauderer wrote:
I _think_ Sebastian tested it on the same evaluation board that I used 
for writing the SD driver: STM32H743I-EVAL2. I'm not entirely sure 
whether the "2" is really relevant or whether that's part of an order 
number at a distributor.


yes, I used this board to test the network interface driver. It works 
also on custom hardware.


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

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

Re: Minimum RAM for "libbsd"? Can't run in 8MB on "imxrt".

[Peter Dufault]

> On Jun 23, 2021, at 01:17 , Sebastian Huber 
>  wrote:
> 
> 
> On 21/06/2021 15:31, dufa...@hda.com wrote:
>>> On Jun 21, 2021, at 08:52 , Sebastian 
>>> Huber  wrote:
>>> 
>>> What happens when you reduce the memory space for the mbufs to 4MiB? What 
>>> is the "RTEMS work space"?
>> By "RTEMS work space" I mean the space between bsp_section_work_begin and 
>> bsp_section_work_end, which I assume is handed over to the unified work 
>> space.  I also assume allocated "libbsd" data structures come from there.
> 
> Yes, the space between bsp_section_work_begin and bsp_section_work_end is 
> used for the heap which is used by libbsd.
> 
>> After reducing the space for the mbufs I still run out of RAM.  I've been 
>> patching rtems_bsd_allocator_domain_page_mbuf_size in the debugger for test. 
>>  I'll put it in at compile time but looking at the code that won't make a 
>> difference.
> 
> Which memory allocation fails? Is it in the libbsd initialization or 
> afterwards?

I want to close this thread before someone finds it in a search (and to be nice 
to Sebastian, thanks for your help).

The failure was in libbsd initialization but that's irrelevant.

To get HyperRAM on "imxrt" functional (at least initially) I need to disable 
read pre-fetch on the FlexSPI.  The HyperRAM worked surprisingly well with 
pre-fetch on without libbsd, but when I tried to initialize libbsd it would 
consistently crash at the same place complaining that it was out of work area, 
so I thought it was out of work area.  The memory locations being allocated 
were valid ones from near the end of the HyperRAM address space, it appears 
that consistent memory corruption caused consistent excess allocation, I don't 
what was happening.

After turning off FlexSPI prefetch it worked.

Without making a heroic effort to reduce the libbsd memory footprint (I don't 
want to chase those problems now) I have about 4MB of the 8MB RAM left.  That 
puts the RTEMS "libbsd" RAM foot print at about 3.5MB (on the imxrt) with my 
preliminary configuration.


signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: source builder fails on master

[Richi Dubey]

Thank you! I checked the config.log after using the --no-clean option and
realized that my GCC wasn't working. Seems like there were some issues with
linking: using binutils vs gold. Following this answer helped:
https://stackoverflow.com/a/53969757 resolve that issue.

On Tue, Jun 29, 2021 at 9:46 PM Gedare Bloom  wrote:

> Run with --no-clean option and see if you can find the config.log for
> the expat package. Otherwise, you might try to build that expat
> package by hand to see what is failing.
>
> On Tue, Jun 29, 2021 at 1:43 AM Richi Dubey  wrote:
> >
> > These are the last few lines of the report:
> >
> > bindir=/home/richi/quick-start/LatestMaster/rtems/6/bin
> --exec-prefix=/home/richi/quick-start/LatestMaster/rtems/6
> --includedir=/home/richi/quick-start/LatestMaster/rtems/6/include
> --libdir=/home/richi/quick-start/LatestMaster/rtems/6/lib
> --mandir=/home/richi/quick-start/LatestMaster/rtems/6/share/man
> --infodir=/home/richi/quick-start/LatestMaster/rtems/6/share/info
> --disable-shared
> > checking build system type... x86_64-pc-linux-gnu
> > checking host system type... x86_64-pc-linux-gnu
> > checking how to print strings... printf
> > checking for x86_64-linux-gnu-gcc... gcc -O2 -g -pipe
> -I/home/richi/quick-start/LatestMaster/src/rsb/rtems/build/tmp/sb-1000/6/rtems-arm/home/richi/quick-start/LatestMaster/rtems/6/include
> > checking whether the C compiler works... no
> > configure: error: in
> `/home/richi/quick-start/LatestMaster/src/rsb/rtems/build/expat-2.1.0-x86_64-linux-gnu-1/expat-2.1.0':
> > configure: error: C compiler cannot create executables
> > See `config.log' for more details
> > shell cmd failed: /bin/sh -ex
> /home/richi/quick-start/LatestMaster/src/rsb/rtems/build/expat-2.1.0-x86_64-linux-gnu-1/do-build
> > error: building expat-2.1.0-x86_64-linux-gnu-1
> >
> > On Tue, Jun 29, 2021 at 1:11 PM Richi Dubey 
> wrote:
> >>
> >> Hi,
> >>
> >> I ran the following commands
> >>
> >> mkdir -p $HOME/quick-start/LatestMaster/src
> >> cd $HOME/quick-start/LatestMaster/src
> >> git clone https://github.com/RTEMS/rtems-source-builder.git rsb
> >> git clone https://github.com/RTEMS/rtems.git
> >> cd $HOME/quick-start/LatestMaster/src/rsb/rtems
> >> ../source-builder/sb-set-builder
> --prefix=$HOME/quick-start/LatestMaster/rtems/6 6/rtems-arm
> >>
> >> but it fails.:
> >> .
> >> .
> >> .
> >> package: expat-2.1.0-x86_64-linux-gnu-1
> >> building: expat-2.1.0-x86_64-linux-gnu-1
> >> error: building expat-2.1.0-x86_64-linux-gnu-1
> >> Build FAILED
> >>   See error report: rsb-report-expat-2.1.0-x86_64-linux-gnu-1.txt
> >> error: building expat-2.1.0-x86_64-linux-gnu-1
> >> Build Set: Time 0:00:15.413288
> >> Build FAILED
> >>
> >> I have attached the report. I think it has something to do with my GCC?
> I update it to 11 as well, but I still get the error.
> >>
> >> Gcc details:
> >> --
> >> sudo update-alternatives --config gcc
> >> There are 5 choices for the alternative gcc (providing /usr/bin/gcc).
> >>
> >>   SelectionPath Priority   Status
> >> 
> >> * 0/usr/bin/gcc-11   110   auto mode
> >>   1/usr/bin/gcc-10   100   manual mode
> >>   2/usr/bin/gcc-11   110   manual mode
> >>   3/usr/bin/gcc-770manual mode
> >>   4/usr/bin/gcc-880manual mode
> >>   5/usr/bin/gcc-970manual mode
> >>
> >> Press  to keep the current choice[*], or type selection number:
> >> richi@YouAreAmazing:~$ gcc -v
> >> Using built-in specs.
> >> COLLECT_GCC=gcc
> >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
> >> OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
> >> OFFLOAD_TARGET_DEFAULT=1
> >> Target: x86_64-linux-gnu
> >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 11.1.0-1ubuntu1~18.04.1'
> --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2
> --prefix=/usr --with-gcc-major-version-only --program-suffix=-11
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-plugin --enable-default-pie
> --with-system-zlib --enable-libphobos-checking=release
> --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
> --disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr
> --without-cuda-driver --enable-checking

[PATCH] defaults.mc: Remove any checks for objdump and objcopy

[chrisj]

From: Chris Johns 

- FreeBSD is removing any dependence on binutils and release 13
  has remove objdump. This is fine as we build our own version.
---
 source-builder/defaults.mc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/source-builder/defaults.mc b/source-builder/defaults.mc
index 8ed7003..98775e8 100644
--- a/source-builder/defaults.mc
+++ b/source-builder/defaults.mc
@@ -184,13 +184,12 @@ __mkdir: exe, required, '/bin/mkdir'
 __mkdir_p:   exe, none, '/bin/mkdir -p'
 __mv:exe, required, '/bin/mv'
 __nm:exe, required, '/usr/bin/nm'
-__objcopy:   exe, optional, '/usr/bin/objcopy'
-__objdump:   exe, optional, '/usr/bin/objdump'
+__objcopy:   exe, none, '/usr/bin/objcopy'
+__objdump:   exe, none, '/usr/bin/objdump'
 __patch_bin: exe, required, '/usr/bin/patch'
 __patch_opts:none,none, '%{nil}'
 __patch: exe, none, '%{__patch_bin} %{__patch_opts}'
 __perl:  exe, optional, 'perl'
-__svn:   exe, optional, '/usr/bin/svn'
 __ranlib:exe, required, 'ranlib'
 __rm:exe, required, '/bin/rm'
 __rmfile:exe, none, '%{__rm} -f'
-- 
2.31.1

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

Re: GSOC: Adding all generated changes in patch to RSB?

[Matthew Joyce]

> Once it's set, If I'm not rebuilding the toolset, I'd guess I go
> straight to steps 2.5, 2.6 in the quick-start guide?

I'm sorry, I should have been more specific...I meant 2.5 (Build a
BSP) and 2.6 (Test a BSP) from the RTEMS quick-start?

Thanks again!

On Tue, Jun 29, 2021 at 7:21 PM Joel Sherrill  wrote:
>
> On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce  wrote:
> >
> > Dr. Joel,
> >
> > Thanks! This made me re-read your discord workflow advice from last
> > week, and it brings me to another question...You wrote:
> >
> > "You don't have to rebuild the entire toolsuite at this point. Just
> > add a functional test for sig2str.c to the testsuite (e.g. psxsigNN or
> > similar based on existing names). You have your implementation in your
> > local newlib patches."
> >
> > I did add the test, but I don't quite understand "you have your
> > implementation in your local newlib patches." Do you mean the
> > sig2str.c patch plus generated files? Where exactly is it supposed to
> > be?
>
> Yes. Your changes to newlib are captured in 1+ changes to hand-written
> source files and 1 patch to hold the generated files that really needed to
> change.
>
> > Am I following the instructions Vaibhav lays out minus the toolset
> > rebuilding? (patch in rtems/rsb/patches, calculate sha512, edit .cfg
> > used by .bset file?)
> >
>
> Yes. You only modified newlib and that's all that needs rebuilding
> until the RSB hashes change. You do not need to build binutils, gcc,
> gdb, and the other libraries every time.
>
> Plus using the RSB method, you are rebuilding newlib from scratch
> every time.
>
> Sometimes you will need to do a clean build but for the most part
> while editing a file in newlib that has been added to the Makefile.am,
> stuff regenerated, and a clean first "j-newlib" build with that, you can
> just do make/make install.
>
> > Once it's set, If I'm not rebuilding the toolset, I'd guess I go
> > straight to steps 2.5, 2.6 in the quick-start guide?
>
> I don't know his step numbers but probably.
>
> The key is to be aware of when you need to build newlib from
> scratch and when you need to address the RSB.
>
> --joel
>
> > Thank you again for your help!
> >
> > Sincerely,
> >
> > Matt
> >
> > On Tue, Jun 29, 2021 at 3:45 PM Joel Sherrill  wrote:
> > >
> > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce  
> > > wrote:
> > > >
> > > > Dear Mentors,
> > > >
> > > > I've implemented my new functions locally in Newlib, created basic
> > > > tests in RTEMS, now I want to add the patches to the RSB to test them.
> > > >
> > > > I think I understand that once I submit these patches to newlib, they
> > > > should only include the added lines of source code...not any changes
> > > > generated through the build process.
> > >
> > > +1
> > >
> > > > However, when I make a patch to add to RSB and test, I need to include
> > > > everything, right? There are probably about 100 modified files from
> > > > the reconf / build. Should I:
> > > > 1) "git add --all" to add the whole load of new files and changes
> > > > 2) make the commit
> > > > 3) git format patch
> > >
> > > Yes -- the RSB patch must include the generated files. But this patch set
> > > and RSB modifications are only for your use. Before RTEMS.org RSB is
> > > updated, the patch must be in the upstream newlib and we will just bump
> > > the newlib hash. That's why I suggested just building newlib (j-newlib, 
> > > make,
> > > make install, etc) locally without the RSB and testing that way.
> > >
> > > With that said, there are a couple of things to do here:
> > >
> > > + Do NOT put generated files in your main patch. Make them a separate
> > > patch in the set so they are easy to ignore.
> > >
> > > + Reverse the generated changes to anything that shouldn't change based
> > > on what you touched. These are just due to autoconf version difference. 
> > > In your
> > > case, I think this means you only need signal/Makefile.in. The rest are
> > > unneeded.
> > >
> > > + Only submit the patches with manual changes for review. Submit to devel@
> > > and when it passes review, it goes to newlib.
> > >
> > > When the work is merged into newlib, you can update the RSB newlib hash
> > > and submit your tests to RTEMS. You will have to track the status of
> > > outstanding work and continue on to the next thing while the review 
> > > process
> > > moves along.
> > >
> > > FWIW Eshan ended up tracking patches for a few months after last year's
> > > GSoC ended before we cleared his queue up.
> > >
> > > --joel
> > >
> > > >
> > > > Just want to make sure I'm understanding this point...
> > > >
> > > > Thank you!
> > > >
> > > > Sincerely,
> > > >
> > > > Matt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel