Re: Two Resource Leaks

[Richi Dubey]

I believe that cause of the recent commits in the last two months, these
are the tests that have started failing on master:
dl09.exe
psxpasswd02.exe
pwdgrp01.exe
shell01.exe
sptimecounter02.exe
ttest02.exe

and a timeout:
smpmrsp01.ex


On Sat, Mar 27, 2021 at 3:21 AM Joel Sherrill  wrote:

> Hi
>
> Jennifer has been working on a network driver and had some odd failures in
> libbsd. I suggested turning on rtems debug and that caused a number of
> libbsd tests to fail. She pointed me in the right direction and I found
> that the following patch resulted in the stack address being freed
> including an "align up" adjustment in some cases. This looks to be from
> something Sebastian committed early this month.
>
>
> https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1
>
> I am not sure how that wasn't noticed since about 40 tests were failing on
> psim due to that.
>
> I have attached a straightforward patch to address this issue.
>
> Unfortunately, even with this patch and using the RTEMS hash just before
> this patch program01 and syscalls01 in libbsd fail. I debugged into
> syscalls01 enough to find that there are 7 blocks at the beginning of one
> of the tests and 5 after. There is another leak and I tried using the has
> before Sebastian's change above but it is still leaking.
>
> On top of that, psxconfig01 and spconfig01 are failing on psim which
> appears to be independent. I am not sure what these are but it is something
> about minimum stack size not matching. Since I was looking for stack memory
> issues, I started to investigate these but decided they were not
> allocation/free issues.
>
> Help really appreciated in addressing these leaks.
>
> Thanks.
>
> --joel
>
> ___
> 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-littlevgl] Update rtems_waf

[Vijay Kumar Banerjee]

---
 rtems_waf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems_waf b/rtems_waf
index ad6c6e8..1a118bb 16
--- a/rtems_waf
+++ b/rtems_waf
@@ -1 +1 @@
-Subproject commit ad6c6e8771b95dffa73a7dc1167d98d208f17cb0
+Subproject commit 1a118bbcd52138dbdc3236e64bc23fd430a064b1
-- 
2.26.2

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

Re: [PATCH rtems-docs v3] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

On Fri, Mar 26, 2021, 17:26 Joel Sherrill  wrote:

>
>
> On Fri, Mar 26, 2021, 5:53 PM Vijay Kumar Banerjee 
> wrote:
>
>> Hi Joel,
>>
>> On Fri, Mar 26, 2021, 16:46 Joel Sherrill 
>> wrote:
>>
>>> I thought I said this looked good on the first round.
>>>
>> In this version of the patch I send networking to bottom of the index in
>> coverpage.
>>
>
> Sorry. That was a subtle change. Thanks for making it.
>
>>
>>
>>> My only question was whether you want to update it the minimum to point
>>> to the legacy stack as a separate package. But that should be a follow up
>>> patch.
>>>
>>
>> Yes, I'll add a note in the docs about the separate package and how to
>> build it manually and with RSB. I'll send that as a separate patch as you
>> mentioned.
>>
>
> Good enough. Thanks to you the legacy network stack is not as dead as it
> could be. Since you did this fantastic piece of work to put it in a
> separate repository, we just want the documentation to reflect that.
>

Thank! I will add the documentation soon. :)

Best regards,
Vijay

>
>>
>> Best regards,
>> Vijay
>>
>>>
>>> --joel
>>>
>>> On Fri, Mar 26, 2021 at 3:48 PM Vijay Kumar Banerjee 
>>> wrote:
>>>
 Ping :)


 On Tue, Mar 23, 2021 at 2:04 PM Vijay Kumar Banerjee 
 wrote:
 >
 > ---
 >  book/index_book.rst | 2 +-
 >  {networking => legacy-networking}/command.rst   | 0
 >  {networking => legacy-networking}/conf.py   | 6
 +++---
 >  {networking => legacy-networking}/dec_21140.rst | 0
 >  {networking => legacy-networking}/index.rst | 2 +-
 >  {networking => legacy-networking}/network_servers.rst   | 0
 >  .../network_task_structure.rst  | 0
 >  {networking => legacy-networking}/networking_driver.rst | 0
 >  {networking => legacy-networking}/preface.rst   | 0
 >  {networking => legacy-networking}/testing_the_driver.rst| 0
 >  .../using_networking_rtems_app.rst  | 0
 >  {networking => legacy-networking}/wscript   | 0
 >  wscript | 4 ++--
 >  13 files changed, 7 insertions(+), 7 deletions(-)
 >  rename {networking => legacy-networking}/command.rst (100%)
 >  rename {networking => legacy-networking}/conf.py (58%)
 >  rename {networking => legacy-networking}/dec_21140.rst (100%)
 >  rename {networking => legacy-networking}/index.rst (92%)
 >  rename {networking => legacy-networking}/network_servers.rst (100%)
 >  rename {networking => legacy-networking}/network_task_structure.rst
 (100%)
 >  rename {networking => legacy-networking}/networking_driver.rst (100%)
 >  rename {networking => legacy-networking}/preface.rst (100%)
 >  rename {networking => legacy-networking}/testing_the_driver.rst
 (100%)
 >  rename {networking =>
 legacy-networking}/using_networking_rtems_app.rst (100%)
 >  rename {networking => legacy-networking}/wscript (100%)
 >
 > diff --git a/book/index_book.rst b/book/index_book.rst
 > index 8282006..afe15a1 100644
 > --- a/book/index_book.rst
 > +++ b/book/index_book.rst
 > @@ -23,7 +23,7 @@ Table of Contents
 > cpu_supplement/index.rst
 > develenv/index.rst
 > filesystem/index.rst
 > -   networking/index.rst
 > porting/index.rst
 > posix1003_1/index.rst
 > posix_users/index.rst
 > +   legacy_networking/index.rst
 > diff --git a/networking/command.rst b/legacy-networking/command.rst
 > similarity index 100%
 > rename from networking/command.rst
 > rename to legacy-networking/command.rst
 > diff --git a/networking/conf.py b/legacy-networking/conf.py
 > similarity index 58%
 > rename from networking/conf.py
 > rename to legacy-networking/conf.py
 > index 1c129bc..98a06b6 100644
 > --- a/networking/conf.py
 > +++ b/legacy-networking/conf.py
 > @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
 >
 >  from conf import *
 >
 > -project = "RTEMS Networking User Manual"
 > +project = "RTEMS Legacy Networking User Manual"
 >
 >  latex_documents = [
 >  ('index',
 > - 'networking.tex',
 > - u'RTEMS Networking User Manual',
 > + 'legacy-networking.tex',
 > + u'RTEMS Legacy Networking User Manual',
 >   u'RTEMS Documentation Project',
 >   'manual'),
 >  ]
 > diff --git a/networking/dec_21140.rst
 b/legacy-networking/dec_21140.rst
 > similarity index 100%
 > rename from networking/dec_21140.rst
 > rename to legacy-networking/dec_21140.rst
 > diff --git a/networking/index.rst b/legacy-networking/index.rst
 > similarity index 92%
 > rename from networking/index.rst
 > rename to 

Re: [PATCH rtems-docs v3] networking: Rename to legacy networking

[Joel Sherrill]

On Fri, Mar 26, 2021, 5:53 PM Vijay Kumar Banerjee  wrote:

> Hi Joel,
>
> On Fri, Mar 26, 2021, 16:46 Joel Sherrill  wrote:
>
>> I thought I said this looked good on the first round.
>>
> In this version of the patch I send networking to bottom of the index in
> coverpage.
>

Sorry. That was a subtle change. Thanks for making it.

>
>
>> My only question was whether you want to update it the minimum to point
>> to the legacy stack as a separate package. But that should be a follow up
>> patch.
>>
>
> Yes, I'll add a note in the docs about the separate package and how to
> build it manually and with RSB. I'll send that as a separate patch as you
> mentioned.
>

Good enough. Thanks to you the legacy network stack is not as dead as it
could be. Since you did this fantastic piece of work to put it in a
separate repository, we just want the documentation to reflect that.

