[PATCH] c-user: Remove spurious "is undefined. "

[Martin Erik Werner]

Remove a spurious "is undefined.  " fragment which was likely a leftover
from sentence re-use.
---
 c-user/self_contained_objects.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/c-user/self_contained_objects.rst 
b/c-user/self_contained_objects.rst
index 1c1e664..0be1423 100644
--- a/c-user/self_contained_objects.rst
+++ b/c-user/self_contained_objects.rst
@@ -159,8 +159,7 @@ They must be destroyed via
 
 * :c:func:`rtems_mutex_destroy`.
 
-is undefined.  Objects of the type :c:type:`rtems_recursive_mutex` must be
-initialized via
+Objects of the type :c:type:`rtems_recursive_mutex` must be initialized via
 
 * :c:func:`RTEMS_RECURSIVE_MUTEX_INITIALIZER`, or
 
-- 
2.20.1

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

[PATCH] c-user: Add & update ratemon get return values

[Martin Erik Werner]

Add a description of the previously missing RTEMS_NOT_DEFINED return
value for rtems_rate_monotonic_get_status().

Update the RTEMS_SUCCESSFUL return value descriptions for
rtems_rate_monotonic_get_status() and
rtems_rate_monotonic_get_statistics() which incorrectly used the same
description as rtems_rate_monotonic_period().
---
 c-user/rate_monotonic_manager.rst | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/c-user/rate_monotonic_manager.rst 
b/c-user/rate_monotonic_manager.rst
index 1cc55fe..6152005 100644
--- a/c-user/rate_monotonic_manager.rst
+++ b/c-user/rate_monotonic_manager.rst
@@ -871,11 +871,14 @@ DIRECTIVE STATUS CODES:
  :class: rtems-table
 
  * - ``RTEMS_SUCCESSFUL``
-   - period initiated successfully
+   - period status retrieved successfully
  * - ``RTEMS_INVALID_ID``
- invalid rate monotonic period id
  * - ``RTEMS_INVALID_ADDRESS``
- invalid address of status
+ * - ``RTEMS_NOT_DEFINED``
+   - no status is available due to the cpu usage of the task having been
+ reset since the period initiated
 
 *DESCRIPTION:
 This directive returns status information associated with the rate
@@ -938,7 +941,7 @@ DIRECTIVE STATUS CODES:
  :class: rtems-table
 
  * - ``RTEMS_SUCCESSFUL``
-   - period initiated successfully
+   - period statistics retrieved successfully
  * - ``RTEMS_INVALID_ID``
- invalid rate monotonic period id
  * - ``RTEMS_INVALID_ADDRESS``
-- 
2.20.1

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

Re: Suggestion

[Chris Johns]

On 2020-02-29 04:18, Amar Takhar wrote:

On 2020-02-28 09:25 -0700, Gedare Bloom wrote:



If there is enough work, and the work can be suitably identified, then
it can also be a possible GSoC. There are also other possibilities to
improve our existing Python code bases to adhere to some proposed
Python coding conventions, which could make a nice GSoC effort to
ensure it is done iteratively and carefully without breaking things.

If that is of interest, we can find more information, but you can also
search the archives last 3-4 months about Python.


There are for sure other tools that need updating to run with Python 3.7 I ran
into several while working with Chris to setup hardware CI testing using the
BBB.

The process...is not pleasant.  Lots of obtuse references and difficult items to
find to figure out how to get this all working.

Having said that, he did share some work with me that helped out immensely.  I
think a part of this project could be to turn this work into a Python utility to
allow easily building images with u-boot and FDT.


I have started on a tool like this. It is rtems-boot-image. It handles 
one of the hard parts, creating an image on a number of host machines. 
It can be updated to do more and handle a few other things.



Part of this would also be a tutorial for new users to go and set up a BBB and
RPI for testing and running using this new tool and getting the new tftp proxy
and ser2net working in conjunction.


Yes, I would like to have this done.


This would be a very close or near similar setup to any other BSP and is
something that RTEMS sorely lacks.

It all makes sense and isn't too bad once it's setup but but the current motto
for new users is arcane.  I think what Gedare mentioned and this  would be an
excellent GSoC project for anyone who only really needs knowledge in Python.

Part of this tutorial would involve ASCII screen captures as well as during this
process there are expected and unexpected behaviours that are best seen
visually.


Yeap.

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

Re: Libbsd 5-freebsd-12 does not build for BBB

[Chris Johns]

On 2020-02-28 17:20, Sebastian Huber wrote:

On 28/02/2020 06:23, Chris Johns wrote:

Hi,

Please find attached an error log for libbsd for the BBB.


This should be already fixed:

https://git.rtems.org/rtems-libbsd/commit/?id=7606ec29778f1fabf70f3fc10edca02155d02c8c 



Looks like my mistake, I am not sure where I got the hash from I pushed 
to the RSB. Hmm.


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

[PATCH] user/hosts/posix.rst: Add CentOS 8 information

[Joel Sherrill]

---
 user/hosts/posix.rst | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index b46497c..d89d1a2 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -74,13 +74,29 @@ provide a manual override:
 CentOS
 ~~
 
-The following packages are required on a minimal CentOS 6.3 64bit installation:
+The following packages are required on a minimal CentOS 6.3 or Cent)S 7
+64-bit installation:
 
 .. code-block:: none
 
-  # yum install autoconf automake binutils gcc gcc-c++ gdb make patch \
+  # yum install autoconf automake binutils gcc gcc-c++ gdb make patch pax \
   bison flex xz unzip ncurses-devel texinfo zlib-devel python-devel git
 
+On CentOS 8, the ``pax`` command is now provided by the ``spax`` package,
+you need to enable the PowerTools repository. and use Python3.  On a
+fresh install, the following commands should install everything you
+need for RTEMS development:
+
+.. code-block:: none
+
+  # dnf install yum-utils
+  # dnf config-manager --set-enabled PowerTools
+  # dnf update
+  # dnf groupinstall "Development Tools"
+  # dnf install python3 python3-pip python3-setuptools python3-devel
+  # dnf install texinfo spax
+  # alternatives --set python /usr/bin/python3
+
 The minimal CentOS distribution is a specific DVD that installs a minimal
 system. If you use a full system some of these packages may have been
 installed.
