Re: [PATCH v1 8/9] smpsignal01: Change state before sending the signal

[Sebastian Huber]

On 31/05/2020 16:22, Jan Sommer wrote:


The signal handler of the consumer might start executing
before rtems_signal_send of the producer returns.
Therefore change the state to SIG_1_SENT before sending the signal.


Sorry, for the delay. This patch is fine.

I didn't look at the i386 specific-patches.

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

Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps

[Sebastian Huber]

On 31/05/2020 16:22, Jan Sommer wrote:

[...]


Some details on the missing tests:
---
smpfatal09: This test actually does pass, but because the fatal error handler 
is executed before the console is initialized, no output is produced.

smpclock01.exe: Here CPU0 disables its local interrupts and waits for a barrier 
release of CPU1. This means it doesn't handle timer interrupts anymore and 
doesn't send corresponding IPIs to other CPUs.
At the same time CPU1 is waiting for a timer event before releasing the 
barrier. Any hints how to resolve this are very welcome.

This could be a Qemu timing issue.


smpatomic01: This test seems very large and a bit complicated to me. I will 
have a look at it next, but any suggestions are welcome. It fails with this 
information:
] === atomic or/and test case ===
] worker 0 value: 1
] worker 1 value: 0
] atomic value: expected = 1, actual = 1
] 
../../../../../../smp-refex-rtems/c/src/../../testsuites/smptests/smpatomic01/init.c:
 404 n - s < LONG_MAX
]
] *** FATAL ***
This looks like a bug in smpatomic01. We need a better test case for 
atomic_thread_fence().


smpopenmp01: I don't know more about openmp then what is on wikipedia. It has 
currently a low priority for me.

This test should not fail. Could be also a Qemu issue.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header

[Niteesh G. S.]

On Sat, Jun 6, 2020 at 5:27 PM Christian Mauderer 
wrote:

> On 04/06/2020 19:43, G S Niteesh Babu wrote:
> > This file serve the purpose as rtems-bsd-kernel-space.h in the
> > rtems-libbsd.
> > This file is intended to be included in every source file that
> > is to imported from FreeBSD. This is to reduce the number of
> > redefinitions for commonly used functions like malloc, free
> > and KASSERT.
> > ---
> >  cpukit/libfreebsd/rtems-freebsd-helper.h | 45 
> >  1 file changed, 45 insertions(+)
> >  create mode 100644 cpukit/libfreebsd/rtems-freebsd-helper.h
> >
> > diff --git a/cpukit/libfreebsd/rtems-freebsd-helper.h
> b/cpukit/libfreebsd/rtems-freebsd-helper.h
>
> How do you plan to include it? Currently you would need a
>
> #include "../../../rtems-freebsd-helper.h"
>
> right? Can become a bit hard to count the .. with a deep directory tree.
>

The right place for this file would be the standard include path. Since we
haven't decided
on this, I placed it temporarily here.
If we can add libfreebsd to the include path that will be really nice
because this will allow
us to have the same include path as in FreeBSD.
i.e.
The openfirm.h is included in FreeBSD sources as
#include 
Including libfreebsd to include path will let us do the same.



> > new file mode 100644
> > index 00..1b9b7609f9
> > --- /dev/null
> > +++ b/cpukit/libfreebsd/rtems-freebsd-helper.h
> > @@ -0,0 +1,45 @@
> > +
> > +/* SPDX-License-Identifier: BSD-2-Clause
> > +
> > + *
> > + * @file
> > + *
> > + * @ingroup LIBFREEBSD
>
> You have a group LIBFREEBSD here. Earlier you had a LIBFREEBSDOFW. Do
> you really want multiple groups? I would suggest to start with one for
> the new libfreebsd subsystem.
>

I changed everything to LIBFREEBSD.



> > + *
> > + * @brief
> > + */
> > +
> > +/*
> > + * Copyright (C) <2020> Niteesh Babu 
> > + *
> > + * 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.
> > + */
> > +
> > +#ifndef _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H
> > +#define _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H
> > +
> > +#define _KERNEL  1
> > +#define KASSERT(cnd, msg)assert(cnd)
> > +#define malloc(size, type, flags)malloc(size)
> > +#define free(addr, type) free(addr)
>
> The tabs between the define name and the value seem a bit random here.
> Please try to use FreeBSD style (I really hope I don't start a
> discussion now whether we should use RTEMS style instead for new files).
>
> https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9
>
> If it's not clear there: Take a look at some FreeBSD files.
>
I'll fix this.



> > +
> > +#endif /* _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H */
> > \ No newline at end of file
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Adding strong and weak definitions

[Richi Dubey]

Hi,

Please mark the following required changes:

1) Add: cd rtems-qual/
After git clone and before git submodule init.

2) I am getting the following error on running git submodule update:

richi@YouAreAmazing:~/rtems-qual$ git submodule update
Cloning into '/home/richi/rtems-qual/external/rsb'...
Cloning into '/home/richi/rtems-qual/external/rtems'...
Cloning into '/home/richi/rtems-qual/external/rtems-docs'...
Submodule path 'external/rsb': checked out
'9482a1b33b4c8552f6affa582664b4ac25f9cdf4'
error: Server does not allow request for unadvertised object
aaa638b1550e94b37df382474fe4785a6cc7d350
Fetched in submodule path 'external/rtems', but it did not contain
aaa638b1550e94b37df382474fe4785a6cc7d350. Direct fetching of that
commit failed.

I don't understand this error.

3) Is the space in ". env/bin/activate" intentional?

4) I do not know how to use cite, Can i use it directly in the text field?

5) When I run ./spec2doc.py, I get the following error:

(env) richi@YouAreAmazing:~/rtems-qual$ ./spec2doc.py
Traceback (most recent call last):
  File "./spec2doc.py", line 41, in 