>
>
> Best regards,
> Vijay
>
>>
>> --joel
>>
>> On Fri, Mar 26, 2021 at 3:48 PM Vijay Kumar Banerjee 
>> wrote:
>>
>>> Ping :)
>>>
>>>
>>> On Tue, Mar 23, 2021 at 2:04 PM Vijay Kumar Banerjee 
>>> wrote:
>>> >
>>> > ---
>>> >  book/index_book.rst | 2 +-
>>> >  {networking => legacy-networking}/command.rst   | 0
>>> >  {networking => legacy-networking}/conf.py   | 6 +++---
>>> >  {networking => legacy-networking}/dec_21140.rst | 0
>>> >  {networking => legacy-networking}/index.rst | 2 +-
>>> >  {networking => legacy-networking}/network_servers.rst   | 0
>>> >  .../network_task_structure.rst  | 0
>>> >  {networking => legacy-networking}/networking_driver.rst | 0
>>> >  {networking => legacy-networking}/preface.rst   | 0
>>> >  {networking => legacy-networking}/testing_the_driver.rst| 0
>>> >  .../using_networking_rtems_app.rst  | 0
>>> >  {networking => legacy-networking}/wscript   | 0
>>> >  wscript | 4 ++--
>>> >  13 files changed, 7 insertions(+), 7 deletions(-)
>>> >  rename {networking => legacy-networking}/command.rst (100%)
>>> >  rename {networking => legacy-networking}/conf.py (58%)
>>> >  rename {networking => legacy-networking}/dec_21140.rst (100%)
>>> >  rename {networking => legacy-networking}/index.rst (92%)
>>> >  rename {networking => legacy-networking}/network_servers.rst (100%)
>>> >  rename {networking => legacy-networking}/network_task_structure.rst
>>> (100%)
>>> >  rename {networking => legacy-networking}/networking_driver.rst (100%)
>>> >  rename {networking => legacy-networking}/preface.rst (100%)
>>> >  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
>>> >  rename {networking =>
>>> legacy-networking}/using_networking_rtems_app.rst (100%)
>>> >  rename {networking => legacy-networking}/wscript (100%)
>>> >
>>> > diff --git a/book/index_book.rst b/book/index_book.rst
>>> > index 8282006..afe15a1 100644
>>> > --- a/book/index_book.rst
>>> > +++ b/book/index_book.rst
>>> > @@ -23,7 +23,7 @@ Table of Contents
>>> > cpu_supplement/index.rst
>>> > develenv/index.rst
>>> > filesystem/index.rst
>>> > -   networking/index.rst
>>> > porting/index.rst
>>> > posix1003_1/index.rst
>>> > posix_users/index.rst
>>> > +   legacy_networking/index.rst
>>> > diff --git a/networking/command.rst b/legacy-networking/command.rst
>>> > similarity index 100%
>>> > rename from networking/command.rst
>>> > rename to legacy-networking/command.rst
>>> > diff --git a/networking/conf.py b/legacy-networking/conf.py
>>> > similarity index 58%
>>> > rename from networking/conf.py
>>> > rename to legacy-networking/conf.py
>>> > index 1c129bc..98a06b6 100644
>>> > --- a/networking/conf.py
>>> > +++ b/legacy-networking/conf.py
>>> > @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>>> >
>>> >  from conf import *
>>> >
>>> > -project = "RTEMS Networking User Manual"
>>> > +project = "RTEMS Legacy Networking User Manual"
>>> >
>>> >  latex_documents = [
>>> >  ('index',
>>> > - 'networking.tex',
>>> > - u'RTEMS Networking User Manual',
>>> > + 'legacy-networking.tex',
>>> > + u'RTEMS Legacy Networking User Manual',
>>> >   u'RTEMS Documentation Project',
>>> >   'manual'),
>>> >  ]
>>> > diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
>>> > similarity index 100%
>>> > rename from networking/dec_21140.rst
>>> > rename to legacy-networking/dec_21140.rst
>>> > diff --git a/networking/index.rst b/legacy-networking/index.rst
>>> > similarity index 92%
>>> > rename from networking/index.rst
>>> > rename to legacy-networking/index.rst
>>> > index f56a60d..b85119d 100644
>>> > --- a/networking/index.rst
>>> > +++ b/legacy-networking/index.rst
>>> > @@ -5,7 +5,7 @@
>>> >  .. highlight:: c
>>> >
>>> >  ==
>>> > -RTEMS Network User Manual 

Re: [PATCH rtems-docs v3] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

Hi Joel,

On Fri, Mar 26, 2021, 16:46 Joel Sherrill  wrote:

> I thought I said this looked good on the first round.
>
In this version of the patch I send networking to bottom of the index in
coverpage.


> My only question was whether you want to update it the minimum to point to
> the legacy stack as a separate package. But that should be a follow up
> patch.
>

Yes, I'll add a note in the docs about the separate package and how to
build it manually and with RSB. I'll send that as a separate patch as you
mentioned.


Best regards,
Vijay

>
> --joel
>
> On Fri, Mar 26, 2021 at 3:48 PM Vijay Kumar Banerjee 
> wrote:
>
>> Ping :)
>>
>>
>> On Tue, Mar 23, 2021 at 2:04 PM Vijay Kumar Banerjee 
>> wrote:
>> >
>> > ---
>> >  book/index_book.rst | 2 +-
>> >  {networking => legacy-networking}/command.rst   | 0
>> >  {networking => legacy-networking}/conf.py   | 6 +++---
>> >  {networking => legacy-networking}/dec_21140.rst | 0
>> >  {networking => legacy-networking}/index.rst | 2 +-
>> >  {networking => legacy-networking}/network_servers.rst   | 0
>> >  .../network_task_structure.rst  | 0
>> >  {networking => legacy-networking}/networking_driver.rst | 0
>> >  {networking => legacy-networking}/preface.rst   | 0
>> >  {networking => legacy-networking}/testing_the_driver.rst| 0
>> >  .../using_networking_rtems_app.rst  | 0
>> >  {networking => legacy-networking}/wscript   | 0
>> >  wscript | 4 ++--
>> >  13 files changed, 7 insertions(+), 7 deletions(-)
>> >  rename {networking => legacy-networking}/command.rst (100%)
>> >  rename {networking => legacy-networking}/conf.py (58%)
>> >  rename {networking => legacy-networking}/dec_21140.rst (100%)
>> >  rename {networking => legacy-networking}/index.rst (92%)
>> >  rename {networking => legacy-networking}/network_servers.rst (100%)
>> >  rename {networking => legacy-networking}/network_task_structure.rst
>> (100%)
>> >  rename {networking => legacy-networking}/networking_driver.rst (100%)
>> >  rename {networking => legacy-networking}/preface.rst (100%)
>> >  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
>> >  rename {networking =>
>> legacy-networking}/using_networking_rtems_app.rst (100%)
>> >  rename {networking => legacy-networking}/wscript (100%)
>> >
>> > diff --git a/book/index_book.rst b/book/index_book.rst
>> > index 8282006..afe15a1 100644
>> > --- a/book/index_book.rst
>> > +++ b/book/index_book.rst
>> > @@ -23,7 +23,7 @@ Table of Contents
>> > cpu_supplement/index.rst
>> > develenv/index.rst
>> > filesystem/index.rst
>> > -   networking/index.rst
>> > porting/index.rst
>> > posix1003_1/index.rst
>> > posix_users/index.rst
>> > +   legacy_networking/index.rst
>> > diff --git a/networking/command.rst b/legacy-networking/command.rst
>> > similarity index 100%
>> > rename from networking/command.rst
>> > rename to legacy-networking/command.rst
>> > diff --git a/networking/conf.py b/legacy-networking/conf.py
>> > similarity index 58%
>> > rename from networking/conf.py
>> > rename to legacy-networking/conf.py
>> > index 1c129bc..98a06b6 100644
>> > --- a/networking/conf.py
>> > +++ b/legacy-networking/conf.py
>> > @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>> >
>> >  from conf import *
>> >
>> > -project = "RTEMS Networking User Manual"
>> > +project = "RTEMS Legacy Networking User Manual"
>> >
>> >  latex_documents = [
>> >  ('index',
>> > - 'networking.tex',
>> > - u'RTEMS Networking User Manual',
>> > + 'legacy-networking.tex',
>> > + u'RTEMS Legacy Networking User Manual',
>> >   u'RTEMS Documentation Project',
>> >   'manual'),
>> >  ]
>> > diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
>> > similarity index 100%
>> > rename from networking/dec_21140.rst
>> > rename to legacy-networking/dec_21140.rst
>> > diff --git a/networking/index.rst b/legacy-networking/index.rst
>> > similarity index 92%
>> > rename from networking/index.rst
>> > rename to legacy-networking/index.rst
>> > index f56a60d..b85119d 100644
>> > --- a/networking/index.rst
>> > +++ b/legacy-networking/index.rst
>> > @@ -5,7 +5,7 @@
>> >  .. highlight:: c
>> >
>> >  ==
>> > -RTEMS Network User Manual (|version|).
>> > +RTEMS Legacy Network User Manual (|version|).
>> >  ==
>> >
>> >  .. topic:: Copyrights and License
>> > diff --git a/networking/network_servers.rst
>> b/legacy-networking/network_servers.rst
>> > similarity index 100%
>> > rename from networking/network_servers.rst
>> > rename to legacy-networking/network_servers.rst
>> > diff --git a/networking/network_task_structure.rst
>> 

Re: [PATCH rtems-docs v3] networking: Rename to legacy networking

[Joel Sherrill]

I thought I said this looked good on the first round.

My only question was whether you want to update it the minimum to point to
the legacy stack as a separate package. But that should be a follow up
patch.

--joel

On Fri, Mar 26, 2021 at 3:48 PM Vijay Kumar Banerjee 
wrote:

> Ping :)
>
>
> On Tue, Mar 23, 2021 at 2:04 PM Vijay Kumar Banerjee 
> wrote:
> >
> > ---
> >  book/index_book.rst | 2 +-
> >  {networking => legacy-networking}/command.rst   | 0
> >  {networking => legacy-networking}/conf.py   | 6 +++---
> >  {networking => legacy-networking}/dec_21140.rst | 0
> >  {networking => legacy-networking}/index.rst | 2 +-
> >  {networking => legacy-networking}/network_servers.rst   | 0
> >  .../network_task_structure.rst  | 0
> >  {networking => legacy-networking}/networking_driver.rst | 0
> >  {networking => legacy-networking}/preface.rst   | 0
> >  {networking => legacy-networking}/testing_the_driver.rst| 0
> >  .../using_networking_rtems_app.rst  | 0
> >  {networking => legacy-networking}/wscript   | 0
> >  wscript | 4 ++--
> >  13 files changed, 7 insertions(+), 7 deletions(-)
> >  rename {networking => legacy-networking}/command.rst (100%)
> >  rename {networking => legacy-networking}/conf.py (58%)
> >  rename {networking => legacy-networking}/dec_21140.rst (100%)
> >  rename {networking => legacy-networking}/index.rst (92%)
> >  rename {networking => legacy-networking}/network_servers.rst (100%)
> >  rename {networking => legacy-networking}/network_task_structure.rst
> (100%)
> >  rename {networking => legacy-networking}/networking_driver.rst (100%)
> >  rename {networking => legacy-networking}/preface.rst (100%)
> >  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
> >  rename {networking => legacy-networking}/using_networking_rtems_app.rst
> (100%)
> >  rename {networking => legacy-networking}/wscript (100%)
> >
> > diff --git a/book/index_book.rst b/book/index_book.rst
> > index 8282006..afe15a1 100644
> > --- a/book/index_book.rst
> > +++ b/book/index_book.rst
> > @@ -23,7 +23,7 @@ Table of Contents
> > cpu_supplement/index.rst
> > develenv/index.rst
> > filesystem/index.rst
> > -   networking/index.rst
> > porting/index.rst
> > posix1003_1/index.rst
> > posix_users/index.rst
> > +   legacy_networking/index.rst
> > diff --git a/networking/command.rst b/legacy-networking/command.rst
> > similarity index 100%
> > rename from networking/command.rst
> > rename to legacy-networking/command.rst
> > diff --git a/networking/conf.py b/legacy-networking/conf.py
> > similarity index 58%
> > rename from networking/conf.py
> > rename to legacy-networking/conf.py
> > index 1c129bc..98a06b6 100644
> > --- a/networking/conf.py
> > +++ b/legacy-networking/conf.py
> > @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
> >
> >  from conf import *
> >
> > -project = "RTEMS Networking User Manual"
> > +project = "RTEMS Legacy Networking User Manual"
> >
> >  latex_documents = [
> >  ('index',
> > - 'networking.tex',
> > - u'RTEMS Networking User Manual',
> > + 'legacy-networking.tex',
> > + u'RTEMS Legacy Networking User Manual',
> >   u'RTEMS Documentation Project',
> >   'manual'),
> >  ]
> > diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
> > similarity index 100%
> > rename from networking/dec_21140.rst
> > rename to legacy-networking/dec_21140.rst
> > diff --git a/networking/index.rst b/legacy-networking/index.rst
> > similarity index 92%
> > rename from networking/index.rst
> > rename to legacy-networking/index.rst
> > index f56a60d..b85119d 100644
> > --- a/networking/index.rst
> > +++ b/legacy-networking/index.rst
> > @@ -5,7 +5,7 @@
> >  .. highlight:: c
> >
> >  ==
> > -RTEMS Network User Manual (|version|).
> > +RTEMS Legacy Network User Manual (|version|).
> >  ==
> >
> >  .. topic:: Copyrights and License
> > diff --git a/networking/network_servers.rst
> b/legacy-networking/network_servers.rst
> > similarity index 100%
> > rename from networking/network_servers.rst
> > rename to legacy-networking/network_servers.rst
> > diff --git a/networking/network_task_structure.rst
> b/legacy-networking/network_task_structure.rst
> > similarity index 100%
> > rename from networking/network_task_structure.rst
> > rename to legacy-networking/network_task_structure.rst
> > diff --git a/networking/networking_driver.rst
> b/legacy-networking/networking_driver.rst
> > similarity index 100%
> > rename from networking/networking_driver.rst
> > rename to legacy-networking/networking_driver.rst
> > diff --git a/networking/preface.rst b/legacy-networking/preface.rst
> > 

Two Resource Leaks

[Joel Sherrill]

Hi

Jennifer has been working on a network driver and had some odd failures in
libbsd. I suggested turning on rtems debug and that caused a number of
libbsd tests to fail. She pointed me in the right direction and I found
that the following patch resulted in the stack address being freed
including an "align up" adjustment in some cases. This looks to be from
something Sebastian committed early this month.

https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1

I am not sure how that wasn't noticed since about 40 tests were failing on
psim due to that.

I have attached a straightforward patch to address this issue.

Unfortunately, even with this patch and using the RTEMS hash just before
this patch program01 and syscalls01 in libbsd fail. I debugged into
syscalls01 enough to find that there are 7 blocks at the beginning of one
of the tests and 5 after. There is another leak and I tried using the has
before Sebastian's change above but it is still leaking.

On top of that, psxconfig01 and spconfig01 are failing on psim which
appears to be independent. I am not sure what these are but it is something
about minimum stack size not matching. Since I was looking for stack memory
issues, I started to investigate these but decided they were not
allocation/free issues.

Help really appreciated in addressing these leaks.

Thanks.

--joel
From b617122b4c8999284800c2f1a89954edf8e2cd14 Mon Sep 17 00:00:00 2001
From: Joel Sherrill 
Date: Thu, 25 Mar 2021 18:08:23 -0500
Subject: [PATCH 2/2] cpukit stack: Keep and free correct stack address

---
 cpukit/include/rtems/score/stack.h | 2 ++
 cpukit/include/rtems/score/stackimpl.h | 7 +--
 cpukit/score/src/threadinitialize.c| 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/stack.h b/cpukit/include/rtems/score/stack.h