-- 
1.8.3.1

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

Re: tar/psx/bsdtar on CentOS 8

[Joel Sherrill]

Gotcha. And re-adding the devel@ mailing list.

It is just a matter of the RPM name changing (and likely the pax
implementation).

I will update the Users Guide and post a patch.

On Fri, Feb 28, 2020 at 4:12 PM Jeff Mayes  wrote:

> Yes, spax is the rpm.  So, “yum install spax” and you get the “pax”
> command.
>
>
>
> Thanks
>
> Jeff
>
>
>
> *From:* Joel Sherrill 
> *Sent:* Friday, February 28, 2020 3:43 PM
> *To:* Jeff Mayes ; rtems-de...@rtems.org <
> devel@rtems.org>
> *Cc:* Chris Johns 
> *Subject:* Re: tar/psx/bsdtar on CentOS 8
>
>
>
> Pax to spax as an rpm?
>
>
>
> I will try to.make a simple patch and let you review it
>
>
>
> On Fri, Feb 28, 2020, 2:10 PM Jeff Mayes  wrote:
>
> Aha!  So, spax provides pax now, and spax is in the BaseOS Repo.  That’ll
> need to be updated in the documentation.
>
>
>
> Thanks!
>
>
>
>
>
> *From:* Joel Sherrill 
> *Sent:* Friday, February 28, 2020 10:21 AM
> *To:* Jeff Mayes 
> *Cc:* Chris Johns ; rtems-de...@rtems.org <
> devel@rtems.org>
> *Subject:* Re: tar/psx/bsdtar on CentOS 8
>
>
>
> This follow up from Jeff didn't hit the list.
>
>
>
> On top of pax may be an inactive/dead project, there is the issue that
> Grsecurity
>
> has been cited as violating the GPL with their business of providing
> kernel patches
>
> to paying customers but not allowing redistribution of those patches.
>
>
>
> https://lkml.org/lkml/2019/11/6/4
>
>
>
> They sued Bruce Perens (
> https://thenewstack.io/open-source-pioneer-bruce-perens-sued-grsecurity/)
>
> for defamation after his comments on their actions.
>
>
>
> But that's not where the CentOS 7 pax says it came from. Do an rpm -i
>
> and you see the URL is http://ftp.suse.com/pub/people/kukuk/pax which
>
> is now dead. The user has a directory but it only has glibc-addons.
>
> I think this project died also.
>
>
>
> Did you try yum provides "*pax"? or the dnf equivalent?
>
>
>
> We may end up needing to identify an upstream pax implementation and
>
> add it to the rtems-source-builder. I'm hoping that's the out here.
>
>
>
> --joel
>
>
>
> On Thu, Feb 27, 2020 at 8:41 PM Jeff Mayes  wrote:
>
> Hi,
> I think you misread that RHEL 8 page.  I had already looked there, but
> looked again tonight.  Pax is only listed once on the whole page, and it's
> under this heading:
>   A.4. Removed packages
>   The following packages are part of RHEL 7 but are not distributed with
> RHEL 8:
>
> The "Homepage of Pax" looks a little stale.  --->
> https://pax.grsecurity.net/
>
> Jeff
>
>
>
>
>
> From: Joel Sherrill 
>
> Sent: Thursday, February 27, 2020 4:20 PM
>
> To: Chris Johns ; Jeff Mayes 
>
> Cc: rtems-de...@rtems.org 
>
> Subject: Re: tar/psx/bsdtar on CentOS 8
>
>
>
>
>
>
> Jeff.. try the stuff below and let us know.
>
>
>
>
> On Tue, Feb 25, 2020 at 9:12 PM Chris Johns  wrote:
>
>
>
> On 25/2/20 5:09 am, Joel Sherrill wrote:
>
> > Hi
>
> >
>
> > CentOS 8 does not have a package for pax. It does have a package for
> bsdtar.
>
> >
>
> > Is bsdtar sufficient for the tests? I don't call the precise issue we
> favored
>
> > pax over
>
> > GNU tar.
>
> >
>
> > If so, could testsuites/libtests/configure.ac 
> accept both?
>
> >
>
> > Pax appears to be used only for the dl* and tar* tests. I had thought
> about it
>
> > not being a hard fail but those seem like bad tests to drop out.
>
>
>
> Does RTEMS understand the standard tar format? If PAX format is needed
> does your
>
> tar accept `--posix` or `--format pax`. I am happy for a change like this
> but it
>
> may only work on FreeBSD ;)
>
>
>
>
>
> Long ago, I swear it was just tar but something broke on some host. My
> vague recollection
> is very large user ids in a Mac networked environment. But the ustar
> format allows 8 octets
> for user ids.
>
>
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06
>
>
>
>
> That may not have tripped the switch to pax except that pax is the POSIX
> name of the
>
>
> command.
>
>
>
> Looking for the RHEL 8 release notes about this, I found
>
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index
>
>
>
>
> which indicates it moved to the "CodeReady Linux Builder repository" along
> with a
>
>
> number of other packages. That is in the PowerTools repo for CentOS.
>
>
>
>
> https://serverfault.com/questions/997896/how-to-enable-powertools-repository-in-centos-8
>
>
>
>
> Hopefully it works. Jeff will let us know.
>
>
>
> --joel
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Chris
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tar/psx/bsdtar on CentOS 8

[Chris Johns]

>> On 29 Feb 2020, at 6:10 am, Jeff Mayes  wrote:
> 
> Aha!  So, spax provides pax now, and spax is in the BaseOS Repo.  That’ll 
> need to be updated in the documentation.
>  

We need the PAX format from any source. I switched to the pax command because 
POSIX defines it and silly me thought a POSIX OS would always provide it. 

If all the tar implementations support an option to generate the PAX format we 
can change back to tar. 

We need to: 
- check tar on each host
- check a test exe that is built

Would this be a simpler long term solution?

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

Re: tar/psx/bsdtar on CentOS 8

[Joel Sherrill]

Pax to spax as an rpm?

I will try to.make a simple patch and let you review it

On Fri, Feb 28, 2020, 2:10 PM Jeff Mayes  wrote:

> Aha!  So, spax provides pax now, and spax is in the BaseOS Repo.  That’ll
> need to be updated in the documentation.
>
>
>
> Thanks!
>
>
>
>
>
> *From:* Joel Sherrill 
> *Sent:* Friday, February 28, 2020 10:21 AM
> *To:* Jeff Mayes 
> *Cc:* Chris Johns ; rtems-de...@rtems.org <
> devel@rtems.org>
> *Subject:* Re: tar/psx/bsdtar on CentOS 8
>
>
>
> This follow up from Jeff didn't hit the list.
>
>
>
> On top of pax may be an inactive/dead project, there is the issue that
> Grsecurity
>
> has been cited as violating the GPL with their business of providing
> kernel patches
>
> to paying customers but not allowing redistribution of those patches.
>
>
>
> https://lkml.org/lkml/2019/11/6/4
>
>
>
> They sued Bruce Perens (
> https://thenewstack.io/open-source-pioneer-bruce-perens-sued-grsecurity/)
>
> for defamation after his comments on their actions.
>
>
>
> But that's not where the CentOS 7 pax says it came from. Do an rpm -i
>
> and you see the URL is http://ftp.suse.com/pub/people/kukuk/pax which
>
> is now dead. The user has a directory but it only has glibc-addons.
>
> I think this project died also.
>
>
>
> Did you try yum provides "*pax"? or the dnf equivalent?
>
>
>
> We may end up needing to identify an upstream pax implementation and
>
> add it to the rtems-source-builder. I'm hoping that's the out here.
>
>
>
> --joel
>
>
>
> On Thu, Feb 27, 2020 at 8:41 PM Jeff Mayes  wrote:
>
> Hi,
> I think you misread that RHEL 8 page.  I had already looked there, but
> looked again tonight.  Pax is only listed once on the whole page, and it's
> under this heading:
>   A.4. Removed packages
>   The following packages are part of RHEL 7 but are not distributed with
> RHEL 8:
>
> The "Homepage of Pax" looks a little stale.  --->
> https://pax.grsecurity.net/
>
> Jeff
>
>
>
>
>
> From: Joel Sherrill 
>
> Sent: Thursday, February 27, 2020 4:20 PM
>
> To: Chris Johns ; Jeff Mayes 
>
> Cc: rtems-de...@rtems.org 
>
> Subject: Re: tar/psx/bsdtar on CentOS 8
>
>
>
>
>
>
> Jeff.. try the stuff below and let us know.
>
>
>
>
> On Tue, Feb 25, 2020 at 9:12 PM Chris Johns  wrote:
>
>
>
> On 25/2/20 5:09 am, Joel Sherrill wrote:
>
> > Hi
>
> >
>
> > CentOS 8 does not have a package for pax. It does have a package for
> bsdtar.
>
> >
>
> > Is bsdtar sufficient for the tests? I don't call the precise issue we
> favored
>
> > pax over
>
> > GNU tar.
>
> >
>
> > If so, could testsuites/libtests/configure.ac 
> accept both?
>
> >
>
> > Pax appears to be used only for the dl* and tar* tests. I had thought
> about it
>
> > not being a hard fail but those seem like bad tests to drop out.
>
>
>
> Does RTEMS understand the standard tar format? If PAX format is needed
> does your
>
> tar accept `--posix` or `--format pax`. I am happy for a change like this
> but it
>
> may only work on FreeBSD ;)
>
>
>
>
>
> Long ago, I swear it was just tar but something broke on some host. My
> vague recollection
> is very large user ids in a Mac networked environment. But the ustar
> format allows 8 octets
> for user ids.
>
>
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06
>
>
>
>
> That may not have tripped the switch to pax except that pax is the POSIX
> name of the
>
>
> command.
>
>
>
> Looking for the RHEL 8 release notes about this, I found
>
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index
>
>
>
>
> which indicates it moved to the "CodeReady Linux Builder repository" along
> with a
>
>
> number of other packages. That is in the PowerTools repo for CentOS.
>
>
>
>
> https://serverfault.com/questions/997896/how-to-enable-powertools-repository-in-centos-8
>
>
>
>
> Hopefully it works. Jeff will let us know.
>
>
>
> --joel
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Chris
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

[Peter Dufault]

And regardless of the value of count it is successful?

> On Feb 28, 2020, at 12:17 , suyash singh  wrote:
> 
> count is unsigned int and will always be >=0. 
> 
> On Fri, Feb 28, 2020 at 10:42 PM suyash singh  
> wrote:
> ---
>  bsps/shared/grlib/1553/b1553brm.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/bsps/shared/grlib/1553/b1553brm.c 
> b/bsps/shared/grlib/1553/b1553brm.c
> index 57ef70126b..4041423541 100644
> --- a/bsps/shared/grlib/1553/b1553brm.c
> +++ b/bsps/shared/grlib/1553/b1553brm.c
> @@ -982,10 +982,8 @@ static rtems_device_driver 
> brm_write(rtems_device_major_number major, rtems_devi
> 
> rw_args->bytes_moved = count; 
> 
> -   if (count >= 0) {
> -   return RTEMS_SUCCESSFUL;
> -   }
> -   return RTEMS_UNSATISFIED;
> +   return RTEMS_SUCCESSFUL;
> +
>  }
> 
>  static rtems_device_driver brm_control(rtems_device_major_number major, 
> rtems_device_minor_number minor, void *arg)
> -- 
> 2.17.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: Suggestion

[Amar Takhar]

On 2020-02-28 12:39 -0600, Joel Sherrill wrote:
> 
> We can't blanket upgrade tools to Python 3. The only thing I think we agreed
> when this was recently discussed is that we have categories of tools in Python
> and some have to be compatible with Python 2 and 3.

I wasn't suggesting that.  I said there are tools that don't work in 3 any 
Python 2 program can be written to work in 3 either directly or using the six 
library sorry for not being clear!


> This would be a good project if there is a summer's worth of work. But it 
> could be combined with something if not. And we always like someone to submit 
> a "bonus" project idea -- just in case our estimate of the main project is 
> woefully over the top and the student kills it in a month. :)