main()
  File "./spec2doc.py", line 34, in main
item_cache = rtemsqual.items.ItemCache(config["spec"])
  File "/home/richi/rtems-qual/rtemsqual/items.py", line 331, in __init__
self._load_items(config)
  File "/home/richi/rtems-qual/rtemsqual/items.py", line 403, in _load_items
self._load_items_recursive(path, path, cache_dir)
  File "/home/richi/rtems-qual/rtemsqual/items.py", line 381, in
_load_items_recursive
for name in os.listdir(path):
FileNotFoundError: [Errno 2] No such file or directory: 'external/rtems/spec'

Is it because I messed something up in the strongapa.yml ?

My /spec/glossary/strongapa.yml is :

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
enabled-by: true
glossary-type: term
links:
- role: glossary-member
  uid: ../glossary-general
term: Strong APA
text:
  In this model, on the arrival of a task, every task reachable
  from the newly arrived task is checked to see if an existing
  task can be shifted(or deallocated its processor) and newly
  arrived task can take its place if the newly arrived task has
  a higher priority. Similar analysis is done when a task
  finishes its execution (Here task and thread have interchangeable
  defintions).
  :cite:`Cerqueira:2014:LPA`.
type: glossary



Please tell me how to resolve this error.

Thanks,
Richi.

On Mon, Jun 8, 2020 at 1:13 PM Sebastian Huber
 wrote:
>
> On 07/06/2020 15:36, Sebastian Huber wrote:
>
> > On 06/06/2020 15:09, Richi Dubey wrote:
> >
> >> Hii,
> >>
> >> Thanks for your review.
> >>
> >>> The glossary is generated from specification items:
> >>>
> >>> https://git.rtems.org/sebh/rtems-qual.git/tree/spec/glos/term
> >>>
> >>> I will work on a documentation how this works in the next days.
> >> Have you already submitted one? If yes, could you please send me the
> >> link to it. If no, Do I need to wait and learn that before sending in
> >> the new patch?
> >
> > Yes, I sent a patch for the RTEMS Software Engineering manual:
> >
> > https://lists.rtems.org/pipermail/devel/2020-June/060036.html
> >
> > I will probably check it in tomorrow.
>
> I updated the documentation:
>
> https://docs.rtems.org/branches/master/eng/req/howto.html#getting-started
>
> Could you please try to add the new glossary terms using the method
> described in this how-to. You are some sort of a beta tester for this.
> If anything is unclear, then please complain immediately.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS

[Niteesh G. S.]

On Sat, Jun 6, 2020 at 5:40 PM Christian Mauderer  wrote:

> On 04/06/2020 19:43, G S Niteesh Babu wrote:
> > The following files have been ported to RTEMS
> > 1) openfirm.h
> > 2) openfirm.c
> > 3) ofw_fdt.c
> > ---
> >  cpukit/libfreebsd/dev/ofw/ofw_fdt.c  | 117 ++-
> >  cpukit/libfreebsd/dev/ofw/openfirm.c |  59 +-
> >  cpukit/libfreebsd/dev/ofw/openfirm.h |  18 +
> >  3 files changed, 191 insertions(+), 3 deletions(-)
> >
> > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > index e4f72e8142..5341440789 100644
> > --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > @@ -29,10 +29,13 @@
> >   * SUCH DAMAGE.
> >   */
> >
> > +#ifndef __rtems__
> >  #include 
> >  __FBSDID("$FreeBSD$");
> > +#endif /* __rtems__ */
> >
> >  #include 
> > +#ifndef __rtems__
> >  #include 
> >  #include 
> >  #include 
> > @@ -45,9 +48,18 @@ __FBSDID("$FreeBSD$");
> >  #include 
> >  #include 
> >  #include 
> > +#endif /* __rtems__ */
> >
> >  #include "ofw_if.h"
> > -
>
> I'm not really happy about lines starting with "-" in the porting
> commits. I think we should apply the same rules like in libbsd: Only add
> stuff. Exception: The one at the end of the file is OK (where git tells
> you "\ No newline at end of file"). You can't really avoid that.
>

I fixed this.



