Re: [PATCH] riscv/console: Updated the console-config.c file

[somesh deshmukh]

On Thu, Apr 29, 2021 at 10:59 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> On Wed, 28 Apr 2021 at 15:23, Somesh Deshmukh
>  wrote:
> >
> > - Parsing the sub-node should be available generic not specific to
> Freedom
> >   Arty310 board. If we remove the Freedom Arty macro now, it will lose
> >   backward compatibility.The proposed change will retain the backward
> >   compatibility and also adds the necessary fix for parsing sub-node.
> >
> > - Line 234 and 235 in riscv_console_probe() uses polled handlers for
> ns16550
> >   read and write while, the console_initialize function uses ns16550
> >   interrupt handler. Proposing a fix to make polled handlers consistant
> >   through out the console-config.c
> > ---
> >  bsps/riscv/riscv/console/console-config.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> > index d962a5a418..f203f0be7d 100644
> > --- a/bsps/riscv/riscv/console/console-config.c
> > +++ b/bsps/riscv/riscv/console/console-config.c
> > @@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt)
> >  stdout_path = "";
> >}
> >
> > -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> > +#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) ||
> (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
> >int root;
> >int soc;
> >root = fdt_path_offset(fdt, "/");
> > @@ -318,7 +318,7 @@ rtems_status_code console_initialize(
> >
> >  rtems_termios_device_install(
> >path,
> > -  _handler_interrupt,
> > +  _handler_polled,
> I would leave the driver interrupt-based as it is. Other than that the
> patch is fine by me.
>
> Thanks Hesham for the review.
One question though, is there any specific reason to use the
ns16550_handler_interrupt?

>NULL,

>>base
> >  );
> > --
> > 2.25.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Vijay Kumar Banerjee]

Hi all,


On Thu, Apr 29, 2021 at 3:01 PM Chris Johns  wrote:
>
> On 30/4/21 5:01 am, Robin Müller wrote:
> > Yes that is the prefix. The rtems.h file is definitely located at the 
> > location
> > in the warning and it works on older commit of rtems_waf (where gccdeps.py 
> > is
> > not used).
> > I briefly looked through the gccdeps.py file and it is doing some string
> > stripping operations.
> > Maybe that is the issue but I am not sure.
>
> Thank you for debugging this and I agree it look like something is a little 
> off
> in gccdeps.
>
Yes, I had a patch for that but I think there was a discussion
upstream between ita1024 and Chris and the conclusion was that the
patch won't be accepted. I can't find it right now but I could fix
this problem by using find_or_declare.

@Robin: Please try to use the find function and see if it fixes.
Here's an example that worked quite nicely in rtems-examples:
https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34


Best regards,
Vijay

> I will need to try and reproduce this to have a chance of finding it. What
> happens if you remove gccdeps.py? Will that you get past this point?
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Chris Johns]

On 30/4/21 5:01 am, Robin Müller wrote:
> Yes that is the prefix. The rtems.h file is definitely located at the location
> in the warning and it works on older commit of rtems_waf (where gccdeps.py is
> not used).
> I briefly looked through the gccdeps.py file and it is doing some string
> stripping operations.
> Maybe that is the issue but I am not sure.

Thank you for debugging this and I agree it look like something is a little off
in gccdeps.

I will need to try and reproduce this to have a chance of finding it. What
happens if you remove gccdeps.py? Will that you get past this point?

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

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

Yes that is the prefix. The rtems.h file is definitely located at the
location in the warning and it works on older commit of rtems_waf (where
gccdeps.py is not used).
I briefly looked through the gccdeps.py file and it is doing some string
stripping operations.
Maybe that is the issue but I am not sure.

Kind Regards
Robin

On Thu, 29 Apr 2021 at 18:00, Gedare Bloom  wrote:

> On Thu, Apr 29, 2021 at 9:59 AM Gedare Bloom  wrote:
> >
> > On Thu, Apr 29, 2021 at 3:14 AM Robin Müller 
> wrote:
> > >
> > > I replaced the file in rtems_waf manually but it still throws the same
> error:
> > >
> > > [1/2] Compiling
> build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
> > >
> > >
> ['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
> '-mcpu=cypress',
> '-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include',
> '-MMD', '../test.c', '-c',
> '-oC:/Users/Robin/Documents/RTEMS/quickstart/build/conf_check_995d7bdd1834199278843e9a51c37759/testbuild/test.c.1.o']
> > > from C:/Users/Robin/Documents/RTEMS/quickstart: Test does not build:
> Traceback (most recent call last):
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Configure.py",
> line 335, in run_build
> > > bld.compile()
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Build.py",
> line 176, in compile
> > > raise Errors.BuildError(self.producer.error)
> > > waflib.Errors.BuildError: Build failed
> > > Traceback (most recent call last):
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Task.py",
> line 190, in process
> > > self.post_run()
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/rtems_waf/gccdeps.py", line 140,
> in post_run
> > > raise ValueError('could not find %r for %r' % (path, self))
> > > ValueError: could not find ['C', ':', 'Users', 'Robin', 'Documents',
> 'RTEMS', 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib',
> 'include', 'rtems.h'] for
> > > {task 2179590063376: c test.c -> test.c.1.o}
> > >
> > It's looking for rtems.h in your rtems-tools directory and not in your
> > prefix. how did you configure waf?
> >
> Sorry, I should also ask, did you install rtems at
> C:\Users\Robin\Documents\RTEMS\rtems-tools/6
>
> > >
> > > no
> > > from C:/Users/Robin/Documents/RTEMS/quickstart: The configuration
> failed
> > >
> > > Kind Regards
> > > Robin
> > >
> > > On Wed, 28 Apr 2021 at 22:35, Chris Johns  wrote:
> > >>
> > >> On 28/4/21 7:59 pm, Robin Müller wrote:
> > >> > I think the following commit in rtems_waf breaks the waf build on
> Windows 10:
> > >> >
> > >> > commit 096372fc4504730e50b51b952ce47ca603b35f01
> > >> > Author: Chris Johns mailto:chr...@rtems.org>>
> > >> > Date:   Thu Oct 10 17:43:11 2019 +1100
> > >> >
> > >> > Use gccdeps for dependency scanning.
> > >> >
> > >> > I get the error that RTEMS is not able to find the rtems.h file in
> a certain
> > >> > directory when building the simple quick start application. The
> error does not
> > >> > occur on commits before that. I tried to run waf both in the
> WIndows CMD and in
> > >> > MinGW64, it is problematic for both.
> > >>
> > >> Could you please update your local version with ...
> > >>
> > >> https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py
> > >>
> > >> ... and report back how that goes?
> > >>
> > >> Thanks
> > >> Chris
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] riscv/start: Startup sequence update.

[Sebastian Huber]

On 29/04/2021 20:18, Hesham Almatary wrote:


I would place the device tree in a noinit section.


That is probably a better solution.

It should also be documented in this start.S file what are the
assumptions about parameters coming from the bootloader since it is
not obvious.

+1


The recent GCC have an attribute for this:

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

We just need support for this in linkcmds.base and an RTEMS_NOINIT in 
basedefs.h.


--
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 v2] Use alias for rtems_task_self() and pthread_self()

[Joel Sherrill]

On Thu, Apr 29, 2021 at 1:37 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/04/2021 20:12, Joel Sherrill wrote:
>
> > I'm not so ok because now the score has symbols for the Classic API
> > and pthreads in it.
> >
> > The point of putting a method shared by both in the score was to avoid
> > contaminating the score with information about the APIs or the the
> > APIs with knowledge of each other. I think we still need separate
> > files in RTEMS and POSIX to hold the alias declarations.
> The alias must be in the same translation unit as the target definition.
>

Well crap. I guess this is OK then. :(

--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 v2] Use alias for rtems_task_self() and pthread_self()

[Sebastian Huber]

On 29/04/2021 20:12, Joel Sherrill wrote:

I'm not so ok because now the score has symbols for the Classic API 
and pthreads in it.


The point of putting a method shared by both in the score was to avoid 
contaminating the score with information about the APIs or the the 
APIs with knowledge of each other. I think we still need separate 
files in RTEMS and POSIX to hold the alias declarations.

The alias must be in the same translation unit as the target definition.

--
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] riscv/start: Startup sequence update.

[Hesham Almatary]

On Thu, 29 Apr 2021 at 20:07, Gedare Bloom  wrote:
>
> On Thu, Apr 29, 2021 at 11:53 AM Sebastian Huber
>  wrote:
> >
> >
> > On 28/04/2021 15:55, Somesh Deshmukh wrote:
> > > +/* Clear .bss */
> > > +LADDRa0, bsp_section_bss_begin
> > > +li   a1, 0
> > > +LADDRa2, bsp_section_bss_size
> > > +call memset
> > > +
> > >   #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
> > >   mv  a0, a1
> > >   callbsp_fdt_copy
> > >   #endif
> >
> > How did you test this? The above memset() sets register a1 to 0 and
> > probably uses this register also, the a1 is later used for the
> > bsp_fdt_copy(), probably with an invalid value.
> >
> Good point, that a1 I guess is a parameter passed in by uboot and
> needs to be preserved if this code should keep working.
>
Right. a1 will be zero on the  bsp_fdt_copy() call this way.