I think it would be a good idea to create a Python RTEMS library that can be 
consumed by all our tools and the API tested using pytest.  The goal of this 
being the actual tools themselves are a thin layer on top of the library.  This 
way we can actually test compatibility as required also any  updates to the 
library would benefit all the tools we have. I think these 3 items would fill 
up 
an entire summer especially when we include the tests.


Something I've been casually working on is an official docker image that 
includes everything anyone would want to work with RTEMS.  That could also be 
added to this project as well.  This would build the tools from scratch but I 
was going to privately offer images that already have all the tools pre-built 
for those who want instant gratification.


> Part of this tutorial would involve ASCII screen captures as well as 
> during this process there are expected and unexpected behaviours that are 
> best seen visually.
> 
> This would help someone on-ramping.

Yes I agree a lot of "is this working right" questions come up a lot when 
you're 
working on this because sometimes nothing happens.  Or you run a tool like 
ser2net and are unsure what the expected outcome is.  There are also simple 
testing procedures you can do to make sure your FTDI setup is working 
correctly.  
A lot of the frustration can be taken out in getting things started which is a 
huge barrier for the entry into RTEMS right now.


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

Re: Suggestion

[Joel Sherrill]

On Fri, Feb 28, 2020 at 11:18 AM Amar Takhar  wrote:

> On 2020-02-28 09:25 -0700, Gedare Bloom wrote:
> > >
> > If there is enough work, and the work can be suitably identified, then
> > it can also be a possible GSoC. There are also other possibilities to
> > improve our existing Python code bases to adhere to some proposed
> > Python coding conventions, which could make a nice GSoC effort to
> > ensure it is done iteratively and carefully without breaking things.
> >
> > If that is of interest, we can find more information, but you can also
> > search the archives last 3-4 months about Python.
>
> There are for sure other tools that need updating to run with Python 3.7 I
> ran
> into several while working with Chris to setup hardware CI testing using
> the
> BBB.
>

We can't blanket upgrade tools to Python 3. The only thing I think we agreed
when this was recently discussed is that we have categories of tools in
Python
and some have to be compatible with Python 2 and 3.

+ Any tool required for a normal user must be Python 2/3 compatible.
   The RSB and tools like the rtems tester are in this category.
+ Tools specific to qualification or documentation have latitude to be
Python 3
   only. For example, Sphinx requires Python 3 and we have no control over
that.
   But this only impacts those working on documentation, not using RTEMS.

If we have code which works with a Python 3 < 3.7 and breaks with 3.7, then
it needs to be fixed. Independent of whether it is compatible with 2 and 3.


>
> The process...is not pleasant.  Lots of obtuse references and difficult
> items to
> find to figure out how to get this all working.
>
> Having said that, he did share some work with me that helped out
> immensely.  I
> think a part of this project could be to turn this work into a Python
> utility to
> allow easily building images with u-boot and FDT.
>
> Part of this would also be a tutorial for new users to go and set up a BBB
> and
> RPI for testing and running using this new tool and getting the new tftp
> proxy
> and ser2net working in conjunction.
>
> This would be a very close or near similar setup to any other BSP and is
> something that RTEMS sorely lacks.
>
> It all makes sense and isn't too bad once it's setup but but the current
> motto
> for new users is arcane.  I think what Gedare mentioned and this  would be
> an
> excellent GSoC project for anyone who only really needs knowledge in
> Python.
>

This would be a good project if there is a summer's worth of work. But it
could
be combined with something if not. And we always like someone to submit a
"bonus" project idea -- just in case our estimate of the main project is
woefully
over the top and the student kills it in a month. :)


>
> Part of this tutorial would involve ASCII screen captures as well as
> during this
> process there are expected and unexpected behaviours that are best seen
> visually.
>

This would help someone on-ramping.

--joel


>
>
> Amar.
> ___
> 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: Suggestion

[Amar Takhar]

On 2020-02-28 09:25 -0700, Gedare Bloom wrote:
> >
> If there is enough work, and the work can be suitably identified, then
> it can also be a possible GSoC. There are also other possibilities to
> improve our existing Python code bases to adhere to some proposed
> Python coding conventions, which could make a nice GSoC effort to
> ensure it is done iteratively and carefully without breaking things.
> 
> If that is of interest, we can find more information, but you can also
> search the archives last 3-4 months about Python.

There are for sure other tools that need updating to run with Python 3.7 I ran 
into several while working with Chris to setup hardware CI testing using the 
BBB.

The process...is not pleasant.  Lots of obtuse references and difficult items 
to 
find to figure out how to get this all working.

Having said that, he did share some work with me that helped out immensely.  I 
think a part of this project could be to turn this work into a Python utility 
to 
allow easily building images with u-boot and FDT.

Part of this would also be a tutorial for new users to go and set up a BBB and 
RPI for testing and running using this new tool and getting the new tftp proxy 
and ser2net working in conjunction.

This would be a very close or near similar setup to any other BSP and is 
something that RTEMS sorely lacks.

It all makes sense and isn't too bad once it's setup but but the current motto 
for new users is arcane.  I think what Gedare mentioned and this  would be an 
excellent GSoC project for anyone who only really needs knowledge in Python.

Part of this tutorial would involve ASCII screen captures as well as during 
this 
process there are expected and unexpected behaviours that are best seen 
visually.


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