> > +#ifdef __rtems__
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "openfirm.h"
> > +#endif /* __rtems__ */
> > +
> > +#ifndef __rtems__
> >  #ifdef DEBUG
> >  #define debugf(fmt, args...) do { printf("%s(): ", __func__);\
> >  printf(fmt,##args); } while (0)
> > @@ -63,6 +75,7 @@ __FBSDID("$FreeBSD$");
> >  #define FDT_MARVELL
> >  #endif
> >  #endif
> > +#endif /* __rtems__ */
> >
> >  static int ofw_fdt_init(ofw_t, void *);
> >  static phandle_t ofw_fdt_peer(ofw_t, phandle_t);
> > @@ -78,6 +91,7 @@ static ssize_t ofw_fdt_canon(ofw_t, const char *, char
> *, size_t);
> >  static phandle_t ofw_fdt_finddevice(ofw_t, const char *);
> >  static ssize_t ofw_fdt_instance_to_path(ofw_t, ihandle_t, char *,
> size_t);
> >  static ssize_t ofw_fdt_package_to_path(ofw_t, phandle_t, char *,
> size_t);
> > +#ifndef __rtems__
> >  static int ofw_fdt_interpret(ofw_t, const char *, int, cell_t *);
> >
> >  static ofw_method_t ofw_fdt_methods[] = {
> > @@ -104,9 +118,11 @@ static ofw_def_t ofw_fdt = {
> >   0
> >  };
> >  OFW_DEF(ofw_fdt);
> > +#endif /* __rtems__ */
> >
> >  static void *fdtp = NULL;
> >
> > +#ifndef __rtems__
> >  static int
> >  sysctl_handle_dtb(SYSCTL_HANDLER_ARGS)
> >  {
> > @@ -127,6 +143,24 @@ sysctl_register_fdt_oid(void *arg)
> >   sysctl_handle_dtb, "", "Device Tree Blob");
> >  }
> >  SYSINIT(dtb_oid, SI_SUB_KMEM, SI_ORDER_ANY, sysctl_register_fdt_oid,
> NULL);
> > +#else /* __rtems__ */
> > +const void* bsp_fdt_get(void);
> > +static void
> > +ofw_init(void)
> > +{
> > + int rv;
> > + const void *fdt;
> > +
> > + fdt = bsp_fdt_get();
> > + rv = ofw_fdt_init(NULL, fdt);
> > + assert(rv == 0);
>
> Is assert really the only error handling possible here? Asserts are
> allways a bit difficult because they stop the entire system. In which
> cases would it hit?


The assert is reached when the FDT is not valid. The check is done
using fdt_check_header. Shutting the system would be the only way
right?
I agree to assert is not the right way to quit. Can we quit with
a proper error code like BSP_FATAL_INVALID_FDT or do we have
something like that already?

>
> > +}
> > +RTEMS_SYSINIT_ITEM(
> > + ofw_init,
> > + RTEMS_SYSINIT_BSP_START,
> > + RTEMS_SYSINIT_ORDER_FIRST
> > +);
> > +#endif /* __rtems__ */
> >
> >  static int
> >  ofw_fdt_init(ofw_t ofw, void *data)
> > @@ -297,7 +331,11 @@ ofw_fdt_getprop(ofw_t ofw, phandle_t package, const
> char *propname, void *buf,
> >   if (prop == NULL)
> >   return (-1);
> >
> > +#ifndef __rtems__
> >   bcopy(prop, buf, min(len, buflen));
> > +#else /* __rtems__ */
> > + memcpy(buf, prop, MIN(len, buflen));
> > +#endif /* __rtems__ */
> >
> >   return (len);
> >  }
> > @@ -407,6 +445,7 @@ ofw_fdt_package_to_path(ofw_t ofw, phandle_t
> package, char *buf, size_t len)
> >   return (-1);
> >  }
> >
> > +#ifndef __rtems__
> >  #if defined(FDT_MARVELL)
> >  static int
> >  ofw_fdt_fixup(ofw_t ofw)
> > @@ -476,4 +515,78 @@ ofw_fdt_interpret(ofw_t ofw, const char *cmd, int
> nret, cell_t *retvals)
> >  #else
> >   return (0);
> >  #endif
> > -}
> > \ No newline at end of file
> > +}
> > +#endif /* __rtems__ */
> > +
> > +#ifdef __rtems__
> > +int OFW_INIT(ofw_t ofw_obj, void *cookie)
>
> Again: Please use FreeBSD style. The return value should be on it's onw
> line during the definition (not during declaration).
>
> > +{
>
> There should be one empty line if you have no local variables (I'm not
> really consequent here too).
>
> > + return ofw_fdt_init(ofw_obj, cookie);
>
> And brac

Re: [PATCH 2/2] Adding strong and weak definitions

[Sebastian Huber]

On 10/06/2020 16:41, Richi Dubey wrote:


Hi,

Please mark the following required changes:

1) Add: cd rtems-qual/
After git clone and before git submodule init.

2) I am getting the following error on running git submodule update:

richi@YouAreAmazing:~/rtems-qual$ git submodule update
Cloning into '/home/richi/rtems-qual/external/rsb'...
Cloning into '/home/richi/rtems-qual/external/rtems'...
Cloning into '/home/richi/rtems-qual/external/rtems-docs'...
Submodule path 'external/rsb': checked out
'9482a1b33b4c8552f6affa582664b4ac25f9cdf4'
error: Server does not allow request for unadvertised object
aaa638b1550e94b37df382474fe4785a6cc7d350
Fetched in submodule path 'external/rtems', but it did not contain
aaa638b1550e94b37df382474fe4785a6cc7d350. Direct fetching of that
commit failed.

I don't understand this error.


Sorry, I fixed this issue. Please do a:

git pull

git submodule init

git submodule update

make env



3) Is the space in ". env/bin/activate" intentional?


Yes:

https://unix.stackexchange.com/questions/114300/whats-the-meaning-of-a-dot-before-a-command-in-shell



4) I do not know how to use cite, Can i use it directly in the text field?

Yes, just use :cite:`XYZ` in the text field.


5) When I run ./spec2doc.py, I get the following error:

(env) richi@YouAreAmazing:~/rtems-qual$ ./spec2doc.py
Traceback (most recent call last):
   File "./spec2doc.py", line 41, in 
 main()
   File "./spec2doc.py", line 34, in main
 item_cache = rtemsqual.items.ItemCache(config["spec"])
   File "/home/richi/rtems-qual/rtemsqual/items.py", line 331, in __init__
 self._load_items(config)
   File "/home/richi/rtems-qual/rtemsqual/items.py", line 403, in _load_items
 self._load_items_recursive(path, path, cache_dir)
   File "/home/richi/rtems-qual/rtemsqual/items.py", line 381, in
_load_items_recursive
 for name in os.listdir(path):
FileNotFoundError: [Errno 2] No such file or directory: 'external/rtems/spec'

Is it because I messed something up in the strongapa.yml ?

My /spec/glossary/strongapa.yml is :

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
enabled-by: true
glossary-type: term
links:
- role: glossary-member
   uid: ../glossary-general
term: Strong APA
text:


Maybe start with:

Strong APA is a specialization of ${apa:/term}.


   In this model, on the arrival of a task, every task reachable


task -> thread

