Re: [PATCH v5 0/1] NOEL-V BSP

2022-08-30 Thread Daniel Cederman 

Hi,

Is it OK to push this or should I wait for additional comments?

On 2022-08-25 10:33, Daniel Cederman wrote:

v5
Made RISCV_CONSOLE_MAX_APBUART_DEVICES an option
bsp_fatal if no uart clock frequency is found
Changed CONSOLE_USE_INTERRUPTS to BSP_CONSOLE_USE_INTERRUPTS
Added error codes for APBUART
Get work area size from /memory node

Martin Aberg (1):
   bsp/riscv: Add NOEL-V BSP

  bsps/include/bsp/fatal.h  |   3 +
  bsps/riscv/noel/console/console-config.c  | 208 ++
  bsps/riscv/noel/include/bsp.h |  76 +++
  bsps/riscv/noel/include/bsp/irq.h |  75 +++
  bsps/riscv/noel/include/tm27.h|   1 +
  bsps/riscv/noel/start/bsp_fatal_halt.c|  46 
  bsps/riscv/riscv/include/bsp.h|   2 +
  bsps/riscv/riscv/include/bsp/irq.h|   2 +
  spec/build/bsps/riscv/noel/abi.yml|  48 
  spec/build/bsps/riscv/noel/bspnoel32im.yml|  19 ++
  spec/build/bsps/riscv/noel/bspnoel32imafd.yml |  19 ++
  spec/build/bsps/riscv/noel/bspnoel64imac.yml  |  19 ++
  spec/build/bsps/riscv/noel/bspnoel64imafd.yml |  19 ++
  .../build/bsps/riscv/noel/bspnoel64imafdc.yml |  19 ++
  spec/build/bsps/riscv/noel/grp.yml|  61 +
  spec/build/bsps/riscv/noel/obj.yml|  38 
  spec/build/bsps/riscv/noel/objsmp.yml |  15 ++
  spec/build/bsps/riscv/noel/optapbuartmax.yml  |  16 ++
  spec/build/bsps/riscv/optrambegin.yml |   3 +
  spec/build/cpukit/optarchbits.yml |   2 +
  spec/build/cpukit/optsmp.yml  |   4 +
  21 files changed, 695 insertions(+)
  create mode 100644 bsps/riscv/noel/console/console-config.c
  create mode 100644 bsps/riscv/noel/include/bsp.h
  create mode 100644 bsps/riscv/noel/include/bsp/irq.h
  create mode 100644 bsps/riscv/noel/include/tm27.h
  create mode 100644 bsps/riscv/noel/start/bsp_fatal_halt.c
  create mode 100644 spec/build/bsps/riscv/noel/abi.yml
  create mode 100644 spec/build/bsps/riscv/noel/bspnoel32im.yml
  create mode 100644 spec/build/bsps/riscv/noel/bspnoel32imafd.yml
  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imac.yml
  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafd.yml
  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml
  create mode 100644 spec/build/bsps/riscv/noel/grp.yml
  create mode 100644 spec/build/bsps/riscv/noel/obj.yml
  create mode 100644 spec/build/bsps/riscv/noel/objsmp.yml
  create mode 100644 spec/build/bsps/riscv/noel/optapbuartmax.yml
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-lwip] lwip.py: Address python formatting issues

2022-08-30 Thread Kinsey Moore 

On 8/29/2022 17:06, Chris Johns wrote:

On 30/8/2022 4:30 am, Kinsey Moore wrote:

---
  lwip.py | 106 
  1 file changed, 61 insertions(+), 45 deletions(-)

diff --git a/lwip.py b/lwip.py
index f8d8eb0..2e12957 100644
--- a/lwip.py
+++ b/lwip.py
@@ -29,43 +29,50 @@ from rtems_waf import rtems
  import json
  import os
  
+

  def removeprefix(data, prefix):
  if data.startswith(prefix):
  return data[len(prefix):]
  return data
  
+

+xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/'
+
  xilinx_drv_incl = ''
-xilinx_drv_incl += 
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/include '
-xilinx_drv_incl += './embeddedsw/lib/bsp/standalone/src/common '
-xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
-xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
-xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
-xilinx_drv_incl += './rtemslwip/xilinx '
+xilinx_drv_incl += xilinx_lwip_prefix + 'src/contrib/ports/xilinx/include '
+xilinx_drv_incl += 'embeddedsw/lib/bsp/standalone/src/common '
+xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
+xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
+xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
+xilinx_drv_incl += 'rtemslwip/xilinx '

Lists or strings? I prefer lists because weird paths can effect the waf
conversion from strings to lists.

This also goes for defines, fkags etc.


I'll go ahead and get this committed and then address the strings issue 
in another patch.



Thanks!


Kinsey

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

Re: [rtems commit] spec/librtemscpu: Fix installed headers

2022-08-30 Thread Sebastian Huber 

On 22/08/2022 01:30, Chris Johns wrote:

- keyimpl.h is not referenced and so not needed


We install all the *impl.h header files. Why should keyimpl.h be an 
exception?


--
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: New Defects reported by Coverity Scan for RTEMS

