Re: [PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

Hello Gedare,

On 15/04/2020 18:23, Gedare Bloom wrote:
> On Wed, Apr 15, 2020 at 9:31 AM Christian Mauderer
>  wrote:
>>
>> On 15/04/2020 15:56, Gedare Bloom wrote:
>>> Yes, go ahead and push them in.
>>
>> Thanks. I pushed them. But now I have a small problem: I wanted to
>> update RSB to use the new versions (Chris said in another mail that it
>> should be up to date that near to a release). But I noted that I have no
>> idea what format is used for the hash. Currently
>> rtems/config/tools/rtems-kernel-5.cfg contains the following:
>>
>>
>> %define rtems_kernel_version01219541289e8081054d4a57924ee169339f1eaf
>> %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
>>
>> qJIBYkdFGRROoJlkmxRk5Ugr2IcrcWIlXH5FfuE88mecUkDDy4JBtFDXcH0YzjwyrpmlFSaaaK850nb4o89ZCA==
>>
>>
>> That's definitively not an unprocessed output of sha512sum. Can someone
>> help me?
>>
> Use rtems-source-builder/source-builder/sha512-base64

Thanks for that.

I've updated the RSB to use the latest patches.

> 
>> Best regards
>>
>> Christian
>>
>>>
>>> On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
>>>  wrote:

 On 15/04/2020 07:06, Sebastian Huber wrote:
> Hello Christian,
>
> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
> bus-dma, imx: Don't sync nocache area.").
>

 Thanks.

 Chris, Gedare, Joel: Would it be OK for you if I push the patches before
 the release?

 Best regards

 Christian
 --
 
 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.
>>
>> --
>> 
>> 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: RTEMS Timeline Update and 25th Anniversary of First Public Commit

[Joel Sherrill]

On Wed, Apr 15, 2020 at 1:22 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 14/04/2020 15:40, Joel Sherrill wrote:
> >
> >
> > On Tue, Apr 14, 2020 at 1:47 AM Christian Mauderer
> >  > > wrote:
> >
> > Hello Joel,
> >
> > On 07/04/2020 22:44, Joel Sherrill wrote:
> > > Hi
> > >
> > > The RTEMS Project is rapidly approaching a major milestone -- the
> 25th
> > > anniversary of the oldest commit in the git repository! That
> > occurs on 4
> > > May 2020!
> > >
> > > Before that time, the source code was managed on an internal
> research
> > > project repository and snapshots/releases made available via ftp.
> > I know
> > > I started with the project in July 1989 and was coding nearly from
> the
> > > first day.
> > >
> > > With this in mind,
> > the https://devel.rtems.org/wiki/History/Timeline is
> > > sorely out of date and lacking missing entries. Multiple mission
> > > launches, addition of SMP, GSoC, GCI, and SOCIC participation,
> move to
> > > OSU OSL, incorporation of RTEMS Foundation, scientific
> > discoveries like
> > > the particle discovered by an Atlas detector at CERN or the famous
> > gamma
> > > ray burst from Fermi. All are missing.
> > >
> > > Please pitch in and help. If you want to help but don't have any
> > ideas,
> > > just post back and I will try to follow up with ideas that someone
> > else
> > > can put a date on.
> > >
> > > Thanks.
> > >
> > > --joel
> >
> > I added some small stuff (start of SMP work, main work, release
> numbers)
> > based on the git history (see
> >
> https://devel.rtems.org/wiki/History/Timeline?action=diff=27_version=25
> ).
> >
> >
> > Thanks! That's a good set of information.
> >
> >
> > Although I'm terribly bad with dates: You said you would try to
> follow
> > up with ideas. If you have any where I might could help, please let
> > me know.
> >
> >
> > How about these (random and before coffee/tea)
> >
> > + Any cool non-space programs folks can admit to?
> > + First submission from some core developers.
> > - Chris was second submitter and is in the 91-92 timeframe. We don't
> > remember.
> > - Thomas first shows up in git in March 1998.
> > - Sebastian gets a nod in July 2008. :)
> > + When were some ports added?
> > + When were some interesting/popular BSPs added: Zyng, Leon3, gba, etc
> > - FWIW the original PC BSP was based on DJ Delorie's go32 and
> pre-dates
> >   the git history. I did that on a single PC (486 with 32 MB RAM). I
> > couldn't run
> >   X11 and compile at the same time. I had to reboot to test. Yes it
> > was uphill
> >   both ways back in those days. :)
> > + When were some of the original ports/BSPs removed?
> >- mvme135/136 was first BSP
> >- i386 was second port
> >- i960 was last of original 3 ports
> > + Interesting features? Like libnetworking, libbsd, shell, dynamic
> loading?
> > + The Cygnus floppy mailing:
> > https://ftp.rtems.org/pub/rtems/people/joel/CygnusFloppyAugust1995/
> >
> > This may be good as a small tasks ticket where people cross things off
> > as they get added.
>
> I added a ticket here: https://devel.rtems.org/ticket/3952


Thank you. I went ahead and added the incorporation of the RTEMS Foundation
to the wiki and the NASA Fermi discovery which won the top prize in high
energy
astrophysics in 2018.

https://www.nasa.gov/centers/marshall/news/releases/2018/18-004.html

I'd love to see folks speak up and share that type of event. :)

And randomly, Fermi was launched in 2008 and expected to last five years.
It is now at 12 and the last I checked with them, they expected to continue
to
get funding to keep running.


> >
> > It is amazing how much this has prodded my memory.  :)
> >
> > --joel
> >
> >
> >
> > Best regards
> >
> > Christian
> > --
> > 
> > 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.
> >
>
> --
> 
> 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: [PATCHES v2] Add more i.MX6UL/ULL support

[Gedare Bloom]

On Wed, Apr 15, 2020 at 9:31 AM Christian Mauderer
 wrote:
>
> On 15/04/2020 15:56, Gedare Bloom wrote:
> > Yes, go ahead and push them in.
>
> Thanks. I pushed them. But now I have a small problem: I wanted to
> update RSB to use the new versions (Chris said in another mail that it
> should be up to date that near to a release). But I noted that I have no
> idea what format is used for the hash. Currently
> rtems/config/tools/rtems-kernel-5.cfg contains the following:
>
>
> %define rtems_kernel_version01219541289e8081054d4a57924ee169339f1eaf
> %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
>
> qJIBYkdFGRROoJlkmxRk5Ugr2IcrcWIlXH5FfuE88mecUkDDy4JBtFDXcH0YzjwyrpmlFSaaaK850nb4o89ZCA==
>
>
> That's definitively not an unprocessed output of sha512sum. Can someone
> help me?
>
Use rtems-source-builder/source-builder/sha512-base64

> Best regards
>
> Christian
>
> >
> > On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
> >  wrote:
> >>
> >> On 15/04/2020 07:06, Sebastian Huber wrote:
> >>> Hello Christian,
> >>>
> >>> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
> >>> bus-dma, imx: Don't sync nocache area.").
> >>>
> >>
> >> Thanks.
> >>
> >> Chris, Gedare, Joel: Would it be OK for you if I push the patches before
> >> the release?
> >>
> >> Best regards
> >>
> >> Christian
> >> --
> >> 
> >> 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.
>
> --
> 
> 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: [PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

On 15/04/2020 15:56, Gedare Bloom wrote:
> Yes, go ahead and push them in.

Thanks. I pushed them. But now I have a small problem: I wanted to
update RSB to use the new versions (Chris said in another mail that it
should be up to date that near to a release). But I noted that I have no
idea what format is used for the hash. Currently
rtems/config/tools/rtems-kernel-5.cfg contains the following:


%define rtems_kernel_version01219541289e8081054d4a57924ee169339f1eaf
%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \

qJIBYkdFGRROoJlkmxRk5Ugr2IcrcWIlXH5FfuE88mecUkDDy4JBtFDXcH0YzjwyrpmlFSaaaK850nb4o89ZCA==


That's definitively not an unprocessed output of sha512sum. Can someone
help me?

Best regards

Christian

> 
> On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
>  wrote:
>>
>> On 15/04/2020 07:06, Sebastian Huber wrote:
>>> Hello Christian,
>>>
>>> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
>>> bus-dma, imx: Don't sync nocache area.").
>>>
>>
>> Thanks.
>>
>> Chris, Gedare, Joel: Would it be OK for you if I push the patches before
>> the release?
>>
>> Best regards
>>
>> Christian
>> --
>> 
>> 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.

-- 

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: [PATCH 1/3] user: Update migration guide

[Joel Sherrill]

On Wed, Apr 15, 2020 at 9:29 AM Gedare Bloom  wrote:

> On Wed, Apr 15, 2020 at 7:56 AM Sebastian Huber
>  wrote:
> >
> > On 15/04/2020 15:52, Gedare Bloom wrote:
> >
> > +The configuration of SMP schedulers changed.  Please read the
> corresponding
> > +chapter in the RTEMS Classic API Guide.
> >
> > I guess inter-doc refs don't work, but maybe the chapter name should
> > be mentioned here?
> >
> > Ok, I will fix this here.
> >
> > In the long run we need a better solution for references in our
> documentation set.
> >
> > We have to make it also easier for others to reference our
> documentation. What I have in mind this is a bibtex entry in one of the
> front pages which someone can simply copy and paste into its bibtex data
> base.
>
> Yes, having some suggested citable sources would be helpful for many
> reasons. We should consider if it is possible to "publish" our release
> manuals some way that makes them more easily citable.
>

If the PDFs are acceptable, the RTEMS Foundation could self-pub them on
Amazon and that would give them ISBN numbers. I looked into doing this
a while back. At that point, I recall the biggest hurdle was having a front
and back cover. The set of template covers may have changed and OAR
now has a graphics artist on staff. Worth evaluating again.

With the RTEMS Foundation a legal entity now, that would give it a
theoretical (small) source of revenue. That's better than one of us doing
it as
an individual.

The hard copy price would be based on the number of pages. The Kindle
version should be much cheaper.

How does this sound as a plan?

We also need bibtex entries. :)

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