For the first use of thread use: ${thread:/term}


   from the newly arrived task is checked to see if an existing
   task can be shifted(or deallocated its processor) and newly

space before (

   arrived task can take its place if the newly arrived task has
   a higher priority. Similar analysis is done when a task
   finishes its execution (Here task and thread have interchangeable
   defintions).
   :cite:`Cerqueira:2014:LPA`.
type: glossary



Please tell me how to resolve this error.

Thanks,
Richi.

On Mon, Jun 8, 2020 at 1:13 PM Sebastian Huber
 wrote:

On 07/06/2020 15:36, Sebastian Huber wrote:


On 06/06/2020 15:09, Richi Dubey wrote:


Hii,

Thanks for your review.


The glossary is generated from specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/glos/term

I will work on a documentation how this works in the next days.

Have you already submitted one? If yes, could you please send me the
link to it. If no, Do I need to wait and learn that before sending in
the new patch?

Yes, I sent a patch for the RTEMS Software Engineering manual:

https://lists.rtems.org/pipermail/devel/2020-June/060036.html

I will probably check it in tomorrow.

I updated the documentation:

https://docs.rtems.org/branches/master/eng/req/howto.html#getting-started

Could you please try to add the new glossary terms using the method
described in this how-to. You are some sort of a beta tester for this.
If anything is unclear, then please complain immediately.


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

Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header

[Christian Mauderer]

On 10/06/2020 15:56, Niteesh G. S. wrote:
> 
> On Sat, Jun 6, 2020 at 5:27 PM Christian Mauderer  > wrote:
> 
> On 04/06/2020 19:43, G S Niteesh Babu wrote:
> > This file serve the purpose as rtems-bsd-kernel-space.h in the
> > rtems-libbsd.
> > This file is intended to be included in every source file that
> > is to imported from FreeBSD. This is to reduce the number of
> > redefinitions for commonly used functions like malloc, free
> > and KASSERT.
> > ---
> >  cpukit/libfreebsd/rtems-freebsd-helper.h | 45
> 
> >  1 file changed, 45 insertions(+)
> >  create mode 100644 cpukit/libfreebsd/rtems-freebsd-helper.h
> >
> > diff --git a/cpukit/libfreebsd/rtems-freebsd-helper.h
> b/cpukit/libfreebsd/rtems-freebsd-helper.h
> 
> How do you plan to include it? Currently you would need a
> 
> #include "../../../rtems-freebsd-helper.h"
> 
> right? Can become a bit hard to count the .. with a deep directory tree.
> 
> 
> The right place for this file would be the standard include path. Since
> we haven't decided
> on this, I placed it temporarily here.
> If we can add libfreebsd to the include path that will be really nice
> because this will allow
> us to have the same include path as in FreeBSD.
> i.e.
> The openfirm.h is included in FreeBSD sources as
> #include 
> Including libfreebsd to include path will let us do the same.

Hm. I'm not sure whether the current build system allows adding that to
the include path. Definitively not for installed headers. If you see a
simple way to add it: Do it. But don't put much effort into it
(<30Minutes). It's not worth it.

> 
>  
> 
> > new file mode 100644
> > index 00..1b9b7609f9
> > --- /dev/null
> > +++ b/cpukit/libfreebsd/rtems-freebsd-helper.h
> > @@ -0,0 +1,45 @@
> > +
> > +/* SPDX-License-Identifier: BSD-2-Clause
> > +
> > + *
> > + * @file
> > + *
> > + * @ingroup LIBFREEBSD
> 
> You have a group LIBFREEBSD here. Earlier you had a LIBFREEBSDOFW. Do
> you really want multiple groups? I would suggest to start with one for
> the new libfreebsd subsystem.
> 
> 
> I changed everything to LIBFREEBSD.

OK

> 
>  
> 
> > + *
> > + * @brief
> > + */
> > +
> > +/*
> > + * Copyright (C) <2020> Niteesh Babu  >
> > + *
> > + * 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.
> > + */
> > +
> > +#ifndef _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H
> > +#define _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H
> > +
> > +#define _KERNEL                                              1
> > +#define KASSERT(cnd, msg)                    assert(cnd)
> > +#define malloc(size, type, flags)    malloc(size)
> > +#define free(addr, type)                     free(addr)
> 
> The tabs between the define name and the value seem a bit random here.
> Please try to use FreeBSD style (I really hope I don't start a
> discussion now whether we should use RTEMS style instead for new files).
> 
> https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9
> 
> If it's not clear there: Take a look at some FreeBSD files.
> 
> I'll fix this.

Thanks.

> 
>  
> 
> > +
> > +#endif /* _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H */
> > \ No newline at end of file
> >
> 
___
devel mailing list
devel@

Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS

[Christian Mauderer]

On 10/06/2020 17:11, Niteesh G. S. wrote:
> On Sat, Jun 6, 2020 at 5:40 PM Christian Mauderer  > wrote:
> 
> On 04/06/2020 19:43, G S Niteesh Babu wrote:
> > The following files have been ported to RTEMS
> > 1) openfirm.h
> > 2) openfirm.c
> > 3) ofw_fdt.c
> > ---
> >  cpukit/libfreebsd/dev/ofw/ofw_fdt.c  | 117
> ++-
> >  cpukit/libfreebsd/dev/ofw/openfirm.c |  59 +-
> >  cpukit/libfreebsd/dev/ofw/openfirm.h |  18 +
> >  3 files changed, 191 insertions(+), 3 deletions(-)
> >
> > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > index e4f72e8142..5341440789 100644
> > --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > @@ -29,10 +29,13 @@
> >   * SUCH DAMAGE.
> >   */
> > 
> > +#ifndef __rtems__
> >  #include 
> >  __FBSDID("$FreeBSD$");
> > +#endif /* __rtems__ */
> > 
> >  #include 
> > +#ifndef __rtems__
> >  #include 
> >  #include 
> >  #include 
> > @@ -45,9 +48,18 @@ __FBSDID("$FreeBSD$");
> >  #include 
> >  #include 
> >  #include 
> > +#endif /* __rtems__ */
> > 
> >  #include "ofw_if.h"
> > -
> 
> I'm not really happy about lines starting with "-" in the porting
> commits. I think we should apply the same rules like in libbsd: Only add
> stuff. Exception: The one at the end of the file is OK (where git tells
> you "\ No newline at end of file"). You can't really avoid that.
> 
> 
> I fixed this.
> 
>  
> 
> > +#ifdef __rtems__
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "openfirm.h"
> > +#endif /* __rtems__ */
> > +
> > +#ifndef __rtems__
> >  #ifdef DEBUG
> >  #define debugf(fmt, args...) do { printf("%s(): ", __func__);   
>     \
> >      printf(fmt,##args); } while (0)
> > @@ -63,6 +75,7 @@ __FBSDID("$FreeBSD$");
> >  #define FDT_MARVELL
> >  #endif
> >  #endif
> > +#endif /* __rtems__ */
> > 
> >  static int ofw_fdt_init(ofw_t, void *);
> >  static phandle_t ofw_fdt_peer(ofw_t, phandle_t);
> > @@ -78,6 +91,7 @@ static ssize_t ofw_fdt_canon(ofw_t, const char
> *, char *, size_t);
> >  static phandle_t ofw_fdt_finddevice(ofw_t, const char *);
> >  static ssize_t ofw_fdt_instance_to_path(ofw_t, ihandle_t, char *,
> size_t);
> >  static ssize_t ofw_fdt_package_to_path(ofw_t, phandle_t, char *,
> size_t);
> > +#ifndef __rtems__
> >  static int ofw_fdt_interpret(ofw_t, const char *, int, cell_t *);
> > 
> >  static ofw_method_t ofw_fdt_methods[] = {
> > @@ -104,9 +118,11 @@ static ofw_def_t ofw_fdt = {
> >       0
> >  };
> >  OFW_DEF(ofw_fdt);
> > +#endif /* __rtems__ */
> > 
> >  static void *fdtp = NULL;
> > 
> > +#ifndef __rtems__
> >  static int
> >  sysctl_handle_dtb(SYSCTL_HANDLER_ARGS)
> >  {
> > @@ -127,6 +143,24 @@ sysctl_register_fdt_oid(void *arg)
> >           sysctl_handle_dtb, "", "Device Tree Blob");
> >  }
> >  SYSINIT(dtb_oid, SI_SUB_KMEM, SI_ORDER_ANY,
> sysctl_register_fdt_oid, NULL);
> > +#else /* __rtems__ */
> > +const void* bsp_fdt_get(void);
> > +static void
> > +ofw_init(void)
> > +{
> > +     int rv;
> > +     const void *fdt;
> > +
> > +     fdt = bsp_fdt_get();
> > +     rv = ofw_fdt_init(NULL, fdt);
> > +     assert(rv == 0);
> 
> Is assert really the only error handling possible here? Asserts are
> allways a bit difficult because they stop the entire system. In which
> cases would it hit?
> 
> 
> The assert is reached when the FDT is not valid. The check is done
> using fdt_check_header. Shutting the system would be the only way
> right?

It's in a low level driver function and if it fails, there is most
likely much else to do. So OK.

> I agree to assert is not the right way to quit. Can we quit with
> a proper error code like BSP_FATAL_INVALID_FDT or do we have
> something like that already?

I don't know of an existing one. Maybe add one. But maybe start a new
group in the bsp/fatal.h and make that a LIBFREEBSD_FATAL_INVALID_FDT.
I'm sure there will be other cases too sooner or later.

> 
> 
> > +}
> > +RTEMS_SYSINIT_ITEM(
> > +     ofw_init,
> > +     RTEMS_SYSINIT_BSP_START,
> > +     RTEMS_SYSINIT_ORDER_FIRST
> > +);
> > +#endif /* __rtems__ */
> > 
> >  static int
> >  ofw_fdt_init(ofw_t ofw, void *data)
> > @@ -297,7 +331,11 @@ ofw_fdt_getprop(ofw_t ofw, phandle_t package,
> const char *propname, void *buf,
> >       if (prop == NULL)
> >               return (-1);
> > 
> > +#ifndef __rtems__
> >       bcopy(prop, buf, min(len, buflen));
> > +#else /* __rtems__ */
> > +     memcpy(buf, prop

Cacheable OCM support for the Zynq BSP

[Jonathan Brandmeyer]

We've patched the RTEMS kernel in order to support using the Zynq on-chip
memory as inner-cacheable memory.  The enclosed patch should apply cleanly
to master.

Background: During normal startup, the ROM bootloader performs
vendor-specific initialization of  core 1, and then sits in a
wait-for-event loop until a special value has been written to a specific
address in OCM.  In that state, the MMU has not yet been initialized and
core 1 is treating OCM as Device memory.

By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's MMU
has already been initialized with the application-defined memory map.  I'd
like to use the on-chip memory as inner cacheable memory in my
application.  In order to ensure that the kick address write actually
becomes visible to core 1, a cache line flush of the affected line is
necessary prior to sending the event that wakes up the other core.

I also added an invalidation prior to the kick-address write out of an
abundance of caution.  it shouldn't be necessary, but I had a hard time
proving it definitively.

There are a plethora of cache maintenance functions available for the job
in RTEMS.  I picked an inline helper that operates directly on CP15.  The
code's commentary suggests that the L2 hasn't been initialized yet, and the
higher-level `rtems_cache_*_multiple_data_lines` API affects both L1D and
L2.  Also, I'm using inner-cacheable/outer-shareable memory attributes for
OCM specifically because of where it sits in the SOC's busswork, so it
turns out that we *never* need to flush L2 for that memory anyway.

-- 
Jonathan Brandmeyer
PlanetiQ
From 56b57b8e6933316827ebd75990bdc96b189c2adf Mon Sep 17 00:00:00 2001
From: Jonathan Brandmeyer 
Date: Wed, 10 Jun 2020 17:09:57 -0600
Subject: [PATCH] bsp: Support cacheable OCM on the Zynq

... by issuing L1D-specific cache invalidation and flushing instructions
around the kick address.
---
 bsps/arm/xilinx-zynq/start/bspsmp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/bsps/arm/xilinx-zynq/start/bspsmp.c b/bsps/arm/xilinx-zynq/start/bspsmp.c
index fdb7f85ba6..d6e8759b95 100644
--- a/bsps/arm/xilinx-zynq/start/bspsmp.c
+++ b/bsps/arm/xilinx-zynq/start/bspsmp.c
@@ -28,6 +28,7 @@
 #include 
 
 #include 
+#include 
 
 bool _CPU_SMP_Start_processor(uint32_t cpu_index)
 {
@@ -36,11 +37,14 @@ bool _CPU_SMP_Start_processor(uint32_t cpu_index)
*/
   if (cpu_index != 0) {
 volatile uint32_t* const kick_address = (uint32_t*) 0xfff0UL;
+arm_cp15_data_cache_invalidate_line((void *)kick_address);
 _ARM_Data_synchronization_barrier();
 _ARM_Instruction_synchronization_barrier();
 *kick_address = (uint32_t) _start;
 _ARM_Data_synchronization_barrier();
 _ARM_Instruction_synchronization_barrier();
+arm_cp15_data_cache_clean_and_invalidate_line((const void *)kick_address);
+_ARM_Data_synchronization_barrier();
 _ARM_Send_event();
   }
 
-- 
2.20.1

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

Re: Cacheable OCM support for the Zynq BSP

[Chris Johns]

On 11/6/20 9:30 am, Jonathan Brandmeyer wrote:
> We've patched the RTEMS kernel in order to support using the Zynq on-chip 
> memory
> as inner-cacheable memory.  The enclosed patch should apply cleanly to master.
> 
> Background: During normal startup, the ROM bootloader performs vendor-specific
> initialization of  core 1, and then sits in a wait-for-event loop until a
> special value has been written to a specific address in OCM.  In that state, 
> the
> MMU has not yet been initialized and core 1 is treating OCM as Device memory.
> 
> By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's MMU has
> already been initialized with the application-defined memory map.  I'd like to
> use the on-chip memory as inner cacheable memory in my application.  In order 
> to
> ensure that the kick address write actually becomes visible to core 1, a cache
> line flush of the affected line is necessary prior to sending the event that
> wakes up the other core.

Have the patches been tested with the OCM in the default state?

Chris

> 
> I also added an invalidation prior to the kick-address write out of an 
> abundance
> of caution.  it shouldn't be necessary, but I had a hard time proving it
> definitively.
> 
> There are a plethora of cache maintenance functions available for the job in
> RTEMS.  I picked an inline helper that operates directly on CP15.  The code's
> commentary suggests that the L2 hasn't been initialized yet, and the
> higher-level `rtems_cache_*_multiple_data_lines` API affects both L1D and L2. 
> Also, I'm using inner-cacheable/outer-shareable memory attributes for OCM
> specifically because of where it sits in the SOC's busswork, so it turns out
> that we *never* need to flush L2 for that memory anyway.
> 
> -- 
> Jonathan Brandmeyer
> PlanetiQ
> 
> ___
> 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: Cacheable OCM support for the Zynq BSP

[Jonathan Brandmeyer]

On Wed, Jun 10, 2020 at 5:57 PM Chris Johns  wrote:

> On 11/6/20 9:30 am, Jonathan Brandmeyer wrote:
> > We've patched the RTEMS kernel in order to support using the Zynq
> on-chip memory
> > as inner-cacheable memory.  The enclosed patch should apply cleanly to
> master.
> >
> > Background: During normal startup, the ROM bootloader performs
> vendor-specific
> > initialization of  core 1, and then sits in a wait-for-event loop until a
> > special value has been written to a specific address in OCM.  In that
> state, the
> > MMU has not yet been initialized and core 1 is treating OCM as Device
> memory.
> >
> > By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's
> MMU has
> > already been initialized with the application-defined memory map.  I'd
> like to
> > use the on-chip memory as inner cacheable memory in my application.  In
> order to
> > ensure that the kick address write actually becomes visible to core 1, a
> cache
> > line flush of the affected line is necessary prior to sending the event
> that
> > wakes up the other core.
>
> Have the patches been tested with the OCM in the default state?
>

Yes.  Performing a cache flush by virtual address to a line which has
Device memory attributes appears to be harmless.

-- 
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Chris Johns]

On 5/6/20 6:03 pm, jan.som...@dlr.de wrote:
> We came across the PPSi library for PTP support some time ago: 
> https://ohwr.org/project/ppsi
> In their documentation its says they started with ptpd and then made an 
> overhaul of the source code.

Interesting. Did you check the licenses and authors?

A search for "ptp v2.1.0" lists PTP v2.1.0 in SF and github. The github repo
seems a more recent version of the SF repo but they seem similar. The PPSi code
is GPLv2 and the SF and github code is 2C-BSD and the list of copyright holders
is different.

> They also claim portability as one of their goals. We haven't had time to 
> look at it closer yet, but the projects looks a bit more active and seems to 
> have the CERN behind it.

Then I hope the copyright is in order.

> Maybe it is worth checking out, if ptpd keeps making trouble.

It is GPL when the other code I have looked at it BSD.

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

Help in figuring out score objects in RTEMS and ticket #3131

[Utkarsh Rai]

Hello,
For my GSoC project, user-configurable thread stack protection, I need to
track, allocate, and manipulate attributes of shared as well as protected
stacks. Dr.Gedare suggested that tracking them with score objects would be
a good idea. He also indicated a good place to start and understand
score objects would be through this ticket.


>From the information that I could find in docs, my understanding of score
objects is that they are a type of directive that
helps introduce modularity to RTEMS as various types of RTEMS objects like
message queues, semaphores, etc. can use the same set of directives for
allocation/deallocation and control of their object types.

Some of the examples of the implementation that I could find used
_Object_Iniitialize_information()
to initialize the object type, then _Object_Allocate()/Free()
allocate/de-allocate the object. Object_Id is used to control the object
type. My confusion is, how do we use object IDs to refer to and control the
allocated objects?

I also have some confusion in the above-mentioned ticket, it says-
'The mmap_h handler should construct a mapping object. A destructor is
currently missing. Maybe the mmap_h handler should use a flag to deal with
construction and destruction.'
 I am unclear as to how the mmap_h handler should precisely look like and
where should it be defined?
I would be grateful if you can provide some help in figuring this out.

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

Re: Cacheable OCM support for the Zynq BSP

[Chris Johns]

On 11/6/20 10:10 am, Jonathan Brandmeyer wrote:
> On Wed, Jun 10, 2020 at 5:57 PM Chris Johns  > wrote:
> 
> On 11/6/20 9:30 am, Jonathan Brandmeyer wrote:
> > We've patched the RTEMS kernel in order to support using the Zynq 
> on-chip
> memory
> > as inner-cacheable memory.  The enclosed patch should apply cleanly to 
> master.
> >
> > Background: During normal startup, the ROM bootloader performs 
> vendor-specific
> > initialization of  core 1, and then sits in a wait-for-event loop until 
> a
> > special value has been written to a specific address in OCM.  In that
> state, the
> > MMU has not yet been initialized and core 1 is treating OCM as Device 
> memory.
> >
> > By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's 
> MMU has
> > already been initialized with the application-defined memory map.  I'd 
> like to
> > use the on-chip memory as inner cacheable memory in my application.  In
> order to
> > ensure that the kick address write actually becomes visible to core 1, 
> a cache
> > line flush of the affected line is necessary prior to sending the event 
> that
> > wakes up the other core.
> 
> Have the patches been tested with the OCM in the default state?
> 
> Yes.  Performing a cache flush by virtual address to a line which has Device
> memory attributes appears to be harmless.
>  

Great.

Could you please create a ticket for this change and attach the patch? Please
set the milestone to 6. The change might be OK for 5.2 so a new ticket for that
milestone can be created once we have the change merged onto master.

A ticket means the change is not lost as a post to this list.

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

Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps

[Chris Johns]

On 1/6/20 12:22 am, Jan Sommer wrote:
> Hello,
> 
> Here is a patch set which should enable SMP again for the pc386-based BSPs 
> (mainly tested with pc686).

Many thanks for these patches and your efforts.

> So far I only tested it with qemu. Tests on real hardware are pending.

It would be good to test results for hardware with SMP disabled. If the test
results do not show any regressions then I am fine with these patches for RTEMS
5.2 with SMP documented as experimental. I will take a look at doing this.

> To me it looks like there are no regressions for the standard non-SMP version 
> of the BSP, but it is difficult to say for sure.

Great.

> Subsequent runs of the testsuite with a current master build already produce 
> different numbers of failed/timeout/invalid tests.

OK.

> However, even with the patch set applied the amount of passed tests continues 
> to range from 550-557 and the failed/timeout/invalid tests seem to be 
> generally the same.
> Regarding smptests, the current status with qemu-4.2.0 and 4 cores looks like 
> this:
> 
> Passed:55
> Failed: 1
> User Input: 0
> Expected Fail:  0
> Indeterminate:  0
> Benchmark:  0
> Timeout:2
> Invalid:1
> Wrong Version:  0
> Wrong Build:0
> Wrong Tools:0
> -
> Total: 59
> Failures:
>  smpatomic01.exe
> Timeouts:
>  smpclock01.exe
>  smpopenmp01.exe
> Invalid:
>  smpfatal09.exe
>  
> Some details on the missing tests:
> ---
> smpfatal09: This test actually does pass, but because the fatal error handler 
> is executed before the console is initialized, no output is produced.
> 
> smpclock01.exe: Here CPU0 disables its local interrupts and waits for a 
> barrier release of CPU1. This means it doesn't handle timer interrupts 
> anymore and doesn't send corresponding IPIs to other CPUs.
> At the same time CPU1 is waiting for a timer event before releasing the 
> barrier. Any hints how to resolve this are very welcome.

Please create a ticket.

> smpatomic01: This test seems very large and a bit complicated to me. I will 
> have a look at it next, but any suggestions are welcome. It fails with this 
> information:
> ] === atomic or/and test case ===
> ] worker 0 value: 1
> ] worker 1 value: 0
> ] atomic value: expected = 1, actual = 1
> ] 
> ../../../../../../smp-refex-rtems/c/src/../../testsuites/smptests/smpatomic01/init.c:
>  404 n - s < LONG_MAX
> ] 
> ] *** FATAL ***
> 
> smpopenmp01: I don't know more about openmp then what is on wikipedia. It has 
> currently a low priority for me.