> > I would place the device tree in a noinit section.
> >
> That is probably a better solution.
>
> It should also be documented in this start.S file what are the
> assumptions about parameters coming from the bootloader since it is
> not obvious.
+1
>
> > --
> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Use alias for rtems_task_self() and pthread_self()

[Joel Sherrill]

I'm not so ok because now the score has symbols for the Classic API and
pthreads in it.

The point of putting a method shared by both in the score was to avoid
contaminating the score with information about the APIs or the the APIs
with knowledge of each other. I think we still need separate files in RTEMS
and POSIX to hold the alias declarations.

On Thu, Apr 29, 2021, 11:03 AM Gedare Bloom  wrote:

> ok
>
> On Thu, Apr 29, 2021 at 7:18 AM Sebastian Huber
>  wrote:
> >
> > This may reduce the code size a bit.
> > ---
> >  cpukit/Makefile.am  |  3 +-
> >  cpukit/include/rtems/score/threadimpl.h |  7 
> >  cpukit/posix/src/pthreadself.c  | 32 ---
> >  cpukit/rtems/src/taskself.c | 28 -
> >  cpukit/score/src/threadselfid.c | 53 +
> >  spec/build/cpukit/librtemscpu.yml   |  3 +-
> >  6 files changed, 62 insertions(+), 64 deletions(-)
> >  delete mode 100644 cpukit/posix/src/pthreadself.c
> >  delete mode 100644 cpukit/rtems/src/taskself.c
> >  create mode 100644 cpukit/score/src/threadselfid.c
> >
> > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> > index b0df610bed..096187c507 100644
> > --- a/cpukit/Makefile.am
> > +++ b/cpukit/Makefile.am
> > @@ -620,7 +620,6 @@ librtemscpu_a_SOURCES +=
> posix/src/pthreadgetschedparam.c
> >  librtemscpu_a_SOURCES += posix/src/pthreadinitthreads.c
> >  librtemscpu_a_SOURCES += posix/src/pthreadjoin.c
> >  librtemscpu_a_SOURCES += posix/src/pthreadonce.c
> > -librtemscpu_a_SOURCES += posix/src/pthreadself.c
> >  librtemscpu_a_SOURCES += posix/src/pthreadsetaffinitynp.c
> >  librtemscpu_a_SOURCES += posix/src/pthreadsetnamenp.c
> >  librtemscpu_a_SOURCES += posix/src/pthreadsetschedparam.c
> > @@ -800,7 +799,6 @@ librtemscpu_a_SOURCES += rtems/src/taskmode.c
> >  librtemscpu_a_SOURCES += rtems/src/taskrestart.c
> >  librtemscpu_a_SOURCES += rtems/src/taskresume.c
> >  librtemscpu_a_SOURCES += rtems/src/tasks.c
> > -librtemscpu_a_SOURCES += rtems/src/taskself.c
> >  librtemscpu_a_SOURCES += rtems/src/tasksetaffinity.c
> >  librtemscpu_a_SOURCES += rtems/src/tasksetpriority.c
> >  librtemscpu_a_SOURCES += rtems/src/tasksetscheduler.c
> > @@ -964,6 +962,7 @@ librtemscpu_a_SOURCES += score/src/threadinitialize.c
> >  librtemscpu_a_SOURCES += score/src/threadidledefault.c
> >  librtemscpu_a_SOURCES += score/src/threadloadenv.c
> >  librtemscpu_a_SOURCES += score/src/threadrestart.c
> > +librtemscpu_a_SOURCES += score/src/threadselfid.c
> >  librtemscpu_a_SOURCES += score/src/threadsetstate.c
> >  librtemscpu_a_SOURCES += score/src/threadstackallocate.c
> >  librtemscpu_a_SOURCES += score/src/threadstackfree.c
> > diff --git a/cpukit/include/rtems/score/threadimpl.h
> b/cpukit/include/rtems/score/threadimpl.h
> > index 5dfd142b92..c861e8b119 100644
> > --- a/cpukit/include/rtems/score/threadimpl.h
> > +++ b/cpukit/include/rtems/score/threadimpl.h
> > @@ -903,6 +903,13 @@ Thread_Control *_Thread_Get(
> >ISR_lock_Context  *lock_context
> >  );
> >
> > +/**
> > + * @brief Gets the identifier of the calling thread.
> > + *
> > + * @return Returns the identifier of the calling thread.
> > + */
> > +Objects_Id _Thread_Self_id( void );
> > +
> >  /**
> >   * @brief Gets the cpu of the thread's scheduler.
> >   *
> > diff --git a/cpukit/posix/src/pthreadself.c
> b/cpukit/posix/src/pthreadself.c
> > deleted file mode 100644
> > index db5f2f189d..00
> > --- a/cpukit/posix/src/pthreadself.c
> > +++ /dev/null
> > @@ -1,32 +0,0 @@
> > -/**
> > - * @file
> > - *
> > - * @ingroup POSIXAPI
> > - *
> > - * @brief Function returns the ID of the Calling Thread
> > - */
> > -
> > -/*
> > - *  16.1.6 Get Calling Thread's ID, p1003.1c/Draft 10, p. 152
> > - *
> > - *  COPYRIGHT (c) 1989-1999.
> > - *  On-Line Applications Research Corporation (OAR).
> > - *
> > - *  The license and distribution terms for this file may be
> > - *  found in the file LICENSE in this distribution or at
> > - *  http://www.rtems.org/license/LICENSE.
> > - */
> > -
> > -#ifdef HAVE_CONFIG_H
> > -#include "config.h"
> > -#endif
> > -
> > -#include 
> > -
> > -#include 
> > -#include 
> > -
> > -pthread_t pthread_self( void )
> > -{
> > -  return _Thread_Get_executing()->Object.id;
> > -}
> > diff --git a/cpukit/rtems/src/taskself.c b/cpukit/rtems/src/taskself.c
> > deleted file mode 100644
> > index 193e691ce5..00
> > --- a/cpukit/rtems/src/taskself.c
> > +++ /dev/null
> > @@ -1,28 +0,0 @@
> > -/**
> > - * @file
> > - *
> > - * @ingroup RTEMSImplClassicTask
> > - *
> > - * @brief This source file contains the implementation of
> > - *   rtems_task_self().
> > - */
> > -
> > -/*
> > - *  COPYRIGHT (c) 1989-2007.
> > - *  On-Line Applications Research Corporation (OAR).
> > - *
> > - *  The license and distribution terms for this file may be
> > - *  found in the file LICENSE in this distribution or at
> > - *  http://www.rtems.org/license/LICENSE.
> > - */
> > -
> > -#ifdef HAVE_CONFIG_H
> > 

Re: [PATCH] riscv/start: Startup sequence update.

[Gedare Bloom]

On Thu, Apr 29, 2021 at 11:53 AM Sebastian Huber
 wrote:
>
>
> On 28/04/2021 15:55, Somesh Deshmukh wrote:
> > +/* Clear .bss */
> > +LADDRa0, bsp_section_bss_begin
> > +li   a1, 0
> > +LADDRa2, bsp_section_bss_size
> > +call memset
> > +
> >   #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
> >   mv  a0, a1
> >   callbsp_fdt_copy
> >   #endif
>
> How did you test this? The above memset() sets register a1 to 0 and
> probably uses this register also, the a1 is later used for the
> bsp_fdt_copy(), probably with an invalid value.
>
Good point, that a1 I guess is a parameter passed in by uboot and
needs to be preserved if this code should keep working.

> I would place the device tree in a noinit section.
>
That is probably a better solution.

It should also be documented in this start.S file what are the
assumptions about parameters coming from the bootloader since it is
not obvious.

> --
> 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: [PATCH] riscv/start: Startup sequence update.

[Sebastian Huber]

On 28/04/2021 15:55, Somesh Deshmukh wrote:

+/* Clear .bss */
+LADDR  a0, bsp_section_bss_begin
+li a1, 0
+LADDR  a2, bsp_section_bss_size
+call   memset
+
  #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
mv  a0, a1
callbsp_fdt_copy
  #endif


How did you test this? The above memset() sets register a1 to 0 and 
probably uses this register also, the a1 is later used for the 
bsp_fdt_copy(), probably with an invalid value.


I would place the device tree in a noinit section.

--
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] riscv/start: Startup sequence update.

[Hesham Almatary]

On Wed, 28 Apr 2021 at 15:55, Somesh Deshmukh
 wrote:
>
> - The current startup sequence performs the call to the bsp_fdt_copy() and 
> then
>   performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates
>   memory for bsp_fdt_blob into BSS region which is yet to initialize. With
>   current startup sequence, the bsp_fdt_blob is getting erased after memset.
>   The proposed fix performs the BSS region memset operation and then performs 
> a
>   call to the bsp_fdt_copy().
> ---
>  bsps/riscv/shared/start/start.S | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/bsps/riscv/shared/start/start.S b/bsps/riscv/shared/start/start.S
> index 04a62a26ce..277760a388 100644
> --- a/bsps/riscv/shared/start/start.S
> +++ b/bsps/riscv/shared/start/start.S
> @@ -74,17 +74,17 @@ SYM(_start):
> LADDR   sp, _ISR_Stack_area_end
>  #endif
>
> +/* Clear .bss */
> +LADDR  a0, bsp_section_bss_begin
> +li a1, 0
> +LADDR  a2, bsp_section_bss_size
> +call   memset
> +
Looks good, thanks! Could you please just maintain the existing
whitespace formatting?