Re: [PATCH 1/3] user: Update migration guide

[Gedare Bloom]

On Wed, Apr 15, 2020 at 7:56 AM Sebastian Huber
 wrote:
>
> On 15/04/2020 15:52, Gedare Bloom wrote:
>
> +The configuration of SMP schedulers changed.  Please read the corresponding
> +chapter in the RTEMS Classic API Guide.
>
> I guess inter-doc refs don't work, but maybe the chapter name should
> be mentioned here?
>
> Ok, I will fix this here.
>
> In the long run we need a better solution for references in our documentation 
> set.
>
> We have to make it also easier for others to reference our documentation. 
> What I have in mind this is a bibtex entry in one of the front pages which 
> someone can simply copy and paste into its bibtex data base.

Yes, having some suggested citable sources would be helpful for many
reasons. We should consider if it is possible to "publish" our release
manuals some way that makes them more easily citable.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Joel Sherrill]

On Wed, Apr 15, 2020 at 9:11 AM Gedare Bloom  wrote:

> On Tue, Apr 14, 2020 at 10:56 PM Sebastian Huber
>  wrote:
> >
> > Hello Utkarsh Rai,
> >
> > do we really need a new test program for this test case? I would prefer
> > add it to an existing test program or add a generic POSIX test program
> > using the RTEMS Test Framework.
> >
> I would also recommend this, or perhaps develop a test for clock
> monotonic that encompasses several features (as done with clock
> realtime).
>

In theory, the clock monotonic test could be the clock realtime one reused
with the clock type changed. There are a few cases of doing something
similar.
The behavior is supposed to be the same for delays.

Missing in this discussion and maybe what Gedare is hinting at is that you
any sleep/delay/etc type of operation is never specified as a precise delay,
it is a minimum delay. The minimum may be set by clock tick time quantum,
other threads, processes, etc. The POSIX standard has precise language
about this for clock_nanosleep. From
https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html

"The suspension time caused by this function may be longer than requested
because the argument value is rounded up to an integer multiple of the
sleep resolution, or because of the scheduling of other activity by the
system."

--joel


> > On 14/04/2020 19:17, Utkarsh Rai wrote:
> > > This test checks for a simple 1 ns delay with clock_nanosleep with
> > > CLOCK_MONOTONIC.
> > > ---
> > >   testsuites/psxtests/Makefile.am   |  9 +++
> > >   testsuites/psxtests/configure.ac  |  1 +
> > >   .../psxtests/psxclocknanosleep01/init.c   | 81
> +++
> > >   .../psxclocknanosleep01.doc   | 10 +++
> > >   .../psxclocknanosleep01.scn   |  3 +
> > >   5 files changed, 104 insertions(+)
> > >   create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
> > >   create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
> > >   create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
> > >
> > > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> > > index 1f9e4233ec..e3918ae7a5 100755
> > > --- a/testsuites/psxtests/Makefile.am
> > > +++ b/testsuites/psxtests/Makefile.am
> > > @@ -321,6 +321,15 @@ psxclockrealtime01_CPPFLAGS = $(AM_CPPFLAGS) \
> > >   $(TEST_FLAGS_psxclockrealtime01) $(support_includes)
> > >   endif
> > >
> > > +if TEST_psxclocknanosleep01
> > > +psx_tests += psxclocknanosleep01
> > > +psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
> > > +psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
> > > +psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
> > > +psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
> > > + $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
> > > +endif
> > > +
> > >   if TEST_psxconcurrency01
> > >   psx_tests += psxconcurrency01
> > >   psx_screens += psxconcurrency01/psxconcurrency01.scn
> > > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> > > index 139787cccb..9bfe8e2c0b 100644
> > > --- a/testsuites/psxtests/configure.ac
> > > +++ b/testsuites/psxtests/configure.ac
> > > @@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
> > >   RTEMS_TEST_CHECK([psxcleanup02])
> > >   RTEMS_TEST_CHECK([psxclock])
> > >   RTEMS_TEST_CHECK([psxclock01])
> > > +RTEMS_TEST_CHECK([psxclocknanosleep01])
> > >   RTEMS_TEST_CHECK([psxclockrealtime01])
> > >   RTEMS_TEST_CHECK([psxconcurrency01])
> > >   RTEMS_TEST_CHECK([psxcond01])
> > > diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
> b/testsuites/psxtests/psxclocknanosleep01/init.c
> > > new file mode 100644
> > > index 00..21b738627d
> > > --- /dev/null
> > > +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
> > > @@ -0,0 +1,81 @@
> > > +/*
> > > + * SPDX-License-Identifier: BSD-2-Clause
> > > + *
> > > + * Copyright (C) 2020 Utkarsh Rai
> > > + *
> > > + * Redistribution and use in source and binary forms, with or without
> > > + * modification, are permitted provided that the following conditions
> > > + * are met:
> > > + * 1. Redistributions of source code must retain the above copyright
> > > + *notice, this list of conditions and the following disclaimer.
> > > + * 2. Redistributions in binary form must reproduce the above
> copyright
> > > + *notice, this list of conditions and the following disclaimer in
> the
> > > + *documentation and/or other materials provided with the
> distribution.
> > > + *
> > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > > + * LIABLE FOR ANY DIRECT, INDIRECT, 

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Utkarsh Rai]

Oh, I missed that, basically the difference between the second would amount
to 59 and hence my assumption would be wrong
Thank you for the clarification, I will remember to consider the cases.

On Wed 15 Apr, 2020, 7:37 PM Gedare Bloom,  wrote:

> I appreciate what Sebastian is doing, but I'll be a bit more explicit.
> You should understand what resources/APIs already exist that may help
> you, such as:
> https://docs.rtems.org/branches/master/c-user/timespec_helpers.html#timespec-helpers
>
> What happens when the time is 11:59:59.9 (HH:MM:SS.mmmuuunnn)
> and you delay for 1 ns?
>
> On Wed, Apr 15, 2020 at 8:00 AM Sebastian Huber
>  wrote:
> >
> > On 15/04/2020 15:55, Utkarsh Rai wrote:
> >
> > Yes sir.
> >
> > Ok, good, then you should do this. Maybe someone else solved this
> problem already.
> >
> >
> > On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 15/04/2020 15:00, Utkarsh Rai wrote:
> >>
> >> > Okay, so from what I could gather the time between the two gettime
> >> > calls can exceed 1 sec if it is preempted by another process in
> >> > between. Is my line of thought correct?
> >> There is no other process. What you want to know is if the difference
> >> between two struct timespec is greater than or equal to 1ns, right?
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Gedare Bloom]

On Tue, Apr 14, 2020 at 10:56 PM Sebastian Huber
 wrote:
>
> Hello Utkarsh Rai,
>
> do we really need a new test program for this test case? I would prefer
> add it to an existing test program or add a generic POSIX test program
> using the RTEMS Test Framework.
>
I would also recommend this, or perhaps develop a test for clock
monotonic that encompasses several features (as done with clock
realtime).

> On 14/04/2020 19:17, Utkarsh Rai wrote:
> > This test checks for a simple 1 ns delay with clock_nanosleep with
> > CLOCK_MONOTONIC.
> > ---
> >   testsuites/psxtests/Makefile.am   |  9 +++
> >   testsuites/psxtests/configure.ac  |  1 +
> >   .../psxtests/psxclocknanosleep01/init.c   | 81 +++
> >   .../psxclocknanosleep01.doc   | 10 +++
> >   .../psxclocknanosleep01.scn   |  3 +
> >   5 files changed, 104 insertions(+)
> >   create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
> >   create mode 100644 
> > testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
> >   create mode 100644 
> > testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
> >
> > diff --git a/testsuites/psxtests/Makefile.am 
> > b/testsuites/psxtests/Makefile.am
> > index 1f9e4233ec..e3918ae7a5 100755
> > --- a/testsuites/psxtests/Makefile.am
> > +++ b/testsuites/psxtests/Makefile.am
> > @@ -321,6 +321,15 @@ psxclockrealtime01_CPPFLAGS = $(AM_CPPFLAGS) \
> >   $(TEST_FLAGS_psxclockrealtime01) $(support_includes)
> >   endif
> >
> > +if TEST_psxclocknanosleep01
> > +psx_tests += psxclocknanosleep01
> > +psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
> > +psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
> > +psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
> > +psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
> > + $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
> > +endif
> > +
> >   if TEST_psxconcurrency01
> >   psx_tests += psxconcurrency01
> >   psx_screens += psxconcurrency01/psxconcurrency01.scn
> > diff --git a/testsuites/psxtests/configure.ac 
> > b/testsuites/psxtests/configure.ac
> > index 139787cccb..9bfe8e2c0b 100644
> > --- a/testsuites/psxtests/configure.ac
> > +++ b/testsuites/psxtests/configure.ac
> > @@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
> >   RTEMS_TEST_CHECK([psxcleanup02])
> >   RTEMS_TEST_CHECK([psxclock])
> >   RTEMS_TEST_CHECK([psxclock01])
> > +RTEMS_TEST_CHECK([psxclocknanosleep01])
> >   RTEMS_TEST_CHECK([psxclockrealtime01])
> >   RTEMS_TEST_CHECK([psxconcurrency01])
> >   RTEMS_TEST_CHECK([psxcond01])
> > diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
> > b/testsuites/psxtests/psxclocknanosleep01/init.c
> > new file mode 100644
> > index 00..21b738627d
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
> > @@ -0,0 +1,81 @@
> > +/*
> > + * SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2020 Utkarsh Rai
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in the
> > + *documentation and/or other materials provided with the distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> > IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, 
> > THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
> > PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
> > THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*Forward declaration to avoid compiler warning*/
> > +void clock_sleep(void);
> Please use a static function instead. Most of these forward declarations
> are just lazy warning fixes and bad examples.
> > +
> > +rtems_task Init(rtems_task_argument ignored);
> > +
> > +const char rtems_test_name[] = "PSXCLOCKNANOSLEEP 01";
> > +
> > +void clock_sleep(void)
> > +{
> > +  struct timespec delay_time;
> > +  intstatus;
> > +
> > +  delay_time.tv_sec = 0;
> > +  delay_time.tv_nsec = 1;
> > +
> > +  

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Gedare Bloom]