Please create a ticket.

> Some details regarding the patch set:
> -
> 
> - The first 3 commits are basically cleaning the original start16.S to be 
> used for starting the application processors only and updating the general 
> bring up infrastructure.
> - The next 2 commits are updating the low level context switch and isr 
> handling in assembly. I used the ARM implementation as a template and tried 
> to stay comparably close to it.
> - The last 4 commits are smaller changes made after debugging certain test 
> cases.
> 
> 
> My next step would be to test the SMP functionality on HW. My goal would be 
> to get the final revision published as part of the RTEMS5 release.

This is something I would like to see. I feel a first step of getting the
changes merge as SMP experimental would be acceptable if no one objects and then
branch release can look at moving SMP to functional if the changed lets us do
that. That may also depend on RTEMS 6 and it's time frame. My hope is a lot
shorter than 5.

Chris

> If you would like to see any logs from a testsuite run with certain 
> parameters, just tell me.
> 
> Best regards,
> 
> Jan
> 
> 
> 
> Jan Sommer (9):
>   bsp/pc386: Fix Makefile for building with SMP
>   bsp/pc386: Turn start16.S into a startAP.S
>   bsp/pc386: Update GDT to work for SMP
>   bsp/pc386: Update context switch and restore
>   bsp/pc386: Define interrupt stack frame for smp
>   bsps/pc386: Fix Clock_isr for SMP
>   bsps/pc386: Separate smp API functions. Makes smpfatal08 link
>   smpsignal01: Change state before sending the signal
>   bsp/pc386: Disable interrupt nesting for job handler
> 
>  bsps/i386/include/bsp/smp-imps.h   |   3 +
>  bsps/i386/pc386/clock/ckinit.c |   2 +-
>  bsps/i386/pc386/include/bsp.h  |   7 +
>  bsps/i386/pc386/include/bsp/tblsizes.h |   8 +-
>  bsps/i386/pc386/start/bspsmp.c |  43 
>  bsps/i386/pc386/start/getcpuid.c   |  22 --
>  bsps/i386/pc386/start/ldsegs.S |   4 +-
>  bsps/i386/pc386/start/smp-imps.c   |  79 ---
>  bsps/i386/pc386/start/start16.S| 254 
> -
>  bsps/i386/pc386/start/startAP.S| 118 ++
>  bsps/i386/shared/irq/irq_asm.S | 102 +
>