Re: [PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

[suyash singh]

count is unsigned int and will always be >=0.

On Fri, Feb 28, 2020 at 10:42 PM suyash singh 
wrote:

> ---
>  bsps/shared/grlib/1553/b1553brm.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/bsps/shared/grlib/1553/b1553brm.c
> b/bsps/shared/grlib/1553/b1553brm.c
> index 57ef70126b..4041423541 100644
> --- a/bsps/shared/grlib/1553/b1553brm.c
> +++ b/bsps/shared/grlib/1553/b1553brm.c
> @@ -982,10 +982,8 @@ static rtems_device_driver
> brm_write(rtems_device_major_number major, rtems_devi
>
> rw_args->bytes_moved = count;
>
> -   if (count >= 0) {
> -   return RTEMS_SUCCESSFUL;
> -   }
> -   return RTEMS_UNSATISFIED;
> +   return RTEMS_SUCCESSFUL;
> +
>  }
>
>  static rtems_device_driver brm_control(rtems_device_major_number major,
> rtems_device_minor_number minor, void *arg)
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

[suyash singh]

---
 bsps/shared/grlib/1553/b1553brm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/grlib/1553/b1553brm.c 
b/bsps/shared/grlib/1553/b1553brm.c
index 57ef70126b..4041423541 100644
--- a/bsps/shared/grlib/1553/b1553brm.c
+++ b/bsps/shared/grlib/1553/b1553brm.c
@@ -982,10 +982,8 @@ static rtems_device_driver 
brm_write(rtems_device_major_number major, rtems_devi
 
rw_args->bytes_moved = count; 
 
-   if (count >= 0) {
-   return RTEMS_SUCCESSFUL;
-   }
-   return RTEMS_UNSATISFIED;
+   return RTEMS_SUCCESSFUL;
+
 }
 
 static rtems_device_driver brm_control(rtems_device_major_number major, 
rtems_device_minor_number minor, void *arg)
-- 
2.17.1

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

Re: Python docstring format?

[Gedare Bloom]

On Fri, Feb 28, 2020 at 2:41 AM Sebastian Huber
 wrote:
>
> Hello,
>
> there are several Python docstring formats available:
>
> https://stackoverflow.com/questions/3898572/what-is-the-standard-python-docstring-format
>
> The reStructuredText Docstring Format (Sphinx) is recommended by PEP 287:
>
> https://www.python.org/dev/peps/pep-0287/
>
> I suggest to use this one for RTEMS as well.
>
That makes sense to me based on our other use of Sphinx.
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: [Project #3860]

[Gedare Bloom]

On Fri, Feb 28, 2020 at 5:34 AM Christian Mauderer
 wrote:
>
> Hello Anmol,
>
> On 28/02/2020 10:31, Anmol Mishra wrote:
> > Hello,
> > I was going through the list of potential projects for GSoC 2020, I love
> > working with automation tools and "Code Formatting and Style Check for
> > RTEMS score" looks exciting to me. I saw you edited the wiki and the
> > owner was not mentioned so pinging you for the same.
>
> I'm not sure whether we already assigned someone. But that is a topic
> that could be handled by multiple mentors. So your best bet is to ask on
> the list.
>
> > I have read the requirements and hurdles, I have a question that
> > 1. "Is there any tool/procedure currently being considered as an option?"
>
> Not as far as I'm concerned. You might want to have a look at the wiki.
> I think there have been some notes for code formatters a few years back.
>
I only know about
https://devel.rtems.org/wiki/Developer/Coding/Conventions#Tools

Additionally, there should be some git hooks for style
check/enforcement, but with the ability to override the hooks (e.g.,
if we need to break the style rules for some good exceptions).

> > 2. "What is the timeframe I should look in the mail archive like the
> > past 3 months?"
>
> That topic was created during a recent discussion regarding style
> checking for Python. It can only be a few weeks now. But there haven't
> been much details about it.
>
+1 should be quite recent discussion. I did a quick search to help you
out. Many of the key points are made in a good thread to read through
with subject: "Requirement Document generator tool" from December
through February.
https://lists.rtems.org/pipermail/devel/2019-December/056455.html
https://lists.rtems.org/pipermail/devel/2020-January/056706.html
https://lists.rtems.org/pipermail/devel/2020-February/057057.html

and then another thread subject: "Tool Roadmap for the RTEMS
Pre-Qualification" has a superset of issues including Python
conventions:
https://lists.rtems.org/pipermail/devel/2020-February/057246.html

> Best regards
>
> Christian
>
> >
> > It goes without saying how much this means to me. I will be submitting 2
> > project proposals and don't want to waste time and start with draft
> > proposal asap. Looking forward to hearing from you.
> >
> > Regards
> > Anmol
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: Suggestion

[Gedare Bloom]

On Fri, Feb 28, 2020 at 5:10 AM Christian Mauderer
 wrote:
>
> Hello Anmol,
>
> On 28/02/2020 10:49, Anmol Mishra wrote:
> > I can see python2 code being used. And as of 2020 python2 has been
> > depreciated but I assume everyone is aware of that. Is there any active
> > plan to shift the codebase. I am open to discussion for this.
>
> We have the problem that some long living distributions (like CentOS 7)
> still only have python2 in the default repositories. So till they run
> out of support (year 2024 for CentOS 7) we will have to write our code
> in a way that it works with python2 and 3 for everything that is daily
> use for a RTEMS user.
>
> We currently have the discussion for some special maintenance tools
> whether they can be python3 only.
>
> So as a summary: If you find any tool that works with python2 but not
> with python3 it should definitively be updated to work with both
> versions. Patches are welcome.
>
If there is enough work, and the work can be suitably identified, then
it can also be a possible GSoC. There are also other possibilities to
improve our existing Python code bases to adhere to some proposed
Python coding conventions, which could make a nice GSoC effort to
ensure it is done iteratively and carefully without breaking things.

If that is of interest, we can find more information, but you can also
search the archives last 3-4 months about Python.

> Best regards
>
> Christian
>
> >
> > Regards
> > Anmol
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: tar/psx/bsdtar on CentOS 8

[Joel Sherrill]

This follow up from Jeff didn't hit the list.

On top of pax may be an inactive/dead project, there is the issue that
Grsecurity
has been cited as violating the GPL with their business of providing kernel
patches
to paying customers but not allowing redistribution of those patches.

https://lkml.org/lkml/2019/11/6/4

They sued Bruce Perens (
https://thenewstack.io/open-source-pioneer-bruce-perens-sued-grsecurity/)
for defamation after his comments on their actions.

But that's not where the CentOS 7 pax says it came from. Do an rpm -i
and you see the URL is http://ftp.suse.com/pub/people/kukuk/pax which
is now dead. The user has a directory but it only has glibc-addons.
I think this project died also.

Did you try yum provides "*pax"? or the dnf equivalent?

We may end up needing to identify an upstream pax implementation and
add it to the rtems-source-builder. I'm hoping that's the out here.

--joel

On Thu, Feb 27, 2020 at 8:41 PM Jeff Mayes  wrote:

> Hi,
> I think you misread that RHEL 8 page.  I had already looked there, but
> looked again tonight.  Pax is only listed once on the whole page, and it's
> under this heading:
>   A.4. Removed packages
>   The following packages are part of RHEL 7 but are not distributed with
> RHEL 8:
>
> The "Homepage of Pax" looks a little stale.  --->
> https://pax.grsecurity.net/
>
> Jeff
>
>
>
>
>
> From: Joel Sherrill 
>
> Sent: Thursday, February 27, 2020 4:20 PM
>
> To: Chris Johns ; Jeff Mayes 
>
> Cc: rtems-de...@rtems.org 
>
> Subject: Re: tar/psx/bsdtar on CentOS 8
>
>
>
>
>
>
> Jeff.. try the stuff below and let us know.
>
>
>
>
> On Tue, Feb 25, 2020 at 9:12 PM Chris Johns  wrote:
>
>
>
> On 25/2/20 5:09 am, Joel Sherrill wrote:
>
> > Hi
>
> >
>
> > CentOS 8 does not have a package for pax. It does have a package for
> bsdtar.
>
> >
>
> > Is bsdtar sufficient for the tests? I don't call the precise issue we
> favored
>
> > pax over
>
> > GNU tar.
>
> >
>
> > If so, could testsuites/libtests/configure.ac 
> accept both?
>
> >
>
> > Pax appears to be used only for the dl* and tar* tests. I had thought
> about it
>
> > not being a hard fail but those seem like bad tests to drop out.
>
>
>
> Does RTEMS understand the standard tar format? If PAX format is needed
> does your
>
> tar accept `--posix` or `--format pax`. I am happy for a change like this
> but it
>
> may only work on FreeBSD ;)
>
>
>
>
>
> Long ago, I swear it was just tar but something broke on some host. My
> vague recollection
> is very large user ids in a Mac networked environment. But the ustar
> format allows 8 octets
> for user ids.
>
>
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06
>
>
>
>
> That may not have tripped the switch to pax except that pax is the POSIX
> name of the
>
>
> command.
>
>
>
> Looking for the RHEL 8 release notes about this, I found
>
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index
>
>
>
>
> which indicates it moved to the "CodeReady Linux Builder repository" along
> with a
>
>
> number of other packages. That is in the PowerTools repo for CentOS.
>
>
>
>
> https://serverfault.com/questions/997896/how-to-enable-powertools-repository-in-centos-8
>
>
>
>
> Hopefully it works. Jeff will let us know.
>
>
>
> --joel
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Chris
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Unsubscribe

[Franck BUCHERON]

t/plain; charset="utf-8"

I'm not opposed to this. I noticed a local uncommitted patch I posted a
while
back to bump dtc in rtems-tools.  What about that as well?


On Fri, Feb 28, 2020, 12:52 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  cpukit/dtc/VERSION | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/dtc/VERSION b/cpukit/dtc/VERSION
> index fa27eb5c8e..a6f7720958 100644
> --- a/cpukit/dtc/VERSION
> +++ b/cpukit/dtc/VERSION
> @@ -4,15 +4,15 @@ git://git.kernel.org/pub/scm/utils/dtc/dtc.git
>
>  Commit:
>
> -c12b2b0c20eb8fbe1a22065f1d5f0f155ab56b0a
> +0f61c72dedc4bf11cd19a78fc36a7bde99d653e0
>
>  Date:
>
> -Thu Jul 19 08:19:43 2018 +0200
> +Thu Feb 20 14:45:57 2020 -0700
>
>  Commands to generate update patches:
>
> -git format-patch c12b2b0c20eb8fbe1a22065f1d5f0f155ab56b0a --
> libfdt/fdt_addresses.c libfdt/fdt.c libfdt/fdt_empty_tree.c libfdt/fdt.h
> libfdt/fdt_ro.c libfdt/fdt_rw.c libfdt/fdt_strerror.c libfdt/fdt_sw.c
> libfdt/fdt_wip.c libfdt/libfdt_env.h libfdt/libfdt.h
> libfdt/libfdt_internal.h libfdt/TODO
> +git format-patch 0f61c72dedc4bf11cd19a78fc36a7bde99d653e0 --
> libfdt/fdt_addresses.c libfdt/fdt.c libfdt/fdt_empty_tree.c libfdt/fdt.h
> libfdt/fdt_ro.c libfdt/fdt_rw.c libfdt/fdt_strerror.c libfdt/fdt_sw.c
> libfdt/fdt_wip.c libfdt/libfdt_env.h libfdt/libfdt.h
> libfdt/libfdt_internal.h libfdt/TODO
>  sed -i 's%/libfdt/fdt.h%/cpukit/include/fdt.h%g' 00*
>  sed -i 's%/libfdt/libfdt.h%/cpukit/include/libfdt.h%g' 00*
>  sed -i 's%/libfdt/libfdt_env.h%/cpukit/include/libfdt_env.h%g' 00*
> --
> 2.16.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.rtems.org/pipermail/devel/attachments/20200228/303c5c1a/attachment-0001.html>

--

Message: 4
Date: Fri, 28 Feb 2020 14:00:28 +0100
From: Sebastian Huber 
To: j...@rtems.org
Cc: RTEMS Devel 
Subject: Re: [PATCH 27/27] dtc: Update VERSION
Message-ID: <065f6bcc-2b8a-b9cc-211a-3765210b1...@embedded-brains.de>
Content-Type: text/plain; charset=utf-8; format=flowed

On 28/02/2020 13:57, Joel Sherrill wrote:
> I'm not opposed to this. I noticed a local uncommitted patch I posted a 
> while
> back to bump dtc in rtems-tools.? What about that as well?

It probably doesn't hurt to update this.

I updated the dtc code in RTEMS just because it was mentioned as an 
example for third-party code without SPDX license identifiers.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.


--

Message: 5
Date: Fri, 28 Feb 2020 08:50:24 -0500
From: Alan Cudmore 
To: Sebastian Huber 
Cc: "rtems-de...@rtems.org" 
Subject: Re: Link issue on xilinx_zynq_a9_qemu BSP on rtems-libbsd
head
Message-ID:

Content-Type: text/plain; charset="UTF-8"

I had logged the verbose output from waf building the testsuite, but I
missed a couple of linker options in my makefile. It links now.
Is there a standalone rtems-libbsd example with a waf script or makefile?
Thank your for your quick response,
Alan

On Fri, Feb 28, 2020 at 1:25 AM Sebastian Huber
 wrote:
>
> On 28/02/2020 04:40, Alan Cudmore wrote:
> > Hi Lou,
> > Did you ever solve this problem?
> > I just tried linking an out of tree program for the beaglebone black
> > BSP and have the same undefined symbols. The testsuite links correctly
> > and the symbols are in the testsuite binaries, but not in libbsd.a
>
> For libbsd it is required that you link with the section garbage
> collection enabled: -Wl,--gc-sections
>
> This is how the tests are linked. If you omit the -Wl,--gc-sections in
> your application you do something which is not tested.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.


--

Subject: Digest Footer

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

--

End of devel Digest, Vol 99, Issue 204
**
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link issue on xilinx_zynq_a9_qemu BSP on rtems-libbsd head

[Alan Cudmore]

I had logged the verbose output from waf building the testsuite, but I
missed a couple of linker options in my makefile. It links now.
Is there a standalone rtems-libbsd example with a waf script or makefile?
Thank your for your quick response,
Alan

On Fri, Feb 28, 2020 at 1:25 AM Sebastian Huber
 wrote:
>
> On 28/02/2020 04:40, Alan Cudmore wrote:
> > Hi Lou,
> > Did you ever solve this problem?
> > I just tried linking an out of tree program for the beaglebone black
> > BSP and have the same undefined symbols. The testsuite links correctly
> > and the symbols are in the testsuite binaries, but not in libbsd.a
>
> For libbsd it is required that you link with the section garbage
> collection enabled: -Wl,--gc-sections
>
> This is how the tests are linked. If you omit the -Wl,--gc-sections in
> your application you do something which is not tested.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 27/27] dtc: Update VERSION

[Sebastian Huber]

On 28/02/2020 13:57, Joel Sherrill wrote:
I'm not opposed to this. I noticed a local uncommitted patch I posted a 
while

back to bump dtc in rtems-tools.  What about that as well?


It probably doesn't hurt to update this.

I updated the dtc code in RTEMS just because it was mentioned as an 
example for third-party code without SPDX license identifiers.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 27/27] dtc: Update VERSION