I appreciate what Sebastian is doing, but I'll be a bit more explicit.
You should understand what resources/APIs already exist that may help
you, such as:  
https://docs.rtems.org/branches/master/c-user/timespec_helpers.html#timespec-helpers

What happens when the time is 11:59:59.9 (HH:MM:SS.mmmuuunnn)
and you delay for 1 ns?

On Wed, Apr 15, 2020 at 8:00 AM Sebastian Huber
 wrote:
>
> On 15/04/2020 15:55, Utkarsh Rai wrote:
>
> Yes sir.
>
> Ok, good, then you should do this. Maybe someone else solved this problem 
> already.
>
>
> On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, 
>  wrote:
>>
>> On 15/04/2020 15:00, Utkarsh Rai wrote:
>>
>> > Okay, so from what I could gather the time between the two gettime
>> > calls can exceed 1 sec if it is preempted by another process in
>> > between. Is my line of thought correct?
>> There is no other process. What you want to know is if the difference
>> between two struct timespec is greater than or equal to 1ns, right?
>
> ___
> 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

FreeBSD 12 Failures - Py_Initialize: can't initialize sys standard streams

[Joel Sherrill]

Hi

I see this type of failure on rtems-tools and rtems-tester. I run nohup'ed
and I suspect these happen after the connection is dropped. I see what I
think is discussion of similar issues here:
https://bugs.python.org/issue32849

I don't see this on Linux although in that issue report, it was
reproducible there.



+ cd rtems-tools-ca7b290f94a19238ed068aad229854cf67dee9b5
+ ./waf distclean configure '--prefix=/home/joel/rtems-cron-5/tools/5'
Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor

Current thread 0x0008009e2000 (most recent call first):
Abort trap (core dumped)
shell cmd failed: /bin/sh -ex
 /usr/home/joel/rtems-cron-5/rtems-source-builder/
rtems/build/rtems-tools-ca7b290f94a19238ed068aad229854cf67dee9b5-1/do-build
error: building rtems-tools-ca7b290f94a19238ed068aad229854cf67dee9b5-1


I also see this in my script that builds a bsp individually and then uses
rtems-tester:

===
Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor

Current thread 0x0008009e2000 (most recent call first):
time: command terminated abnormally
===

I have everything nohup'ed and redirected to files which shouldn't be a big
surprise.

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

Re: [PATCH] Canonicalize config.h include

[Sebastian Huber]

On 15/04/2020 15:59, Gedare Bloom wrote:


This is fine with me to go in 5.1 or defer to 6 it doesn't really matter.
It reduces a bit the probability for merge conflicts. So, I will push it 
after a compile run.

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

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Sebastian Huber]

On 15/04/2020 15:55, Utkarsh Rai wrote:


Yes sir.
Ok, good, then you should do this. Maybe someone else solved this 
problem already.


On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, 
> wrote:


On 15/04/2020 15:00, Utkarsh Rai wrote:

> Okay, so from what I could gather the time between the two gettime
> calls can exceed 1 sec if it is preempted by another process in
> between. Is my line of thought correct?
There is no other process. What you want to know is if the difference
between two struct timespec is greater than or equal to 1ns, right?

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

Re: [PATCH] Canonicalize config.h include

[Gedare Bloom]

This is fine with me to go in 5.1 or defer to 6 it doesn't really matter.

On Wed, Apr 15, 2020 at 1:55 AM Sebastian Huber
 wrote:
>
> Use the following variant which was already used by most source files:
>
>   #ifdef HAVE_CONFIG_H
>   #include "config.h"
>   #endif
> ---
>  cpukit/dev/i2c/eeprom.c | 4 ++--
>  cpukit/dev/i2c/fpga-i2c-slave.c | 4 ++--
>  cpukit/dev/i2c/gpio-nxp-pca9535.c   | 4 ++--
>  cpukit/dev/i2c/i2c-bus.c| 4 ++--
>  cpukit/dev/i2c/i2c-dev.c| 4 ++--
>  cpukit/dev/i2c/sensor-lm75a.c   | 2 +-
>  cpukit/dev/i2c/switch-nxp-pca9548a.c| 4 ++--
>  cpukit/dev/i2c/ti-ads-16bit-adc.c   | 4 ++--
>  cpukit/dev/i2c/ti-lm25066a.c| 4 ++--
>  cpukit/dev/i2c/ti-tmp112.c  | 4 ++--
>  cpukit/dev/spi/spi-bus.c| 4 ++--
>  cpukit/ftpd/ftpd-init.c | 2 +-
>  cpukit/ftpd/ftpd.c  | 2 +-
>  cpukit/libblock/src/bdbuf.c | 2 +-
>  cpukit/libblock/src/bdpart-register.c   | 2 +-
>  cpukit/libblock/src/blkdev-blkstats.c   | 4 ++--
>  cpukit/libblock/src/blkdev-imfs.c   | 4 ++--
>  cpukit/libblock/src/blkdev-ioctl.c  | 4 ++--
>  cpukit/libblock/src/blkdev-print-stats.c| 4 ++--
>  cpukit/libblock/src/blkdev.c| 2 +-
>  cpukit/libblock/src/diskdevs-init.c | 4 ++--
>  cpukit/libblock/src/diskdevs.c  | 2 +-
>  cpukit/libblock/src/flashdisk.c | 2 +-
>  cpukit/libblock/src/ide_part_table.c| 2 +-
>  cpukit/libblock/src/nvdisk-sram.c   | 2 +-
>  cpukit/libblock/src/nvdisk.c| 2 +-
>  cpukit/libblock/src/ramdisk-init.c  | 2 +-
>  cpukit/libblock/src/ramdisk-register.c  | 2 +-
>  cpukit/libblock/src/show_bdbuf.c| 2 +-
>  cpukit/libcsupport/src/__assert.c   | 2 +-
>  cpukit/libcsupport/src/__getpid.c   | 2 +-
>  cpukit/libcsupport/src/__gettod.c   | 2 +-
>  cpukit/libcsupport/src/__times.c| 2 +-
>  cpukit/libcsupport/src/__usrenv.c   | 4 ++--
>  cpukit/libcsupport/src/_calloc_r.c  | 2 +-
>  cpukit/libcsupport/src/_free_r.c| 2 +-
>  cpukit/libcsupport/src/_malloc_r.c  | 2 +-
>  cpukit/libcsupport/src/_realloc_r.c | 2 +-
>  cpukit/libcsupport/src/_rename_r.c  | 2 +-
>  cpukit/libcsupport/src/access.c | 2 +-
>  cpukit/libcsupport/src/alignedalloc.c   | 2 +-
>  cpukit/libcsupport/src/assoc32tostring.c| 2 +-
>  cpukit/libcsupport/src/assoclocalbyname.c   | 2 +-
>  cpukit/libcsupport/src/assoclocalbyremote.c | 2 +-
>  cpukit/libcsupport/src/assoclocalbyremotebitfield.c | 2 +-
>  cpukit/libcsupport/src/assocnamebad.c   | 2 +-
>  cpukit/libcsupport/src/assocnamebylocal.c   | 2 +-
>  cpukit/libcsupport/src/assocnamebylocalbitfield.c   | 2 +-
>  cpukit/libcsupport/src/assocnamebyremote.c  | 2 +-
>  cpukit/libcsupport/src/assocnamebyremotebitfield.c  | 2 +-
>  cpukit/libcsupport/src/assocptrbylocal.c| 2 +-
>  cpukit/libcsupport/src/assocptrbyname.c | 2 +-
>  cpukit/libcsupport/src/assocptrbyremote.c   | 2 +-
>  cpukit/libcsupport/src/assocremotebylocal.c | 2 +-
>  cpukit/libcsupport/src/assocremotebylocalbitfield.c | 2 +-
>  cpukit/libcsupport/src/assocremotebyname.c  | 2 +-
>  cpukit/libcsupport/src/assocthreadstatestostring.c  | 2 +-
>  cpukit/libcsupport/src/base_fs.c| 2 +-
>  cpukit/libcsupport/src/cachecoherentalloc.c | 4 ++--
>  cpukit/libcsupport/src/calloc.c | 2 +-
>  cpukit/libcsupport/src/cfgetispeed.c| 2 +-
>  cpukit/libcsupport/src/cfgetospeed.c| 2 +-
>  cpukit/libcsupport/src/cfmakeraw.c  | 2 +-
>  cpukit/libcsupport/src/cfmakesane.c | 2 +-
>  cpukit/libcsupport/src/cfsetispeed.c| 2 +-
>  cpukit/libcsupport/src/cfsetospeed.c| 2 +-
>  cpukit/libcsupport/src/cfsetspeed.c | 2 +-

Re: [PATCHES v2] Add more i.MX6UL/ULL support

[Gedare Bloom]

Yes, go ahead and push them in.

On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
 wrote:
>
> On 15/04/2020 07:06, Sebastian Huber wrote:
> > Hello Christian,
> >
> > the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
> > bus-dma, imx: Don't sync nocache area.").
> >
>
> Thanks.
>
> Chris, Gedare, Joel: Would it be OK for you if I push the patches before
> the release?
>
> Best regards
>
> Christian
> --
> 
> 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: [PATCH 1/3] user: Update migration guide

[Sebastian Huber]

On 15/04/2020 15:52, Gedare Bloom wrote:


+The configuration of SMP schedulers changed.  Please read the corresponding
+chapter in the RTEMS Classic API Guide.

I guess inter-doc refs don't work, but maybe the chapter name should
be mentioned here?


Ok, I will fix this here.

In the long run we need a better solution for references in our 
documentation set.


We have to make it also easier for others to reference our 
documentation. What I have in mind this is a bibtex entry in one of the 
front pages which someone can simply copy and paste into its bibtex data 
base.


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

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Utkarsh Rai]

Yes sir.

On Wed 15 Apr, 2020, 7:21 PM Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/04/2020 15:00, Utkarsh Rai wrote:
>
> > Okay, so from what I could gather the time between the two gettime
> > calls can exceed 1 sec if it is preempted by another process in
> > between. Is my line of thought correct?
> There is no other process. What you want to know is if the difference
> between two struct timespec is greater than or equal to 1ns, right?
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] c-user: Split deprecated/removed directives chapter

[Gedare Bloom]

thanks, make the minor typo corrections and push

On Tue, Apr 14, 2020 at 9:13 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/task_manager.rst | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/c-user/task_manager.rst b/c-user/task_manager.rst
> index aca3699..c3919f4 100644
> --- a/c-user/task_manager.rst
> +++ b/c-user/task_manager.rst
> @@ -600,7 +600,7 @@ against the current system configuration.
>  .. index:: rtems_task_get_note
>  .. index:: rtems_task_set_note
>
> -Transition Advice for Obsolete Notepads
> +Transition Advice for Removed Notepads
>  ---
>
>  Task notepads and the associated directives :ref:`rtems_task_get_note` and
> @@ -618,7 +618,7 @@ also possible that thread-local storage (TLS) is an 
> option for some use cases.
>  .. index:: rtems_task_variable_get
>  .. index:: rtems_task_variable_delete
>
> -Transition Advice for Obsolete Task Variables
> +Transition Advice for Removed Task Variables
>  -
>
>  Task notepads and the associated directives :ref:`rtems_task_variable_add`,
> @@ -1757,8 +1757,8 @@ NOTES:
>  visitor, however, take care that no deadlocks via the object allocator 
> lock
>  can occur.
>
> -Deprecated and Removed Directives
> -=
> +Deprecated Directives
> +=
>
>  .. raw:: latex
>
> @@ -1800,6 +1800,9 @@ NOTES:
>  control block may be in an inconsistent state or may change due to
>  interrupts or activity on other processors.
>
> +Removed Directives
> +==
> +
>  .. raw:: latex
>
> \clearpage
> --
> 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: [PATCH 2/3] c-user: Add removed directive rtems_clock_get()

[Gedare Bloom]

On Tue, Apr 14, 2020 at 9:13 AM Sebastian Huber
 wrote:
>
> Be in line with Task Manager chapter.
>
> Update #2693.
> ---
>  c-user/clock_manager.rst | 128 
> +++
>  1 file changed, 107 insertions(+), 21 deletions(-)
>
> diff --git a/c-user/clock_manager.rst b/c-user/clock_manager.rst
> index 905d327..9ece420 100644
> --- a/c-user/clock_manager.rst
> +++ b/c-user/clock_manager.rst
> @@ -184,20 +184,28 @@ RTEMS provides multiple directives which can be used by 
> an application to obtain
>  Calendar time operations will return an error code if invoked before the date
>  and time have been set.
>
> -.. index:: rtems_clock_get
> +.. _ClockManagerAdviceClockGet:
> +
> +Transition Advice for the Removed rtems_clock_get()
> +---
> +
> +The method :ref:`rtems_clock_get` took an untyped pointer with an options
> +argument to indicate the time information desired. This has been replaced 
> with
> +a set of typed directives:
> +
> +* :ref:`rtems_clock_get_seconds_since_epoch`
>
> -Transition Advice for the Obsolete rtems_clock_get
> ---
> +* :ref:`rtems_clock_get_ticks_per_second`
>
> -The method ``rtems_clock_get`` took an untyped pointer with an
> -options argument to indicate the time information desired. This has
> -been replaced with a set of typed directives whose name is of the form
> -``rtems_clock_get_INFORMATION`` where INFORMATION indicates the type of
> -information and possibly the format.  These methods directly correspond to
> -what were previously referred to ask "clock options." These strongly typed
> -were available for multiple releases in parallel with ``rtems_clock_get``
> -until that method was removed.
> +* :ref:`rtems_clock_get_ticks_since_boot`
>
> +* :ref:`rtems_clock_get_tod`
> +
> +* :ref:`rtems_clock_get_tod_timeval`
> +
> +These methods directly correspond to what were previously referred to ask
s/ask/as

> +*clock options*.  These strongly typed were available for multiple releases 
> in
add "methods" after typed