2022-08-30 Thread Joel Sherrill 
On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/08/2022 00:56, scan-ad...@coverity.com wrote:
> > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)
> > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
> >
> >
> >
> 
> > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)
> > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
> > 1798  /* Go live with the new struct timehands. */
> > 1799 #ifdef FFCLOCK
> > 1800  switch (sysclock_active) {
> > 1801  case SYSCLOCK_FBCK:
> > 1802 #endif
> > 1803  time_second = th->th_microtime.tv_sec;
>   CID 1512552:  High impact quality  (Y2K38_SAFETY)
>   A "time_t" value is stored in an integer with too few bits to
> accommodate it.  The expression "th->th_offset.sec" is cast to "int32_t".
> > 1804  time_uptime = th->th_offset.sec;
> > 1805 #ifdef FFCLOCK
> > 1806  break;
> > 1807  case SYSCLOCK_FFWD:
> > 1808  time_second = fftimehands->tick_time_lerp.sec;
> > 1809  time_uptime = fftimehands->tick_time_lerp.sec -
> ffclock_boottime.sec;
> >
> > ** CID 1512551:(Y2K38_SAFETY)
>
> This seems to be a new Coverity feature. The Newlib time_t definition is:
>
> #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffL
> #define _TIME_T_ long
> #else
> #define _TIME_T_ __int_least64_t
> #endif
> typedef _TIME_T___time_t;
>
> Does Coverity use the Newlib header files? The _USE_LONG_TIME_T should
> be undefined for RTEMS.
>

Yes it should. It works by doing something like this:

cov-build waf|make

And looking at the newlib headers, I agree everything looks like it should
be defined to _int_least64_t. And preprocessing a simple file that includes
 shows that it is typed to that.

But something else is going on. time_uptime is defined to
_Timecounter_Time_uptime
which is an int32_t.

$ grep -r _Timecounter_Time_uptime cpukit/
cpukit/include/rtems/score/timecounter.h:extern volatile int32_t
_Timecounter_Time_uptime;
cpukit/include/machine/_kernel_time.h:#define   time_uptime
_Timecounter_Time_uptime
cpukit/include/machine/_timecounter.h:extern volatile int32_t
_Timecounter_Time_uptime;
cpukit/rtems/src/clockgetuptimeseconds.c:  return _Timecounter_Time_uptime
- 1;
cpukit/score/src/kern_tc.c: *  ::_Timecounter, ::_Timecounter_Time_second,
and ::_Timecounter_Time_uptime
cpukit/score/src/kern_tc.c:#define  time_uptime _Timecounter_Time_uptime
cpukit/score/src/kern_ntptime.c:#define time_uptime _Timecounter_Time_uptime

The declaration in kern_tc.c doesn't align with the prototype in
_timecounter.h
once the macro redefinition is taken into account.

I'm surprised that gcc isn't generating a warning of some type for the
mismatch.

--joel


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

Re: New Defects reported by Coverity Scan for RTEMS

2022-08-30 Thread Sebastian Huber 

On 30/08/2022 15:40, Joel Sherrill wrote:



On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber 
> wrote:


On 30/08/2022 00:56, scan-ad...@coverity.com
 wrote:
 > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)
 > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
 >
 >
 >


 > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)
 > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
 > 1798          /* Go live with the new struct timehands. */
 > 1799     #ifdef FFCLOCK
 > 1800          switch (sysclock_active) {
 > 1801          case SYSCLOCK_FBCK:
 > 1802     #endif
 > 1803                  time_second = th->th_microtime.tv_sec;
       CID 1512552:  High impact quality  (Y2K38_SAFETY)
       A "time_t" value is stored in an integer with too few
bits to accommodate it.  The expression "th->th_offset.sec" is cast
to "int32_t".
 > 1804                  time_uptime = th->th_offset.sec;
 > 1805     #ifdef FFCLOCK
 > 1806                  break;
 > 1807          case SYSCLOCK_FFWD:
 > 1808                  time_second = fftimehands->tick_time_lerp.sec;
 > 1809                  time_uptime =
fftimehands->tick_time_lerp.sec - ffclock_boottime.sec;
 >
 > ** CID 1512551:    (Y2K38_SAFETY)

This seems to be a new Coverity feature. The Newlib time_t
definition is:

#if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffL
#define _TIME_T_ long
#else
#define _TIME_T_ __int_least64_t
#endif
typedef _TIME_T_        __time_t;

Does Coverity use the Newlib header files? The _USE_LONG_TIME_T should
be undefined for RTEMS.


Yes it should. It works by doing something like this:

cov-build waf|make

And looking at the newlib headers, I agree everything looks like it should
be defined to _int_least64_t. And preprocessing a simple file that includes
 shows that it is typed to that.

But something else is going on. time_uptime is defined to 
_Timecounter_Time_uptime

which is an int32_t.


Oh, sorry, I didn't notice this. Then this is a false positive. Using an 
int32_t for uptime seconds is enough.


--
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: New Defects reported by Coverity Scan for RTEMS

2022-08-30 Thread Joel Sherrill 
On Tue, Aug 30, 2022 at 8:44 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/08/2022 15:40, Joel Sherrill wrote:
> >
> >
> > On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber
> >  > > wrote:
> >
> > On 30/08/2022 00:56, scan-ad...@coverity.com
> >  wrote:
> >  > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)
> >  > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
> >  >
> >  >
> >  >
> >
>  
> 
> >  > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)
> >  > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
> >  > 1798  /* Go live with the new struct timehands. */
> >  > 1799 #ifdef FFCLOCK
> >  > 1800  switch (sysclock_active) {
> >  > 1801  case SYSCLOCK_FBCK:
> >  > 1802 #endif
> >  > 1803  time_second = th->th_microtime.tv_sec;
> >    CID 1512552:  High impact quality  (Y2K38_SAFETY)
> >    A "time_t" value is stored in an integer with too few
> > bits to accommodate it.  The expression "th->th_offset.sec" is cast
> > to "int32_t".
> >  > 1804  time_uptime = th->th_offset.sec;
> >  > 1805 #ifdef FFCLOCK
> >  > 1806  break;
> >  > 1807  case SYSCLOCK_FFWD:
> >  > 1808  time_second =
> fftimehands->tick_time_lerp.sec;
> >  > 1809  time_uptime =
> > fftimehands->tick_time_lerp.sec - ffclock_boottime.sec;
> >  >
> >  > ** CID 1512551:(Y2K38_SAFETY)
> >
> > This seems to be a new Coverity feature. The Newlib time_t
> > definition is:
> >
> > #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffL
> > #define _TIME_T_ long
> > #else
> > #define _TIME_T_ __int_least64_t
> > #endif
> > typedef _TIME_T___time_t;
> >
> > Does Coverity use the Newlib header files? The _USE_LONG_TIME_T
> should
> > be undefined for RTEMS.
> >
> >
> > Yes it should. It works by doing something like this:
> >
> > cov-build waf|make
> >
> > And looking at the newlib headers, I agree everything looks like it
> should
> > be defined to _int_least64_t. And preprocessing a simple file that
> includes
> >  shows that it is typed to that.
> >
> > But something else is going on. time_uptime is defined to
> > _Timecounter_Time_uptime
> > which is an int32_t.
>
> Oh, sorry, I didn't notice this. Then this is a false positive. Using an
> int32_t for uptime seconds is enough.
>

The variable  time_uptime is still defined as two separate types. The
prototype and the declaration do not match.

Even if int32_t is wide enough for seconds of uptime, it is an assignment
that narrows types. Casting to make this narrowing intentional would at
least hint this was intentional.

But better would be to use the proper type and just make it time_t like
FreeBSD.

--joel

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

Re: [PATCH] Fix pedanic warnings without a storage increase

2022-08-30 Thread Joel Sherrill 
On Tue, Aug 30, 2022 at 1:10 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Use RTEMS_ZERO_LENGTH_ARRAY for flexible array member.
>
> Update #4662.
> ---
>  cpukit/include/rtems/confdefs/scheduler.h  | 10 ++
>  cpukit/include/rtems/score/schedulerpriority.h |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/include/rtems/confdefs/scheduler.h
> b/cpukit/include/rtems/confdefs/scheduler.h
> index 84ca810fd7..8ac943921f 100644
> --- a/cpukit/include/rtems/confdefs/scheduler.h
> +++ b/cpukit/include/rtems/confdefs/scheduler.h
> @@ -234,7 +234,17 @@ extern "C" {
>  #endif
>
>  #ifdef CONFIGURE_SCHEDULER
> +  /*
> +   * Ignore these warnings:
> +   *
> +   * - invalid use of structure with flexible array member
> +   *
> +   * - struct has no members
> +   */
> +  #pragma GCC diagnostic push
> +  #pragma GCC diagnostic ignored "-Wpedantic"
>

This is heavy handed. -Warray-bounds should be enough.


>CONFIGURE_SCHEDULER;
> +  #pragma GCC diagnostic pop
>  #endif
>
>  const Scheduler_Control _Scheduler_Table[] = {
> diff --git a/cpukit/include/rtems/score/schedulerpriority.h
> b/cpukit/include/rtems/score/schedulerpriority.h
> index e485e97c60..1325224fa9 100644
> --- a/cpukit/include/rtems/score/schedulerpriority.h
> +++ b/cpukit/include/rtems/score/schedulerpriority.h
> @@ -94,7 +94,7 @@ typedef struct {
>/**
> * @brief One ready queue per priority level.
> */
> -  Chain_Control Ready[ 1 ];
> +  Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
>  } Scheduler_priority_Context;
>
>  /**
> --
> 2.35.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] Fix pedanic warnings without a storage increase

2022-08-30 Thread Sebastian Huber 

On 30/08/2022 16:38, Joel Sherrill wrote:

+  /*
+   * Ignore these warnings:
+   *
+   * - invalid use of structure with flexible array member
+   *
+   * - struct has no members
+   */
+  #pragma GCC diagnostic push
+  #pragma GCC diagnostic ignored "-Wpedantic"


This is heavy handed. -Warray-bounds should be enough.


There is no array bounds warning. There are only the above two 
-Wpedantic warnings.


--
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: New Defects reported by Coverity Scan for RTEMS

2022-08-30 Thread Sebastian Huber 



On 30/08/2022 16:37, Joel Sherrill wrote:


On Tue, Aug 30, 2022 at 8:44 AM Sebastian Huber 
> wrote:


On 30/08/2022 15:40, Joel Sherrill wrote:
 >
 >
 > On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 30/08/2022 00:56, scan-ad...@coverity.com

 >     > wrote:
 >      > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)
 >      > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
 >      >
 >      >
 >      >
 >   
  

 >      > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)
 >      > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
 >      > 1798          /* Go live with the new struct timehands. */
 >      > 1799     #ifdef FFCLOCK
 >      > 1800          switch (sysclock_active) {
 >      > 1801          case SYSCLOCK_FBCK:
 >      > 1802     #endif
 >      > 1803                  time_second = th->th_microtime.tv_sec;
 >            CID 1512552:  High impact quality  (Y2K38_SAFETY)
 >            A "time_t" value is stored in an integer with too few
 >     bits to accommodate it.  The expression "th->th_offset.sec"
is cast
 >     to "int32_t".
 >      > 1804                  time_uptime = th->th_offset.sec;
 >      > 1805     #ifdef FFCLOCK
 >      > 1806                  break;
 >      > 1807          case SYSCLOCK_FFWD:
 >      > 1808                  time_second =
fftimehands->tick_time_lerp.sec;
 >      > 1809                  time_uptime =
 >     fftimehands->tick_time_lerp.sec - ffclock_boottime.sec;
 >      >
 >      > ** CID 1512551:    (Y2K38_SAFETY)
 >
 >     This seems to be a new Coverity feature. The Newlib time_t
 >     definition is:
 >
 >     #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffL
 >     #define _TIME_T_ long
 >     #else
 >     #define _TIME_T_ __int_least64_t
 >     #endif
 >     typedef _TIME_T_        __time_t;
 >
 >     Does Coverity use the Newlib header files? The
_USE_LONG_TIME_T should
 >     be undefined for RTEMS.
 >
 >
 > Yes it should. It works by doing something like this:
 >
 > cov-build waf|make
 >
 > And looking at the newlib headers, I agree everything looks like
it should
 > be defined to _int_least64_t. And preprocessing a simple file
that includes
 >  shows that it is typed to that.
 >
 > But something else is going on. time_uptime is defined to
 > _Timecounter_Time_uptime
 > which is an int32_t.

Oh, sorry, I didn't notice this. Then this is a false positive.
Using an
int32_t for uptime seconds is enough.


The variable  time_uptime is still defined as two separate types. The
prototype and the declaration do not match.


I think this is all right:

#ifndef __rtems__
volatile time_t time_second = 1;
volatile time_t time_uptime = 1;
#else /* __rtems__ */
volatile time_t time_second = TOD_SECONDS_1970_THROUGH_1988;
volatile int32_t time_uptime = 1;
#endif /* __rtems__ */



Even if int32_t is wide enough for seconds of uptime, it is an assignment
that narrows types. Casting to make this narrowing intentional would at
least hint this was intentional.


From looking at the other Y2K38_SAFETY reports, a cast probably doesn't 
help to get rid of it.




But better would be to use the proper type and just make it time_t like
FreeBSD.


The time_uptime is used in the libbsd. This is a performance optimization.

There is also an unsolved issue with the time_second. On 32-bit targets 
you can't reliably read this value.


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

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

[PATCH rtems-lwip] lwip.py: Track includes as lists

2022-08-30 Thread Kinsey Moore 
The original work for rtems-lwip tracked include directories as raw
strings to be passed into the build infrastructure. This reformulates
include directory management as lists to reduce errors in future
changes.
---
 lwip.py | 130 +---
 1 file changed, 78 insertions(+), 52 deletions(-)

diff --git a/lwip.py b/lwip.py
index 2e12957..84eef2c 100644
--- a/lwip.py
+++ b/lwip.py
@@ -36,52 +36,67 @@ def removeprefix(data, prefix):
 return data
 
 
-xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/'
-
-xilinx_drv_incl = ''
-xilinx_drv_incl += xilinx_lwip_prefix + 'src/contrib/ports/xilinx/include '
-xilinx_drv_incl += 'embeddedsw/lib/bsp/standalone/src/common '
-xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
-xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
-xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
-xilinx_drv_incl += 'rtemslwip/xilinx '
-
-xilinx_aarch64_drv_incl = ''
-xilinx_aarch64_drv_incl += 'rtemslwip/zynqmp '
-xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
-xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common/gcc '
-xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common '
+xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/'
+xilinx_standalone_prefix = 'embeddedsw/lib/bsp/standalone/src/'
+
+xilinx_drv_incl = [
+xilinx_lwip_prefix + 'ports/xilinx/include',
+xilinx_standalone_prefix + 'common',
+'embeddedsw/XilinxProcessorIPLib/drivers/common/src/',
+'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src',
+'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src',
+'rtemslwip/xilinx'
+]
+
+xilinx_aarch64_drv_incl = [
+'rtemslwip/zynqmp',
+xilinx_standalone_prefix + 'arm/ARMv8/64bit',
+xilinx_standalone_prefix + 'arm/common/gcc',
+xilinx_standalone_prefix + 'arm/common'
+]
 
 # These sources are explicitly listed instead of using walk_sources below
 # because multiple BSPs of varying architecture are expected to use code from
 # the embeddedsw repository.
 xilinx_aarch64_driver_source = [
-xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xadapter.c',
-xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xpqueue.c',
-xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif.c',
-xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_dma.c',
-xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
-xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
+xilinx_lwip_prefix + 'ports/xilinx/netif/xadapter.c',
+xilinx_lwip_prefix + 'ports/xilinx/netif/xpqueue.c',
+xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif.c',
+xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif_dma.c',
+xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif_hw.c',
+xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif_physpeed.c',
 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
-'embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
+xilinx_standalone_prefix + 'common/xil_assert.c'
+]
+
+common_includes = [
+'lwip/src/include',
+'uLan/ports/os/rtems',
+'rtemslwip/include'
+]
+
+bsd_compat_incl = [
+'rtemslwip/bsd_compat_include'
+]
+
+common_source_files = [
+'uLan/ports/os/rtems/arch/sys_arch.c',
+'rtemslwip/common/syslog.c',
+'rtemslwip/common/rtems_lwip_io.c',
+'rtemslwip/common/network_compat.c',
+'rtemslwip/bsd_compat/netdb.c',
+'rtemslwip/bsd_compat/ifaddrs.c',
+'rtemslwip/bsd_compat/rtems-kernel-program.c'
 ]
 
 
 def build(bld):
 source_files = []
-common_includes = 'lwip/src/include uLan/ports/os/rtems rtemslwip/include '
 driver_source = []
-drv_incl = ' '
-bsd_compat_sources = [
-"rtemslwip/bsd_compat/netdb.c",
-"rtemslwip/bsd_compat/ifaddrs.c",
-"rtemslwip/bsd_compat/rtems-kernel-program.c"
-]
-bsd_compat_incl = 'rtemslwip/bsd_compat_include '
-
+drv_incl = []
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
 with open('file-import.json', 'r') as cf:
@@ -90,11 +105,7 @@ def build(bld):
 if f[-2:] == '.c':
 source_files.append(os.path.join('lwip', f))
 
-source_files.append('uLan/ports/os/rtems/arch/sys_arch.c')
-source_files.append('rtemslwip/common/syslog.c')
-source_files.append('rtemslwip/common/rtems_lwip_io.c')
-source_files.append('rtemslwip/common/network_compat.c')
-source_files.extend(bsd_compat_sources)
+source_files.extend(common_source_files)
 
 def wa

Re: [PATCH] Fix pedanic warnings without a storage increase

2022-08-30 Thread Joel Sherrill 
On Tue, Aug 30, 2022 at 9:40 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/08/2022 16:38, Joel Sherrill wrote:
> > +  /*
> > +   * Ignore these warnings:
> > +   *
> > +   * - invalid use of structure with flexible array member
> > +   *
> > +   * - struct has no members
> > +   */
> > +  #pragma GCC diagnostic push
> > +  #pragma GCC diagnostic ignored "-Wpedantic"
> >
> >
> > This is heavy handed. -Warray-bounds should be enough.
>
> There is no array bounds warning. There are only the above two
> -Wpedantic warnings.
>

OK I was suggesting that because -Wzero-length-bounds which should be
the precise warning was turned on by -Warray-bounds.

How about just -Wzero-length-bounds?

-Wzero-length-bounds

Warn about accesses to elements of zero-length array members that might
overlap other members of the same object. Declaring interior zero-length
arrays is discouraged because accesses to them are undefined. See See Zero
Length

.

For example, the first two stores in function bad are diagnosed because the
array elements overlap the subsequent members b and c. The third store is
diagnosed by -Warray-bounds because it is beyond the bounds of the
enclosing object.

struct X { int a[0]; int b, c; };
struct X x;

void bad (void)
{
  x.a[0] = 0;   // -Wzero-length-bounds
  x.a[1] = 1;   // -Wzero-length-bounds
  x.a[2] = 2;   // -Warray-bounds
}

Option -Wzero-length-bounds is enabled by -Warray-bounds.


>
> --
> 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: New Defects reported by Coverity Scan for RTEMS

2022-08-30 Thread Joel Sherrill 
On Tue, Aug 30, 2022 at 9:53 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 30/08/2022 16:37, Joel Sherrill wrote:
> >
> > On Tue, Aug 30, 2022 at 8:44 AM Sebastian Huber
> >  > > wrote:
> >
> > On 30/08/2022 15:40, Joel Sherrill wrote:
> >  >
> >  >
> >  > On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > On 30/08/2022 00:56, scan-ad...@coverity.com
> > 
> >  >  > > wrote:
> >  >  > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)
> >  >  > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
> >  >  >
> >  >  >
> >  >  >
> >  >
> >
>  
> 
> >  >  > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)
> >  >  > /cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
> >  >  > 1798  /* Go live with the new struct timehands. */
> >  >  > 1799 #ifdef FFCLOCK
> >  >  > 1800  switch (sysclock_active) {
> >  >  > 1801  case SYSCLOCK_FBCK:
> >  >  > 1802 #endif
> >  >  > 1803  time_second =
> th->th_microtime.tv_sec;
> >  >    CID 1512552:  High impact quality  (Y2K38_SAFETY)
> >  >    A "time_t" value is stored in an integer with too
> few
> >  > bits to accommodate it.  The expression "th->th_offset.sec"
> > is cast
> >  > to "int32_t".
> >  >  > 1804  time_uptime = th->th_offset.sec;
> >  >  > 1805 #ifdef FFCLOCK
> >  >  > 1806  break;
> >  >  > 1807  case SYSCLOCK_FFWD:
> >  >  > 1808  time_second =
> > fftimehands->tick_time_lerp.sec;
> >  >  > 1809  time_uptime =
> >  > fftimehands->tick_time_lerp.sec - ffclock_boottime.sec;
> >  >  >
> >  >  > ** CID 1512551:(Y2K38_SAFETY)
> >  >
> >  > This seems to be a new Coverity feature. The Newlib time_t
> >  > definition is:
> >  >
> >  > #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffL
> >  > #define _TIME_T_ long
> >  > #else
> >  > #define _TIME_T_ __int_least64_t
> >  > #endif
> >  > typedef _TIME_T___time_t;
> >  >
> >  > Does Coverity use the Newlib header files? The
> > _USE_LONG_TIME_T should
> >  > be undefined for RTEMS.
> >  >
> >  >
> >  > Yes it should. It works by doing something like this:
> >  >
> >  > cov-build waf|make
> >  >
> >  > And looking at the newlib headers, I agree everything looks like
> > it should
> >  > be defined to _int_least64_t. And preprocessing a simple file
> > that includes
> >  >  shows that it is typed to that.
> >  >
> >  > But something else is going on. time_uptime is defined to
> >  > _Timecounter_Time_uptime
> >  > which is an int32_t.
> >
> > Oh, sorry, I didn't notice this. Then this is a false positive.
> > Using an
> > int32_t for uptime seconds is enough.
> >
> >
> > The variable  time_uptime is still defined as two separate types. The
> > prototype and the declaration do not match.
>
> I think this is all right:
>
> #ifndef __rtems__
> volatile time_t time_second = 1;
> volatile time_t time_uptime = 1;
> #else /* __rtems__ */
> volatile time_t time_second = TOD_SECONDS_1970_THROUGH_1988;
> volatile int32_t time_uptime = 1;
> #endif /* __rtems__ */
>
> >
> > Even if int32_t is wide enough for seconds of uptime, it is an assignment
> > that narrows types. Casting to make this narrowing intentional would at
> > least hint this was intentional.
>
>  From looking at the other Y2K38_SAFETY reports, a cast probably doesn't
> help to get rid of it.
>
> >
> > But better would be to use the proper type and just make it time_t like
> > FreeBSD.
>
> The time_uptime is used in the libbsd. This is a performance optimization.
>

And the declaration you show is mismatched because of these:

cpukit/include/machine/_kernel_time.h:#define   time_uptime
_Timecounter_Time_uptime
cpukit/include/rtems/score/timecounter.h:extern volatile int32_t
_Timecounter_Time_uptime;

This is inconsistent with the declaration of time_uptime above.


>
> There is also an unsolved issue with the time_second. On 32-bit targets
> you can't reliably read this value.
>

I assume you mean because it will take two accesses?

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Pu

Re: [rtems commit] spec/librtemscpu: Fix installed headers

2022-08-30 Thread Joel Sherrill 
On Tue, Aug 30, 2022 at 8:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 22/08/2022 01:30, Chris Johns wrote:
> > - keyimpl.h is not referenced and so not needed
>
> We install all the *impl.h header files. Why should keyimpl.h be an
> exception?
>

I'd lean to installing all of them for consistency.

I have written introspection code for applications which lived external to
rtems itself. it needed to peek inside.

>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Defects reported by Coverity Scan for RTEMS

2022-08-30 Thread Sebastian Huber 



On 30/08/2022 19:48, Joel Sherrill wrote:



On Tue, Aug 30, 2022 at 9:53 AM Sebastian Huber 
> wrote:




On 30/08/2022 16:37, Joel Sherrill wrote:
 >
 > On Tue, Aug 30, 2022 at 8:44 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 30/08/2022 15:40, Joel Sherrill wrote:
 >      >
 >      >
 >      > On Tue, Aug 30, 2022 at 12:05 AM Sebastian Huber
 >      > mailto:sebastian.hu...@embedded-brains.de>
 >     >
 >      > 
 >           >
 >      >     On 30/08/2022 00:56, scan-ad...@coverity.com

 >     >
 >      >     
 >     >> wrote:
 >      >      > ** CID 1512552:  High impact quality  (Y2K38_SAFETY)
 >      >      > /cpukit/score/src/kern_tc.c: 1804 in
_Timecounter_Windup()
 >      >      >
 >      >      >
 >      >      >
 >      >
 > 
  

 >      >      > *** CID 1512552:  High impact quality  (Y2K38_SAFETY)
 >      >      > /cpukit/score/src/kern_tc.c: 1804 in
_Timecounter_Windup()
 >      >      > 1798          /* Go live with the new struct
timehands. */
 >      >      > 1799     #ifdef FFCLOCK
 >      >      > 1800          switch (sysclock_active) {
 >      >      > 1801          case SYSCLOCK_FBCK:
 >      >      > 1802     #endif
 >      >      > 1803                  time_second =
th->th_microtime.tv_sec;
 >      >            CID 1512552:  High impact quality 
(Y2K38_SAFETY)

 >      >            A "time_t" value is stored in an integer
with too few
 >      >     bits to accommodate it.  The expression
"th->th_offset.sec"
 >     is cast
 >      >     to "int32_t".
 >      >      > 1804                  time_uptime = th->th_offset.sec;
 >      >      > 1805     #ifdef FFCLOCK
 >      >      > 1806                  break;
 >      >      > 1807          case SYSCLOCK_FFWD:
 >      >      > 1808                  time_second =
 >     fftimehands->tick_time_lerp.sec;
 >      >      > 1809                  time_uptime =
 >      >     fftimehands->tick_time_lerp.sec - ffclock_boottime.sec;
 >      >      >
 >      >      > ** CID 1512551:    (Y2K38_SAFETY)
 >      >
 >      >     This seems to be a new Coverity feature. The Newlib time_t
 >      >     definition is:
 >      >
 >      >     #if defined(_USE_LONG_TIME_T) || __LONG_MAX__ >
0x7fffL
 >      >     #define _TIME_T_ long
 >      >     #else
 >      >     #define _TIME_T_ __int_least64_t
 >      >     #endif
 >      >     typedef _TIME_T_        __time_t;
 >      >
 >      >     Does Coverity use the Newlib header files? The
 >     _USE_LONG_TIME_T should
 >      >     be undefined for RTEMS.
 >      >
 >      >
 >      > Yes it should. It works by doing something like this:
 >      >
 >      > cov-build waf|make
 >      >
 >      > And looking at the newlib headers, I agree everything
looks like
 >     it should
 >      > be defined to _int_least64_t. And preprocessing a simple file
 >     that includes
 >      >  shows that it is typed to that.
 >      >
 >      > But something else is going on. time_uptime is defined to
 >      > _Timecounter_Time_uptime
 >      > which is an int32_t.
 >
 >     Oh, sorry, I didn't notice this. Then this is a false positive.
 >     Using an
 >     int32_t for uptime seconds is enough.
 >
 >
 > The variable  time_uptime is still defined as two separate types. The
 > prototype and the declaration do not match.

I think this is all right:

#ifndef __rtems__
volatile time_t time_second = 1;
volatile time_t time_uptime = 1;
#else /* __rtems__ */
volatile time_t time_second = TOD_SECONDS_1970_THROUGH_1988;
volatile int32_t time_uptime = 1;
#endif /* __rtems__ */

 >
 > Even if int32_t is wide enough for seconds of uptime, it is an
assignment
 > that narrows types. Casting to make this narrowing intentional
would at
 > least hint this was intentional.

  From looking at the

Re: [rtems commit] spec/librtemscpu: Fix installed headers

2022-08-30 Thread Sebastian Huber 

On 30/08/2022 19:55, Joel Sherrill wrote:
On Tue, Aug 30, 2022 at 8:12 AM Sebastian Huber 
> wrote:


On 22/08/2022 01:30, Chris Johns wrote:
 > - keyimpl.h is not referenced and so not needed

We install all the *impl.h header files. Why should keyimpl.h be an
exception?


I'd lean to installing all of them for consistency.

I have written introspection code for applications which lived external to
rtems itself. it needed to peek inside.


Yes, I found it occasionally helpful to have all the header files 
installed. For example to write diagnostic and debug code for a 
particular issue.


--
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] Fix pedanic warnings without a storage increase

2022-08-30 Thread Sebastian Huber 

On 30/08/2022 19:45, Joel Sherrill wrote:



On Tue, Aug 30, 2022 at 9:40 AM Sebastian Huber 
> wrote:


On 30/08/2022 16:38, Joel Sherrill wrote:
 >     +  /*
 >     +   * Ignore these warnings:
 >     +   *
 >     +   * - invalid use of structure with flexible array member
 >     +   *
 >     +   * - struct has no members
 >     +   */
 >     +  #pragma GCC diagnostic push
 >     +  #pragma GCC diagnostic ignored "-Wpedantic"
 >
 >
 > This is heavy handed. -Warray-bounds should be enough.

There is no array bounds warning. There are only the above two
-Wpedantic warnings.


OK I was suggesting that because -Wzero-length-bounds which should be
the precise warning was turned on by -Warray-bounds.

How about just -Wzero-length-bounds?


The patch changes Ready to a flexible array member, so the 
-Wzero-length-bounds should not be applicable.


--
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 v5 1/1] bsp/riscv: Add NOEL-V BSP