[Joel Sherrill]

I'm not opposed to this. I noticed a local uncommitted patch I posted a
while
back to bump dtc in rtems-tools.  What about that as well?


On Fri, Feb 28, 2020, 12:52 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  cpukit/dtc/VERSION | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/dtc/VERSION b/cpukit/dtc/VERSION
> index fa27eb5c8e..a6f7720958 100644
> --- a/cpukit/dtc/VERSION
> +++ b/cpukit/dtc/VERSION
> @@ -4,15 +4,15 @@ git://git.kernel.org/pub/scm/utils/dtc/dtc.git
>
>  Commit:
>
> -c12b2b0c20eb8fbe1a22065f1d5f0f155ab56b0a
> +0f61c72dedc4bf11cd19a78fc36a7bde99d653e0
>
>  Date:
>
> -Thu Jul 19 08:19:43 2018 +0200
> +Thu Feb 20 14:45:57 2020 -0700
>
>  Commands to generate update patches:
>
> -git format-patch c12b2b0c20eb8fbe1a22065f1d5f0f155ab56b0a --
> libfdt/fdt_addresses.c libfdt/fdt.c libfdt/fdt_empty_tree.c libfdt/fdt.h
> libfdt/fdt_ro.c libfdt/fdt_rw.c libfdt/fdt_strerror.c libfdt/fdt_sw.c
> libfdt/fdt_wip.c libfdt/libfdt_env.h libfdt/libfdt.h
> libfdt/libfdt_internal.h libfdt/TODO
> +git format-patch 0f61c72dedc4bf11cd19a78fc36a7bde99d653e0 --
> libfdt/fdt_addresses.c libfdt/fdt.c libfdt/fdt_empty_tree.c libfdt/fdt.h
> libfdt/fdt_ro.c libfdt/fdt_rw.c libfdt/fdt_strerror.c libfdt/fdt_sw.c
> libfdt/fdt_wip.c libfdt/libfdt_env.h libfdt/libfdt.h
> libfdt/libfdt_internal.h libfdt/TODO
>  sed -i 's%/libfdt/fdt.h%/cpukit/include/fdt.h%g' 00*
>  sed -i 's%/libfdt/libfdt.h%/cpukit/include/libfdt.h%g' 00*
>  sed -i 's%/libfdt/libfdt_env.h%/cpukit/include/libfdt_env.h%g' 00*
> --
> 2.16.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Project #3860]

[Christian Mauderer]

Hello Anmol,

On 28/02/2020 10:31, Anmol Mishra wrote:
> Hello,
> I was going through the list of potential projects for GSoC 2020, I love
> working with automation tools and "Code Formatting and Style Check for
> RTEMS score" looks exciting to me. I saw you edited the wiki and the
> owner was not mentioned so pinging you for the same.

I'm not sure whether we already assigned someone. But that is a topic
that could be handled by multiple mentors. So your best bet is to ask on
the list.

> I have read the requirements and hurdles, I have a question that
> 1. "Is there any tool/procedure currently being considered as an option?"

Not as far as I'm concerned. You might want to have a look at the wiki.
I think there have been some notes for code formatters a few years back.

> 2. "What is the timeframe I should look in the mail archive like the
> past 3 months?"

That topic was created during a recent discussion regarding style
checking for Python. It can only be a few weeks now. But there haven't
been much details about it.

Best regards

Christian

> 
> It goes without saying how much this means to me. I will be submitting 2
> project proposals and don't want to waste time and start with draft
> proposal asap. Looking forward to hearing from you.
> 
> Regards
> Anmol
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Suggestion

[Christian Mauderer]

Hello Anmol,

On 28/02/2020 10:49, Anmol Mishra wrote:
> I can see python2 code being used. And as of 2020 python2 has been
> depreciated but I assume everyone is aware of that. Is there any active
> plan to shift the codebase. I am open to discussion for this. 

We have the problem that some long living distributions (like CentOS 7)
still only have python2 in the default repositories. So till they run
out of support (year 2024 for CentOS 7) we will have to write our code
in a way that it works with python2 and 3 for everything that is daily
use for a RTEMS user.