> +parallel with :c:func:`rtems_clock_get` until that method was removed.
>
>  Directives
>  ==
> @@ -260,11 +268,11 @@ NOTES:
>
> \clearpage
>
> -.. _rtems_clock_get_tod:
> -
>  .. index:: obtain the time of day
>  .. index:: rtems_clock_get_tod
>
> +.. _rtems_clock_get_tod:
> +
>  CLOCK_GET_TOD - Get date and time in TOD format
>  ---
>
> @@ -304,11 +312,11 @@ NOTES:
>
> \clearpage
>
> -.. _rtems_clock_get_tod_timeval:
> -
>  .. index:: obtain the time of day
>  .. index:: rtems_clock_get_tod_timeval
>
> +.. _rtems_clock_get_tod_timeval:
> +
>  CLOCK_GET_TOD_TIMEVAL - Get date and time in timeval format
>  ---
>
> @@ -348,11 +356,11 @@ NOTES:
>
> \clearpage
>
> -.. _rtems_clock_get_seconds_since_epoch:
> -
>  .. index:: obtain seconds since epoch
>  .. index:: rtems_clock_get_seconds_since_epoch
>
> +.. _rtems_clock_get_seconds_since_epoch:
> +
>  CLOCK_GET_SECONDS_SINCE_EPOCH - Get seconds since epoch
>  ---
>
> @@ -392,11 +400,11 @@ NOTES:
>
> \clearpage
>
> -.. _rtems_clock_get_ticks_per_second:
> -
>  .. index:: obtain seconds since epoch
>  .. index:: rtems_clock_get_ticks_per_second
>
> +.. _rtems_clock_get_ticks_per_second:
> +
>  CLOCK_GET_TICKS_PER_SECOND - Get ticks per second
>  -
>
> @@ -422,12 +430,12 @@ NOTES:
>
> \clearpage
>
> -.. _rtems_clock_get_ticks_since_boot:
> -
>  .. index:: obtain ticks since boot
>  .. index:: get current ticks counter value
>  .. index:: rtems_clock_get_ticks_since_boot
>
> +.. _rtems_clock_get_ticks_since_boot:
> +
>  CLOCK_GET_TICKS_SINCE_BOOT - Get current ticks counter value
>  
>
> @@ -666,3 +674,81 @@ DESCRIPTION:
>
>  NOTES:
>  This directive may be called from an ISR.
> +
> +Removed Directives
> +==
> +
> +.. raw:: latex
> +
> +   \clearpage
> +
> +.. _rtems_clock_get:
> +
> +CLOCK_GET - Get date and time information
> +-
> +.. index:: obtain the time of day
> +.. index:: rtems_clock_get
> +
> +.. warning::
> +
> +This directive was removed in RTEMS 5.1.  See also
> +:ref:`ClockManagerAdviceClockGet`.
> +
> +CALLING SEQUENCE:
> +.. code-block:: c
> +
> +rtems_status_code rtems_clock_get(
> +   rtems_clock_get_options  option,
> +   void*time_buffer
> +);
> +
> +DIRECTIVE STATUS CODES:
> +.. list-table::
> +  :class: rtems-table
> +
> +  * - ``RTEMS_SUCCESSFUL``
> +- current time obtained successfully
> +  * - ``RTEMS_NOT_DEFINED``
> +- system date and time is not set
> +  * - ``RTEMS_INVALID_ADDRESS``
> +- ``time_buffer`` is NULL
> +
> 

Re: [PATCH 1/3] user: Update migration guide

[Gedare Bloom]

On Tue, Apr 14, 2020 at 9:13 AM Sebastian Huber
 wrote:
>
> Update #3895.
> ---
>  user/migration/v4_11-to-v5.rst | 54 
> --
>  1 file changed, 42 insertions(+), 12 deletions(-)
>
> diff --git a/user/migration/v4_11-to-v5.rst b/user/migration/v4_11-to-v5.rst
> index 4329771..2917951 100644
> --- a/user/migration/v4_11-to-v5.rst
> +++ b/user/migration/v4_11-to-v5.rst
> @@ -1,6 +1,7 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
>  .. Copyright (C) 2020 Chris Johns
> +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>
>  .. _Migration_4_11_to_5:
>
> @@ -10,33 +11,62 @@ RTEMS 4.11 to RTEMS 5
>  This section provides helpful information when migrating from RTEMS 4.11 to
>  RTEMS 5.
>
> -Configuration
> --
> +Application Configuration Options
> +-
> +
> +The evaluation of application configuration options in 
> +was reworked during the RTEMS 5 development cycle.  All options which let the
> +user define data structures were removed, this includes
> +
> +* ``CONFIGURE_HAS_OWN_CONFIGURATION_TABLE``,
> +
> +* ``CONFIGURE_HAS_OWN_BDBUF_TABLE``,
> +
> +* ``CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE``,
> +
> +* ``CONFIGURE_HAS_OWN_FILESYSTEM_TABLE``,
> +
> +* ``CONFIGURE_HAS_OWN_INIT_TABLE``,
>
> -A number of configurations macros have moved as a result of internal changes 
> in
> -RTEMS. Some of these will produce a warning indicating the new configuration
> -setings you need to define. If you need to run an application on RTEMS 4.11 
> and
> -RTEMS 5 the following code exmaple shows how to conditionally define the
> -settings. The example is:
> +* ``CONFIGURE_HAS_OWN_MOUNT_TABLE``,
> +
> +* ``CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE``, and
> +
> +* ``CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE``.
> +
> +The configuration of SMP schedulers changed.  Please read the corresponding
> +chapter in the RTEMS Classic API Guide.

I guess inter-doc refs don't work, but maybe the chapter name should
be mentioned here?

> +
> +A number of configurations options have moved or are obsolete as a result of
> +internal changes in RTEMS.  Some of these will produce a warning indicating 
> the
> +new configuration setings you need to define. If you need to run an 
> application
s/setings/settings
Not introduced by your change, but still should fix.

> +on RTEMS 4.11 and RTEMS 5 the following code exmaple shows how to 
> conditionally
s/exmaple/example
Also not your typo.

> +define the settings. The example is:
>
>  .. code-block:: c
>
>  #include 
>
>  #if __RTEMS_MAJOR__ < 5
> - #define CONFIGURE_MAXIMUM_FIFOS 10
> - #define CONFIGURE_MAXIMUM_PIPES 10
> +  #define CONFIGURE_MAXIMUM_FIFOS 10
> +  #define CONFIGURE_MAXIMUM_PIPES 10
>  #else
> - #define CONFIGURE_IMFS_ENABLE_MKFIFO
> +  #define CONFIGURE_IMFS_ENABLE_MKFIFO
>  #endif
>
>  #define MAX_FILE_DESCRIPTORS 200
>  #if __RTEMS_MAJOR__ < 5
> - #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS MAX_FILE_DESCRIPTORS
> +  #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS MAX_FILE_DESCRIPTORS
>  #else
> - #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS   MAX_FILE_DESCRIPTORS
> +  #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS   MAX_FILE_DESCRIPTORS
>  #endif
>
> +Clock Manager
> +-
> +
> +The directive :c:func:`rtems_clock_get` was removed.  See the RTEMS Classic 
> API
> +Guide for alternatives.
Again, providing further direction would help.

> +
>  Networking
>  --
>
> --
> 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: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Sebastian Huber]

On 15/04/2020 15:00, Utkarsh Rai wrote:

Okay, so from what I could gather the time between the two gettime 
calls can exceed 1 sec if it is preempted by another process in 
between. Is my line of thought correct?
There is no other process. What you want to know is if the difference 
between two struct timespec is greater than or equal to 1ns, right?

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

Re: Missing link on the RTEMS website

[Joel Sherrill]

On Wed, Apr 15, 2020, 7:59 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/04/2020 14:55, Joel Sherrill wrote:
>
>
>
> On Wed, Apr 15, 2020 at 6:11 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>> On 15/04/2020 13:03, Kuan-Hsun Chen wrote:
>>
>> Hello all,
>>
>> I just notice that https://www.rtems.org/ page has a link point to,
>> which is missing:
>> https://devel.rtems.org/wiki/TBR/Website/Mission_Statement
>>
>> I am writing some descriptions regarding RTEMS at meanwhile, should I
>> just report here or directly update the website somehow?
>>
>> I moved the mission statement to the engineering manual:
>>
>> https://docs.rtems.org/branches/master/eng/mission.html
>>
>> It would be nice if someone can fix the link on www.rtems.org.
>>
>
> I think this is done now. Please check and confirm.
>
> Thanks, this one is fixed. There are a couple of other links which point
> to the wiki and should instead point to the documentation.
>

Could you provide specifics? There are a lot of links there.

I am to fix them if I know what to fix.

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

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Utkarsh Rai]

Okay, so from what I could gather the time between the two gettime calls
can exceed 1 sec if it is preempted by another process in between. Is my
line of thought correct?