index 23421cf..5498145 100644
--- a/cpukit/include/rtems/score/stack.h
+++ b/cpukit/include/rtems/score/stack.h
@@ -52,6 +52,8 @@ extern "C" {
 typedef struct {
   /** This is the stack size. */
   size_t  size;
+  /** This is the allocated address of stack and must be the one freed. */
+  void   *address_to_free;
   /** This is the low memory address of stack. */
   void   *area;
 }   Stack_Control;
diff --git a/cpukit/include/rtems/score/stackimpl.h b/cpukit/include/rtems/score/stackimpl.h
index c152060..92d08e9 100644
--- a/cpukit/include/rtems/score/stackimpl.h
+++ b/cpukit/include/rtems/score/stackimpl.h
@@ -41,17 +41,20 @@ extern "C" {
  * reserved for a stack.
  *
  * @param[out] the_stack The stack to initialize.
+ * @param address_to_free The address allocated which must be freed.
  * @param starting_address The starting_address for the new stack.
  * @param size The size of the stack in bytes.
  */
 RTEMS_INLINE_ROUTINE void _Stack_Initialize (
   Stack_Control *the_stack,
+  void  *address_to_free,
   void  *starting_address,
   size_t size
 )
 {
-  the_stack->area = starting_address;
-  the_stack->size = size;
+  the_stack->address_to_free = address_to_free;
+  the_stack->area= starting_address;
+  the_stack->size= size;
 }
 
 /**
diff --git a/cpukit/score/src/threadinitialize.c b/cpukit/score/src/threadinitialize.c
index 18c98c6..c12436d 100644
--- a/cpukit/score/src/threadinitialize.c
+++ b/cpukit/score/src/threadinitialize.c
@@ -83,7 +83,7 @@ void _Thread_Free(
*  Free the rest of the memory associated with this task
*  and set the associated pointers to NULL for safety.
*/
-  ( *the_thread->Start.stack_free )( the_thread->Start.Initial_stack.area );
+  ( *the_thread->Start.stack_free )( the_thread->Start.Initial_stack.address_to_free );
 
 #if defined(RTEMS_SMP)
   _ISR_lock_Destroy( _thread->Scheduler.Lock );
@@ -158,6 +158,7 @@ static bool _Thread_Try_initialize(
 
   _Stack_Initialize(
 _thread->Start.Initial_stack,
+config->stack_area,
 stack_begin,
 stack_end - stack_begin
   );
-- 
1.8.3.1

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

RE: [PATCH v4] covoar: Handle periods in symbols from objdump

[Alex White]

ping

> -Original Message-
> From: Alex White 
> Sent: Friday, March 19, 2021 2:10 PM
> To: devel@rtems.org
> Cc: Alex White 
> Subject: [PATCH v4] covoar: Handle periods in symbols from objdump
> 
> Occasionally the compiler will generate symbols that look similar to symbols
> defined in RTEMS code except that they contain some suffix.
> These symbol suffixes are only found in the ELF symbol table; the symbols
> appear to be normal in the DWARF info. This appears to be happening on all
> architectures.
> 
> For example, the function _Message_queue_Create from rtems appears as
> "_Message_queue_Create.part.0". Other suffixes include ".isra.0",
> ".constprop.0", and ".0".
> 
> This looks to be related to compiler optimizations. Symbols with suffixes
> were being treated as unique. For our purposes, they should be mapped to
> the equivalent symbols in the DWARF info. This has been fixed.
> ---
>  tester/covoar/ExecutableInfo.cc   |  3 +--
>  tester/covoar/ObjdumpProcessor.cc | 15 +++
>  tester/covoar/SymbolTable.cc  | 12 +---
>  3 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/tester/covoar/ExecutableInfo.cc
> b/tester/covoar/ExecutableInfo.cc index c996d75..1e14721 100644
> --- a/tester/covoar/ExecutableInfo.cc
> +++ b/tester/covoar/ExecutableInfo.cc
> @@ -118,8 +118,7 @@ namespace Coverage {
>  // Obtain the coverage map containing the specified address.
>  itsSymbol = theSymbolTable.getSymbol( address );
>  if (itsSymbol != "") {
> -  it = coverageMaps.find( itsSymbol );
> -  aCoverageMap = (*it).second;
> +  aCoverageMap = (itsSymbol);
>  }
> 
>  return aCoverageMap;
> diff --git a/tester/covoar/ObjdumpProcessor.cc
> b/tester/covoar/ObjdumpProcessor.cc
> index 0647ff9..e19fa92 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -417,6 +417,21 @@ namespace Coverage {
>  processSymbol = false;
>  theInstructions.clear();
> 
> +// Look for a '.' character and strip everything after it.
> +// There is a chance that the compiler splits function bodies to 
> improve
> +// inlining. If there exists some inlinable function that contains a
> +// branch where one path is more expensive and less likely to be 
> taken
> +// than the other, inlining only the branch instruction and the less
> +// expensive path results in smaller code size while preserving most 
> of
> +// the performance improvement.
> +// When this happens, the compiler will generate a function with a
> +// ".part.n" suffix. For our purposes, this generated function part 
> is
> +// equivalent to the original function and should be treated as such.
> +char *periodIndex = strstr(symbol, ".");
> +if (periodIndex != NULL) {
> +  *periodIndex = 0;
> +}
> +
>  // See if the new symbol is one that we care about.
>  if (SymbolsToAnalyze->isDesired( symbol )) {
>currentSymbol = symbol;
> diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
> index 53bc8af..00062cc 100644
> --- a/tester/covoar/SymbolTable.cc
> +++ b/tester/covoar/SymbolTable.cc
> @@ -46,12 +46,18 @@ namespace Coverage {
>  symbolData.startingAddress = start;
>  symbolData.length = length;
> 
> -if ( info[ symbol ].empty() == false ) {
> -  if ( info[ symbol ].front().length != length ) {
> +for (auto& symData : info[ symbol ]) {
> +  // The starting address could differ since we strip any suffixes 
> beginning
> +  // with a '.'
> +  if (symData.startingAddress != start) {
> +continue;
> +  }
> +
> +  if (symData.length != length) {
>  std::ostringstream what;
>  what << "Different lengths for the symbol "
>   << symbol
> - << " (" << info[ symbol ].front().length
> + << " (" << symData.length
>   << " and " << length
>   << ")";
>  throw rld::error( what, "SymbolTable::addSymbol" );
> --
> 2.27.0

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

Re: [PATCH rtems-docs v3] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

Ping :)


On Tue, Mar 23, 2021 at 2:04 PM Vijay Kumar Banerjee  wrote:
>
> ---
>  book/index_book.rst | 2 +-
>  {networking => legacy-networking}/command.rst   | 0
>  {networking => legacy-networking}/conf.py   | 6 +++---
>  {networking => legacy-networking}/dec_21140.rst | 0
>  {networking => legacy-networking}/index.rst | 2 +-
>  {networking => legacy-networking}/network_servers.rst   | 0
>  .../network_task_structure.rst  | 0
>  {networking => legacy-networking}/networking_driver.rst | 0
>  {networking => legacy-networking}/preface.rst   | 0
>  {networking => legacy-networking}/testing_the_driver.rst| 0
>  .../using_networking_rtems_app.rst  | 0
>  {networking => legacy-networking}/wscript   | 0
>  wscript | 4 ++--
>  13 files changed, 7 insertions(+), 7 deletions(-)
>  rename {networking => legacy-networking}/command.rst (100%)
>  rename {networking => legacy-networking}/conf.py (58%)
>  rename {networking => legacy-networking}/dec_21140.rst (100%)
>  rename {networking => legacy-networking}/index.rst (92%)
>  rename {networking => legacy-networking}/network_servers.rst (100%)
>  rename {networking => legacy-networking}/network_task_structure.rst (100%)
>  rename {networking => legacy-networking}/networking_driver.rst (100%)
>  rename {networking => legacy-networking}/preface.rst (100%)
>  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
>  rename {networking => legacy-networking}/using_networking_rtems_app.rst 
> (100%)
>  rename {networking => legacy-networking}/wscript (100%)
>
> diff --git a/book/index_book.rst b/book/index_book.rst
> index 8282006..afe15a1 100644
> --- a/book/index_book.rst
> +++ b/book/index_book.rst
> @@ -23,7 +23,7 @@ Table of Contents
> cpu_supplement/index.rst
> develenv/index.rst
> filesystem/index.rst
> -   networking/index.rst
> porting/index.rst
> posix1003_1/index.rst
> posix_users/index.rst
> +   legacy_networking/index.rst
> diff --git a/networking/command.rst b/legacy-networking/command.rst
> similarity index 100%
> rename from networking/command.rst
> rename to legacy-networking/command.rst
> diff --git a/networking/conf.py b/legacy-networking/conf.py
> similarity index 58%
> rename from networking/conf.py
> rename to legacy-networking/conf.py
> index 1c129bc..98a06b6 100644
> --- a/networking/conf.py
> +++ b/legacy-networking/conf.py
> @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>
>  from conf import *
>
> -project = "RTEMS Networking User Manual"
> +project = "RTEMS Legacy Networking User Manual"
>
>  latex_documents = [
>  ('index',
> - 'networking.tex',
> - u'RTEMS Networking User Manual',
> + 'legacy-networking.tex',
> + u'RTEMS Legacy Networking User Manual',
>   u'RTEMS Documentation Project',
>   'manual'),
>  ]
> diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
> similarity index 100%
> rename from networking/dec_21140.rst
> rename to legacy-networking/dec_21140.rst
> diff --git a/networking/index.rst b/legacy-networking/index.rst
> similarity index 92%
> rename from networking/index.rst
> rename to legacy-networking/index.rst
> index f56a60d..b85119d 100644
> --- a/networking/index.rst
> +++ b/legacy-networking/index.rst
> @@ -5,7 +5,7 @@
>  .. highlight:: c
>
>  ==
> -RTEMS Network User Manual (|version|).
> +RTEMS Legacy Network User Manual (|version|).
>  ==
>
>  .. topic:: Copyrights and License
> diff --git a/networking/network_servers.rst 
> b/legacy-networking/network_servers.rst
> similarity index 100%
> rename from networking/network_servers.rst
> rename to legacy-networking/network_servers.rst
> diff --git a/networking/network_task_structure.rst 
> b/legacy-networking/network_task_structure.rst
> similarity index 100%
> rename from networking/network_task_structure.rst
> rename to legacy-networking/network_task_structure.rst
> diff --git a/networking/networking_driver.rst 
> b/legacy-networking/networking_driver.rst
> similarity index 100%
> rename from networking/networking_driver.rst
> rename to legacy-networking/networking_driver.rst
> diff --git a/networking/preface.rst b/legacy-networking/preface.rst
> similarity index 100%
> rename from networking/preface.rst
> rename to legacy-networking/preface.rst
> diff --git a/networking/testing_the_driver.rst 
> b/legacy-networking/testing_the_driver.rst
> similarity index 100%
> rename from networking/testing_the_driver.rst
> rename to legacy-networking/testing_the_driver.rst
> diff --git a/networking/using_networking_rtems_app.rst 
> b/legacy-networking/using_networking_rtems_app.rst
> similarity index 100%
> rename from 

[PATCH rtems-examples] lvgl/wscript: Add libpath to search for required libraries

[Vijay Kumar Banerjee]

---
 lvgl/wscript | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lvgl/wscript b/lvgl/wscript
index 064ebed..281af25 100644
--- a/lvgl/wscript
+++ b/lvgl/wscript
@@ -5,11 +5,19 @@
 
 import rtems_waf.rtems as rtems
 import rtems_waf.rtems_bsd as rtems_bsd
+import os
 
 def configure(conf):
+arch_lib_path = rtems.arch_bsp_lib_path(str(conf.env.RTEMS_VERSION),
+str(conf.env.RTEMS_ARCH_BSP))
+arch_lib_path = os.path.join(conf.env.PREFIX, arch_lib_path)
 rtems.check_lib_path(conf, lib = 'm')
-rtems.check_lib_path(conf, lib = 'lvgl', mandatory = False)
-rtems.check_lib_path(conf, lib = 'bsd', mandatory = False)
+rtems.check_lib_path(conf, lib = 'lvgl',
+ libpath = [arch_lib_path],
+ mandatory = False)
+rtems.check_lib_path(conf, lib = 'bsd',
+ libpath = [arch_lib_path],
+ mandatory = False)
 
 def build(bld):
 bld.recurse('hello')
-- 
2.26.2

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

[PATCH rtems-littlevgl] wscript: Upgrade rtems_version number

[Vijay Kumar Banerjee]

---
 lvgl.py | 2 +-
 wscript | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lvgl.py b/lvgl.py
index 0eadd90..2574acd 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -110,5 +110,5 @@ def build(bld):
 bld.install_files(os.path.join("${PREFIX}", arch_inc_path, 
include_path),
   include_headers)
 bld.install_files(os.path.join('${PREFIX}', arch_lib_path), ["liblvgl.a"])
-bld.install_files(os.path.join('${PREFIX}', arch_inc_path, include_path),
+bld.install_files(os.path.join('${PREFIX}', arch_inc_path),
 [lv_conf_h, lv_drv_conf_h])
diff --git a/wscript b/wscript
index b3aa96f..6e2c722 100644
--- a/wscript
+++ b/wscript
@@ -30,7 +30,7 @@ from __future__ import print_function
 import lvgl
 import sys
 
-rtems_version = "5"
+rtems_version = "6"
 
 try:
 import rtems_waf.rtems as rtems
-- 
2.26.2

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

[PATCH rtems-libbsd] libbsd.py: Build i2c shell command

[Vijay Kumar Banerjee]

---
 libbsd.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libbsd.py b/libbsd.py
index f7efda43..fe0566e7 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -258,6 +258,7 @@ class rtems(builder.Module):
 'rtems/rtems-bsd-rc-conf.c',
 'rtems/rtems-bsd-set-if-input.c',
 'rtems/rtems-bsd-shell-arp.c',
+'rtems/rtems-bsd-shell-i2c.c',
 'rtems/rtems-bsd-shell-ifconfig.c',
 'rtems/rtems-bsd-shell-ifmcstat.c',
 'rtems/rtems-bsd-shell-netstat.c',
-- 
2.26.2

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

Instructions to build Micro-Python on RTEMS

[Eshan Dhawan]

Hello Everyone,
Where can I find instructions to Build MicroPython on RTEMS??

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

Re: GSoC Project : Package Micro-python

[Eshan Dhawan]

On Fri, Mar 26, 2021 at 5:46 AM Joel Sherrill  wrote:

>
>
> On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom  wrote:
>
>> On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan 
>> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom  wrote:
>> >>
>> >> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan 
>> wrote:
>> >> >
>> >> >
>> >> > Apologies for the late reply.
>> >> >
>> >> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill 
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom 
>> wrote:
>> >> >>>
>> >> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill 
>> wrote:
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom 
>> wrote:
>> >> >>> >>
>> >> >>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan <
>> eshandhawa...@gmail.com> wrote:
>> >> >>> >> >
>> >> >>> >> > Hello Everyone,
>> >> >>> >> > I wanted to take Packaging Micro Python up as GSOC project
>> this summer and the project will also include packaging LUA and picoC
>> >> >>> >> > The ticket for Micro Python  :
>> https://devel.rtems.org/ticket/4349
>> >> >>> >> > What would be the complete Scope of the project?
>> >> >>> >> > And what would be a good starting point?
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >> Well, I guess Joel must have described the task, so I'll leave
>> it to
>> >> >>> >> him to fill in some more details.
>> >> >>> >>
>> >> >>> >> Adding RSB packages may be not sufficient coding work for GSoC.
>> It is
>> >> >>> >> important in the proposal to identify what would be the coding
>> >> >>> >> activities involved in this project. For example, we know from
>> >> >>> >> experience that Lua can just be built from some minor tailoring
>> of its
>> >> >>> >> Makefile, so the package is very straightforward. However, the
>> >> >>> >> projects you mention are scripting environments, so maybe
>> creating a
>> >> >>> >> framework in RTEMS for a "shell/intepreter" that can be built
>> as an
>> >> >>> >> add-on by RSB would be a proper way to scope this effort
>> >> >
>> >> > Packaging might not be a lot of coding part but adding its
>> documentation and its example would be a very iterative and time consuming
>> process.
>> >>
>> >> Remember that code is what counts, while we expect the other stuff to
>> >> come along too, you don't want to be doing 90% doco and 10% code. Just
>> >> keep it in mind.
>> >
>> > What would be a good inclusion to this project ?
>> > I was thinking long double support since I worked on porting POSIX
>> functions I might find it easier.
>> > But it might interfere with matt's project if I understand that project
>> correctly.
>>
>> Right, please don't include that. You'll want to think/talk through
>> (with Joel, maybe) what could be good code contributions. If the RSB
>> packaging is fairly minimal, then creating a suite of examples might
>> be one way to increase the SLOC contributions. I also think there is
>> merit to the idea of creating a "plug-in" way to add shells to RTEMS.
>> Maybe even refactoring our current shell out to a add-on package then.
>> Just a thought.
>>
>
> I'd rather see two languages with good packaging, examples for RTEMS use
> cases, and documentation. It's a fair project.
>
> If you get through those, we can find another language. TCL probably. I
> don't expect Forth or  LISP to be high on the list. Lol
>
We can figure that out while framing the proposal time management section.
That how many languages can be packaged.
Currently, the scope of the project is to be determined so I can start with
the Proposal.

>
>> >>
>> >>
>> >> >>>
>> >> >>> >
>> >> >>> >
>> >> >>> > I agree that Lua and Micropython should build easy but I had more
>> >> >>> > in mind.
>> >> >>> >
>> >> >>> > The full project was language stacks for RTEMS with a better user
>> >> >>> > experience for Micropython, Lua, Tcl, etc although I am not sure
>> what
>> >> >>> > etc would entail. I am not sure all three can be completed in
>> the new
>> >> >>> > GSoC timeframe. All would follow the same pattern:
>> >> >
>> >> > Etc can be managed while framing the proposal according to how time
>> is being managed.
>> >> >>>
>> >> >>> >
>> >> >>> > + RSB package offering a reasonable default and access to
>> configuration
>> >> >>> > + Examples including at least bare embedded, use of custom
>> commands,
>> >> >>> > and integrating with RTEMS shell commands Perhaps  interactive
>> use with
>> >> >>> > command line history and editing integrated if we have that as a
>> library now.
>> >> >>> > + Documentation specific to RTEMS and the examples
>> >> >>> >
>> >> >>> > I imagined completely parallel kits for each embedded language
>> we wanted
>> >> >>> > to support.
>> >> >>> >
>> >> >>> > Does that help? Should he plan on Micropython and Lua?
>> >> >>> >
>> >> >>>
>> >> >>> Sure. Lua should be easy way to get started and develop the
>> >> >>> framework/infrastructure side in Phase 1. Phase 2 could be
>> extension
>> >> >>> to micropython / other 

Re: [PATCH] covoar/Target_arm: Add THUMB branch instructions

[Gedare Bloom]

Looks fine to me.

On Fri, Mar 26, 2021 at 11:53 AM Alex White  wrote:
>
> ping
>
> > -Original Message-
> > From: Alex White 
> > Sent: Thursday, March 11, 2021 12:26 PM
> > To: devel@rtems.org
> > Cc: Alex White 
> > Subject: [PATCH] covoar/Target_arm: Add THUMB branch instructions
> >
> > The ".n" and ".w" variants of the THUMB branch instructions were not
> > included in the list of conditional branch instructions. They have been 
> > added.
> > ---
> >  tester/covoar/Target_arm.cc | 34
> > ++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/tester/covoar/Target_arm.cc b/tester/covoar/Target_arm.cc
> > index 4b7b2e1..75ec406 100644
> > --- a/tester/covoar/Target_arm.cc
> > +++ b/tester/covoar/Target_arm.cc
> > @@ -36,6 +36,40 @@ namespace Target {
> >  conditionalBranchInstructions.push_back("bvc");
> >  conditionalBranchInstructions.push_back("bvs");
> >
> > +conditionalBranchInstructions.push_back("beq.n");
> > +conditionalBranchInstructions.push_back("bne.n");
> > +conditionalBranchInstructions.push_back("bcs.n");
> > +conditionalBranchInstructions.push_back("bhs.n");
> > +conditionalBranchInstructions.push_back("bcc.n");
> > +conditionalBranchInstructions.push_back("blo.n");
> > +conditionalBranchInstructions.push_back("bmi.n");
> > +conditionalBranchInstructions.push_back("bpl.n");
> > +conditionalBranchInstructions.push_back("bvs.n");
> > +conditionalBranchInstructions.push_back("bvc.n");
> > +conditionalBranchInstructions.push_back("bhi.n");
> > +conditionalBranchInstructions.push_back("bls.n");
> > +conditionalBranchInstructions.push_back("bge.n");
> > +conditionalBranchInstructions.push_back("blt.n");
> > +conditionalBranchInstructions.push_back("bgt.n");
> > +conditionalBranchInstructions.push_back("ble.n");
> > +
> > +conditionalBranchInstructions.push_back("beq.w");
> > +conditionalBranchInstructions.push_back("bne.w");
> > +conditionalBranchInstructions.push_back("bcs.w");
> > +conditionalBranchInstructions.push_back("bhs.w");
> > +conditionalBranchInstructions.push_back("bcc.w");
> > +conditionalBranchInstructions.push_back("blo.w");
> > +conditionalBranchInstructions.push_back("bmi.w");
> > +conditionalBranchInstructions.push_back("bpl.w");
> > +conditionalBranchInstructions.push_back("bvs.w");
> > +conditionalBranchInstructions.push_back("bvc.w");
> > +conditionalBranchInstructions.push_back("bhi.w");
> > +conditionalBranchInstructions.push_back("bls.w");
> > +conditionalBranchInstructions.push_back("bge.w");
> > +conditionalBranchInstructions.push_back("blt.w");
> > +conditionalBranchInstructions.push_back("bgt.w");
> > +conditionalBranchInstructions.push_back("ble.w");
> > +
> >  conditionalBranchInstructions.sort();
> >
> >}
> > --
> > 2.27.0
>
> ___
> 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: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel,

I finally built rtems-libbsd and see that pselect and sockatmark are
both defined there. I went ahead and added a "In rtems-libbsd" column
in the spreadsheet to reflect that.

With those two defined, it looks like the only methods from the FACE
3.0 General Purpose Profile that aren't currently supported are
confstr() and the  set. Could I ask, what is the thinking on
those? The man page suggests that spawn was created with embedded
systems in mind, but I'd guess a conscious decision was made to leave
them out? How about confstr?

Thank you!

Matt


On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> Thanks very much, that's a big help!  Correct, I've been updating the
>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>> in rtems/cpukit and implemented in Newlib.
>>
>> One additional question, please: I haven't yet looked into the source
>> of NetBSD or FreeBSD, but I do see that Newlib already implements
>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>> sockatmark (net.cc). None of them are defined in the rtems environment
>> yet. Is there any reason why the NetBSD/FreeBSD version would be
>> preferable to Newlib for these? Or is it just a matter of testing
>> what's out there to find what works well in the rtems environment?
>
>
> Without looking at the newlib git repo, I can tell you that the files
> you cite are the implementation of those methods for Cygwin. Just
> because they are in C++. :)
>
> The parts of the newlib repo RTEMS uses are under the newlib/
> subdirectory not the cygwin one. Within that, there is a libc/sys and
> only libc/sys/rtems is used for RTEMS. The others are for different
> operating systems. There are a few places with "machine" directory
> structures. Only the ones for the architecture you are building for
> is used.
>
> As to why NetBSD for libdl, that is because portions of the code
> originated there.
>
> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> source as we can keep it.
>
>>
>>
>> In my proposal I'll take your advice and work on some of the easier
>> ones first in order to get the experience and process down.
>
>
> There are tickets for a lot of methods. The rtems-docs repo has the
> csv file (e.g. spreadsheet) which tracks RTEMS support against
> various standards. The RTEMS POSIX Compliance Guide is generated
> from that csv file. Between those, you can find other methods to ask
> about. In general, if it is required by the Software Communications
> Architecture (SCA) or FACE Technical Standard, then it is a method
> someone expected to possibly be used in an embedded system.
> SCA is a set of POSIX profiles focused on software defined radios and
> the FACE Technical Standard was developed with avionics in mind.
>
> But any are fair game if they are actually implementable. I don;t think
> the Compliance Guide says it yet, but we decided last year that
> wordexp() is likely not supportable on RTEMS. The newlib
> implementation assumes the presence of a shell with wildcard expansion
> and ability to fork a process.
>
> --joel
>
>>
>>
>> Thank you again for your time!
>>
>> Matt
>>
>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>> >
>> > Wow! Good work. There is a lot to digest here. Comments interspersed.
>> >
>> > I assume the spreadsheet is updated.
>> >
>> > On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  
>> > wrote:
>> >>
>> >> Hi Dr. Joel,
>> >>
>> >> I've gone over the list a few times now and see a few categories shaping 
>> >> up:
>> >>
>> >> 1) Already done (In Newlib source, defined in libc.a):
>> >> a) reallocarray
>> >> b) qsort_r
>> >> c) memmem
>> >> d) strlcat / strlcpy
>> >> d) wcslcat / wcslcpy
>> >> *Out of this group, strlcat and strlcpy also show up in
>> >> src/rtems/cpukit. Why is that?
>> >
>> >
>> > The good news is that we support these. :)
>> >
>> > It looks to me that strlcat and strlcpy are used in cpukit but not 
>> > implemented
>> > there. Where do you think they are implemented.
>> >
>> > This is a good example where a source code browser is helpful. grep can
>> > often answer the question but a source code browser can be easier. 
>> > Personally,
>> > I use cscope but that is exceedingly old school. Any modern IDE should be
>> > helpful.
>> >
>> >>
>> >> 2) Not done yet (Do not show up in Newlib source or RTEMS):
>> >> a) getlocalename_l
>> >> b) posix_getdents
>> >> c) sem_clockwait
>> >> d) sig2str / str2sig
>> >>
>> >> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
>> >> a) pthread_cond_clockwait
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)
>> >> b) pthread_mutex_clocklock
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)
>> >> c) pthread_rwlock_clockrdlock
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> >> c) pthread_rwlock_clockwrlock
>> >> 