Re: Cacheable OCM support for the Zynq BSP

[Jonathan Brandmeyer]

On Wed, Jun 10, 2020 at 8:08 PM Chris Johns  wrote:

>
> Could you please create a ticket for this change and attach the patch?
> Please
> set the milestone to 6. The change might be OK for 5.2 so a new ticket for
> that
> milestone can be created once we have the change merged onto master.
>
>
https://devel.rtems.org/attachment/ticket/4003

-- 
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cacheable OCM support for the Zynq BSP

[Chris Johns]

On 11/6/20 12:22 pm, Jonathan Brandmeyer wrote:
> On Wed, Jun 10, 2020 at 8:08 PM Chris Johns  > wrote:
> 
> Could you please create a ticket for this change and attach the patch? 
> Please
> set the milestone to 6. The change might be OK for 5.2 so a new ticket 
> for that
> milestone can be created once we have the change merged onto master.
> 
> 
> https://devel.rtems.org/attachment/ticket/4003

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

RE: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Jan.Sommer]

> -Original Message-
> From: Chris Johns [mailto:chr...@rtems.org]
> Sent: Thursday, June 11, 2020 2:26 AM
> To: Sommer, Jan; mritunjaysharma...@gmail.com
> Cc: rtems-de...@rtems.org
> Subject: Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This
> time building for xilinx_zynq_a9_qemu
> 
> On 5/6/20 6:03 pm, jan.som...@dlr.de wrote:
> > We came across the PPSi library for PTP support some time ago:
> https://ohwr.org/project/ppsi
> > In their documentation its says they started with ptpd and then made an
> overhaul of the source code.
> 
> Interesting. Did you check the licenses and authors?
> 
> A search for "ptp v2.1.0" lists PTP v2.1.0 in SF and github. The github repo
> seems a more recent version of the SF repo but they seem similar. 