>  #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
> mv  a0, a1
> callbsp_fdt_copy
>  #endif
>
> -   /* Clear .bss */
> -   LADDR   a0, bsp_section_bss_begin
> -   li  a1, 0
> -   LADDR   a2, bsp_section_bss_size
> -   callmemset
> -
>  #ifdef RTEMS_SMP
> /* Give go to secondary processors */
> LADDR   t0, .Lsecondary_processor_go
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] riscv/console: Updated the console-config.c file

[Hesham Almatary]

On Wed, 28 Apr 2021 at 15:23, Somesh Deshmukh
 wrote:
>
> - Parsing the sub-node should be available generic not specific to Freedom
>   Arty310 board. If we remove the Freedom Arty macro now, it will lose
>   backward compatibility.The proposed change will retain the backward
>   compatibility and also adds the necessary fix for parsing sub-node.
>
> - Line 234 and 235 in riscv_console_probe() uses polled handlers for ns16550
>   read and write while, the console_initialize function uses ns16550
>   interrupt handler. Proposing a fix to make polled handlers consistant
>   through out the console-config.c
> ---
>  bsps/riscv/riscv/console/console-config.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/riscv/riscv/console/console-config.c 
> b/bsps/riscv/riscv/console/console-config.c
> index d962a5a418..f203f0be7d 100644
> --- a/bsps/riscv/riscv/console/console-config.c
> +++ b/bsps/riscv/riscv/console/console-config.c
> @@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt)
>  stdout_path = "";
>}
>
> -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> +#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) || 
> (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
>int root;
>int soc;
>root = fdt_path_offset(fdt, "/");
> @@ -318,7 +318,7 @@ rtems_status_code console_initialize(
>
>  rtems_termios_device_install(
>path,
> -  _handler_interrupt,
> +  _handler_polled,
I would leave the driver interrupt-based as it is. Other than that the
patch is fine by me.

>NULL,
>>base
>  );
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] cpukit/Makefile.am: Remove remaining LIBNETWORKING files

[Vijay Kumar Banerjee]

On Thu, Apr 29, 2021 at 10:13 AM Gedare Bloom  wrote:
>
> ok
>
Pushed. Thanks.

> On Thu, Apr 29, 2021 at 10:07 AM Vijay Kumar Banerjee  wrote:
> >
> > ---
> >  cpukit/Makefile.am  | 43 ---
> >  cpukit/configure.ac |  1 -
> >  2 files changed, 44 deletions(-)
> >
> > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> > index b0df610bed..44ab945778 100644
> > --- a/cpukit/Makefile.am
> > +++ b/cpukit/Makefile.am
> > @@ -1372,15 +1372,6 @@ librtemscpu_a_SOURCES += libmisc/shell/main_pci.c
> >
> >  endif
> >
> > -if LIBNETWORKING
> > -
> > -librtemscpu_a_SOURCES += libmisc/shell/main_ifconfig.c
> > -librtemscpu_a_SOURCES += libmisc/shell/main_route.c
> > -librtemscpu_a_SOURCES += libmisc/shell/main_netstats.c
> > -librtemscpu_a_SOURCES += libmisc/shell/main_ping.c
> > -
> > -endif
> > -
> >  endif
> >
> >  if LIBUTF8PROC
> > @@ -1813,40 +1804,6 @@ libz_a_SOURCES += zlib/trees.c
> >  libz_a_SOURCES += zlib/uncompr.c
> >  libz_a_SOURCES += zlib/zutil.c
> >
> > -if LIBNETWORKING
> > -
> > -project_lib_LIBRARIES += libnfs.a
> > -
> > -libnfs_a_SOURCES =
> > -libnfs_a_SOURCES += libfs/src/nfsclient/proto/mount_prot_xdr.c
> > -libnfs_a_SOURCES += libfs/src/nfsclient/proto/nfs_prot_xdr.c
> > -libnfs_a_SOURCES += libfs/src/nfsclient/src/nfs.c
> > -libnfs_a_SOURCES += libfs/src/nfsclient/src/rpcio.c
> > -libnfs_a_SOURCES += libfs/src/nfsclient/src/sock_mbuf.c
> > -libnfs_a_SOURCES += libfs/src/nfsclient/src/xdr_mbuf.c
> > -
> > -project_lib_LIBRARIES += libpppd.a
> > -
> > -libpppd_a_SOURCES =
> > -libpppd_a_SOURCES += pppd/auth.c
> > -libpppd_a_SOURCES += pppd/ccp.c
> > -libpppd_a_SOURCES += pppd/chap.c
> > -libpppd_a_SOURCES += pppd/chap_ms.c
> > -libpppd_a_SOURCES += pppd/chat.c
> > -libpppd_a_SOURCES += pppd/demand.c
> > -libpppd_a_SOURCES += pppd/fsm.c
> > -libpppd_a_SOURCES += pppd/ipcp.c
> > -libpppd_a_SOURCES += pppd/lcp.c
> > -libpppd_a_SOURCES += pppd/magic.c
> > -libpppd_a_SOURCES += pppd/options.c
> > -libpppd_a_SOURCES += pppd/rtemsmain.c
> > -libpppd_a_SOURCES += pppd/rtemspppd.c
> > -libpppd_a_SOURCES += pppd/sys-rtems.c
> > -libpppd_a_SOURCES += pppd/upap.c
> > -libpppd_a_SOURCES += pppd/utils.c
> > -
> > -endif
> > -
> >  if HACK_TO_AVOID_LONG_ARG_LIST
> >
> >  librtemscpu.a: $(librtemscpu_a_OBJECTS) $(librtemscpu_a_DEPENDENCIES) 
> > $(EXTRA_librtemscpu_a_DEPENDENCIES)
> > diff --git a/cpukit/configure.ac b/cpukit/configure.ac
> > index 9c25c3770d..e3c039383c 100644
> > --- a/cpukit/configure.ac
> > +++ b/cpukit/configure.ac
> > @@ -293,7 +293,6 @@ AM_CONDITIONAL(HAS_MP,test x"$enable_multiprocessing" = 
> > x"yes" )
> >  AM_CONDITIONAL(HAS_SMP,[test "$RTEMS_HAS_SMP" = "yes"])
> >
> >  AM_CONDITIONAL(HAS_PTHREADS,test x"$rtems_cv_HAS_POSIX_API" = x"yes")
> > -AM_CONDITIONAL(LIBNETWORKING,test x"$rtems_cv_HAS_NETWORKING" = x"yes")
> >
> >  AM_CONDITIONAL([LIBSHELL],[test x"$HAVE_ASSIGNABLE_STDIO" = x"yes"])
> >  AM_CONDITIONAL([LIBSERDBG],[test x"$rtems_cv_cc_attribute_weak" = x"yes"])
> > --
> > 2.26.2
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] cpukit/Makefile.am: Remove remaining LIBNETWORKING files

[Gedare Bloom]

ok