RE: [PATCH] covoar/Target_arm: Add THUMB branch instructions

[Alex White]

ping

> -Original Message-
> From: Alex White 
> Sent: Thursday, March 11, 2021 12:26 PM
> To: devel@rtems.org
> Cc: Alex White 
> Subject: [PATCH] covoar/Target_arm: Add THUMB branch instructions
> 
> The ".n" and ".w" variants of the THUMB branch instructions were not
> included in the list of conditional branch instructions. They have been added.
> ---
>  tester/covoar/Target_arm.cc | 34
> ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/tester/covoar/Target_arm.cc b/tester/covoar/Target_arm.cc
> index 4b7b2e1..75ec406 100644
> --- a/tester/covoar/Target_arm.cc
> +++ b/tester/covoar/Target_arm.cc
> @@ -36,6 +36,40 @@ namespace Target {
>  conditionalBranchInstructions.push_back("bvc");
>  conditionalBranchInstructions.push_back("bvs");
> 
> +conditionalBranchInstructions.push_back("beq.n");
> +conditionalBranchInstructions.push_back("bne.n");
> +conditionalBranchInstructions.push_back("bcs.n");
> +conditionalBranchInstructions.push_back("bhs.n");
> +conditionalBranchInstructions.push_back("bcc.n");
> +conditionalBranchInstructions.push_back("blo.n");
> +conditionalBranchInstructions.push_back("bmi.n");
> +conditionalBranchInstructions.push_back("bpl.n");
> +conditionalBranchInstructions.push_back("bvs.n");
> +conditionalBranchInstructions.push_back("bvc.n");
> +conditionalBranchInstructions.push_back("bhi.n");
> +conditionalBranchInstructions.push_back("bls.n");
> +conditionalBranchInstructions.push_back("bge.n");
> +conditionalBranchInstructions.push_back("blt.n");
> +conditionalBranchInstructions.push_back("bgt.n");
> +conditionalBranchInstructions.push_back("ble.n");
> +
> +conditionalBranchInstructions.push_back("beq.w");
> +conditionalBranchInstructions.push_back("bne.w");
> +conditionalBranchInstructions.push_back("bcs.w");
> +conditionalBranchInstructions.push_back("bhs.w");
> +conditionalBranchInstructions.push_back("bcc.w");
> +conditionalBranchInstructions.push_back("blo.w");
> +conditionalBranchInstructions.push_back("bmi.w");
> +conditionalBranchInstructions.push_back("bpl.w");
> +conditionalBranchInstructions.push_back("bvs.w");
> +conditionalBranchInstructions.push_back("bvc.w");
> +conditionalBranchInstructions.push_back("bhi.w");
> +conditionalBranchInstructions.push_back("bls.w");
> +conditionalBranchInstructions.push_back("bge.w");
> +conditionalBranchInstructions.push_back("blt.w");
> +conditionalBranchInstructions.push_back("bgt.w");
> +conditionalBranchInstructions.push_back("ble.w");
> +
>  conditionalBranchInstructions.sort();
> 
>}
> --
> 2.27.0

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