On Wed, Apr 15, 2020 at 6:01 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 15/04/2020 14:29, Utkarsh Rai wrote:
>
> On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 15/04/2020 14:02, Utkarsh Rai wrote:
>>
>> > +  status = clock_gettime( CLOCK_MONOTONIC, _time );
>>> > +  rtems_test_assert( status == 0 );
>>> > +
>>> > +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) == 0 );
>>>
>>> Is end_time.tv_sec - init_time.tv_sec == 0 under all circumstances?
>>>
>>
>> My idea was to check for a 1ns delay with a reasonable amount of
>> overhead, hence I checked for  end_time.tv_sec - init_time.tv_sec == 0.
>>
>> Exists there a value of init_time for which end_time.tv_sec !=
>> init_time.tv_sec and still 1ns elapsed?
>>
>
> Sorry, maybe I am confused in my concept, kidly help me out. I want to
> produce a 1ns delay, so I make a call to clock_nanosleep with flag value as
> 0 (to sleep for specified time) and the delay being 1ns. I recorded the
> time before the sleep call and after the sleep call. Now, I want to check
> if the delay produced was actually 1ns with a reasonable overhead, my
> assumption for an unreasonable overhead was that if I specify a delay of
> 1ns
>
> Up to here everything is fine.
>
> and I get a delay in seconds, it would be an error.
>
> Think about this once more.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Missing link on the RTEMS website

[Sebastian Huber]

On 15/04/2020 14:55, Joel Sherrill wrote:




On Wed, Apr 15, 2020 at 6:11 AM Sebastian Huber 
> wrote:


Hello,

On 15/04/2020 13:03, Kuan-Hsun Chen wrote:

Hello all,

I just notice that https://www.rtems.org/page has a link point
to, which is missing:
https://devel.rtems.org/wiki/TBR/Website/Mission_Statement

I am writing some descriptions regarding RTEMS at meanwhile,
should I just report here or directly update the website somehow?


I moved the mission statement to the engineering manual:

https://docs.rtems.org/branches/master/eng/mission.html

It would be nice if someone can fix the link on www.rtems.org
.


I think this is done now. Please check and confirm.
Thanks, this one is fixed. There are a couple of other links which point 
to the wiki and should instead point to the documentation.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Missing link on the RTEMS website

[Joel Sherrill]

On Wed, Apr 15, 2020 at 6:11 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
> On 15/04/2020 13:03, Kuan-Hsun Chen wrote:
>
> Hello all,
>
> I just notice that https://www.rtems.org/ page has a link point to, which
> is missing:
> https://devel.rtems.org/wiki/TBR/Website/Mission_Statement
>
> I am writing some descriptions regarding RTEMS at meanwhile, should I just
> report here or directly update the website somehow?
>
> I moved the mission statement to the engineering manual:
>
> https://docs.rtems.org/branches/master/eng/mission.html
>
> It would be nice if someone can fix the link on www.rtems.org.
>

I think this is done now. Please check and confirm.

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

AW: [PATCH v4 3/3] i386: Port to RTEMS

[Jan.Sommer]

> -Ursprüngliche Nachricht-
> Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Gesendet: Mittwoch, 15. April 2020 09:23
> An: Sommer, Jan; devel@rtems.org
> Betreff: Re: [PATCH v4 3/3] i386: Port to RTEMS
> 
> On 09/04/2020 15:56, Jan Sommer wrote:
> 
> > - Update imported files to compile rtems-libbsd for i386 based BSPs
> > ---
> >   freebsd-org  |2 +-
> >   freebsd/sbin/sysctl/sysctl.c |8 +
> >   freebsd/sys/dev/pci/pci_pci.c|2 +
> >   freebsd/sys/i386/i386/legacy.c   |  381 -
> >   freebsd/sys/i386/include/machine/cpufunc.h   |2 +
> >   freebsd/sys/i386/include/machine/legacyvar.h |   63 --
> >   freebsd/sys/kern/subr_gtaskqueue.c   |4 +
> Looks good.

Does that ok include the deactivation of the BSD_ASSERT for i386 as well?
I am not that deep in the FreeBSD internals, yet, so I have no reliable gut 
feeling for those kind of changes.

> >   freebsd/sys/net/iflib.c  |   24 +
> Please move this to a separate commit with a reason for the change.
Ok.

> >   freebsd/sys/sys/callout.h|6 +
> 
> Please move this to a separate commit with a reason for the change.
>
Ok.
 
> >   rtemsbsd/i386/include/machine/clock.h|2 +
> >   rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0
> 
> >   rtemsbsd/include/x86/legacyvar.h |1 +
> >   rtemsbsd/include/x86/specialreg.h| 1074
> ++
> >   rtemsbsd/include/x86/x86_var.h   |  156 
> Where do these files come from?

Originally from freebsd-org/sys/x86/include . 
However, I just noticed that with the path-mappings feature it is now pretty 
easy to solve that with header indirection.
In the next version I will add the files to libbsd.py and add here only a 
oneliner.
That should be more future proof.

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

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Sebastian Huber]

On 15/04/2020 14:29, Utkarsh Rai wrote:
On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber 
> wrote:


On 15/04/2020 14:02, Utkarsh Rai wrote:


> +  status = clock_gettime( CLOCK_MONOTONIC, _time );
> +  rtems_test_assert( status == 0 );
> +
> +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) ==
0 );

Is end_time.tv_sec - init_time.tv_sec == 0 under all
circumstances?


My idea was to check for a 1ns delay with a reasonable amount of
overhead, hence I checked for  end_time.tv_sec - init_time.tv_sec
== 0.

Exists there a value of init_time for which end_time.tv_sec !=
init_time.tv_sec and still 1ns elapsed?


Sorry, maybe I am confused in my concept, kidly help me out. I want to 
produce a 1ns delay, so I make a call to clock_nanosleep with flag 
value as 0 (to sleep for specified time) and the delay being 1ns. I 
recorded the time before the sleep call and after the sleep call. Now, 
I want to check if the delay produced was actually 1ns with a 
reasonable overhead, my assumption for an unreasonable overhead was 
that if I specify a delay of 1ns

Up to here everything is fine.

and I get a delay in seconds, it would be an error.

Think about this once more.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Utkarsh Rai]

On Wed, Apr 15, 2020 at 5:35 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/04/2020 14:02, Utkarsh Rai wrote:
>
> > +  status = clock_gettime( CLOCK_MONOTONIC, _time );
>> > +  rtems_test_assert( status == 0 );
>> > +
>> > +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) == 0 );
>>
>> Is end_time.tv_sec - init_time.tv_sec == 0 under all circumstances?
>>
>
> My idea was to check for a 1ns delay with a reasonable amount of overhead,
> hence I checked for  end_time.tv_sec - init_time.tv_sec == 0.
>
> Exists there a value of init_time for which end_time.tv_sec !=
> init_time.tv_sec and still 1ns elapsed?
>

Sorry, maybe I am confused in my concept, kidly help me out. I want to
produce a 1ns delay, so I make a call to clock_nanosleep with flag value as
0 (to sleep for specified time) and the delay being 1ns. I recorded the
time before the sleep call and after the sleep call. Now, I want to check
if the delay produced was actually 1ns with a reasonable overhead, my
assumption for an unreasonable overhead was that if I specify a delay of
1ns and I get a delay in seconds, it would be an error.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Sebastian Huber]

On 15/04/2020 14:02, Utkarsh Rai wrote:


> +  status = clock_gettime( CLOCK_MONOTONIC, _time );
> +  rtems_test_assert( status == 0 );
> +
> +  rtems_test_assert( (end_time.tv_sec-init_time.tv_sec) == 0 );

Is end_time.tv_sec - init_time.tv_sec == 0 under all circumstances?


My idea was to check for a 1ns delay with a reasonable amount of 
overhead, hence I checked for  end_time.tv_sec - init_time.tv_sec == 0.
Exists there a value of init_time for which end_time.tv_sec != 
init_time.tv_sec and still 1ns elapsed?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Test for clock_nanosleep with CLOCK_MONOTONIC option.

[Utkarsh Rai]

On Wed, Apr 15, 2020 at 10:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Utkarsh Rai,
>
> do we really need a new test program for this test case? I would prefer
> add it to an existing test program or add a generic POSIX test program
> using the RTEMS Test Framework.
>
Would it be alright to add the test cases for clock nanosleep in
psxtests/psxclock? I had two test cases in mind-
To check for a simple desired delay and to check that clock_nanosleep
produces the required delay with CLOCK_MONOTONIC even when CLOCK_REALTIME
is modified.