On Thu, Apr 29, 2021 at 10:07 AM Vijay Kumar Banerjee  wrote:
>
> ---
>  cpukit/Makefile.am  | 43 ---
>  cpukit/configure.ac |  1 -
>  2 files changed, 44 deletions(-)
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index b0df610bed..44ab945778 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -1372,15 +1372,6 @@ librtemscpu_a_SOURCES += libmisc/shell/main_pci.c
>
>  endif
>
> -if LIBNETWORKING
> -
> -librtemscpu_a_SOURCES += libmisc/shell/main_ifconfig.c
> -librtemscpu_a_SOURCES += libmisc/shell/main_route.c
> -librtemscpu_a_SOURCES += libmisc/shell/main_netstats.c
> -librtemscpu_a_SOURCES += libmisc/shell/main_ping.c
> -
> -endif
> -
>  endif
>
>  if LIBUTF8PROC
> @@ -1813,40 +1804,6 @@ libz_a_SOURCES += zlib/trees.c
>  libz_a_SOURCES += zlib/uncompr.c
>  libz_a_SOURCES += zlib/zutil.c
>
> -if LIBNETWORKING
> -
> -project_lib_LIBRARIES += libnfs.a
> -
> -libnfs_a_SOURCES =
> -libnfs_a_SOURCES += libfs/src/nfsclient/proto/mount_prot_xdr.c
> -libnfs_a_SOURCES += libfs/src/nfsclient/proto/nfs_prot_xdr.c
> -libnfs_a_SOURCES += libfs/src/nfsclient/src/nfs.c
> -libnfs_a_SOURCES += libfs/src/nfsclient/src/rpcio.c
> -libnfs_a_SOURCES += libfs/src/nfsclient/src/sock_mbuf.c
> -libnfs_a_SOURCES += libfs/src/nfsclient/src/xdr_mbuf.c
> -
> -project_lib_LIBRARIES += libpppd.a
> -
> -libpppd_a_SOURCES =
> -libpppd_a_SOURCES += pppd/auth.c
> -libpppd_a_SOURCES += pppd/ccp.c
> -libpppd_a_SOURCES += pppd/chap.c
> -libpppd_a_SOURCES += pppd/chap_ms.c
> -libpppd_a_SOURCES += pppd/chat.c
> -libpppd_a_SOURCES += pppd/demand.c
> -libpppd_a_SOURCES += pppd/fsm.c
> -libpppd_a_SOURCES += pppd/ipcp.c
> -libpppd_a_SOURCES += pppd/lcp.c
> -libpppd_a_SOURCES += pppd/magic.c
> -libpppd_a_SOURCES += pppd/options.c
> -libpppd_a_SOURCES += pppd/rtemsmain.c
> -libpppd_a_SOURCES += pppd/rtemspppd.c
> -libpppd_a_SOURCES += pppd/sys-rtems.c
> -libpppd_a_SOURCES += pppd/upap.c
> -libpppd_a_SOURCES += pppd/utils.c
> -
> -endif
> -
>  if HACK_TO_AVOID_LONG_ARG_LIST
>
>  librtemscpu.a: $(librtemscpu_a_OBJECTS) $(librtemscpu_a_DEPENDENCIES) 
> $(EXTRA_librtemscpu_a_DEPENDENCIES)
> diff --git a/cpukit/configure.ac b/cpukit/configure.ac
> index 9c25c3770d..e3c039383c 100644
> --- a/cpukit/configure.ac
> +++ b/cpukit/configure.ac
> @@ -293,7 +293,6 @@ AM_CONDITIONAL(HAS_MP,test x"$enable_multiprocessing" = 
> x"yes" )
>  AM_CONDITIONAL(HAS_SMP,[test "$RTEMS_HAS_SMP" = "yes"])
>
>  AM_CONDITIONAL(HAS_PTHREADS,test x"$rtems_cv_HAS_POSIX_API" = x"yes")
> -AM_CONDITIONAL(LIBNETWORKING,test x"$rtems_cv_HAS_NETWORKING" = x"yes")
>
>  AM_CONDITIONAL([LIBSHELL],[test x"$HAVE_ASSIGNABLE_STDIO" = x"yes"])
>  AM_CONDITIONAL([LIBSERDBG],[test x"$rtems_cv_cc_attribute_weak" = x"yes"])
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems] cpukit/Makefile.am: Remove remaining LIBNETWORKING files

[Vijay Kumar Banerjee]

---
 cpukit/Makefile.am  | 43 ---
 cpukit/configure.ac |  1 -
 2 files changed, 44 deletions(-)

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index b0df610bed..44ab945778 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1372,15 +1372,6 @@ librtemscpu_a_SOURCES += libmisc/shell/main_pci.c
 
 endif
 
-if LIBNETWORKING
-
-librtemscpu_a_SOURCES += libmisc/shell/main_ifconfig.c
-librtemscpu_a_SOURCES += libmisc/shell/main_route.c
-librtemscpu_a_SOURCES += libmisc/shell/main_netstats.c
-librtemscpu_a_SOURCES += libmisc/shell/main_ping.c
-
-endif
-
 endif
 
 if LIBUTF8PROC
@@ -1813,40 +1804,6 @@ libz_a_SOURCES += zlib/trees.c
 libz_a_SOURCES += zlib/uncompr.c
 libz_a_SOURCES += zlib/zutil.c
 
-if LIBNETWORKING
-
-project_lib_LIBRARIES += libnfs.a
-
-libnfs_a_SOURCES =
-libnfs_a_SOURCES += libfs/src/nfsclient/proto/mount_prot_xdr.c
-libnfs_a_SOURCES += libfs/src/nfsclient/proto/nfs_prot_xdr.c
-libnfs_a_SOURCES += libfs/src/nfsclient/src/nfs.c
-libnfs_a_SOURCES += libfs/src/nfsclient/src/rpcio.c
-libnfs_a_SOURCES += libfs/src/nfsclient/src/sock_mbuf.c
-libnfs_a_SOURCES += libfs/src/nfsclient/src/xdr_mbuf.c
-
-project_lib_LIBRARIES += libpppd.a
-
-libpppd_a_SOURCES =
-libpppd_a_SOURCES += pppd/auth.c
-libpppd_a_SOURCES += pppd/ccp.c
-libpppd_a_SOURCES += pppd/chap.c
-libpppd_a_SOURCES += pppd/chap_ms.c
-libpppd_a_SOURCES += pppd/chat.c
-libpppd_a_SOURCES += pppd/demand.c
-libpppd_a_SOURCES += pppd/fsm.c
-libpppd_a_SOURCES += pppd/ipcp.c
-libpppd_a_SOURCES += pppd/lcp.c
-libpppd_a_SOURCES += pppd/magic.c
-libpppd_a_SOURCES += pppd/options.c
-libpppd_a_SOURCES += pppd/rtemsmain.c
-libpppd_a_SOURCES += pppd/rtemspppd.c
-libpppd_a_SOURCES += pppd/sys-rtems.c
-libpppd_a_SOURCES += pppd/upap.c
-libpppd_a_SOURCES += pppd/utils.c
-
-endif
-
 if HACK_TO_AVOID_LONG_ARG_LIST
 
 librtemscpu.a: $(librtemscpu_a_OBJECTS) $(librtemscpu_a_DEPENDENCIES) 
$(EXTRA_librtemscpu_a_DEPENDENCIES)
diff --git a/cpukit/configure.ac b/cpukit/configure.ac
index 9c25c3770d..e3c039383c 100644
--- a/cpukit/configure.ac
+++ b/cpukit/configure.ac
@@ -293,7 +293,6 @@ AM_CONDITIONAL(HAS_MP,test x"$enable_multiprocessing" = 
x"yes" )
 AM_CONDITIONAL(HAS_SMP,[test "$RTEMS_HAS_SMP" = "yes"])
 
 AM_CONDITIONAL(HAS_PTHREADS,test x"$rtems_cv_HAS_POSIX_API" = x"yes")
-AM_CONDITIONAL(LIBNETWORKING,test x"$rtems_cv_HAS_NETWORKING" = x"yes")
 
 AM_CONDITIONAL([LIBSHELL],[test x"$HAVE_ASSIGNABLE_STDIO" = x"yes"])
 AM_CONDITIONAL([LIBSERDBG],[test x"$rtems_cv_cc_attribute_weak" = x"yes"])
-- 
2.26.2

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

Re: [PATCH] riscv/console: Updated the console-config.c file

[Gedare Bloom]

Hesham, please review. I'm not certain.

On Wed, Apr 28, 2021 at 7:23 AM Somesh Deshmukh
 wrote:
>
> - Parsing the sub-node should be available generic not specific to Freedom
>   Arty310 board. If we remove the Freedom Arty macro now, it will lose
>   backward compatibility.The proposed change will retain the backward
>   compatibility and also adds the necessary fix for parsing sub-node.
>
> - Line 234 and 235 in riscv_console_probe() uses polled handlers for ns16550
>   read and write while, the console_initialize function uses ns16550
>   interrupt handler. Proposing a fix to make polled handlers consistant
>   through out the console-config.c
> ---
>  bsps/riscv/riscv/console/console-config.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/riscv/riscv/console/console-config.c 
> b/bsps/riscv/riscv/console/console-config.c
> index d962a5a418..f203f0be7d 100644
> --- a/bsps/riscv/riscv/console/console-config.c
> +++ b/bsps/riscv/riscv/console/console-config.c
> @@ -91,7 +91,7 @@ static int riscv_get_console_node(const void *fdt)
>  stdout_path = "";
>}
>
> -#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> +#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) || 
> (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
>int root;
>int soc;
>root = fdt_path_offset(fdt, "/");
> @@ -318,7 +318,7 @@ rtems_status_code console_initialize(
>
>  rtems_termios_device_install(
>path,
> -  _handler_interrupt,
> +  _handler_polled,
>NULL,
>>base
>  );
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] riscv/start: Startup sequence update.

[Gedare Bloom]

looks good. someone using riscv can build/test and push, any takers?

On Wed, Apr 28, 2021 at 7:55 AM Somesh Deshmukh
 wrote:
>
> - The current startup sequence performs the call to the bsp_fdt_copy() and 
> then
>   performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates
>   memory for bsp_fdt_blob into BSS region which is yet to initialize. With
>   current startup sequence, the bsp_fdt_blob is getting erased after memset.
>   The proposed fix performs the BSS region memset operation and then performs 
> a
>   call to the bsp_fdt_copy().
> ---
>  bsps/riscv/shared/start/start.S | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/bsps/riscv/shared/start/start.S b/bsps/riscv/shared/start/start.S
> index 04a62a26ce..277760a388 100644
> --- a/bsps/riscv/shared/start/start.S
> +++ b/bsps/riscv/shared/start/start.S
> @@ -74,17 +74,17 @@ SYM(_start):
> LADDR   sp, _ISR_Stack_area_end
>  #endif
>
> +/* Clear .bss */
> +LADDR  a0, bsp_section_bss_begin
> +li a1, 0
> +LADDR  a2, bsp_section_bss_size
> +call   memset
> +
>  #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
> mv  a0, a1
> callbsp_fdt_copy
>  #endif
>
> -   /* Clear .bss */
> -   LADDR   a0, bsp_section_bss_begin
> -   li  a1, 0
> -   LADDR   a2, bsp_section_bss_size
> -   callmemset
> -
>  #ifdef RTEMS_SMP
> /* Give go to secondary processors */
> LADDR   t0, .Lsecondary_processor_go
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Use alias for rtems_task_self() and pthread_self()

[Gedare Bloom]

ok

On Thu, Apr 29, 2021 at 7:18 AM Sebastian Huber
 wrote:
>
> This may reduce the code size a bit.
> ---
>  cpukit/Makefile.am  |  3 +-
>  cpukit/include/rtems/score/threadimpl.h |  7 
>  cpukit/posix/src/pthreadself.c  | 32 ---
>  cpukit/rtems/src/taskself.c | 28 -
>  cpukit/score/src/threadselfid.c | 53 +
>  spec/build/cpukit/librtemscpu.yml   |  3 +-
>  6 files changed, 62 insertions(+), 64 deletions(-)
>  delete mode 100644 cpukit/posix/src/pthreadself.c
>  delete mode 100644 cpukit/rtems/src/taskself.c
>  create mode 100644 cpukit/score/src/threadselfid.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index b0df610bed..096187c507 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -620,7 +620,6 @@ librtemscpu_a_SOURCES += posix/src/pthreadgetschedparam.c
>  librtemscpu_a_SOURCES += posix/src/pthreadinitthreads.c
>  librtemscpu_a_SOURCES += posix/src/pthreadjoin.c
>  librtemscpu_a_SOURCES += posix/src/pthreadonce.c
> -librtemscpu_a_SOURCES += posix/src/pthreadself.c
>  librtemscpu_a_SOURCES += posix/src/pthreadsetaffinitynp.c
>  librtemscpu_a_SOURCES += posix/src/pthreadsetnamenp.c
>  librtemscpu_a_SOURCES += posix/src/pthreadsetschedparam.c
> @@ -800,7 +799,6 @@ librtemscpu_a_SOURCES += rtems/src/taskmode.c
>  librtemscpu_a_SOURCES += rtems/src/taskrestart.c
>  librtemscpu_a_SOURCES += rtems/src/taskresume.c
>  librtemscpu_a_SOURCES += rtems/src/tasks.c
> -librtemscpu_a_SOURCES += rtems/src/taskself.c
>  librtemscpu_a_SOURCES += rtems/src/tasksetaffinity.c
>  librtemscpu_a_SOURCES += rtems/src/tasksetpriority.c
>  librtemscpu_a_SOURCES += rtems/src/tasksetscheduler.c
> @@ -964,6 +962,7 @@ librtemscpu_a_SOURCES += score/src/threadinitialize.c
>  librtemscpu_a_SOURCES += score/src/threadidledefault.c
>  librtemscpu_a_SOURCES += score/src/threadloadenv.c
>  librtemscpu_a_SOURCES += score/src/threadrestart.c
> +librtemscpu_a_SOURCES += score/src/threadselfid.c
>  librtemscpu_a_SOURCES += score/src/threadsetstate.c
>  librtemscpu_a_SOURCES += score/src/threadstackallocate.c
>  librtemscpu_a_SOURCES += score/src/threadstackfree.c
> diff --git a/cpukit/include/rtems/score/threadimpl.h 
> b/cpukit/include/rtems/score/threadimpl.h
> index 5dfd142b92..c861e8b119 100644
> --- a/cpukit/include/rtems/score/threadimpl.h
> +++ b/cpukit/include/rtems/score/threadimpl.h
> @@ -903,6 +903,13 @@ Thread_Control *_Thread_Get(
>ISR_lock_Context  *lock_context
>  );
>
> +/**
> + * @brief Gets the identifier of the calling thread.
> + *
> + * @return Returns the identifier of the calling thread.
> + */
> +Objects_Id _Thread_Self_id( void );
> +
>  /**
>   * @brief Gets the cpu of the thread's scheduler.
>   *
> diff --git a/cpukit/posix/src/pthreadself.c b/cpukit/posix/src/pthreadself.c
> deleted file mode 100644
> index db5f2f189d..00
> --- a/cpukit/posix/src/pthreadself.c
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -/**
> - * @file
> - *
> - * @ingroup POSIXAPI
> - *
> - * @brief Function returns the ID of the Calling Thread
> - */
> -
> -/*
> - *  16.1.6 Get Calling Thread's ID, p1003.1c/Draft 10, p. 152
> - *
> - *  COPYRIGHT (c) 1989-1999.
> - *  On-Line Applications Research Corporation (OAR).
> - *
> - *  The license and distribution terms for this file may be
> - *  found in the file LICENSE in this distribution or at
> - *  http://www.rtems.org/license/LICENSE.
> - */
> -
> -#ifdef HAVE_CONFIG_H
> -#include "config.h"
> -#endif
> -
> -#include 
> -
> -#include 
> -#include 
> -
> -pthread_t pthread_self( void )
> -{
> -  return _Thread_Get_executing()->Object.id;
> -}
> diff --git a/cpukit/rtems/src/taskself.c b/cpukit/rtems/src/taskself.c
> deleted file mode 100644
> index 193e691ce5..00
> --- a/cpukit/rtems/src/taskself.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -/**
> - * @file
> - *
> - * @ingroup RTEMSImplClassicTask
> - *
> - * @brief This source file contains the implementation of
> - *   rtems_task_self().
> - */
> -
> -/*
> - *  COPYRIGHT (c) 1989-2007.
> - *  On-Line Applications Research Corporation (OAR).
> - *
> - *  The license and distribution terms for this file may be
> - *  found in the file LICENSE in this distribution or at
> - *  http://www.rtems.org/license/LICENSE.
> - */
> -
> -#ifdef HAVE_CONFIG_H
> -#include "config.h"
> -#endif
> -
> -#include 
> -
> -rtems_id rtems_task_self(void)
> -{
> -   return _Thread_Get_executing()->Object.id;
> -}
> diff --git a/cpukit/score/src/threadselfid.c b/cpukit/score/src/threadselfid.c
> new file mode 100644
> index 00..f888a37619
> --- /dev/null
> +++ b/cpukit/score/src/threadselfid.c
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreThread
> + *
> + * @brief This source file contains the implementation of _Thread_Self_id().
> + */
> +
> +/*
> + * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
> + * Copyright (C) 

Re: [PATCH] c-user: CONFIGURE_BSP_PREREQUISITE_DRIVERS

[Gedare Bloom]

ok

On Thu, Apr 29, 2021 at 7:02 AM Sebastian Huber
 wrote:
>
> Replace copy and paste with a provide a proper description.
> ---
>  c-user/config/bsp-related.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
> index 4b6848d..45f31a8 100644
> --- a/c-user/config/bsp-related.rst
> +++ b/c-user/config/bsp-related.rst
> @@ -217,8 +217,8 @@ DESCRIPTION:
>
>  * and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
>
> -then the value of this configuration option is used to initialize the 
> table
> -of initial user extensions.
> +then the value of this configuration option is used to add BSP-provided
> +prerequisite drivers to the Device Driver Table.
>
>  NOTES:
>  The value of this configuration option is placed before the entries of 
> all
> --
> 2.26.2
>
> ___
> 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: Issues with rtems_waf on Windows 10 with gccdeps module

[Gedare Bloom]

On Thu, Apr 29, 2021 at 9:59 AM Gedare Bloom  wrote:
>
> On Thu, Apr 29, 2021 at 3:14 AM Robin Müller  
> wrote:
> >
> > I replaced the file in rtems_waf manually but it still throws the same 
> > error:
> >
> > [1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
> >
> > ['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
> >  '-mcpu=cypress', 
> > '-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include',
> >  '-MMD', '../test.c', '-c', 
> > '-oC:/Users/Robin/Documents/RTEMS/quickstart/build/conf_check_995d7bdd1834199278843e9a51c37759/testbuild/test.c.1.o']
> > from C:/Users/Robin/Documents/RTEMS/quickstart: Test does not build: 
> > Traceback (most recent call last):
> >   File 
> > "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Configure.py",
> >  line 335, in run_build
> > bld.compile()
> >   File 
> > "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Build.py",
> >  line 176, in compile
> > raise Errors.BuildError(self.producer.error)
> > waflib.Errors.BuildError: Build failed
> > Traceback (most recent call last):
> >   File 
> > "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Task.py",
> >  line 190, in process
> > self.post_run()
> >   File "C:/Users/Robin/Documents/RTEMS/quickstart/rtems_waf/gccdeps.py", 
> > line 140, in post_run
> > raise ValueError('could not find %r for %r' % (path, self))
> > ValueError: could not find ['C', ':', 'Users', 'Robin', 'Documents', 
> > 'RTEMS', 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib', 
> > 'include', 'rtems.h'] for
> > {task 2179590063376: c test.c -> test.c.1.o}
> >
> It's looking for rtems.h in your rtems-tools directory and not in your
> prefix. how did you configure waf?
>
Sorry, I should also ask, did you install rtems at
C:\Users\Robin\Documents\RTEMS\rtems-tools/6

> >
> > no
> > from C:/Users/Robin/Documents/RTEMS/quickstart: The configuration failed
> >
> > Kind Regards
> > Robin
> >
> > On Wed, 28 Apr 2021 at 22:35, Chris Johns  wrote:
> >>
> >> On 28/4/21 7:59 pm, Robin Müller wrote:
> >> > I think the following commit in rtems_waf breaks the waf build on 
> >> > Windows 10:
> >> >
> >> > commit 096372fc4504730e50b51b952ce47ca603b35f01
> >> > Author: Chris Johns mailto:chr...@rtems.org>>
> >> > Date:   Thu Oct 10 17:43:11 2019 +1100
> >> >
> >> > Use gccdeps for dependency scanning.
> >> >
> >> > I get the error that RTEMS is not able to find the rtems.h file in a 
> >> > certain
> >> > directory when building the simple quick start application. The error 
> >> > does not
> >> > occur on commits before that. I tried to run waf both in the WIndows CMD 
> >> > and in
> >> > MinGW64, it is problematic for both.
> >>
> >> Could you please update your local version with ...
> >>
> >> https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py
> >>
> >> ... and report back how that goes?
> >>
> >> Thanks
> >> Chris
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Gedare Bloom]

On Thu, Apr 29, 2021 at 3:14 AM Robin Müller  wrote:
>
> I replaced the file in rtems_waf manually but it still throws the same error:
>
> [1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
>
> ['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
>  '-mcpu=cypress', 
> '-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include',
>  '-MMD', '../test.c', '-c', 
> '-oC:/Users/Robin/Documents/RTEMS/quickstart/build/conf_check_995d7bdd1834199278843e9a51c37759/testbuild/test.c.1.o']
> from C:/Users/Robin/Documents/RTEMS/quickstart: Test does not build: 
> Traceback (most recent call last):
>   File 
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Configure.py",
>  line 335, in run_build
> bld.compile()
>   File 
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Build.py",
>  line 176, in compile
> raise Errors.BuildError(self.producer.error)
> waflib.Errors.BuildError: Build failed
> Traceback (most recent call last):
>   File 
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Task.py",
>  line 190, in process
> self.post_run()
>   File "C:/Users/Robin/Documents/RTEMS/quickstart/rtems_waf/gccdeps.py", line 
> 140, in post_run
> raise ValueError('could not find %r for %r' % (path, self))
> ValueError: could not find ['C', ':', 'Users', 'Robin', 'Documents', 'RTEMS', 
> 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib', 'include', 
> 'rtems.h'] for
> {task 2179590063376: c test.c -> test.c.1.o}
>
It's looking for rtems.h in your rtems-tools directory and not in your
prefix. how did you configure waf?

>
> no
> from C:/Users/Robin/Documents/RTEMS/quickstart: The configuration failed
>
> Kind Regards
> Robin
>
> On Wed, 28 Apr 2021 at 22:35, Chris Johns  wrote:
>>
>> On 28/4/21 7:59 pm, Robin Müller wrote:
>> > I think the following commit in rtems_waf breaks the waf build on Windows 
>> > 10:
>> >
>> > commit 096372fc4504730e50b51b952ce47ca603b35f01
>> > Author: Chris Johns mailto:chr...@rtems.org>>
>> > Date:   Thu Oct 10 17:43:11 2019 +1100
>> >
>> > Use gccdeps for dependency scanning.
>> >
>> > I get the error that RTEMS is not able to find the rtems.h file in a 
>> > certain
>> > directory when building the simple quick start application. The error does 
>> > not
>> > occur on commits before that. I tried to run waf both in the WIndows CMD 
>> > and in
>> > MinGW64, it is problematic for both.
>>
>> Could you please update your local version with ...
>>
>> https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py
>>
>> ... and report back how that goes?
>>
>> Thanks
>> Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Reformat configuration option constraints

[Gedare Bloom]

ok

On Wed, Apr 28, 2021 at 11:30 PM Sebastian Huber
 wrote:
>
> If only one constraint is present, then use a single sentence, otherwise
> use a list for the constraints.  Format the constraints so that the line
> length limit is maintained.
> ---
>  c-user/config/bdbuf.rst |  94 ++-
>  c-user/config/bsp-related.rst   |  22 ++--
>  c-user/config/classic-api.rst   | 176 ++--
>  c-user/config/classic-init-task.rst |  28 +++--
>  c-user/config/device-driver.rst |  18 +--
>  c-user/config/event-record.rst  |  11 +-
>  c-user/config/filesystem.rst|   6 +-
>  c-user/config/general.rst   | 114 ++
>  c-user/config/idle-task.rst |  12 +-
>  c-user/config/mpci.rst  |  50 +---
>  c-user/config/posix-api.rst | 168 +-
>  c-user/config/posix-init-thread.rst |  11 +-
>  c-user/config/scheduler-general.rst |  28 ++---
>  c-user/config/task-stack-alloc.rst  |   6 +-
>  14 files changed, 414 insertions(+), 330 deletions(-)
>
> diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
> index 7377bee..c5381e1 100644
> --- a/c-user/config/bdbuf.rst
> +++ b/c-user/config/bdbuf.rst
> @@ -1,6 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +.. Copyright (C) 2020, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
>
>  .. This file is part of the RTEMS quality process and was automatically
> @@ -76,9 +76,10 @@ VALUE CONSTRAINTS:
>  The value of this configuration option shall satisfy all of the following
>  constraints:
>
> -* It shall be greater than or equal to 0.
> +* It shall be greater than or equal to zero.
>
> -* It shall be an integral multiple of 
> :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
> +* It shall be an integral multiple of
> +  :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
>
>  DESCRIPTION:
>  The value of this configuration option defines the maximum size of a 
> buffer
> @@ -106,8 +107,13 @@ DEFAULT VALUE:
>  The default value is 512.
>
>  VALUE CONSTRAINTS:
> -The value of this configuration option shall be greater than or equal to > 0
> -and less than or equal to `UINT32_MAX 
> `_.
> +The value of this configuration option shall satisfy all of the following
> +constraints:
> +
> +* It shall be greater than or equal to zero.
> +
> +* It shall be less than or equal to `UINT32_MAX
> +  `_.
>
>  DESCRIPTION:
>  The value of this configuration option defines the minimum size of a 
> buffer
> @@ -135,8 +141,13 @@ DEFAULT VALUE:
>  The default value is 32768.
>
>  VALUE CONSTRAINTS:
> -The value of this configuration option shall be greater than or equal to > 0
> -and less than or equal to `SIZE_MAX 
> `_.
> +The value of this configuration option shall satisfy all of the following
> +constraints:
> +
> +* It shall be greater than or equal to zero.
> +
> +* It shall be less than or equal to `SIZE_MAX
> +  `_.
>
>  DESCRIPTION:
>  The value of this configuration option defines the size of the cache 
> memory
> @@ -164,8 +175,13 @@ DEFAULT VALUE:
>  The default value is 0.
>
>  VALUE CONSTRAINTS:
> -The value of this configuration option shall be greater than or equal to > 0
> -and less than or equal to `UINT32_MAX 
> `_.
> +The value of this configuration option shall satisfy all of the following
> +constraints:
> +
> +* It shall be greater than or equal to zero.
> +
> +* It shall be less than or equal to `UINT32_MAX
> +  `_.
>
>  DESCRIPTION:
>  The value of this configuration option defines the maximum blocks per
> @@ -195,8 +211,13 @@ DEFAULT VALUE:
>  The default value is 16.
>
>  VALUE CONSTRAINTS:
> -The value of this configuration option shall be greater than or equal to > 0
> -and less than or equal to `UINT32_MAX 
> `_.
> +The value of this configuration option shall satisfy all of the following
> +constraints:
> +
> +* It shall be greater than or equal to zero.
> +
> +* It shall be less than or equal to `UINT32_MAX
> +  `_.
>
>  DESCRIPTION:
>  The value of this configuration option defines the maximum blocks per 
> write
> @@ -225,7 +246,8 @@ DEFAULT VALUE:
>
>  VALUE CONSTRAINTS:
>  The value of this configuration option shall be a valid Classic API task
> -priority.  The set of valid task priorities is scheduler-specific.
> +

Re: [PATCH] bsps/shared/ofw: Fix coverity defects

[Gedare Bloom]

On Wed, Apr 28, 2021 at 9:04 PM Niteesh G. S.  wrote:
>
>
>
> On Thu, Apr 29, 2021 at 12:50 AM Gedare Bloom  wrote:
>>
>> On Wed, Apr 28, 2021 at 11:30 AM G S Niteesh Babu  
>> wrote:
>> >
>> > This patch adds asserts to fix coverity defects
>> > 1) CID 1474437 (Out-of-bounds access)
>> > 2) CID 1474436 (Out-of-bounds access)
>> >
>> > From manual inspection, out of bounds access cannot occur due to
>> > bounds checking but coverity fails to detect the checks.
>> > We are adding asserts as a secondary check.
>> > ---
>> >  bsps/shared/ofw/ofw.c | 12 +++-
>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
>> > index f4b8b63931..808fa85d81 100644
>> > --- a/bsps/shared/ofw/ofw.c
>> > +++ b/bsps/shared/ofw/ofw.c
>> > @@ -42,6 +42,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  static void *fdtp = NULL;
>> >
>> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
>> >const void *prop;
>> >int offset;
>> >int len;
>> > +  int copy_len;
>> >uint32_t cpuid;
>> >
>> >offset = rtems_fdt_phandle_to_offset(node);
>> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
>> >  return -1;
>> >}
>> >
>> > -  bcopy(prop, buf, MIN(len, bufsize));
>> > +  copy_len = MIN(len, bufsize);
>> > +  _Assert(copy_len <= bufsize);
>> > +  memmove(prop, buf, copy_len);
>> >
>> >return len;
>> >  }
>> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
>> >  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
>> >  range.size = fdt32_to_cpu(ptr[j].size);
>> >
>> > +/*
>> > + * buf[i + 1] should upperbound the access for buf[i].
>> > + * Thus by making sure buf[i + 1] <= (buf + size) we
>> > + * can be sure buf[i] will always be inbounds.
>> > + */
>> > +_Assert(buf[i + 1] <= (buf + size));
>> This looks suspect. It can make an out-of-bounds read access I think. How 
>> about
>> _Assert(i < size);
>> Is that equivalent?
>
> No that won't work because size is the length of the buffer in bytes. I right 
> thing would be
> _Assert(i < nregs) where nregs = size / sizeof(rtems_ofw_reg)
You can also do this generically with size / sizeof(buf[0]). We might
have such helpers already for array / address calculations, I'm not
sure.

> but I don't think adding this will make any change.
> BTW what makes you suspect that it can still make an out-of-bounds access?
I meant that buf[i+1] is out of range if (i >= size - 1).

However, even then the logic is suspicious, you're comparing the value
at buf[i+1] to the address of buf+size. What you mean is [i+1] <=
(buf+size). This actually might not be an out-of-bounds access then, I
think you can do this safely since you don't dereference *(buf + i +
1).