Re: [PATCH v7 2/2] covoar/Target_i386: Add NOP patterns

[Gedare Bloom]

seriously, push this patch by itself already :)

On Fri, Mar 26, 2021 at 10:40 AM Alex White  wrote:
>
> A couple of NOP patterns found with the pc686 BSP were not detected.
> This has been fixed.
> ---
>  tester/covoar/Target_i386.cc | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/tester/covoar/Target_i386.cc b/tester/covoar/Target_i386.cc
> index e0c9c0f..4567c1e 100644
> --- a/tester/covoar/Target_i386.cc
> +++ b/tester/covoar/Target_i386.cc
> @@ -87,6 +87,15 @@ namespace Target {
>size = 3;
>return true;
>  }
> +if (!strncmp( [strlen(line)-28], "lea0x0(%esi,%eiz,1),%esi", 
> 28)) {
> +  // Could be 4 or 7 bytes of padding.
> +  if (!strncmp( [strlen(line)-32], "00", 2)) {
> +size = 7;
> +  } else {
> +size = 4;
> +  }
> +  return true;
> +}
>
>  return false;
>}
> --
> 2.27.0
>
> ___
> 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 v7 0/2] Fix NOP recognition

[Alex White]

v7:
- Add comment clarifying `using` declaration in CoverageMapNotFoundError class

v6:
- Consolidate loop conditionals in Coverage::finalizeSymbol()

v5:
- Fix missing std::dec at the end of error message printing in
  Coverage::finalizeSymbol()

v4:
- Add specialized CoverageMapNotFoundError exception class to ExecutableInfo
- Catch ExecutableInfo::CoverageMapNotFoundError in Coverage::finalizeSymbol()

v3:
- Fix double increment of rangeIndex in Coverage::finalizeSymbol()

v2:
- Fix leftover debugging code in Coverage::finalizeSymbol()

This patch set fixes a couple cases where NOP instructions were showing up as 
unexecuted in coverage reports.

Alex White (2):
  covoar: Fix NOP execution marking
  covoar/Target_i386: Add NOP patterns

 tester/covoar/CoverageMapBase.cc  |  10 +++
 tester/covoar/CoverageMapBase.h   |   4 ++
 tester/covoar/DesiredSymbols.cc   |  38 +--
 tester/covoar/DesiredSymbols.h|  11 +++-
 tester/covoar/ExecutableInfo.cc   |   2 +-
 tester/covoar/ExecutableInfo.h|   5 ++
 tester/covoar/ObjdumpProcessor.cc | 105 ++
 tester/covoar/Target_i386.cc  |   9 +++
 8 files changed, 148 insertions(+), 36 deletions(-)

-- 
2.27.0

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

[PATCH v7 1/2] covoar: Fix NOP execution marking

[Alex White]

Some NOP instructions were not being marked as executed because they
are located at the end of uncovered ranges. This has been fixed.
---
 tester/covoar/CoverageMapBase.cc  |  10 +++
 tester/covoar/CoverageMapBase.h   |   4 ++
 tester/covoar/DesiredSymbols.cc   |  38 +--
 tester/covoar/DesiredSymbols.h|  11 +++-
 tester/covoar/ExecutableInfo.cc   |   2 +-
 tester/covoar/ExecutableInfo.h|   5 ++
 tester/covoar/ObjdumpProcessor.cc | 105 ++
 7 files changed, 139 insertions(+), 36 deletions(-)

diff --git a/tester/covoar/CoverageMapBase.cc b/tester/covoar/CoverageMapBase.cc
index ad0080d..6ca5cf7 100644
--- a/tester/covoar/CoverageMapBase.cc
+++ b/tester/covoar/CoverageMapBase.cc
@@ -142,6 +142,11 @@ namespace Coverage {
 return size;
   }
 