On 14/04/2020 19:17, Utkarsh Rai wrote:
> > This test checks for a simple 1 ns delay with clock_nanosleep with
> > CLOCK_MONOTONIC.
> > ---
> >   testsuites/psxtests/Makefile.am   |  9 +++
> >   testsuites/psxtests/configure.ac  |  1 +
> >   .../psxtests/psxclocknanosleep01/init.c   | 81 +++
> >   .../psxclocknanosleep01.doc   | 10 +++
> >   .../psxclocknanosleep01.scn   |  3 +
> >   5 files changed, 104 insertions(+)
> >   create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
> >   create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
> >   create mode 100644
> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
> >
> > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> > index 1f9e4233ec..e3918ae7a5 100755
> > --- a/testsuites/psxtests/Makefile.am
> > +++ b/testsuites/psxtests/Makefile.am
> > @@ -321,6 +321,15 @@ psxclockrealtime01_CPPFLAGS = $(AM_CPPFLAGS) \
> >   $(TEST_FLAGS_psxclockrealtime01) $(support_includes)
> >   endif
> >
> > +if TEST_psxclocknanosleep01
> > +psx_tests += psxclocknanosleep01
> > +psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
> > +psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
> > +psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
> > +psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
> > + $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
> > +endif
> > +
> >   if TEST_psxconcurrency01
> >   psx_tests += psxconcurrency01
> >   psx_screens += psxconcurrency01/psxconcurrency01.scn
> > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> > index 139787cccb..9bfe8e2c0b 100644
> > --- a/testsuites/psxtests/configure.ac
> > +++ b/testsuites/psxtests/configure.ac
> > @@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
> >   RTEMS_TEST_CHECK([psxcleanup02])
> >   RTEMS_TEST_CHECK([psxclock])
> >   RTEMS_TEST_CHECK([psxclock01])
> > +RTEMS_TEST_CHECK([psxclocknanosleep01])
> >   RTEMS_TEST_CHECK([psxclockrealtime01])
> >   RTEMS_TEST_CHECK([psxconcurrency01])
> >   RTEMS_TEST_CHECK([psxcond01])
> > diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c
> b/testsuites/psxtests/psxclocknanosleep01/init.c
> > new file mode 100644
> > index 00..21b738627d
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxclocknanosleep01/init.c
> > @@ -0,0 +1,81 @@
> > +/*
> > + * SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2020 Utkarsh Rai
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in
> the
> > + *documentation and/or other materials provided with the
> distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*Forward declaration to avoid compiler warning*/
> > +void clock_sleep(void);
> Please use a static function instead. Most of these forward declarations
> are just lazy warning fixes and bad examples.
> > +
> > +rtems_task Init(rtems_task_argument ignored);
> > +
> > +const char rtems_test_name[] = "PSXCLOCKNANOSLEEP 01";
> > +
> > +void 

Re: Missing link on the RTEMS website

[Sebastian Huber]

Hello,

On 15/04/2020 13:03, Kuan-Hsun Chen wrote:

Hello all,

I just notice that https://www.rtems.org/page has a link point to, 
which is missing:

https://devel.rtems.org/wiki/TBR/Website/Mission_Statement

I am writing some descriptions regarding RTEMS at meanwhile, should I 
just report here or directly update the website somehow?


I moved the mission statement to the engineering manual:

https://docs.rtems.org/branches/master/eng/mission.html

It would be nice if someone can fix the link on www.rtems.org.

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

Missing link on the RTEMS website

[Kuan-Hsun Chen]

Hello all,

I just notice that https://www.rtems.org/ page has a link point to, which
is missing:
https://devel.rtems.org/wiki/TBR/Website/Mission_Statement

I am writing some descriptions regarding RTEMS at meanwhile, should I just
report here or directly update the website somehow?

Best,
Kuan-Hsun
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Canonicalize config.h include

[Sebastian Huber]

Use the following variant which was already used by most source files:

  #ifdef HAVE_CONFIG_H
  #include "config.h"
  #endif
---
 cpukit/dev/i2c/eeprom.c | 4 ++--
 cpukit/dev/i2c/fpga-i2c-slave.c | 4 ++--
 cpukit/dev/i2c/gpio-nxp-pca9535.c   | 4 ++--
 cpukit/dev/i2c/i2c-bus.c| 4 ++--
 cpukit/dev/i2c/i2c-dev.c| 4 ++--
 cpukit/dev/i2c/sensor-lm75a.c   | 2 +-
 cpukit/dev/i2c/switch-nxp-pca9548a.c| 4 ++--
 cpukit/dev/i2c/ti-ads-16bit-adc.c   | 4 ++--
 cpukit/dev/i2c/ti-lm25066a.c| 4 ++--
 cpukit/dev/i2c/ti-tmp112.c  | 4 ++--
 cpukit/dev/spi/spi-bus.c| 4 ++--
 cpukit/ftpd/ftpd-init.c | 2 +-
 cpukit/ftpd/ftpd.c  | 2 +-
 cpukit/libblock/src/bdbuf.c | 2 +-
 cpukit/libblock/src/bdpart-register.c   | 2 +-
 cpukit/libblock/src/blkdev-blkstats.c   | 4 ++--
 cpukit/libblock/src/blkdev-imfs.c   | 4 ++--
 cpukit/libblock/src/blkdev-ioctl.c  | 4 ++--
 cpukit/libblock/src/blkdev-print-stats.c| 4 ++--
 cpukit/libblock/src/blkdev.c| 2 +-
 cpukit/libblock/src/diskdevs-init.c | 4 ++--
 cpukit/libblock/src/diskdevs.c  | 2 +-
 cpukit/libblock/src/flashdisk.c | 2 +-
 cpukit/libblock/src/ide_part_table.c| 2 +-
 cpukit/libblock/src/nvdisk-sram.c   | 2 +-
 cpukit/libblock/src/nvdisk.c| 2 +-
 cpukit/libblock/src/ramdisk-init.c  | 2 +-
 cpukit/libblock/src/ramdisk-register.c  | 2 +-
 cpukit/libblock/src/show_bdbuf.c| 2 +-
 cpukit/libcsupport/src/__assert.c   | 2 +-
 cpukit/libcsupport/src/__getpid.c   | 2 +-
 cpukit/libcsupport/src/__gettod.c   | 2 +-
 cpukit/libcsupport/src/__times.c| 2 +-
 cpukit/libcsupport/src/__usrenv.c   | 4 ++--
 cpukit/libcsupport/src/_calloc_r.c  | 2 +-
 cpukit/libcsupport/src/_free_r.c| 2 +-
 cpukit/libcsupport/src/_malloc_r.c  | 2 +-
 cpukit/libcsupport/src/_realloc_r.c | 2 +-
 cpukit/libcsupport/src/_rename_r.c  | 2 +-
 cpukit/libcsupport/src/access.c | 2 +-
 cpukit/libcsupport/src/alignedalloc.c   | 2 +-
 cpukit/libcsupport/src/assoc32tostring.c| 2 +-
 cpukit/libcsupport/src/assoclocalbyname.c   | 2 +-
 cpukit/libcsupport/src/assoclocalbyremote.c | 2 +-
 cpukit/libcsupport/src/assoclocalbyremotebitfield.c | 2 +-
 cpukit/libcsupport/src/assocnamebad.c   | 2 +-
 cpukit/libcsupport/src/assocnamebylocal.c   | 2 +-
 cpukit/libcsupport/src/assocnamebylocalbitfield.c   | 2 +-
 cpukit/libcsupport/src/assocnamebyremote.c  | 2 +-
 cpukit/libcsupport/src/assocnamebyremotebitfield.c  | 2 +-
 cpukit/libcsupport/src/assocptrbylocal.c| 2 +-
 cpukit/libcsupport/src/assocptrbyname.c | 2 +-
 cpukit/libcsupport/src/assocptrbyremote.c   | 2 +-
 cpukit/libcsupport/src/assocremotebylocal.c | 2 +-
 cpukit/libcsupport/src/assocremotebylocalbitfield.c | 2 +-
 cpukit/libcsupport/src/assocremotebyname.c  | 2 +-
 cpukit/libcsupport/src/assocthreadstatestostring.c  | 2 +-
 cpukit/libcsupport/src/base_fs.c| 2 +-
 cpukit/libcsupport/src/cachecoherentalloc.c | 4 ++--
 cpukit/libcsupport/src/calloc.c | 2 +-
 cpukit/libcsupport/src/cfgetispeed.c| 2 +-
 cpukit/libcsupport/src/cfgetospeed.c| 2 +-
 cpukit/libcsupport/src/cfmakeraw.c  | 2 +-
 cpukit/libcsupport/src/cfmakesane.c | 2 +-
 cpukit/libcsupport/src/cfsetispeed.c| 2 +-
 cpukit/libcsupport/src/cfsetospeed.c| 2 +-
 cpukit/libcsupport/src/cfsetspeed.c | 2 +-
 cpukit/libcsupport/src/chdir.c  | 4 ++--
 cpukit/libcsupport/src/chmod.c  | 4 ++--
 cpukit/libcsupport/src/chown.c  | 4 ++--
 cpukit/libcsupport/src/chroot.c | 4 