Is it also correct to use [i] < (buf+size)? That will be better
than testing equality. Or, use
[i] < (buf + size - (sizeof(buf[0]) - 1))
since what you really want to confirm is that buf[i] is not going to
access any bytes past the buf+size.

>>
>>
>> >  if (buf[i].start >= range.child_bus &&
>> >  buf[i].start < range.child_bus + range.size) {
>> >offset = range.parent_bus - range.child_bus;
>> > --
>> > 2.17.1
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Use alias for rtems_task_self() and pthread_self()

[Sebastian Huber]

This may reduce the code size a bit.
---
 cpukit/Makefile.am  |  3 +-
 cpukit/include/rtems/score/threadimpl.h |  7 
 cpukit/posix/src/pthreadself.c  | 32 ---
 cpukit/rtems/src/taskself.c | 28 -
 cpukit/score/src/threadselfid.c | 53 +
 spec/build/cpukit/librtemscpu.yml   |  3 +-
 6 files changed, 62 insertions(+), 64 deletions(-)
 delete mode 100644 cpukit/posix/src/pthreadself.c
 delete mode 100644 cpukit/rtems/src/taskself.c
 create mode 100644 cpukit/score/src/threadselfid.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index b0df610bed..096187c507 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -620,7 +620,6 @@ librtemscpu_a_SOURCES += posix/src/pthreadgetschedparam.c
 librtemscpu_a_SOURCES += posix/src/pthreadinitthreads.c
 librtemscpu_a_SOURCES += posix/src/pthreadjoin.c
 librtemscpu_a_SOURCES += posix/src/pthreadonce.c
-librtemscpu_a_SOURCES += posix/src/pthreadself.c
 librtemscpu_a_SOURCES += posix/src/pthreadsetaffinitynp.c
 librtemscpu_a_SOURCES += posix/src/pthreadsetnamenp.c
 librtemscpu_a_SOURCES += posix/src/pthreadsetschedparam.c
@@ -800,7 +799,6 @@ librtemscpu_a_SOURCES += rtems/src/taskmode.c
 librtemscpu_a_SOURCES += rtems/src/taskrestart.c
 librtemscpu_a_SOURCES += rtems/src/taskresume.c
 librtemscpu_a_SOURCES += rtems/src/tasks.c
-librtemscpu_a_SOURCES += rtems/src/taskself.c
 librtemscpu_a_SOURCES += rtems/src/tasksetaffinity.c
 librtemscpu_a_SOURCES += rtems/src/tasksetpriority.c
 librtemscpu_a_SOURCES += rtems/src/tasksetscheduler.c
@@ -964,6 +962,7 @@ librtemscpu_a_SOURCES += score/src/threadinitialize.c
 librtemscpu_a_SOURCES += score/src/threadidledefault.c
 librtemscpu_a_SOURCES += score/src/threadloadenv.c
 librtemscpu_a_SOURCES += score/src/threadrestart.c
+librtemscpu_a_SOURCES += score/src/threadselfid.c
 librtemscpu_a_SOURCES += score/src/threadsetstate.c
 librtemscpu_a_SOURCES += score/src/threadstackallocate.c
 librtemscpu_a_SOURCES += score/src/threadstackfree.c
diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index 5dfd142b92..c861e8b119 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -903,6 +903,13 @@ Thread_Control *_Thread_Get(
   ISR_lock_Context  *lock_context
 );
 
+/**
+ * @brief Gets the identifier of the calling thread.
+ *
+ * @return Returns the identifier of the calling thread.
+ */
+Objects_Id _Thread_Self_id( void );
+
 /**
  * @brief Gets the cpu of the thread's scheduler.
  *
diff --git a/cpukit/posix/src/pthreadself.c b/cpukit/posix/src/pthreadself.c
deleted file mode 100644
index db5f2f189d..00
--- a/cpukit/posix/src/pthreadself.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/**
- * @file
- *
- * @ingroup POSIXAPI
- *
- * @brief Function returns the ID of the Calling Thread 
- */
-
-/*
- *  16.1.6 Get Calling Thread's ID, p1003.1c/Draft 10, p. 152
- *
- *  COPYRIGHT (c) 1989-1999.
- *  On-Line Applications Research Corporation (OAR).
- *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
- */
-
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#endif
-
-#include 
-
-#include 
-#include 
-
-pthread_t pthread_self( void )
-{
-  return _Thread_Get_executing()->Object.id;
-}
diff --git a/cpukit/rtems/src/taskself.c b/cpukit/rtems/src/taskself.c
deleted file mode 100644
index 193e691ce5..00
--- a/cpukit/rtems/src/taskself.c
+++ /dev/null
@@ -1,28 +0,0 @@
-/**
- * @file
- *
- * @ingroup RTEMSImplClassicTask
- *
- * @brief This source file contains the implementation of
- *   rtems_task_self().
- */
-
-/*
- *  COPYRIGHT (c) 1989-2007.
- *  On-Line Applications Research Corporation (OAR).
- *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
- */
-
-#ifdef HAVE_CONFIG_H
-#include "config.h"
-#endif
-
-#include 
-
-rtems_id rtems_task_self(void)
-{
-   return _Thread_Get_executing()->Object.id;
-}
diff --git a/cpukit/score/src/threadselfid.c b/cpukit/score/src/threadselfid.c
new file mode 100644
index 00..f888a37619
--- /dev/null
+++ b/cpukit/score/src/threadselfid.c
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreThread
+ *
+ * @brief This source file contains the implementation of _Thread_Self_id().
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 1995 On-Line Applications Research Corporation (OAR)
+ *
+ * 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. 

[PATCH] c-user: CONFIGURE_BSP_PREREQUISITE_DRIVERS

[Sebastian Huber]

Replace copy and paste with a provide a proper description.
---
 c-user/config/bsp-related.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
index 4b6848d..45f31a8 100644
--- a/c-user/config/bsp-related.rst
+++ b/c-user/config/bsp-related.rst
@@ -217,8 +217,8 @@ DESCRIPTION:
 
 * and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
 
-then the value of this configuration option is used to initialize the table
-of initial user extensions.
+then the value of this configuration option is used to add BSP-provided
+prerequisite drivers to the Device Driver Table.
 
 NOTES:
 The value of this configuration option is placed before the entries of all
-- 
2.26.2

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

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

I replaced the file in rtems_waf manually but it still throws the same
error:

[1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c

['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
'-mcpu=cypress',
'-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include',
'-MMD', '../test.c', '-c',
'-oC:/Users/Robin/Documents/RTEMS/quickstart/build/conf_check_995d7bdd1834199278843e9a51c37759/testbuild/test.c.1.o']
from C:/Users/Robin/Documents/RTEMS/quickstart: Test does not build:
Traceback (most recent call last):
  File
"C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Configure.py",
line 335, in run_build
bld.compile()
  File
"C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Build.py",
line 176, in compile
raise Errors.BuildError(self.producer.error)
waflib.Errors.BuildError: Build failed
Traceback (most recent call last):
  File
"C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Task.py",
line 190, in process
self.post_run()
  File "C:/Users/Robin/Documents/RTEMS/quickstart/rtems_waf/gccdeps.py",
line 140, in post_run
raise ValueError('could not find %r for %r' % (path, self))
ValueError: could not find ['C', ':', 'Users', 'Robin', 'Documents',
'RTEMS', 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib',
'include', 'rtems.h'] for
{task 2179590063376: c test.c -> test.c.1.o}


no
from C:/Users/Robin/Documents/RTEMS/quickstart: The configuration failed

Kind Regards
Robin

On Wed, 28 Apr 2021 at 22:35, Chris Johns  wrote:

> On 28/4/21 7:59 pm, Robin Müller wrote:
> > I think the following commit in rtems_waf breaks the waf build on
> Windows 10:
> >
> > commit 096372fc4504730e50b51b952ce47ca603b35f01
> > Author: Chris Johns mailto:chr...@rtems.org>>
> > Date:   Thu Oct 10 17:43:11 2019 +1100
> >
> > Use gccdeps for dependency scanning.
> >
> > I get the error that RTEMS is not able to find the rtems.h file in a
> certain
> > directory when building the simple quick start application. The error
> does not
> > occur on commits before that. I tried to run waf both in the WIndows CMD
> and in
> > MinGW64, it is problematic for both.
>
> Could you please update your local version with ...
>
> https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py
>
> ... and report back how that goes?
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tcpreplay for testing network stacks

[Chris Johns]

On 29/4/21 4:30 pm, Christian MAUDERER wrote:
> Am 29.04.21 um 00:54 schrieb Vijay Kumar Banerjee:
>> On Wed, Apr 28, 2021 at 3:27 PM Chris Johns  wrote:
>>>
>>>
>>>
>>> On 29/4/21 3:00 am, Vijay Kumar Banerjee wrote:
 On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer  
 wrote:
>
> Hello Vijay,
>
> On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:
>> On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
>>  wrote:
>>>
>>> Hello Vijay,
>>>
>>> Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
 Hi,

 I came across the tcpreplay tool and it looks like a nice tool for
 testing the network stacks. It can be used to capture network traffic
 and then play it back, this will help with testing the network packets
 from different network stacks.
>>>
>>> Sounds like an interesting tool.
>>>

 My proposal is to add the tcpreply as a host-side tool in rtems-tools
 and use it with the network interface where the network application is
 running. The only issue that I see with the whole idea is that the
 tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
 The github repository says that it's compatible with UNIX and Windows
 with cygwin.
>>>
>>> The more difficult problem could be the missing Mac and FreeBSD support.
>>>
>> That's a good point.
>>
>>> What would be the advantage of having tcpreply in rtems-tools? Do you
>>> want to use it for automated tests?
>>>
>> Yes. I was thinking about capturing the pcap format packets in
>> temporary files and then running tcpreplay to check for any network
>> issues. I haven't planned exactly how that will be implemented but
>> roughly this is the idea.
>>
>
> In what form would you automate that? Some test case in RTEMS or some
> special repository? I assume that you need some special setup for
> specific (simulator) targets anyway, don't you? So a general purpose
> test for all targets will be difficult.
>
 I was not thinking about a special repository. It would be nice to
 have it as test case or as an rtems-test config where the script will
 capture the packets and feed them to tcpreplay.
>>>
>>> Capture from where? How do these traces deal with the differences in 
>>> networks?
>> more tools :). What I was attempting is tcpdump to get the pcap and
>> then tcpreplay. I was basically in search of some way to effectively
>> test the network stacks.
>>
>>> Does tcpreply rewrite various fields, for example a DHCP server response? I
>>> suspect it does not.
>>>
>> I'm not sure.
>>
>>> Tcpreplay may work out to be a good tool we use but I think there needs to 
>>> be
>>> some more ground work to see if you can "virtualize" a network. If you can 
>>> do
>>> this you control the arena the devices operate in and all the 
>>> characteristics
>>> and then play back would be possible and portable.
>>>
>>> VDE may be an interesting part of this. I seem to remember it has a DHCP 
>>> server
>>> so if you use this with a tap that VDE manages rtems-test could use that
>>> interface.
>>>
>> That sounds like a great idea.
>>
>>> A tricky area to look into is if a VDE port can map to a physical port? If 
>>> this
>>> can be done you could mix simulation and real hardware and that would be 
>>> amazing
>>> to have.
>>>
>> I'll search about this.
> 
> Could be a nice application, yes. But note that this would be rather a test of
> the driver on the specific hardware. And it sounds like a rather complex 
> setup.

I did not expect the set up I posted to be the one to use. It was an example of
using VDE.

> I'm not sure whether such a thing would be easy to automate in a way that a 
> lot
> of people could use it.

The challenge is seeing if it can. I suspect there will need to be some set up
done. What that is, I do not know.

>> Thanks for the great ideas, I'm indeed getting some direction.
>>
>> Best regards,
>> Vijay
> If it is about testing the stacks and not the drivers, it might would be
> possible to write some kind of dummy network driver that can read pcap
> format (or some other raw packet format) directly and hands the packets
> to the network stack. Such a driver maybe could even provide packets to
> a test frame again so that you can check responses.
>
 The objective is to test the stacks. The dummy network driver sounds
 like a great idea, thanks. I'll explore this direction more.
>>>
>>> I prefer real drivers are used as it lets us extend testing to VLAN and
>>> multicast (driver hashes and filter testing).
>>>
>>> A solution needs to find a suitable lowest common denominator. This means
>>> hardware and simulation and possibly the different networking stack options
>>> we have.
>>>
> 
> After thinking a night over it you maybe also should note that we already have
> some tests that 

Re: tcpreplay for testing network stacks

[Christian MAUDERER]

Am 29.04.21 um 00:54 schrieb Vijay Kumar Banerjee:

On Wed, Apr 28, 2021 at 3:27 PM Chris Johns  wrote:




On 29/4/21 3:00 am, Vijay Kumar Banerjee wrote:

On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer  wrote:


Hello Vijay,

On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:

On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
 wrote:


Hello Vijay,

Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:

Hi,

I came across the tcpreplay tool and it looks like a nice tool for
testing the network stacks. It can be used to capture network traffic
and then play it back, this will help with testing the network packets
from different network stacks.


Sounds like an interesting tool.



My proposal is to add the tcpreply as a host-side tool in rtems-tools
and use it with the network interface where the network application is
running. The only issue that I see with the whole idea is that the
tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools?
The github repository says that it's compatible with UNIX and Windows
with cygwin.


The more difficult problem could be the missing Mac and FreeBSD support.


That's a good point.


What would be the advantage of having tcpreply in rtems-tools? Do you
want to use it for automated tests?


Yes. I was thinking about capturing the pcap format packets in
temporary files and then running tcpreplay to check for any network
issues. I haven't planned exactly how that will be implemented but
roughly this is the idea.



In what form would you automate that? Some test case in RTEMS or some
special repository? I assume that you need some special setup for
specific (simulator) targets anyway, don't you? So a general purpose
test for all targets will be difficult.


I was not thinking about a special repository. It would be nice to
have it as test case or as an rtems-test config where the script will
capture the packets and feed them to tcpreplay.


Capture from where? How do these traces deal with the differences in networks?

more tools :). What I was attempting is tcpdump to get the pcap and
then tcpreplay. I was basically in search of some way to effectively
test the network stacks.