We currently have the discussion for some special maintenance tools
whether they can be python3 only.

So as a summary: If you find any tool that works with python2 but not
with python3 it should definitively be updated to work with both
versions. Patches are welcome.

Best regards

Christian

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

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Gedare and Chris,

On 27/02/2020 23:14, Gedare Bloom wrote:
> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>>
>> On 28/2/20 7:23 am, Alan Cudmore wrote:
>>> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
>>> device tree based initialization for all of its BSPs.
>>> For example, here is the top level device tree source for the Adafruit
>>> Trinket M0, which is a very small Atmel Cortex M0 based board:
>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>>>
>>> The rest of the device tree source for common processors and devices are 
>>> here:
>>> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>>>
>>> To me, it looks like they have to develop (or port) and maintain
>>> device trees for each board and device that is supported.
>>>
>>> Does that look like a model that RTEMS could use? I'm not sure I
>>> understand everything that deploying such a model implies, or if it
>>> just makes more sense to use the existing FreeBSD or linux device
>>> trees.
>>
>> This is where I was heading in my thinking but I am not sure. I am settling 
>> on
>> having a dts tree in rtems.git and we may just have to manually manage the
>> files. I am not sure there are enough files to warrant a system like libbsd 
>> and
>> FreeBSD at this point in time. That may change with the new build system and
>> python being available however until then manual is fine. Let me explain ...
>>
>> I have been looking beyond the internal development aspects and to how we use
>> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
>> support is the right fit for RTEMS and a statically linked executable.
>>
>> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
>> This is the Linux way of doing things and this may be the right approach for
>> Linux but I am not so sure it is for us. It means you need u-boot and a 
>> suitable
>> file system plus you have a lot more items to configuration manage in 
>> production
>> systems and a lot more complexity for self upgrading.

I think for Boards that normally run a Linux it is a sane approach to
just replace the Linux Kernel with a RTEMS binary and otherwise keep the
boot process with for example U-Boot. Everything else is a lot of extra
effort to implement and not necessary in a lot of situations.

>>
>> Why do we have a bootloader load the FDT files when we statically link
>> everything else?>>
>> Why not link them into the executable and register them? It s easy to do.
>>

One BSP where it is a disadvantage to statically link is Raspberry Pi.
With the recent work you currently can use the same binary for RPi2 and
3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W.

I'm not against the possibility to link the FDT. But we should be open
to use both methods.

>> The flow on from doing this has some real advantages. FDT files that are 
>> linked
>> into an executable can then live in the rtems.git repo. If you move branches
>> when testing or in production you do not need to manage and match suitable 
>> FDT
>> blobs.
>>
>> I am not advocating this is the only solution. I can see for some BSPs this 
>> will
>> not work and u-boot loading is the only or best solution. I however believe 
>> for
>> DTS that is open and available we should avoid the whole mess of needing to
>> build and manage them on boot media separately to the executable.

Note the licensing issues if you use FreeBSD or Linux FDTs: They are
GPL. If you statically link them you will infect other code too.

Although for BSPs where no FDT exists it might is a good idea to write
your own FDT and license it with a RTEMS compatible license. For BSPs
like BBB it's not a good idea if you ask me. It's a lot of work.

>>
>> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
>> our
>> users and simply linking the blobs into the executable would solve this.

Again: It opens licensing issues for our users!

>>
>> I am confronted by this now. I have a BBB with FDT blobs for libbsd master 
>> and
>> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my 
>> test
>> set up open, pop the SD card and then update it. This seems unnecessary and
>> avoidable to me.
>>
>> This also looks like a blocker for CI testing.
>>
>> Chris
>>
> Hi Chris,
> 
> I'm 100% with you. I will also go a step further and advocate that
> source-based DTS -> dtc -> FDT in static images seems beneficial to
> users. I don't know if we could get any input from users to justify
> that, but I can see advantages for pre-qual and license compliance
> that go beyond the technical advantages that you discuss above.
> 
> Initial steps in this direction would make a good GSoC for the right
> (strong) student.

If Chris sees it as a blocker for the release, GSoC might is not the
right frame. It would need too much time and the result is not
guaranteed to be OK.

Maybe we 

Suggestion

[Anmol Mishra]

I can see python2 code being used. And as of 2020 python2 has been
depreciated but I assume everyone is aware of that. Is there any active
plan to shift the codebase. I am open to discussion for this.

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

Python docstring format?

[Sebastian Huber]

Hello,

there are several Python docstring formats available:

https://stackoverflow.com/questions/3898572/what-is-the-standard-python-docstring-format

The reStructuredText Docstring Format (Sphinx) is recommended by PEP 287:

https://www.python.org/dev/peps/pep-0287/

I suggest to use this one for RTEMS as well.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Function descriptions: descriptive-style or imperative-style?

[Sebastian Huber]

Hello,

I worked a bit on Python development guidelines this week and noticed 
that our Doxygen style guide is not really clear if function 
descriptions should be in descriptive-style or imperative-style:


https://docs.rtems.org/branches/master/eng/coding-doxygen.html#function-declarations

The example "Sends a message to the message queue." suggests that it 
should be descriptive-style. In the RTEMS sources we find also 
imperative-style:


/**
 * @brief Pin the executing thread.
 *
 * @param executing The currently executing thread.
 */

I would like to give an explicit recommendation in the guide. The Google 
Python Style Guide recommends descriptive-style:


http://google.github.io/styleguide/pyguide.html#383-functions-and-methods

PEP 257 recommends imperative-style:

https://www.python.org/dev/peps/pep-0257/

I am in favour of the descriptive-style.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[Project #3860]

[Anmol Mishra]

Hello,
I was going through the list of potential projects for GSoC 2020, I love
working with automation tools and "Code Formatting and Style Check for
RTEMS score" looks exciting to me. I saw you edited the wiki and the owner
was not mentioned so pinging you for the same.
I have read the requirements and hurdles, I have a question that
1. "Is there any tool/procedure currently being considered as an option?"
2. "What is the timeframe I should look in the mail archive like the past 3
months?"

It goes without saying how much this means to me. I will be submitting 2
project proposals and don't want to waste time and start with draft
proposal asap. Looking forward to hearing from you.

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