2022-08-30 Thread Sebastian Huber 

On 25/08/2022 10:33, Daniel Cederman wrote:

+#define BSP_INTERRUPT_VECTOR_MIN 0
+
+#define BSP_INTERRUPT_VECTOR_MAX 
RISCV_INTERRUPT_VECTOR_EXTERNAL(RISCV_MAXIMUM_EXTERNAL_INTERRUPTS - 1)


I am a bit surprised that this worked, since the API changed. The BSP 
should define


#define BSP_INTERRUPT_VECTOR_COUNT 
RISCV_INTERRUPT_VECTOR_EXTERNAL(RISCV_MAXIMUM_EXTERNAL_INTERRUPTS


Did you rebase your patch set to the current master and test it?

--
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 v5 0/1] NOEL-V BSP

2022-08-30 Thread Joel Sherrill 
I think it's OK to push after this long.

Also be sure to add some to the RTEMS Users Guide for this BSP.

Does this work on any simulator?

--joel

On Tue, Aug 30, 2022 at 6:39 AM Daniel Cederman 
wrote:

> Hi,
>
> Is it OK to push this or should I wait for additional comments?
>
> On 2022-08-25 10:33, Daniel Cederman wrote:
>
> v5
> Made RISCV_CONSOLE_MAX_APBUART_DEVICES an option
> bsp_fatal if no uart clock frequency is found
> Changed CONSOLE_USE_INTERRUPTS to BSP_CONSOLE_USE_INTERRUPTS
> Added error codes for APBUART
> Get work area size from /memory node
>
> Martin Aberg (1):
>   bsp/riscv: Add NOEL-V BSP
>
>  bsps/include/bsp/fatal.h  |   3 +
>  bsps/riscv/noel/console/console-config.c  | 208 ++
>  bsps/riscv/noel/include/bsp.h |  76 +++
>  bsps/riscv/noel/include/bsp/irq.h |  75 +++
>  bsps/riscv/noel/include/tm27.h|   1 +
>  bsps/riscv/noel/start/bsp_fatal_halt.c|  46 
>  bsps/riscv/riscv/include/bsp.h|   2 +
>  bsps/riscv/riscv/include/bsp/irq.h|   2 +
>  spec/build/bsps/riscv/noel/abi.yml|  48 
>  spec/build/bsps/riscv/noel/bspnoel32im.yml|  19 ++
>  spec/build/bsps/riscv/noel/bspnoel32imafd.yml |  19 ++
>  spec/build/bsps/riscv/noel/bspnoel64imac.yml  |  19 ++
>  spec/build/bsps/riscv/noel/bspnoel64imafd.yml |  19 ++
>  .../build/bsps/riscv/noel/bspnoel64imafdc.yml |  19 ++
>  spec/build/bsps/riscv/noel/grp.yml|  61 +
>  spec/build/bsps/riscv/noel/obj.yml|  38 
>  spec/build/bsps/riscv/noel/objsmp.yml |  15 ++
>  spec/build/bsps/riscv/noel/optapbuartmax.yml  |  16 ++
>  spec/build/bsps/riscv/optrambegin.yml |   3 +
>  spec/build/cpukit/optarchbits.yml |   2 +
>  spec/build/cpukit/optsmp.yml  |   4 +
>  21 files changed, 695 insertions(+)
>  create mode 100644 bsps/riscv/noel/console/console-config.c
>  create mode 100644 bsps/riscv/noel/include/bsp.h
>  create mode 100644 bsps/riscv/noel/include/bsp/irq.h
>  create mode 100644 bsps/riscv/noel/include/tm27.h
>  create mode 100644 bsps/riscv/noel/start/bsp_fatal_halt.c
>  create mode 100644 spec/build/bsps/riscv/noel/abi.yml
>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel32im.yml
>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel32imafd.yml
>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imac.yml
>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafd.yml
>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml
>  create mode 100644 spec/build/bsps/riscv/noel/grp.yml
>  create mode 100644 spec/build/bsps/riscv/noel/obj.yml
>  create mode 100644 spec/build/bsps/riscv/noel/objsmp.yml
>  create mode 100644 spec/build/bsps/riscv/noel/optapbuartmax.yml
>
>
> ___
> 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 v5 0/1] NOEL-V BSP

2022-08-30 Thread Joel Sherrill 
And then Sebastian replies while I was typing that.

Address his concerns. :)

On Tue, Aug 30, 2022 at 2:10 PM Joel Sherrill  wrote:

> I think it's OK to push after this long.
>
> Also be sure to add some to the RTEMS Users Guide for this BSP.
>
> Does this work on any simulator?
>
> --joel
>
> On Tue, Aug 30, 2022 at 6:39 AM Daniel Cederman 
> wrote:
>
>> Hi,
>>
>> Is it OK to push this or should I wait for additional comments?
>>
>> On 2022-08-25 10:33, Daniel Cederman wrote:
>>
>> v5
>> Made RISCV_CONSOLE_MAX_APBUART_DEVICES an option
>> bsp_fatal if no uart clock frequency is found
>> Changed CONSOLE_USE_INTERRUPTS to BSP_CONSOLE_USE_INTERRUPTS
>> Added error codes for APBUART
>> Get work area size from /memory node
>>
>> Martin Aberg (1):
>>   bsp/riscv: Add NOEL-V BSP
>>
>>  bsps/include/bsp/fatal.h  |   3 +
>>  bsps/riscv/noel/console/console-config.c  | 208 ++
>>  bsps/riscv/noel/include/bsp.h |  76 +++
>>  bsps/riscv/noel/include/bsp/irq.h |  75 +++
>>  bsps/riscv/noel/include/tm27.h|   1 +
>>  bsps/riscv/noel/start/bsp_fatal_halt.c|  46 
>>  bsps/riscv/riscv/include/bsp.h|   2 +
>>  bsps/riscv/riscv/include/bsp/irq.h|   2 +
>>  spec/build/bsps/riscv/noel/abi.yml|  48 
>>  spec/build/bsps/riscv/noel/bspnoel32im.yml|  19 ++
>>  spec/build/bsps/riscv/noel/bspnoel32imafd.yml |  19 ++
>>  spec/build/bsps/riscv/noel/bspnoel64imac.yml  |  19 ++
>>  spec/build/bsps/riscv/noel/bspnoel64imafd.yml |  19 ++
>>  .../build/bsps/riscv/noel/bspnoel64imafdc.yml |  19 ++
>>  spec/build/bsps/riscv/noel/grp.yml|  61 +
>>  spec/build/bsps/riscv/noel/obj.yml|  38 
>>  spec/build/bsps/riscv/noel/objsmp.yml |  15 ++
>>  spec/build/bsps/riscv/noel/optapbuartmax.yml  |  16 ++
>>  spec/build/bsps/riscv/optrambegin.yml |   3 +
>>  spec/build/cpukit/optarchbits.yml |   2 +
>>  spec/build/cpukit/optsmp.yml  |   4 +
>>  21 files changed, 695 insertions(+)
>>  create mode 100644 bsps/riscv/noel/console/console-config.c
>>  create mode 100644 bsps/riscv/noel/include/bsp.h
>>  create mode 100644 bsps/riscv/noel/include/bsp/irq.h
>>  create mode 100644 bsps/riscv/noel/include/tm27.h
>>  create mode 100644 bsps/riscv/noel/start/bsp_fatal_halt.c
>>  create mode 100644 spec/build/bsps/riscv/noel/abi.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel32im.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel32imafd.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imac.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafd.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/bspnoel64imafdc.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/grp.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/obj.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/objsmp.yml
>>  create mode 100644 spec/build/bsps/riscv/noel/optapbuartmax.yml
>>
>>
>> ___
>> 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

rtems-central appears to be out of sync with rtems and rtems-docs

2022-08-30 Thread Joel Sherrill 
Hi

When I am on master of rtems-central.git and sub spec2modules.py, it
generates updates to rtems-docs and rtems. My understanding is that if they
were in sync, there would be no changes in rtems-docs and rtems.

(env) [joel@localhost rtems-central]$ ./spec2modules.py
(env) [joel@localhost rtems-central]$ cd modules/rtems-docs/
(env) [joel@localhost rtems-docs]$ git st
# HEAD detached at 657f744
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working
directory)
#
#   modified:   c-user/config/device-driver.rst
#   modified:   c-user/config/general.rst
#   modified:   c-user/config/idle-task.rst
#   modified:   c-user/glossary.rst
#   modified:   eng/req/items.rst

Thanks.

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

Re: [PATCH rtems-lwip] lwip.py: Address python formatting issues

2022-08-30 Thread Chris Johns 
On 30/8/2022 11:09 pm, Kinsey Moore wrote:
> I'll go ahead and get this committed and then address the strings issue in
> another patch.

Good idea.

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

Re: [PATCH rtems-lwip] lwip.py: Track includes as lists

2022-08-30 Thread Chris Johns 
OK

Thanks
Chris

On 31/8/2022 3:21 am, Kinsey Moore wrote:
> The original work for rtems-lwip tracked include directories as raw
> strings to be passed into the build infrastructure. This reformulates
> include directory management as lists to reduce errors in future
> changes.
> ---
>  lwip.py | 130 +---
>  1 file changed, 78 insertions(+), 52 deletions(-)
> 
> diff --git a/lwip.py b/lwip.py
> index 2e12957..84eef2c 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -36,52 +36,67 @@ def removeprefix(data, prefix):
>  return data
>  
>  
> -xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/'
> -
> -xilinx_drv_incl = ''
> -xilinx_drv_incl += xilinx_lwip_prefix + 'src/contrib/ports/xilinx/include '
> -xilinx_drv_incl += 'embeddedsw/lib/bsp/standalone/src/common '
> -xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
> -xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
> -xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
> -xilinx_drv_incl += 'rtemslwip/xilinx '
> -
> -xilinx_aarch64_drv_incl = ''
> -xilinx_aarch64_drv_incl += 'rtemslwip/zynqmp '
> -xilinx_aarch64_drv_incl += 
> 'embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
> -xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common/gcc 
> '
> -xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common '
> +xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/'
> +xilinx_standalone_prefix = 'embeddedsw/lib/bsp/standalone/src/'
> +
> +xilinx_drv_incl = [
> +xilinx_lwip_prefix + 'ports/xilinx/include',
> +xilinx_standalone_prefix + 'common',
> +'embeddedsw/XilinxProcessorIPLib/drivers/common/src/',
> +'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src',
> +'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src',
> +'rtemslwip/xilinx'
> +]
> +
> +xilinx_aarch64_drv_incl = [
> +'rtemslwip/zynqmp',
> +xilinx_standalone_prefix + 'arm/ARMv8/64bit',
> +xilinx_standalone_prefix + 'arm/common/gcc',
> +xilinx_standalone_prefix + 'arm/common'
> +]
>  
>  # These sources are explicitly listed instead of using walk_sources below
>  # because multiple BSPs of varying architecture are expected to use code from
>  # the embeddedsw repository.
>  xilinx_aarch64_driver_source = [
> -xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xadapter.c',
> -xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xpqueue.c',
> -xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif.c',
> -xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_dma.c',
> -xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
> -xilinx_lwip_prefix + 
> 'src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
> +xilinx_lwip_prefix + 'ports/xilinx/netif/xadapter.c',
> +xilinx_lwip_prefix + 'ports/xilinx/netif/xpqueue.c',
> +xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif.c',
> +xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif_dma.c',
> +xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif_hw.c',
> +xilinx_lwip_prefix + 'ports/xilinx/netif/xemacpsif_physpeed.c',
>  'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
>  'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
>  'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
>  'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
> -'embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
> +xilinx_standalone_prefix + 'common/xil_assert.c'
> +]
> +
> +common_includes = [
> +'lwip/src/include',
> +'uLan/ports/os/rtems',
> +'rtemslwip/include'
> +]
> +
> +bsd_compat_incl = [
> +'rtemslwip/bsd_compat_include'
> +]
> +
> +common_source_files = [
> +'uLan/ports/os/rtems/arch/sys_arch.c',
> +'rtemslwip/common/syslog.c',
> +'rtemslwip/common/rtems_lwip_io.c',
> +'rtemslwip/common/network_compat.c',
> +'rtemslwip/bsd_compat/netdb.c',
> +'rtemslwip/bsd_compat/ifaddrs.c',
> +'rtemslwip/bsd_compat/rtems-kernel-program.c'
>  ]
>  
>  
>  def build(bld):
>  source_files = []
> -common_includes = 'lwip/src/include uLan/ports/os/rtems 
> rtemslwip/include '
>  driver_source = []
> -drv_incl = ' '
> -bsd_compat_sources = [
> -"rtemslwip/bsd_compat/netdb.c",
> -"rtemslwip/bsd_compat/ifaddrs.c",
> -"rtemslwip/bsd_compat/rtems-kernel-program.c"
> -]
> -bsd_compat_incl = 'rtemslwip/bsd_compat_include '
> -
> +drv_incl = []
>  arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>  bld.env.RTEMS_ARCH_BSP)
>  with open('file-import.json', 'r') as cf:
> @@ -90,11 +105,7 @@ def build(bld):
>  if f[-2:] == '.c':
>  source_files.append(os.path.join('lwip', f))
>  
> -source_files.append('uLan/ports/os/r

Re: [rtems commit] spec/librtemscpu: Fix installed headers

2022-08-30 Thread Chris Johns 
On 31/8/2022 4:57 am, Sebastian Huber wrote:
> On 30/08/2022 19:55, Joel Sherrill wrote:
>> On Tue, Aug 30, 2022 at 8:12 AM Sebastian Huber
>> > > wrote:
>>
>>     On 22/08/2022 01:30, Chris Johns wrote:
>>  > - keyimpl.h is not referenced and so not needed
>>
>>     We install all the *impl.h header files. Why should keyimpl.h be an
>>     exception?
>>
>>
>> I'd lean to installing all of them for consistency.
>>
>> I have written introspection code for applications which lived external to
>> rtems itself. it needed to peek inside.
> 
> Yes, I found it occasionally helpful to have all the header files installed. 
> For
> example to write diagnostic and debug code for a particular issue.

I removed it as part of an audit of what failed to compile with C++. Because it
is "internal" it was not directly included so it was removed. I suspect it
failed when included in C++.

I am not sure what happens here. There are valid points for both cases.

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