Does tcpreply rewrite various fields, for example a DHCP server response? I
suspect it does not.


I'm not sure.


Tcpreplay may work out to be a good tool we use but I think there needs to be
some more ground work to see if you can "virtualize" a network. If you can do
this you control the arena the devices operate in and all the characteristics
and then play back would be possible and portable.

VDE may be an interesting part of this. I seem to remember it has a DHCP server
so if you use this with a tap that VDE manages rtems-test could use that 
interface.


That sounds like a great idea.


A tricky area to look into is if a VDE port can map to a physical port? If this
can be done you could mix simulation and real hardware and that would be amazing
to have.


I'll search about this.


Could be a nice application, yes. But note that this would be rather a 
test of the driver on the specific hardware. And it sounds like a rather 
complex setup. I'm not sure whether such a thing would be easy to 
automate in a way that a lot of people could use it.





Thanks for the great ideas, I'm indeed getting some direction.

Best regards,
Vijay

If it is about testing the stacks and not the drivers, it might would be
possible to write some kind of dummy network driver that can read pcap
format (or some other raw packet format) directly and hands the packets
to the network stack. Such a driver maybe could even provide packets to
a test frame again so that you can check responses.


The objective is to test the stacks. The dummy network driver sounds
like a great idea, thanks. I'll explore this direction more.


I prefer real drivers are used as it lets us extend testing to VLAN and
multicast (driver hashes and filter testing).

A solution needs to find a suitable lowest common denominator. This means
hardware and simulation and possibly the different networking stack options we 
have.



After thinking a night over it you maybe also should note that we 
already have some tests that test the stack. For example the pf01 in 
libbsd uses loopback devices for that. You can already test big parts of 
the stack with that.


Best regards

Christian


Chris

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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

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