+  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
+  {
+return Ranges.at(index).size();
+  }
+
   bool CoverageMapBase::getBeginningOfInstruction(
 uint32_t  address,
 uint32_t* beginning
@@ -178,6 +183,11 @@ namespace Coverage {
 return Ranges.front().lowAddress;
   }
 
+  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
+  {
+return Ranges.at(index).lowAddress;
+  }
+
   bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) const
   {
 for ( auto r : Ranges ) {
diff --git a/tester/covoar/CoverageMapBase.h b/tester/covoar/CoverageMapBase.h
index 6ad76d3..a58c696 100644
--- a/tester/covoar/CoverageMapBase.h
+++ b/tester/covoar/CoverageMapBase.h
@@ -156,6 +156,8 @@ namespace Coverage {
  */
 int32_t getFirstLowAddress() const;
 
+uint32_t getLowAddressOfRange( size_t index ) const;
+
 /*!
  *  This method returns true and sets the address range if
  *  the address falls with the bounds of an address range
@@ -177,6 +179,8 @@ namespace Coverage {
  */
 uint32_t getSize() const;
 
+uint32_t getSizeOfRange( size_t index ) const;
+
 /*!
  *  This method returns the address of the beginning of the
  *  instruction that contains the specified address.
diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
index b9a5bb7..c97b25c 100644
--- a/tester/covoar/DesiredSymbols.cc
+++ b/tester/covoar/DesiredSymbols.cc
@@ -142,7 +142,7 @@ namespace Coverage {
   CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
   if (theCoverageMap)
   {
-// Increment the total sizeInBytes byt the bytes in the symbol
+// Increment the total sizeInBytes by the bytes in the symbol
 stats.sizeInBytes += s.second.stats.sizeInBytes;
 
 // Now scan through the coverage map of this symbol.
@@ -202,6 +202,26 @@ namespace Coverage {
 uint32_t count;
 
 // Mark NOPs as executed
+a = s.second.stats.sizeInBytes - 1;
+count = 0;
+while (a > 0) {
+  if (theCoverageMap->isStartOfInstruction( a )) {
+break;
+  }
+
+  count++;
+
+  if (theCoverageMap->isNop( a )) {
+for (la = a; la < (a + count); la++) {
+  theCoverageMap->setWasExecuted( la );
+}
+
+count = 0;
+  }
+
+  a--;
+}
+
 endAddress = s.second.stats.sizeInBytes - 1;
 a = 0;
 while (a < endAddress) {
@@ -223,12 +243,13 @@ namespace Coverage {
   ha++;
   if ( ha >= endAddress )
 break;
-} while ( !theCoverageMap->isStartOfInstruction( ha ) );
+} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
+  theCoverageMap->isNop( ha ) );
   a = ha;
 }
 
 // Now scan through the coverage map of this symbol.
-endAddress = s.second.stats.sizeInBytes - 1;
+endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
 a = 0;
 while (a <= endAddress) {
   // If an address was NOT executed, find consecutive unexecuted
@@ -316,7 +337,8 @@ namespace Coverage {
   void DesiredSymbols::createCoverageMap(
 const std::string& exefileName,
 const std::string& symbolName,
-uint32_t   size
+uint32_t   size,
+uint32_t   sizeWithoutNops
   )
   {
 CoverageMapBase* aCoverageMap;
@@ -354,9 +376,10 @@ namespace Coverage {
   << '/' << size << ')'
   << std::endl;
 
-if ( itr->second.stats.sizeInBytes < size )
+if ( itr->second.stats.sizeInBytes < size ) {
   itr->second.stats.sizeInBytes = size;
-else
+  itr->second.stats.sizeInBytesWithoutNops = sizeWithoutNops;
+} else
   size = itr->second.stats.sizeInBytes;
   }
 }
@@ -376,6 +399,7 @@ namespace Coverage {
 );
   itr->second.unifiedCoverageMap = aCoverageMap;
   itr->second.stats.sizeInBytes = size;
+  itr->second.stats.sizeInBytesWithoutNops = sizeWithoutNops;
 }
   }
 
@@ -479,7 +503,7 @@ namespace 

[PATCH v7 2/2] covoar/Target_i386: Add NOP patterns

[Alex White]

A couple of NOP patterns found with the pc686 BSP were not detected.
This has been fixed.
---
 tester/covoar/Target_i386.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tester/covoar/Target_i386.cc b/tester/covoar/Target_i386.cc
index e0c9c0f..4567c1e 100644
--- a/tester/covoar/Target_i386.cc
+++ b/tester/covoar/Target_i386.cc
@@ -87,6 +87,15 @@ namespace Target {
   size = 3;
   return true;
 }
+if (!strncmp( [strlen(line)-28], "lea0x0(%esi,%eiz,1),%esi", 28)) 
{
+  // Could be 4 or 7 bytes of padding.
+  if (!strncmp( [strlen(line)-32], "00", 2)) {
+size = 7;
+  } else {
+size = 4;
+  }
+  return true;
+}
 
 return false;
   }
-- 
2.27.0

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

Re: libbsd: Backport fd_set size fixes for racoon and ping6 to 5

[Gedare Bloom]

seems fine to me.

On Fri, Mar 26, 2021 at 7:14 AM Christian MAUDERER
 wrote:
>
> Hello,
>
> I would like to backport the following patches to 5 and 5-freebsd-12:
>
> https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=e7fb073f3a1040847daab3ef917aeade755eb30b
> https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=33e3cf8eaff0081e74593f8a91edc8e37f732430
>
> Ticket is here:
>
> https://devel.rtems.org/ticket/4361
>
> Is that OK?
>
> Best regards
>
> Christian
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About locks and concurrency rules for SMP systems

[Gedare Bloom]

On Thu, Mar 25, 2021 at 11:30 PM Richi Dubey  wrote:
>
> Thanks for your quick response!
>
>> Each scheduler has its own lock. There are a couple of more locks involved.
>
> I understand.
>
> I backtracked a little and found that we have:
> _Thread_State_acquire_critical( the_thread, lock_context );
>
> to lock access to thread-specific variables.
>
> _Scheduler_Acquire_critical( scheduler, _context
>
> to lock access to the current scheduler-specific data structures.
>
> What other locks do we have related to schedulers?
>

By definition, all locks relate to scheduling. The other major one
though would be _Thread_Dispatch_disable_critical and relatives like
_Thread_queue_Dispatch_disable, if you think of dispatching as part of
scheduling. However, the two operations are a little bit different.
Scheduling is selecting the next thread(s) to run, while dispatching
is actually making them run.


> On Wed, Mar 24, 2021 at 1:03 PM Sebastian Huber 
>  wrote:
>>
>> On 24/03/2021 08:07, Richi Dubey wrote:
>>
>> > How does RTEMS handle cases where two different cores access
>> > scheduler-related functions at the same time?
>> Each scheduler has its own lock. There are a couple of more locks involved.
>> > For ex., Can they access (or modify) the Scheduler_strong_APA_Context
>> > 
>> > at the same time?
>> No, unless we have a bug.
>>
>> --
>> 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: GSoC Project - Beagle BSP Projects

[Christian MAUDERER]

Hello Ahamed,

Am 26.03.21 um 15:31 schrieb Ahamed Husni:

USB OTG would be a nice area. But that will be less writing a driver
for
Beagle but more finding out how that works with libbsd and finding a
good way to configure it. I once put a few hours into it didn't take
too
much time till a PC detected an USB device (see
https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
).
Basically it's about importing the "usb_template" stuff and finding a
way to configure it in libbsd.

I think that topic would have to be a bit of an open one: You might
work
only a day on it and have a working CDC Ethernet afterwards or you can
need weeks for that. So you should add an open list of possible
advanced
targets. An OTG device can be:

- Ethernet
- Serial port
- Mass storage
- Keyboard / Mouse
- Modem
- Audio
- ...

The simplest one will most likely be Ethernet followed by serial
port. I
would add some of the others (like mass storage) as an extended targets.

Best regards

Christian


USB OTG would allow more extended capabilities for the beagle board.
To work on the USB OTG devices, what would be the best way?
What I understood from what Christian says is,

 1. Finding out how USB OTG works with libbsd and finding a
  way to configure it for the beagle.
 2. Work on CDC Ethernet
 3. CDC Ethernet - Example application & Documentation
 4. Work on Serial over USB
 5. Serial over USB - Example application & Documentation

Am I right?


Most likely we would have to put some further open points at the end of 
that because like I said: Depending on how well it works you might need 
anything between a day and three weeks to get CDC Ethernet running. From 
my first guess, it's maybe a week.


Note that I would expect that you will need a debugger and the RTEMS 
event recording for this kind of project.



CDC Serial should be only a small step as soon as CDC Ethernet is running.

Mass storage depends on the current implementation for that in FreeBSD. 
It might could be an interesting part.




Would implementing Ethernet and Serial solve the problem of using TTL 
converters

when working on RTEMS in Beagle for the developers?



Depends on the application. For those who want to write an application, 
a CDC Serial device would be a nice alternative. For those who want to 
develop drivers or RTEMS itself: Very unlikely that CDC Serial is enough 
for that.



Yes, this seems like an area that can be chipped away at, with a
strong plan of activities. My concern would be whether it is about
writing code or not?


After completing the above milestones, if we have more time I can start 
to work on

the Mass storage support.



I would suggest to put _more_ into the proposal and make it clear that 
the later points depend on whether there is enough time or not.


@Gedare: The time and effort for that project is really hard to estimate 
in my point of view. Do you have an idea how we could handle that?





Hi,

Regarding the PRU.
I was able to load code to the PRU.
However I wasn't able to map IRQ interrupts to the PRU, thus unable
to communicate with it in a meaningful way.
Also I don't think that this project should be continued without a
full DEBUGGING Setup.

Best,
Nils


+1, without a proper debugging setup I found it hard to precisely
pin point the problem when I initially took up this task.


What is the full DEBUGGING setup needed to work on the PRU?


I expect a JTAG-Debugger. I had good experience with the Segger J-Link 
EDU for GSoC projects with BBB. Alternatively there are OpenOCD based 
ones out there too that are said do work well. Note that you have to 
solder a debug connector to the Beagle for that.


Best regards

Christian



Regards,
Husni.

On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai > wrote:





On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher mailto:nilho...@gmail.com>> wrote:

Hi,

Regarding the PRU.
I was able to load code to the PRU.
However I wasn't able to map IRQ interrupts to the PRU, thus
unable to communicate with it in a meaningful way



Just a small addition, AFAIK the issue with this was the fact that
mmap() would always fail.

.
Also I don't think that this project should be continued without
a full DEBUGGING Setup.


+1, without a proper debugging setup I found it hard to precisely
pin point the problem when I initially took up this task.


Best,
Nils

On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER
mailto:christian.maude...@embedded-brains.de>> wrote:

Hello Gedare,

Am 23.03.21 um 16:48 schrieb Gedare Bloom:
 > CC: Nils, Utkarsh
 >
 > On Tue, Mar 

Re: GSoC Project - Beagle BSP Projects

[Ahamed Husni]

>
> USB OTG would be a nice area. But that will be less writing a driver for
> Beagle but more finding out how that works with libbsd and finding a
> good way to configure it. I once put a few hours into it didn't take too
> much time till a PC detected an USB device (see
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
> Basically it's about importing the "usb_template" stuff and finding a
> way to configure it in libbsd.
>
> I think that topic would have to be a bit of an open one: You might work
> only a day on it and have a working CDC Ethernet afterwards or you can
> need weeks for that. So you should add an open list of possible advanced
> targets. An OTG device can be:
>
> - Ethernet
> - Serial port
> - Mass storage
> - Keyboard / Mouse
> - Modem
> - Audio
> - ...
>
> The simplest one will most likely be Ethernet followed by serial port. I
> would add some of the others (like mass storage) as an extended targets.
>
> Best regards
>
> Christian


USB OTG would allow more extended capabilities for the beagle board.
To work on the USB OTG devices, what would be the best way?
What I understood from what Christian says is,

   1. Finding out how USB OTG works with libbsd and finding a
way to configure it for the beagle.
   2. Work on CDC Ethernet
   3. CDC Ethernet - Example application & Documentation
   4. Work on Serial over USB
   5. Serial over USB - Example application & Documentation

Am I right?

Would implementing Ethernet and Serial solve the problem of using TTL
converters
when working on RTEMS in Beagle for the developers?

Yes, this seems like an area that can be chipped away at, with a
> strong plan of activities. My concern would be whether it is about
> writing code or not?
>

After completing the above milestones, if we have more time I can start to
work on
the Mass storage support.



> Hi,
>
> Regarding the PRU.
> I was able to load code to the PRU.
> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
> communicate with it in a meaningful way.
> Also I don't think that this project should be continued without a full
> DEBUGGING Setup.
>
> Best,
> Nils
>

+1, without a proper debugging setup I found it hard to precisely pin point
> the problem when I initially took up this task.
>

What is the full DEBUGGING setup needed to work on the PRU?

Regards,
Husni.

On Tue, Mar 23, 2021 at 10:25 PM Utkarsh Rai 
wrote:

>
>
>
> On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher  wrote:
>
>> Hi,
>>
>> Regarding the PRU.
>> I was able to load code to the PRU.
>> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
>> communicate with it in a meaningful way
>>
>
>
> Just a small addition, AFAIK the issue with this was the fact that mmap()
> would always fail.
>
>
>> .
>> Also I don't think that this project should be continued without a full
>> DEBUGGING Setup.
>>
>
> +1, without a proper debugging setup I found it hard to precisely pin
> point the problem when I initially took up this task.
>
>
>>
>>
> Best,
>> Nils
>>
>> On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER <
>> christian.maude...@embedded-brains.de> wrote:
>>
>>> Hello Gedare,
>>>
>>> Am 23.03.21 um 16:48 schrieb Gedare Bloom:
>>> > CC: Nils, Utkarsh
>>> >
>>> > On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
>>> >  wrote:
>>> >>
>>> >> Hello Ahamed,
>>> >>
>>> >> Am 23.03.21 um 11:24 schrieb Ahamed Husni:
>>> >>> Hi everyone,
>>> >>>
>>> >>> I'm really interested to work on the *Beagle BSP Projects* [#2891
>>> >>> ]. *
>>> >>> *
>>> >>> *Adding PRU Support* [#3730 ]
>>> >>> project seems really interesting to me.
>>> >>> This project is partially done during GSoC 2019
>>> >>> by Nils Hölscher .
>>> >>> Is this a good project for the GSoC?
>>> >>>
>>> >>> Up to now I have,
>>> >>>
>>> >>>   1. Completed the GSoC prerequisite task
>>> >>>   2. Got the required hardware and tested it. (Beagleboard Black,
>>> USB to
>>> >>>  TTL Converter)
>>> >>>   3. Installed RTEMS on the Beagleboard and tested. (Screenshot
>>> attached
>>> >>>  below)
>>> >>>
>>> >>>
>>> >>> I need guidance to define the scope of the project.
>>> >>> I'm currently thinking of ,
>>> >>>
>>> >>>   1. First finish the remaining work from GSoC 2019 on the PRU.
>>> >>>  (What is the status of current implementation of the PRU?)
>>> >>
>>> >> I'm really not sure what the state of the PRU is. I didn't follow that
>>> >> project closely. Maybe one of the mentors of that project can say
>>> >> anything regarding that.
>>> >>
>>> > Some more background:
>>> > https://lists.rtems.org/pipermail/devel/2019-December/056478.html
>>> > https://lists.rtems.org/pipermail/devel/2020-January/056958.html
>>> >
>>> > Maybe Utkarsh or Nils have more to say.
>>> >
>>> >>>   2. Implement additional peripheral support.
>>> >>>  What would be most useful?
>>> >>>  (USB OTG, CAN, ...).
>>> >>
>>> >> I 

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 26/03/2021 11:34, Robin Müller wrote:
How would you define a generic linker section? I tried to put the 
following section into the
linkcmdsmemory file like you suggested (at 
spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):


  SECTIONS {
    .stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
      bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
      bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
    } > SRAM_3 AT > FLASH
  }


This should work. You need also input sections for this output section. 
I still don't know why you can't use the already existing:


    .nocache : ALIGN_WITH_INPUT {
        bsp_section_nocache_begin = .;
        *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_nocache*)))
        bsp_section_nocache_end = .;
    } > REGION_NOCACHE AT > REGION_NOCACHE_LOAD
    bsp_section_nocache_size = bsp_section_nocache_end - 
bsp_section_nocache_begin;

    bsp_section_nocache_load_begin = LOADADDR (.nocache);
    bsp_section_nocache_load_end = bsp_section_nocache_load_begin + 
bsp_section_nocache_size;


    .nocachenoload (NOLOAD) : ALIGN_WITH_INPUT {
        bsp_section_nocachenoload_begin = .;
        *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_noload_nocache*)))
        bsp_section_nocacheheap_begin = .;
        . += ORIGIN (REGION_NOCACHE) + LENGTH (REGION_NOCACHE) - 
ABSOLUTE (.);

        bsp_section_nocacheheap_end = .;
        bsp_section_nocachenoload_end = .;
    } > REGION_NOCACHE AT > REGION_NOCACHE
    bsp_section_nocacheheap_size = bsp_section_nocacheheap_end - 
bsp_section_nocacheheap_begin;
    bsp_section_nocachenoload_size = bsp_section_nocachenoload_end - 
bsp_section_nocachenoload_begin;


For the stm32h7 these regions are used:

  REGION_ALIAS ("REGION_NOCACHE", SRAM_1);
  REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM_1);



But the waf build fails with  a syntax error:

[1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
[1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84: 
syntax error

collect2.exe: error: ld returned 1 exit status

c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84: 
syntax error

collect2.exe: error: ld returned 1 exit status

What is around line 84?

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

libbsd: Backport fd_set size fixes for racoon and ping6 to 5

[Christian MAUDERER]

Hello,

I would like to backport the following patches to 5 and 5-freebsd-12:

https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=e7fb073f3a1040847daab3ef917aeade755eb30b
https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=33e3cf8eaff0081e74593f8a91edc8e37f732430

Ticket is here:

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

Is that OK?

Best regards

Christian
--

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

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

How would you define a generic linker section? I tried to put the following
section into the
linkcmdsmemory file like you suggested (at
spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):

  SECTIONS {
.stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
  bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
  bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
} > SRAM_3 AT > FLASH
  }

But the waf build fails with  a syntax error:

[1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
[1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
syntax error
collect2.exe: error: ld returned 1 exit status

c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
syntax error
collect2.exe: error: ld returned 1 exit status

Kind Regards
Robin

On Thu, 25 Mar 2021 at 13:15, Robin Müller 
wrote:

> That is how it was done in the lwIP demo provided by STM, I simply adopted
> that. The SRAM3 is small, but big enough for lwIP, so all of it is used
> completely by lwIP.
> How would you place the descriptors in code so that these linker script
> sections are not necessary? You mentioned RTEMS_SECTIONs. Are those used in
> the source code?
>
> Kind Regards
> Robin Müller
>
> On Mon, 22 Mar 2021 at 11:43, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 03/02/2021 14:50, Robin Müller wrote:
>>
>> > The following link contains more theoretical information about why
>> > these sections were placed at these addresses:
>> >
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>> > <
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>> >
>> >
>> > Kind Regards
>> > Robin
>> >
>> > On Wed, 3 Feb 2021 at 14:44, Robin Müller > > > wrote:
>> >
>> > The DMA descriptors need to be placed at the start of the SRAM3
>> > and need to be aligned in a certain way. The RX buffer will take
>> > up the first (slightly less than) 16 kB of SRAM3 but needs to be
>> > placed
>> > behind the DMA descriptors. It also needs to be placed in a way
>> > that the MPU configuration required for the DMA descriptors will
>> > not do something with the RX buffers.
>> > In the example provided by STM32, the first 256 bytes are
>> > configured by MPU Config.
>> >
>> I had a look at the FAQ and the manual. Currently, we use the SRAM1 for
>> the .nocache area. This is in the D2 domain. The Ethernet module is in
>> the D2 domain. I am not sure why you have to change this to the smaller
>> SRAM3? The libbsd driver works well with the current setting.
>>
>> --
>> 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: GSoC project: Memory protection (Ticket no: 2904)

[Rajiv Vaidyanathan]

Dear Hesham,

Thank you for providing information about the RISC-V MMU. I want to know
what work has to be done in improving MMU in RISC-V and if it can be a GSoC
project. It would be great if you could provide the details regarding this.

Thanks and regards,
Rajiv

On Wed, 24 Mar 2021 at 00:03, Hesham Almatary 
wrote:

> On Tue, 23 Mar 2021 at 17:14, Gedare Bloom  wrote:
> >
> > CC: Hesham
> > CC: devel
> >
> > On Tue, Mar 23, 2021 at 6:34 AM Rajiv Vaidyanathan
> >  wrote:
> > >
> > > Dear Gedare,
> > >
> > > Thank you for providing information regarding the project. For risk-v
> MMU support, will I require to have hardware?
> > >
> > That's a good question. I don't know if the current risc-v simulators
> > support the risc-v mmu. maybe, another expert could advise. I have
> > CC'd someone with experience in both risc-v and memory protection.
> >
> Yes, both Spike and QEMU have MMU and PMP support.
>
> > Let's keep technical discussions on the mailing list. Thanks.
> >
> > > Thanks and regards,
> > > Rajiv
> > >
> > > On Mon, 22 Mar 2021 at 21:54, Gedare Bloom  wrote:
> > >>
> > >> Hi Rajiv,
> > >>
> > >> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
> > >>  wrote:
> > >> >
> > >> > Hello RTEMS community,
> > >> >
> > >> > I am interested in the ticket: Memory protection. I saw that this
> topic has been pursued a few times in GSoC. It would be great if someone
> can let me know the current status of this project and guide me about what
> are the contributions that can be done this year.
> > >> >
> > >> Yes, this is a frequently attempted project that slowly makes progress
> > >> over time. I think that Utkarsh has gotten somewhat close to a
> > >> workable solution, but there were some design flaws in his approach
> > >> for task stack protection (mainly, iterating over all the tasks) that
> > >> are still lingering.
> > >>
> > >> There could be enough work here to pick up from his progress. The
> > >> major issue would be figuring out what  the final state of his code is
> > >> in, and to dig in to the design and implementation details to write a
> > >> concrete proposal how to bring task stack protection to a production
> > >> state. There may be other directions to consider as well, such as
> > >> improving the risc-v MMU support perhaps.
> > >>
> > >> > Thanks and regards,
> > >> > Rajiv
> > >> > ___
> > >> > 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