[PATCH] eng: Adjust config.h include

[Sebastian Huber]

Use variant used by most source files.
---
 eng/coding-file-hdr.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index f67a199..6355173 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -196,7 +196,7 @@ and  placeholders see 
:ref:`FileHeaderCopyright`.
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#if HAVE_CONFIG_H
+#ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
 
-- 
2.16.4

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

Re: [PATCH v4 3/3] i386: Port to RTEMS

[Sebastian Huber]

On 09/04/2020 15:56, Jan Sommer wrote:


- Update imported files to compile rtems-libbsd for i386 based BSPs
---
  freebsd-org  |2 +-
  freebsd/sbin/sysctl/sysctl.c |8 +
  freebsd/sys/dev/pci/pci_pci.c|2 +
  freebsd/sys/i386/i386/legacy.c   |  381 -
  freebsd/sys/i386/include/machine/cpufunc.h   |2 +
  freebsd/sys/i386/include/machine/legacyvar.h |   63 --
  freebsd/sys/kern/subr_gtaskqueue.c   |4 +

Looks good.

  freebsd/sys/net/iflib.c  |   24 +

Please move this to a separate commit with a reason for the change.

  freebsd/sys/sys/callout.h|6 +


Please move this to a separate commit with a reason for the change.


  rtemsbsd/i386/include/machine/clock.h|2 +
  rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0



  rtemsbsd/include/x86/legacyvar.h |1 +
  rtemsbsd/include/x86/specialreg.h| 1074 ++
  rtemsbsd/include/x86/x86_var.h   |  156 

Where do these files come from?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4 2/3] i386: Update build system

[Sebastian Huber]

On 09/04/2020 15:56, Jan Sommer wrote:


- Update FreeBSD files in libbsd.py
- Introduce path-mappings in waf_libsd.py and libbsd.py for include path
fixes
Could you please split this commit. One part for the mappings, the other 
part for the new files imported from FreeBSD.

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

Re: [PATCH v4 3/3] i386: Port to RTEMS

[Sebastian Huber]

On 09/04/2020 16:10, jan.som...@dlr.de wrote:


-Ursprüngliche Nachricht-
Von: Sommer, Jan
Gesendet: Donnerstag, 9. April 2020 15:57
An:devel@rtems.org
Cc: Sommer, Jan
Betreff: [PATCH v4 3/3] i386: Port to RTEMS

- Update imported files to compile rtems-libbsd for i386 based BSPs
---

[...]

diff --git a/freebsd/sys/kern/subr_gtaskqueue.c
b/freebsd/sys/kern/subr_gtaskqueue.c
index c061c6b0..4ef05e0a 100644
--- a/freebsd/sys/kern/subr_gtaskqueue.c
+++ b/freebsd/sys/kern/subr_gtaskqueue.c
@@ -744,7 +744,9 @@ taskqgroup_attach(struct taskqgroup *qgroup, struct
grouptask *gtask,
__func__, gtask->gt_name, error);
} else
  #else /* __rtems__ */
+#ifndef __i386__
BSD_ASSERT(irq == -1);
+#endif /* __i386 */
  #endif /* __rtems__ */
mtx_unlock(>tqg_lock);
  }
@@ -776,7 +778,9 @@ taskqgroup_attach_deferred(struct taskqgroup
*qgroup, struct grouptask *gtask)

}
  #else /* __rtems__ */
+#ifndef __i386__
BSD_ASSERT(gtask->gt_irq == -1);
+#endif /* __i386 */
  #endif /* __rtems__ */
qgroup->tqg_queue[qid].tgc_cnt++;
LIST_INSERT_HEAD(>tqg_queue[qid].tgc_tasks, gtask,
gt_list);

For example in "iflib_legacy_setup" the function " taskqgroup_attach" is called 
with an irq value other than -1, which triggers the assert.
Now, with the assert disabled the driver seems to work and we can, e.g. get an 
IP with the dhcpcd0x tests.
We haven't managed to find out what the assert is for exactly, so I don't know 
if that opens a can of worms.
Is this safe to do?


It looks like your upper layers request an unsupported feature. I 
disabled several things related to CPU affinity in libbsd since this was 
not properly supported by RTEMS before the EDF SMP scheduler was 
introduced. It may be possible to enable these features now. If you want 
to enable something in this area, please add test cases.


FreeBSD sometimes uses per-CPU data structures. They must be used with care.

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

Re: RTEMS Timeline Update and 25th Anniversary of First Public Commit

[Christian Mauderer]

On 14/04/2020 15:40, Joel Sherrill wrote:
> 
> 
> On Tue, Apr 14, 2020 at 1:47 AM Christian Mauderer
>  > wrote:
> 
> Hello Joel,
> 
> On 07/04/2020 22:44, Joel Sherrill wrote:
> > Hi
> >
> > The RTEMS Project is rapidly approaching a major milestone -- the 25th
> > anniversary of the oldest commit in the git repository! That
> occurs on 4
> > May 2020!
> >
> > Before that time, the source code was managed on an internal research
> > project repository and snapshots/releases made available via ftp.
> I know
> > I started with the project in July 1989 and was coding nearly from the
> > first day.
> >
> > With this in mind,
> the https://devel.rtems.org/wiki/History/Timeline is
> > sorely out of date and lacking missing entries. Multiple mission
> > launches, addition of SMP, GSoC, GCI, and SOCIC participation, move to
> > OSU OSL, incorporation of RTEMS Foundation, scientific
> discoveries like
> > the particle discovered by an Atlas detector at CERN or the famous
> gamma
> > ray burst from Fermi. All are missing. 
> >
> > Please pitch in and help. If you want to help but don't have any
> ideas,
> > just post back and I will try to follow up with ideas that someone
> else
> > can put a date on. 
> >
> > Thanks.
> >
> > --joel
> 
> I added some small stuff (start of SMP work, main work, release numbers)
> based on the git history (see
> 
> https://devel.rtems.org/wiki/History/Timeline?action=diff=27_version=25).
> 
> 
> Thanks! That's a good set of information. 
> 
> 
> Although I'm terribly bad with dates: You said you would try to follow
> up with ideas. If you have any where I might could help, please let
> me know.
> 
> 
> How about these (random and before coffee/tea)
> 
> + Any cool non-space programs folks can admit to?
> + First submission from some core developers.
>     - Chris was second submitter and is in the 91-92 timeframe. We don't
> remember.
>     - Thomas first shows up in git in March 1998. 
>     - Sebastian gets a nod in July 2008. :)
> + When were some ports added?
> + When were some interesting/popular BSPs added: Zyng, Leon3, gba, etc
>     - FWIW the original PC BSP was based on DJ Delorie's go32 and pre-dates 
>       the git history. I did that on a single PC (486 with 32 MB RAM). I
> couldn't run
>       X11 and compile at the same time. I had to reboot to test. Yes it
> was uphill
>       both ways back in those days. :)
> + When were some of the original ports/BSPs removed?
>    - mvme135/136 was first BSP
>    - i386 was second port
>    - i960 was last of original 3 ports
> + Interesting features? Like libnetworking, libbsd, shell, dynamic loading?
> + The Cygnus floppy mailing:
>     https://ftp.rtems.org/pub/rtems/people/joel/CygnusFloppyAugust1995/
> 
> This may be good as a small tasks ticket where people cross things off 
> as they get added.

I added a ticket here: https://devel.rtems.org/ticket/3952

> 
> It is amazing how much this has prodded my memory.  :)
> 
> --joel
>      
> 
> 
> Best regards
> 
> Christian
> -- 
> 
> 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.
> 

-- 

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: [PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

On 15/04/2020 07:06, Sebastian Huber wrote:
> Hello Christian,
> 
> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
> bus-dma, imx: Don't sync nocache area.").
> 

Thanks.

Chris, Gedare, Joel: Would it be OK for you if I push the patches before
the release?

Best regards

Christian
-- 

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: [PATCH rtems-libbsd v2 09/14] bus-dma, imx: Don't sync nocache area.

[Christian Mauderer]

On 15/04/2020 07:02, Sebastian Huber wrote:
> Is this patch still necessary?
> 

Thanks for the hint. I missed to remove it. It's not necessary any more
and I'll just skip it when pushing.

-- 

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