In the PPSi manual they write: 

"The algorithm and computation routines regarding the basic ieee 1588 are 
derived from the
PTPd project, v.2.1.0 (see AUTHORS for details about copyright); but as of 
March 2013 very
little remains of the original code base."

In their AUTHORS file they seem to have copied the information from here: 
https://sourceforge.net/p/ptpd/code/HEAD/tree/branches/ptpd-2.1.1/COPYRIGHT

>The PPSi code is GPLv2 and the SF and github code is 2C-BSD and the list of 
>copyright
> holders is different.
> 

Most of it seems to be LGPL with 2 exceptions according to the manual:

"The code is licensed according to the GNU LGPL, version 2.1 or later. Some 
files are individually
released to the public domain, when we think they are especially simple or 
generic.
Both the full and the partial printf code is distributed according to the 
GPL-2, as it comes from
the Linux kernel. This means that any code using our diagnostics fall under the 
GPL requirements; you may compile and use the diagnostic code internally with 
your own proprietary code
but you can’t distribute binaries with diagnostics without the complete source 
code and associated rights. You may avoid the GPL requirements by using 
different printf implementations; if
so we’d love to have them contributed back in the package.
The same issue about the GPL license applies to the div64_32 function. We need 
this implementation in our wrpc code base because the default libgcc division 
is very big, and we are always
tight with our in-FPGA memory space."

It would have been nice if this information would be more prominent in their 
repository and not hidden in the manual.

Cheers,

   Jan

> > They also claim portability as one of their goals. We haven't had time to
> look at it closer yet, but the projects looks a bit more active and seems to
> have the CERN behind it.
> 
> Then I hope the copyright is in order.
> 
> > Maybe it is worth checking out, if ptpd keeps making trouble.
> 
> It is GPL when the other code I have looked at it BSD.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel