Re: [PATCH 2/2] rtems: define _POSIX_CLOCK_SELECTION feature

[Gedare Bloom]

Alright -- I still get some missing prototype warning for
clock_nanosleep, so more feature magic might be needed still.

On Mon, Aug 1, 2016 at 4:03 PM, Joel Sherrill  wrote:
> Looks OK to me.
>
> --joel
>
> On August 1, 2016 4:01:39 PM EDT, Gedare Bloom  wrote:
>>This feature enables the prototype for clock_nanosleep, which is now
>>available in RTEMS.
>>
>>On Mon, Aug 1, 2016 at 3:55 PM, Gedare Bloom  wrote:
>>> ---
>>>  newlib/libc/include/sys/features.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/newlib/libc/include/sys/features.h
>>b/newlib/libc/include/sys/features.h
>>> index dbc4ebe..93635ba 100644
>>> --- a/newlib/libc/include/sys/features.h
>>> +++ b/newlib/libc/include/sys/features.h
>>> @@ -328,6 +328,7 @@ extern "C" {
>>>  #define _POSIX_MEMORY_PROTECTION   1
>>>  #define _POSIX_MESSAGE_PASSING 1
>>>  #define _POSIX_MONOTONIC_CLOCK 200112L
>>> +#define _POSIX_CLOCK_SELECTION 200112L
>>>  #define _POSIX_PRIORITIZED_IO  1
>>>  #define _POSIX_PRIORITY_SCHEDULING 1
>>>  #define _POSIX_REALTIME_SIGNALS1
>>> --
>>> 1.9.1
>>>
>
> --joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd: How to add an option for switching off IPv6 (or other BSD Kernel configurations)

[Chris Johns]

On 02/08/2016 00:04, Christian Mauderer wrote:

Hello,

we have a special use case where we want to use the new network stack
but without the IPv6 support. I could need some advice how this could be
integrated into the waf build system. If we find a good solution, this
could also be an example for other BSD Kernel options.


I found multiple places where IPv6 is enabled in libbsd:

If I remove the INET6 option out of the FreeBSD kernel configuration on
a FreeBSD system, this has the effect, that the "opt_inet6.h" is
generated as an empty file instead of with a single define "#define
INET6 1". In the rtems-libbsd the configuration header is located at
rtemsbsd/include/rtems/bsd/local/opt_inet6.h. It has a fixed content
with the define set. This would be the first place where the support
would have to be disabled.

Beneath that, some user space tools have a special option to enable IPv6
which is currently set in libbsd.py. One such example is tcpdump with a
compiler flag '-DINET6' set. As far as I could tell, the kernel and
every application that is included in libbsd currently uses the INET6
macro. But I think this is more of a convention than a general rule.



What about 'dhcpcd/ipv6.c' in the dhcpcd module? I think the problem may 
be a little more complicated and you may need to control the code being 
built based on the selected configuration.




So I think we would roughly need the following:

If i configure libbsd using

waf configure --disable-ipv6



I would prefer something like --config="networking:ipv6=no,..;" so a 
general interface can be added. I doubt this will be the last option 
that needs to be added. This avoids growing a long list of 
enable/disable options being used to add features. It also allows us to 
implement a generic framework we can use use in different areas where 
this may also need to happen, eg --config="usb:...;".


If you consider the interface as a list of 'name=value' pairs it can be 
mapped to the INI format file which Python can read via the 
ConfigParser. This means:


 [networking]
 ipv6=no

 [udb]
 ...

In time we could allow reading of these setting from a user defined 
configuration file, eg --config='file:myconfig.ini'.



the build system would either have to regenerate opt_inet6.h or use an
alternative version of it. Further I would need the ability to set
compiler flags in libbsd.py depending on this configure option.


You could provide -DRTEMS_LIBBSD_INET6=1 and that would conditionally 
control '#define INET6 1' in 'opt_inet6.h'. I would prefer something 
static to generating files.



Are there any better ideas how to implement such an option?


There are 2 parts that need be to changed to make this work. This 
assumes you will need to control the source being built.


The first is the module descriptions in libbsd.py and then the 
generator. I suggest you look at the various module class methods used 
to add source and consider adding a 'section' argument which defaults to 
'default' (always True). This would lets you move code into specific 
sections, for example:


dhcpcd_defines='-D__FreeBSD__ -DTHERE_IS_NO_FORK ...'
mod.addSourceFiles(
[
'dhcpcd/ipv6.c',
'dhcpcd/ipv6nd.c',
],
mm.generator['source'](dhcpcd_defines),
section = 'networking.ipv6_yes'
)

Note, this definition generates something that is evaluated when waf 
runs so the 'section' populates a dict where the 'networking.ipv6_yes' 
key is tested for True or False depending what the user specifies.


You could also change the class constructor so you have:

 mod = builder.Module('dhcpcd', section = 'networking.dhcp')

The dot notation would allow control of the sources at the module level 
to finally get sorted out. The dhcpcd module becomes 'networking.dhcpcd' 
which means build if networking and dhcpcd are True. You could work down 
the dots checking at each point to make sure the module can be built. 
Currently module level user control has been left hanging with commented 
modules, eg '#mm.addModule(dev_usb_controller_add_on(mm)'. If the 
section 'usb.dev_usb_controller_add_on' is False by default that module 
is not built which is what we have now.


The second part is in the waf script (wscript) which handles the user 
interface, ie parses 
--config="networking:ipv6=no,pink-frames-only,chrismac-buf-frames=64". I 
would add this code in a new Python module libbsd_opts.py and imported 
into libbsd_waf.py (generated) and called in the 'options' function in 
libbsd_waf.py. This would parse and populate a dict the generated module 
code uses.



I'm quite inexperienced on how to use waf, so I would need some guidance
how this could be implemented. Are there any hints how I could start
implementing such an option? Some examples or similar code?


There is nothing similar as the core of the functionality is in 
freebsd-to-rtems.py and related code which has been an on going 
development. Conditionally adding source can 

Re: [PATCH v2] linker set: Allow adding any variable into content

[Chris Johns]

On 02/08/2016 01:38, Gedare Bloom wrote:

The code looks fine, but I don't quite understand the
purpose/usefulness of the change.


I am wondering if this makes porting BSD user code to RTEMS easier by 
grouping variables.


I would like to see a doc ticket created to be completed once I branch 
the doc repo. If this is available for users and so an API we should 
document it.



On Mon, Aug 1, 2016 at 7:16 AM, Christian Mauderer
 wrote:

From: Christian Mauderer 

The newly created macro allows to add any kind of variable into the


The newly created macro adds any kind of variable into a linker set. It 
allows (for example) the saving an execution state of a function using 
the following method:


This allows (for example) saving an execution

state of a function using the following method:

- put a group of different variables into one linker set
- save the memory area containing the group of variables before the
   execution of a function
- restore the memory area after the function has been executed


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

[PATCH 2/2] rtems: define _POSIX_CLOCK_SELECTION feature

[Gedare Bloom]

---
 newlib/libc/include/sys/features.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/newlib/libc/include/sys/features.h 
b/newlib/libc/include/sys/features.h
index dbc4ebe..93635ba 100644
--- a/newlib/libc/include/sys/features.h
+++ b/newlib/libc/include/sys/features.h
@@ -328,6 +328,7 @@ extern "C" {
 #define _POSIX_MEMORY_PROTECTION   1
 #define _POSIX_MESSAGE_PASSING 1
 #define _POSIX_MONOTONIC_CLOCK 200112L
+#define _POSIX_CLOCK_SELECTION 200112L
 #define _POSIX_PRIORITIZED_IO  1
 #define _POSIX_PRIORITY_SCHEDULING 1
 #define _POSIX_REALTIME_SIGNALS1
-- 
1.9.1

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

[PATCH] posix: nanosleep: adjust elapsed time calculation

[Gedare Bloom]

Use clock_gettime before and after sleep to calculate
the time spent asleep, and the amount of time remaining.

updates #2732
---
 cpukit/posix/src/nanosleep.c | 61 ++--
 1 file changed, 31 insertions(+), 30 deletions(-)

diff --git a/cpukit/posix/src/nanosleep.c b/cpukit/posix/src/nanosleep.c
index 05d559a..2a95d84 100644
--- a/cpukit/posix/src/nanosleep.c
+++ b/cpukit/posix/src/nanosleep.c
@@ -33,21 +33,19 @@ static Thread_queue_Control _Nanosleep_Pseudo_queue =
   THREAD_QUEUE_INITIALIZER( "Nanosleep" );
 
 static inline int nanosleep_helper(
+  clockid_t clock_id,
   uint64_t  ticks,
-  Watchdog_Interval relative_interval,
+  struct timespec  *timeout,
   struct timespec  *rmtp,
   Watchdog_Discipline   discipline
 )
 {
   Thread_Control  *executing;
-
-  Watchdog_Interval  start;
-  Watchdog_Interval  elapsed;
+  struct timespec stop;
+  int err = 0;
 
   executing = _Thread_Get_executing();
 
-  start = _Watchdog_Ticks_since_boot;
-
   /*
*  Block for the desired amount of time
*/
@@ -61,21 +59,12 @@ static inline int nanosleep_helper(
 1
   );
 
-  /*
-   * Calculate the time that passed while we were sleeping and how
-   * much remains from what we requested.
-   */
-  elapsed = _Watchdog_Ticks_since_boot - start;
-  if ( elapsed >= relative_interval )
-relative_interval = 0;
-  else
-relative_interval -= elapsed;
-
+  clock_gettime( clock_id,  );
   /*
* If the user wants the time remaining, do the conversion.
*/
-  if ( rmtp ) {
-_Timespec_From_ticks( relative_interval, rmtp );
+  if ( rmtp != NULL ) {
+_Timespec_Subtract( , , rmtp );
   }
 
   /*
@@ -85,7 +74,7 @@ static inline int nanosleep_helper(
 /*
  *  If there is time remaining, then we were interrupted by a signal.
  */
-if ( relative_interval )
+if ( _Timespec_Greater_than( , ) )
   return EINTR;
   #endif
 
@@ -152,7 +141,12 @@ int nanosleep(
 return -1;
   _Timespec_Add_to( , rqtp );
   ticks = _Watchdog_Ticks_from_timespec(  );
-  err = nanosleep_helper(ticks, relative_interval, rmtp, WATCHDOG_ABSOLUTE );
+  err = nanosleep_helper( CLOCK_REALTIME,
+  ticks,
+  ,
+  rmtp,
+  WATCHDOG_ABSOLUTE
+  );
   if ( err != 0 ) {
 rtems_set_errno_and_return_minus_one( err );
   }
@@ -170,10 +164,9 @@ int clock_nanosleep(
 )
 {
   int err = 0;
-  struct timespec now;
+  struct timespec timeout;
   uint64_t ticks;
   Watchdog_Interval relative_interval;
-  struct timespec relative_ts;
   TOD_Absolute_timeout_conversion_results status;
 
   if ( !_Timespec_Is_valid( rqtp ) )
@@ -190,25 +183,33 @@ int clock_nanosleep(
 if ( status == TOD_ABSOLUTE_TIMEOUT_IS_NOW )
   return nanosleep_yield( NULL );
 rmtp = NULL; /* Do not touch rmtp when using absolute time */
+timeout = 0;
   } else {
+/* prepare to convert relative ticks to absolute timeout */
+err = clock_gettime( clock_id,  );
+if ( err != 0 )
+  return EINVAL;
 relative_interval = _Timespec_To_ticks( rqtp );
   }
   if ( relative_interval == 0 )
 return nanosleep_yield( rmtp );
 
+  _Timespec_Add_to( , rqtp );
   if ( clock_id == CLOCK_REALTIME ) {
-/* convert relative ticks to absolute timeout */
-err = clock_gettime( CLOCK_REALTIME,  );
-if ( err != 0 )
-  return EINVAL;
-_Timespec_Add_to( , rqtp );
-ticks = _Watchdog_Ticks_from_timespec(  );
-err = nanosleep_helper( ticks, relative_interval, rmtp, WATCHDOG_ABSOLUTE 
);
+ticks = _Watchdog_Ticks_from_timespec(  );
+err = nanosleep_helper(
+clock_id,
+ticks,
+,
+rmtp,
+WATCHDOG_ABSOLUTE
+);
   } else if ( clock_id == CLOCK_MONOTONIC ) {
 /* use the WATCHDOG_RELATIVE to ignore changes in wall time */
 err = nanosleep_helper(
+clock_id,
 relative_interval,
-relative_interval,
+,
 rmtp,
 WATCHDOG_RELATIVE
 );
-- 
1.9.1

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

[PATCH] posix: move sys/mman.h to newlib and test it in psxhdrs

[Gedare Bloom]

---
 cpukit/Makefile.am |   1 -
 cpukit/posix/include/sys/mman.h| 189 -
 cpukit/posix/src/mprotect.c|   2 +-
 cpukit/preinstall.am   |   4 -
 testsuites/psxtests/psxhdrs/Makefile.am|  13 ++
 testsuites/psxtests/psxhdrs/sys/mman/mlock.c   |  28 +++
 testsuites/psxtests/psxhdrs/sys/mman/mlockall.c|  27 +++
 testsuites/psxtests/psxhdrs/sys/mman/mmap.c|  30 
 testsuites/psxtests/psxhdrs/sys/mman/mprotect.c|  29 
 testsuites/psxtests/psxhdrs/sys/mman/msync.c   |  29 
 testsuites/psxtests/psxhdrs/sys/mman/munlock.c |  28 +++
 testsuites/psxtests/psxhdrs/sys/mman/munlockall.c  |  25 +++
 testsuites/psxtests/psxhdrs/sys/mman/munmap.c  |  28 +++
 .../psxtests/psxhdrs/sys/mman/posix_madvise.c  |  29 
 testsuites/psxtests/psxhdrs/sys/mman/shm_open.c|  29 
 testsuites/psxtests/psxhdrs/sys/mman/shm_unlink.c  |  27 +++
 16 files changed, 323 insertions(+), 195 deletions(-)
 delete mode 100644 cpukit/posix/include/sys/mman.h
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mlock.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mlockall.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mmap.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mprotect.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/msync.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/munlock.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/munlockall.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/munmap.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/posix_madvise.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/shm_open.c
 create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/shm_unlink.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index ac97530..9d90f82 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -54,7 +54,6 @@ include_sys_HEADERS =
 include_HEADERS += include/crypt.h
 include_HEADERS += include/memory.h
 
-include_sys_HEADERS += posix/include/sys/mman.h
 include_sys_HEADERS += libcsupport/include/sys/ioccom.h
 include_sys_HEADERS += libcsupport/include/sys/event.h
 include_sys_HEADERS += libcsupport/include/sys/filio.h
diff --git a/cpukit/posix/include/sys/mman.h b/cpukit/posix/include/sys/mman.h
deleted file mode 100644
index ddf34cc..000
--- a/cpukit/posix/include/sys/mman.h
+++ /dev/null
@@ -1,189 +0,0 @@
-/* $NetBSD: mman.h,v 1.36 2005/09/13 01:42:51 christos Exp $   */
-
-/*-
- * Copyright (c) 1982, 1986, 1993
- * The Regents of the University of California.  All rights reserved.
- *
- * 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.
- * 3. Neither the name of the University nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
- *
- * @(#)mman.h  8.2 (Berkeley) 1/9/95
- */
-
-#ifndef _SYS_MMAN_H_
-#define _SYS_MMAN_H_
-
-#ifdef __rtems__
-
-#include 
-#include 
-#include 
-
-#else /* __rtems__ */
-#include 
-
-#include 
-
-#ifdef _BSD_SIZE_T_
-typedef_BSD_SIZE_T_size_t;
-#undef _BSD_SIZE_T_
-#endif
-
-#include 
-
-#ifndefmode_t
-typedef__mode_tmode_t;
-#definemode_t  __mode_t
-#endif
-
-#ifndefoff_t
-typedef__off_t off_t;  /* file offset */
-#defineoff_t   __off_t
-#endif
-#endif /* __rtems__ */
-
-
-/*
- * Protections are chosen from these bits, or-ed together
- */
-#definePROT_NONE   0x00/* no permissions */
-#definePROT_READ   0x01/* 

Re: [PATCH 2/2] rtems: define _POSIX_CLOCK_SELECTION feature

[Gedare Bloom]

This feature enables the prototype for clock_nanosleep, which is now
available in RTEMS.

On Mon, Aug 1, 2016 at 3:55 PM, Gedare Bloom  wrote:
> ---
>  newlib/libc/include/sys/features.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/newlib/libc/include/sys/features.h 
> b/newlib/libc/include/sys/features.h
> index dbc4ebe..93635ba 100644
> --- a/newlib/libc/include/sys/features.h
> +++ b/newlib/libc/include/sys/features.h
> @@ -328,6 +328,7 @@ extern "C" {
>  #define _POSIX_MEMORY_PROTECTION   1
>  #define _POSIX_MESSAGE_PASSING 1
>  #define _POSIX_MONOTONIC_CLOCK 200112L
> +#define _POSIX_CLOCK_SELECTION 200112L
>  #define _POSIX_PRIORITIZED_IO  1
>  #define _POSIX_PRIORITY_SCHEDULING 1
>  #define _POSIX_REALTIME_SIGNALS1
> --
> 1.9.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] posix: move sys/mman.h to newlib and test it in psxhdrs

[Gedare Bloom]

This requires toolchain bump with the sister patch "rtems: add
sys/mman.h" on newlib.

On Mon, Aug 1, 2016 at 4:11 PM, Gedare Bloom  wrote:
> ---
>  cpukit/Makefile.am |   1 -
>  cpukit/posix/include/sys/mman.h| 189 
> -
>  cpukit/posix/src/mprotect.c|   2 +-
>  cpukit/preinstall.am   |   4 -
>  testsuites/psxtests/psxhdrs/Makefile.am|  13 ++
>  testsuites/psxtests/psxhdrs/sys/mman/mlock.c   |  28 +++
>  testsuites/psxtests/psxhdrs/sys/mman/mlockall.c|  27 +++
>  testsuites/psxtests/psxhdrs/sys/mman/mmap.c|  30 
>  testsuites/psxtests/psxhdrs/sys/mman/mprotect.c|  29 
>  testsuites/psxtests/psxhdrs/sys/mman/msync.c   |  29 
>  testsuites/psxtests/psxhdrs/sys/mman/munlock.c |  28 +++
>  testsuites/psxtests/psxhdrs/sys/mman/munlockall.c  |  25 +++
>  testsuites/psxtests/psxhdrs/sys/mman/munmap.c  |  28 +++
>  .../psxtests/psxhdrs/sys/mman/posix_madvise.c  |  29 
>  testsuites/psxtests/psxhdrs/sys/mman/shm_open.c|  29 
>  testsuites/psxtests/psxhdrs/sys/mman/shm_unlink.c  |  27 +++
>  16 files changed, 323 insertions(+), 195 deletions(-)
>  delete mode 100644 cpukit/posix/include/sys/mman.h
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mlock.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mlockall.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mmap.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/mprotect.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/msync.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/munlock.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/munlockall.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/munmap.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/posix_madvise.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/shm_open.c
>  create mode 100644 testsuites/psxtests/psxhdrs/sys/mman/shm_unlink.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index ac97530..9d90f82 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -54,7 +54,6 @@ include_sys_HEADERS =
>  include_HEADERS += include/crypt.h
>  include_HEADERS += include/memory.h
>
> -include_sys_HEADERS += posix/include/sys/mman.h
>  include_sys_HEADERS += libcsupport/include/sys/ioccom.h
>  include_sys_HEADERS += libcsupport/include/sys/event.h
>  include_sys_HEADERS += libcsupport/include/sys/filio.h
> diff --git a/cpukit/posix/include/sys/mman.h b/cpukit/posix/include/sys/mman.h
> deleted file mode 100644
> index ddf34cc..000
> --- a/cpukit/posix/include/sys/mman.h
> +++ /dev/null
> @@ -1,189 +0,0 @@
> -/* $NetBSD: mman.h,v 1.36 2005/09/13 01:42:51 christos Exp $   */
> -
> -/*-
> - * Copyright (c) 1982, 1986, 1993
> - * The Regents of the University of California.  All rights reserved.
> - *
> - * 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.
> - * 3. Neither the name of the University nor the names of its contributors
> - *may be used to endorse or promote products derived from this software
> - *without specific prior written permission.
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
> - *
> - * @(#)mman.h  8.2 (Berkeley) 1/9/95
> - */
> -
> -#ifndef _SYS_MMAN_H_
> -#define _SYS_MMAN_H_
> -
> -#ifdef __rtems__
> -
> -#include 
> -#include 
> -#include 
> -
> -#else /* __rtems__ */
> -#include 
> -
> -#include 
> -
> -#ifdef _BSD_SIZE_T_
> -typedef_BSD_SIZE_T_size_t;
> -#undef _BSD_SIZE_T_
> -#endif
> -
> -#include 
> -
> -#ifndefmode_t
> -typedef__mode_tmode_t;
> -#define

[PATCH 1/2] rtems: add sys/mman.h

[Gedare Bloom]

---
 newlib/libc/sys/rtems/include/sys/mman.h | 263 +++
 1 file changed, 263 insertions(+)
 create mode 100644 newlib/libc/sys/rtems/include/sys/mman.h

diff --git a/newlib/libc/sys/rtems/include/sys/mman.h 
b/newlib/libc/sys/rtems/include/sys/mman.h
new file mode 100644
index 000..e7e5cf4
--- /dev/null
+++ b/newlib/libc/sys/rtems/include/sys/mman.h
@@ -0,0 +1,263 @@
+/*-
+ * Copyright (c) 1982, 1986, 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * 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.
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
+ *
+ * @(#)mman.h  8.2 (Berkeley) 1/9/95
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_MMAN_H_
+#define _SYS_MMAN_H_
+
+#include 
+#include 
+
+#if __BSD_VISIBLE
+/*
+ * Inheritance for minherit()
+ */
+#define INHERIT_SHARE  0
+#define INHERIT_COPY   1
+#define INHERIT_NONE   2
+#endif
+
+/*
+ * Protections are chosen from these bits, or-ed together
+ */
+#definePROT_NONE   0x00/* no permissions */
+#definePROT_READ   0x01/* pages can be read */
+#definePROT_WRITE  0x02/* pages can be written */
+#definePROT_EXEC   0x04/* pages can be executed */
+
+/*
+ * Flags contain sharing type and options.
+ * Sharing types; choose one.
+ */
+#defineMAP_SHARED  0x0001  /* share changes */
+#defineMAP_PRIVATE 0x0002  /* changes are private */
+#if __BSD_VISIBLE
+#defineMAP_COPYMAP_PRIVATE /* Obsolete */
+#endif
+
+/*
+ * Other flags
+ */
+#defineMAP_FIXED0x0010 /* map addr must be exactly as 
requested */
+
+#if __BSD_VISIBLE
+#defineMAP_RENAME   0x0020 /* Sun: rename private pages to file */
+#defineMAP_NORESERVE0x0040 /* Sun: don't reserve needed swap area 
*/
+#defineMAP_RESERVED0080 0x0080 /* previously misimplemented 
MAP_INHERIT */
+#defineMAP_RESERVED0100 0x0100 /* previously unimplemented 
MAP_NOEXTEND */
+#defineMAP_HASSEMAPHORE 0x0200 /* region may contain semaphores */
+#defineMAP_STACK0x0400 /* region grows down, like a stack */
+#defineMAP_NOSYNC   0x0800 /* page to but do not sync underlying 
file */
+
+/*
+ * Mapping type
+ */
+#defineMAP_FILE 0x /* map from file (default) */
+#defineMAP_ANON 0x1000 /* allocated from memory, swap space */
+#ifndef _KERNEL
+#defineMAP_ANONYMOUSMAP_ANON /* For compatibility. */
+#endif /* !_KERNEL */
+
+/*
+ * Extended flags
+ */
+#defineMAP_NOCORE   0x0002 /* dont include these pages in a 
coredump */
+#defineMAP_PREFAULT_READ 0x0004 /* prefault mapping for reading */
+
+/*
+ * Request specific alignment (n == log2 of the desired alignment).
+ *
+ * MAP_ALIGNED_SUPER requests optimal superpage alignment, but does
+ * not enforce a specific alignment.
+ */
+#defineMAP_ALIGNED(n)   ((n) << MAP_ALIGNMENT_SHIFT)
+#defineMAP_ALIGNMENT_SHIFT 24
+#defineMAP_ALIGNMENT_MASK  MAP_ALIGNED(0xff)
+#defineMAP_ALIGNED_SUPER   MAP_ALIGNED(1) /* align on a superpage 
*/
+#endif /* __BSD_VISIBLE */
+
+#if __POSIX_VISIBLE >= 199309
+/*
+ * Process memory locking
+ */
+#define MCL_CURRENT0x0001  /* Lock only current memory */
+#define MCL_FUTURE 0x0002  /* Lock all future memory as well */
+#endif
+
+/*
+ * Error return from mmap()
+ */
+#define MAP_FAILED ((void *)-1)
+
+/*
+ * msync() flags
+ */
+#defineMS_SYNC 0x  /* msync synchronously 

Re: [PATCH] doc: source-builder.txt: Update installtion for ubuntu packages

[Gedare Bloom]

committed, thanks.

On Thu, Jul 28, 2016 at 4:05 PM, Punit Vara  wrote:
> This patch fixes the most common python missing error for RTEMS
> tool chain build and RSB built is tested for ubuntu 16.04.1 LTS
> ---
>  doc/source-builder.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/doc/source-builder.txt b/doc/source-builder.txt
> index 43bcf77..8b0cd89 100644
> --- a/doc/source-builder.txt
> +++ b/doc/source-builder.txt
> @@ -3098,11 +3098,12 @@ home directory as recommended and end up on the SD 
> card.
>  Ubuntu
>  ^^
>
> -The latest testing was with Ubuntu 13.10 64bit. This section also includes 
> Xubuntu. A
> +The latest testing was with Ubuntu 16.04.1 LTS 64bit. This section also 
> includes Xubuntu. A
>  minimal installation was used and the following packages installed.
>
>  -
> -$ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev
> +$ sudo apt-get build-dep binutils gcc g++ gdb unzip git
> +$ sudo apt-get install python2.7-dev
>  -
>
>  FreeBSD
> --
> 2.7.4
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: nanosleep.c remarks

[Pavel Pisa]

Hello Gedare

On Monday 01 of August 2016 17:21:14 Gedare Bloom wrote:
> On Mon, Aug 1, 2016 at 1:18 AM, Sebastian Huber
> It would be good to add some test cases calling clock_settime() and
> delivering signals while a thread nanosleep()s. I don't know that we
> have those cases tested yet.
>
> The rmtp is calculated only in consideration of elapsed score ticks.
> Maybe it would be better to call the clock functions using the
> clock_id.

I would like that approach much more.

The concept

int clock_nanosleep(
  clockid_t   clock_id,
  int flags,
  const struct timespec  *rqtp,
  struct timespec*rmtp
)
{
  struct timespec  rqt = *rqtp;
  struct timespec startt;

  checks ...

  if ( ( rmtp != NULL ) || !( flags & TIMER_ABSTIME ) ) {
 clock_gettime(clk_id, )
 if ( !( flags & TIMER_ABSTIME ) ) {
timespecadd(, );
 }
  }

  sleep until ABS rqt on clock_id,  WATCHDOG_REALTIME or WATCHDOG_MONOTONIC

  if ( rmtp != NULL ) {
if ( timeout ) {
  struct timespec stopt;
  clock_gettime(clk_id, );
  timespecsub(, );
  *rtmp = rtm;
} else {
  rmtp->tv_sec = 0;
  rmtp->tv_nsec = 0;
}
  }
}

I think that this has no bigger overhead than actual implementation,
no conversion in this part of the code. It is prepared for high resolution
timers and even without these it provides precise remaining time information
so prevents rounding errors etc.

As for 

  sleep until ABS rqt on clock_id,  WATCHDOG_REALTIME or WATCHDOG_MONOTONIC

I think that both timer queues used for POSIX related time operations
should work on same time resolution and same mechanism.

If we can afford to lose tick based queue then I would not regret its
killing, simply one queue for REALTIME one for MONOTONIC. The same
code same resolution same operations and ready for high resolution
timer support. This requires only to reprogram timer (compare value
for free running counter, initial count for single shot when time
source is separate) each time when the first timer on any queue changes
(use earlier from both/all).

If the queues are kept in compact timespec or bintime (I like that 64-bit
int + 64-bit fract but it is quite huge) then processing at HW timer
interrupt (today the tick) only needs to retrieve MONOTONIC time
process MONOTONIC queue add actual MONOTONIC to REALTIME offset
and process REALTIME queue expires. Then setup new tick or reprogram
for high resolution.

Only problem (I see for now) is that queue based on ticks is probably
required to stay. One option is to simulate it by MONOTONIC but with
scale adjustment, it can result in unexpected behavior (two tick coalesced
or one skipped). So if the tick based timing should be preserved
then third queue is required unfortuantelly. In the long term,
rough precision queue mechanisms with lower premature timer removal
cost can worth its existence. See the LWN article how Linux optimizes
timeouts performance (code actually merged to 4.8) by sacrificing 
timeouts precision

  http://lwn.net/Articles/646950/

On the other hand, Linux provides high resolution timers at nanosecond
"precision"/resolution (in the fact, precision is artificially lowered
and API allows even ranges specification to ensure that system is not
block by too many interrupts with minimal time distance).

As for the formats, I have read BSD timecounters papers and I like
the concept. May it be 10 timehands take too much memory for small systems.
Does this RTEMS limit to two or three for UP?

As for the format, linear/binary 64+64 is really nice and seem to be quite
effective for conversion to and from timespec. But arithmetic
for fractions and addition is quite huge. I think that 64-bits has
to be enough for timers/events for centuries (time measurement is
another case). If I think about quite often MONOTONIC + offset
to REALTIME conversion then compacted 34+30 is usable but has some
overhead. May it be 34+30 binary can work quite well. Resolution is not
integer multiple/fraction of 1 ns, but for timers it is not
problem. Conversion from tiemspec requires 32 * 32 -> 64 multiply + shr,
conversion back (if required - not so probable) should suffice with the same.

Compacted is worse for computation at tick or high resolution timer
fire time, but insertion of watchdogs is cheaper.

Anyway, I understand that all this timers discussion is in the theoretic level
now. But I hope that Gedare's and my clock_nanosleep with clock_gettime
proposal is future proof and conversion to non-optimal ticks for MONOTONIC
is the last step which can be easily changed to adjust for possible
future changes in underlaying code.

> > This function is probably superfluous now due to the timekeeping via the
> > FreeBSD timecounters. We tried to keep the existing behaviour during the
> > introduction of the FreeBSD timecounters. However, some parts of the
> > POSIX implementation in RTEMS are not according to POSIX. This must be
> > fixed step by step (its not on my 

Re: [PATCH v2] linker set: Allow adding any variable into content

[Gedare Bloom]

The code looks fine, but I don't quite understand the
purpose/usefulness of the change.

On Mon, Aug 1, 2016 at 7:16 AM, Christian Mauderer
 wrote:
> From: Christian Mauderer 
>
> The newly created macro allows to add any kind of variable into the
> content of a linker set. This allows (for example) saving an execution
> state of a function using the following method:
>
> - put a group of different variables into one linker set
> - save the memory area containing the group of variables before the
>   execution of a function
> - restore the memory area after the function has been executed
> ---
>  cpukit/score/include/rtems/linkersets.h|  8 
>  testsuites/sptests/splinkersets01/init.c   | 24 
> ++
>  testsuites/sptests/splinkersets01/items.c  |  8 
>  testsuites/sptests/splinkersets01/sets.c   |  4 
>  testsuites/sptests/splinkersets01/splinkersets01.h | 12 +++
>  5 files changed, 56 insertions(+)
>
> diff --git a/cpukit/score/include/rtems/linkersets.h 
> b/cpukit/score/include/rtems/linkersets.h
> index e40be66..47c210d 100644
> --- a/cpukit/score/include/rtems/linkersets.h
> +++ b/cpukit/score/include/rtems/linkersets.h
> @@ -57,6 +57,10 @@ extern "C" {
>type volatile const _Linker_set_##set##_##item \
>RTEMS_SECTION( ".rtemsroset." #set ".content.1" ) RTEMS_USED
>
> +#define RTEMS_LINKER_ROSET_CONTENT( set, decl ) \
> +  decl \
> +  RTEMS_SECTION( ".rtemsroset." #set ".content" )
> +
>  #define RTEMS_LINKER_RWSET_DECLARE( set, type ) \
>extern type volatile RTEMS_LINKER_SET_BEGIN( set )[0]; \
>extern type volatile RTEMS_LINKER_SET_END( set )[0]
> @@ -89,6 +93,10 @@ extern "C" {
>type volatile _Linker_set_##set##_##item \
>RTEMS_SECTION( ".rtemsrwset." #set ".content.1" ) RTEMS_USED
>
> +#define RTEMS_LINKER_RWSET_CONTENT( set, decl ) \
> +  decl \
> +  RTEMS_SECTION( ".rtemsrwset." #set ".content" )
> +
>  #ifdef __cplusplus
>  }
>  #endif /* __cplusplus */
> diff --git a/testsuites/sptests/splinkersets01/init.c 
> b/testsuites/sptests/splinkersets01/init.c
> index 3d35a4e..28c6384 100644
> --- a/testsuites/sptests/splinkersets01/init.c
> +++ b/testsuites/sptests/splinkersets01/init.c
> @@ -130,11 +130,35 @@ static void test(void)
>rtems_test_assert( == sb[2]);
>  }
>
> +static void test_content(void)
> +{
> +  void volatile *b_rw = RTEMS_LINKER_SET_BEGIN(test_content_rw);
> +  void volatile *e_rw = RTEMS_LINKER_SET_END(test_content_rw);
> +
> +  void volatile const *b_ro = RTEMS_LINKER_SET_BEGIN(test_content_ro);
> +  void volatile const *e_ro = RTEMS_LINKER_SET_END(test_content_ro);
> +
> +  rtems_test_assert(_rw_1 >= b_rw);
> +  rtems_test_assert(_rw_2 >= b_rw);
> +  rtems_test_assert(_rw_3 >= b_rw);
> +  rtems_test_assert(_rw_1 <= e_rw);
> +  rtems_test_assert(_rw_2 <= e_rw);
> +  rtems_test_assert(_rw_3 <= e_rw);
> +
> +  rtems_test_assert(_ro_1 >= b_ro);
> +  rtems_test_assert(_ro_2 >= b_ro);
> +  rtems_test_assert(_ro_3 >= b_ro);
> +  rtems_test_assert(_ro_1 <= e_ro);
> +  rtems_test_assert(_ro_2 <= e_ro);
> +  rtems_test_assert(_ro_3 <= e_ro);
> +}
> +
>  static void Init(rtems_task_argument arg)
>  {
>TEST_BEGIN();
>
>test();
> +  test_content();
>
>TEST_END();
>rtems_test_exit(0);
> diff --git a/testsuites/sptests/splinkersets01/items.c 
> b/testsuites/sptests/splinkersets01/items.c
> index 7ca6f53..fde102a 100644
> --- a/testsuites/sptests/splinkersets01/items.c
> +++ b/testsuites/sptests/splinkersets01/items.c
> @@ -21,3 +21,11 @@
>  RTEMS_LINKER_RWSET_ITEM_ORDERED(test_rw, const int *, a1, 1) = [1];
>
>  RTEMS_LINKER_ROSET_ITEM_ORDERED(test_ro, const int *, ca2, OC) = [2];
> +
> +int content_rw_1;
> +char content_rw_2;
> +char content_rw_3;
> +
> +const int content_ro_1;
> +const char content_ro_2;
> +const char content_ro_3;
> diff --git a/testsuites/sptests/splinkersets01/sets.c 
> b/testsuites/sptests/splinkersets01/sets.c
> index 0cc1993..1061379 100644
> --- a/testsuites/sptests/splinkersets01/sets.c
> +++ b/testsuites/sptests/splinkersets01/sets.c
> @@ -21,3 +21,7 @@
>  RTEMS_LINKER_RWSET(test_rw, const int *);
>
>  RTEMS_LINKER_ROSET(test_ro, const int *);
> +
> +RTEMS_LINKER_RWSET(test_content_rw, char);
> +
> +RTEMS_LINKER_ROSET(test_content_ro, char);
> diff --git a/testsuites/sptests/splinkersets01/splinkersets01.h 
> b/testsuites/sptests/splinkersets01/splinkersets01.h
> index 5da8ec6..0339154 100644
> --- a/testsuites/sptests/splinkersets01/splinkersets01.h
> +++ b/testsuites/sptests/splinkersets01/splinkersets01.h
> @@ -29,10 +29,22 @@ RTEMS_LINKER_RWSET_DECLARE(test_rw, const int *);
>
>  RTEMS_LINKER_ROSET_DECLARE(test_ro, const int *);
>
> +RTEMS_LINKER_RWSET_DECLARE(test_content_rw, char);
> +
> +RTEMS_LINKER_ROSET_DECLARE(test_content_ro, char);
> +
>  RTEMS_LINKER_RWSET_ITEM_DECLARE(test_rw, const int *, a1);
>
>  RTEMS_LINKER_ROSET_ITEM_DECLARE(test_ro, const int *, 

Re: Internal time representations

[Gedare Bloom]

On Mon, Aug 1, 2016 at 12:47 PM, Joel Sherrill  wrote:
> On Aug 1, 2016 11:41 AM, "Gedare Bloom"  wrote:
>>
>> On Mon, Aug 1, 2016 at 1:26 AM, Sebastian Huber
>>  wrote:
>> > On 28/07/16 16:53, Gedare Bloom wrote:
>> >>
>> >> Hi Sebastian,
>> >>
>> >> The problem that I encountered was that there are two different
>> >> representations used for the watchdogs, the 34+30 compact timespec,
>> >> a.k.a. "watchdog ticks", used for absolute, and the 64-bit "score
>> >> ticks" used for relative. Since both of these are called ticks
>> >> internally, I had a bit of confusion on what to use, and which
>> >> interfaces for converting time formats into something each watchdog
>> >> uses as a timeout. Pavel suggested that switching to a single format
>> >> would help reduce confusion, and may help with variable clock ticks.
>> >
>> >
>> > I still think that the time formats for the watchdogs are the right
>> > ones.
>> > Maybe we should rename
>> >
>> > _Watchdog_Ticks_from_seconds() ->
>> > _Watchdog_Expiration_time_from_seconds()
>> >
>> > _Watchdog_Ticks_from_timespec() ->
>> > _Watchdog_Expiration_time_from_timespec()
>> >
>> > We already have a Watchdog_Control:
>> >
>> >   /** @brief This field is the expiration time point. */
>> >   uint64_t expire;
>> >
>> Yes, renaming would alleviate some of the confusion I encountered.
>
> Just to be clear. Are both the ticks and seconds watchdog sets at ticks
> resolution?
>
We have a relative and absolute watchdog. Relative is programmed in
score "ticks", and absolute is programmed in nanoseconds.

> Formerly, one was ticks and the other was seconds. Seconds granularity is
> insufficient for POSIX.
>
I don't think there exists a watchdog with seconds granularity now.

>> >>
>> >> Perhaps the FreeBSD time counters are a sufficient representation to
>> >> handle setting up variable ticks. Confusion might also be less if we
>> >> don't use the same terminology "ticks" for the two different formats.
>> >> Relative are actual "ticks" based on the configured RTEMS clock, while
>> >> absolute are ns time-based.
>> >>
>> >> Gedare
>> >>
>> >> On Thu, Jul 28, 2016 at 2:23 AM, Sebastian Huber
>> >>  wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I am not sure which problem you want to address. For the watchdogs we
>> >>> use
>> >>> currently a 64-bit integer key for relative and absolute timeouts. For
>> >>> the
>> >>> watchdog it is important that
>> >>>
>> >>> * the key comparison operations are fast,
>> >>> * the conversion from common time formats to the key are fast, and
>> >>> * there is no integer overflow within a reasonable time frame.
>> >>>
>> >>> This is all satisfied currently. It is NOT important to convert this
>> >>> key
>> >>> into a common time format, since there is no use case for this.
>> >>>
>> >>> For timekeeping we use the FreeBSD time counters (provider for
>> >>> CLOCK_REALTIME and CLOCK_MONOTONIC). They use struct bintime (aka
>> >>> Timestamp_Control) for time representation. It allows fast conversion
>> >>> to/from common time formats. Addition is also fast. In addition there
>> >>> is
>> >>> a
>> >>> sbintime_t available which can be used for some problem domains as an
>> >>> optimization.
>> >>>
>> >>> For NTP and PPS we just have to port the code from FreeBSD. It is very
>> >>> well
>> >>> integrated into the FreeBSD time counters.
>> >>>
>> >>>
>> >>> On 27/07/16 23:29, Pavel Pisa wrote:
>> 
>>  Hello Gedare,
>> 
>>  thanks much for the great summary of the discussion.
>> 
>>  On Wednesday 27 of July 2016 18:30:02 Gedare Bloom wrote:
>> >
>> > After an IRC chat this morning with Pavel, we've decided to query
>> > everyone about thoughts on unifying the internal score
>> > representations
>> > for time into a single format. This discussion comes from the work
>> > I've done with nanosleep, which now uses both the relative and
>> > absolute watchdogs that have two different representations of
>> > time--relative uses the score "ticks", and absolute uses a 64-bit
>> > compacted version of timespec with seconds in the upper 32-bits and
>> > ns
>> > in the lower 32. The proposed format is a count of nanoseconds in
>> > 64-bits, or ns64.
>> 
>>  minor correction, copact time works in 34+30 bit format so it
>>  has no 2038 problem (final year is about 2514 for unsigned
>>  and 2242 for signed representation)
>> 
>> 
>> 
>> 
>>  https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/watchdogimpl.h#n295
>> 
>>  On the other hand, conversion of the timespec seconds to this format
>>  requires some shifts and masking. Conversion of 32-bit + 32-bit
>>  timespec
>>  to linear ns64 requires one 32*32->64 bit multiply and 64-bit
>>  addition.
>>  This has higher cost but on the modern CPUs it is not so big
>>  

Re: Internal time representations

[Joel Sherrill]

On Aug 1, 2016 11:41 AM, "Gedare Bloom"  wrote:
>
> On Mon, Aug 1, 2016 at 1:26 AM, Sebastian Huber
>  wrote:
> > On 28/07/16 16:53, Gedare Bloom wrote:
> >>
> >> Hi Sebastian,
> >>
> >> The problem that I encountered was that there are two different
> >> representations used for the watchdogs, the 34+30 compact timespec,
> >> a.k.a. "watchdog ticks", used for absolute, and the 64-bit "score
> >> ticks" used for relative. Since both of these are called ticks
> >> internally, I had a bit of confusion on what to use, and which
> >> interfaces for converting time formats into something each watchdog
> >> uses as a timeout. Pavel suggested that switching to a single format
> >> would help reduce confusion, and may help with variable clock ticks.
> >
> >
> > I still think that the time formats for the watchdogs are the right
ones.
> > Maybe we should rename
> >
> > _Watchdog_Ticks_from_seconds() ->
_Watchdog_Expiration_time_from_seconds()
> >
> > _Watchdog_Ticks_from_timespec() ->
_Watchdog_Expiration_time_from_timespec()
> >
> > We already have a Watchdog_Control:
> >
> >   /** @brief This field is the expiration time point. */
> >   uint64_t expire;
> >
> Yes, renaming would alleviate some of the confusion I encountered.

Just to be clear. Are both the ticks and seconds watchdog sets at ticks
resolution?

Formerly, one was ticks and the other was seconds. Seconds granularity is
insufficient for POSIX.

> >>
> >> Perhaps the FreeBSD time counters are a sufficient representation to
> >> handle setting up variable ticks. Confusion might also be less if we
> >> don't use the same terminology "ticks" for the two different formats.
> >> Relative are actual "ticks" based on the configured RTEMS clock, while
> >> absolute are ns time-based.
> >>
> >> Gedare
> >>
> >> On Thu, Jul 28, 2016 at 2:23 AM, Sebastian Huber
> >>  wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am not sure which problem you want to address. For the watchdogs we
use
> >>> currently a 64-bit integer key for relative and absolute timeouts. For
> >>> the
> >>> watchdog it is important that
> >>>
> >>> * the key comparison operations are fast,
> >>> * the conversion from common time formats to the key are fast, and
> >>> * there is no integer overflow within a reasonable time frame.
> >>>
> >>> This is all satisfied currently. It is NOT important to convert this
key
> >>> into a common time format, since there is no use case for this.
> >>>
> >>> For timekeeping we use the FreeBSD time counters (provider for
> >>> CLOCK_REALTIME and CLOCK_MONOTONIC). They use struct bintime (aka
> >>> Timestamp_Control) for time representation. It allows fast conversion
> >>> to/from common time formats. Addition is also fast. In addition there
is
> >>> a
> >>> sbintime_t available which can be used for some problem domains as an
> >>> optimization.
> >>>
> >>> For NTP and PPS we just have to port the code from FreeBSD. It is very
> >>> well
> >>> integrated into the FreeBSD time counters.
> >>>
> >>>
> >>> On 27/07/16 23:29, Pavel Pisa wrote:
> 
>  Hello Gedare,
> 
>  thanks much for the great summary of the discussion.
> 
>  On Wednesday 27 of July 2016 18:30:02 Gedare Bloom wrote:
> >
> > After an IRC chat this morning with Pavel, we've decided to query
> > everyone about thoughts on unifying the internal score
representations
> > for time into a single format. This discussion comes from the work
> > I've done with nanosleep, which now uses both the relative and
> > absolute watchdogs that have two different representations of
> > time--relative uses the score "ticks", and absolute uses a 64-bit
> > compacted version of timespec with seconds in the upper 32-bits and
ns
> > in the lower 32. The proposed format is a count of nanoseconds in
> > 64-bits, or ns64.
> 
>  minor correction, copact time works in 34+30 bit format so it
>  has no 2038 problem (final year is about 2514 for unsigned
>  and 2242 for signed representation)
> 
> 
> 
> 
https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/watchdogimpl.h#n295
> 
>  On the other hand, conversion of the timespec seconds to this format
>  requires some shifts and masking. Conversion of 32-bit + 32-bit
timespec
>  to linear ns64 requires one 32*32->64 bit multiply and 64-bit
addition.
>  This has higher cost but on the modern CPUs it is not so big
difference.
>  It simplifies computation of differences, adding of relative time
>  to actual time etc. It can be significant overhead for
16-architectures
>  (bare h8, even h8s) and blocker for 8-bit ones (AVR). But they are
>  not so common today.
> 
>  Conversion to timespec is significant problem.
> 
>  If the 34+30 bit compact timespec advantage of the faster conversion
>  prevails for PER_CPU_WATCHDOG_ABSOLUTE then I would 

Re: libbsd: How to add an option for switching off IPv6 (or other BSD Kernel configurations)

[Gedare Bloom]

On Mon, Aug 1, 2016 at 10:04 AM, Christian Mauderer
 wrote:
> Hello,
>
> we have a special use case where we want to use the new network stack
> but without the IPv6 support. I could need some advice how this could be
> integrated into the waf build system. If we find a good solution, this
> could also be an example for other BSD Kernel options.
>
>
> I found multiple places where IPv6 is enabled in libbsd:
>
> If I remove the INET6 option out of the FreeBSD kernel configuration on
> a FreeBSD system, this has the effect, that the "opt_inet6.h" is
> generated as an empty file instead of with a single define "#define
> INET6 1". In the rtems-libbsd the configuration header is located at
> rtemsbsd/include/rtems/bsd/local/opt_inet6.h. It has a fixed content
> with the define set. This would be the first place where the support
> would have to be disabled.
>
> Beneath that, some user space tools have a special option to enable IPv6
> which is currently set in libbsd.py. One such example is tcpdump with a
> compiler flag '-DINET6' set. As far as I could tell, the kernel and
> every application that is included in libbsd currently uses the INET6
> macro. But I think this is more of a convention than a general rule.
>
>
> So I think we would roughly need the following:
>
> If i configure libbsd using
>
>waf configure --disable-ipv6
>
> the build system would either have to regenerate opt_inet6.h or use an
> alternative version of it. Further I would need the ability to set
> compiler flags in libbsd.py depending on this configure option.
>
>
> Are there any better ideas how to implement such an option?
>
> I'm quite inexperienced on how to use waf, so I would need some guidance
> how this could be implemented. Are there any hints how I could start
> implementing such an option? Some examples or similar code?
>
The "Waf Book" is handy for learning how to hack on waf. Sounds like
you should add your option in the top-level wscript options(), then
parse it in libbsd_waf to determine whether or not to use ipv6. waf
does not modify the source files, and these includes appear to remain
in the source, so it might be easier to generate an empty header file
and always provide the define through the command line instead, by
adding e.g. -DINET6 to cflags by default and removing it in case the
option is used.

> Kind regards
>
> Christian Mauderer
> --
> 
> embedded brains GmbH
> 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: Internal time representations

[Gedare Bloom]

On Mon, Aug 1, 2016 at 1:26 AM, Sebastian Huber
 wrote:
> On 28/07/16 16:53, Gedare Bloom wrote:
>>
>> Hi Sebastian,
>>
>> The problem that I encountered was that there are two different
>> representations used for the watchdogs, the 34+30 compact timespec,
>> a.k.a. "watchdog ticks", used for absolute, and the 64-bit "score
>> ticks" used for relative. Since both of these are called ticks
>> internally, I had a bit of confusion on what to use, and which
>> interfaces for converting time formats into something each watchdog
>> uses as a timeout. Pavel suggested that switching to a single format
>> would help reduce confusion, and may help with variable clock ticks.
>
>
> I still think that the time formats for the watchdogs are the right ones.
> Maybe we should rename
>
> _Watchdog_Ticks_from_seconds() -> _Watchdog_Expiration_time_from_seconds()
>
> _Watchdog_Ticks_from_timespec() -> _Watchdog_Expiration_time_from_timespec()
>
> We already have a Watchdog_Control:
>
>   /** @brief This field is the expiration time point. */
>   uint64_t expire;
>
Yes, renaming would alleviate some of the confusion I encountered.

>>
>> Perhaps the FreeBSD time counters are a sufficient representation to
>> handle setting up variable ticks. Confusion might also be less if we
>> don't use the same terminology "ticks" for the two different formats.
>> Relative are actual "ticks" based on the configured RTEMS clock, while
>> absolute are ns time-based.
>>
>> Gedare
>>
>> On Thu, Jul 28, 2016 at 2:23 AM, Sebastian Huber
>>  wrote:
>>>
>>> Hello,
>>>
>>> I am not sure which problem you want to address. For the watchdogs we use
>>> currently a 64-bit integer key for relative and absolute timeouts. For
>>> the
>>> watchdog it is important that
>>>
>>> * the key comparison operations are fast,
>>> * the conversion from common time formats to the key are fast, and
>>> * there is no integer overflow within a reasonable time frame.
>>>
>>> This is all satisfied currently. It is NOT important to convert this key
>>> into a common time format, since there is no use case for this.
>>>
>>> For timekeeping we use the FreeBSD time counters (provider for
>>> CLOCK_REALTIME and CLOCK_MONOTONIC). They use struct bintime (aka
>>> Timestamp_Control) for time representation. It allows fast conversion
>>> to/from common time formats. Addition is also fast. In addition there is
>>> a
>>> sbintime_t available which can be used for some problem domains as an
>>> optimization.
>>>
>>> For NTP and PPS we just have to port the code from FreeBSD. It is very
>>> well
>>> integrated into the FreeBSD time counters.
>>>
>>>
>>> On 27/07/16 23:29, Pavel Pisa wrote:

 Hello Gedare,

 thanks much for the great summary of the discussion.

 On Wednesday 27 of July 2016 18:30:02 Gedare Bloom wrote:
>
> After an IRC chat this morning with Pavel, we've decided to query
> everyone about thoughts on unifying the internal score representations
> for time into a single format. This discussion comes from the work
> I've done with nanosleep, which now uses both the relative and
> absolute watchdogs that have two different representations of
> time--relative uses the score "ticks", and absolute uses a 64-bit
> compacted version of timespec with seconds in the upper 32-bits and ns
> in the lower 32. The proposed format is a count of nanoseconds in
> 64-bits, or ns64.

 minor correction, copact time works in 34+30 bit format so it
 has no 2038 problem (final year is about 2514 for unsigned
 and 2242 for signed representation)



 https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/score/watchdogimpl.h#n295

 On the other hand, conversion of the timespec seconds to this format
 requires some shifts and masking. Conversion of 32-bit + 32-bit timespec
 to linear ns64 requires one 32*32->64 bit multiply and 64-bit addition.
 This has higher cost but on the modern CPUs it is not so big difference.
 It simplifies computation of differences, adding of relative time
 to actual time etc. It can be significant overhead for 16-architectures
 (bare h8, even h8s) and blocker for 8-bit ones (AVR). But they are
 not so common today.

 Conversion to timespec is significant problem.

 If the 34+30 bit compact timespec advantage of the faster conversion
 prevails for PER_CPU_WATCHDOG_ABSOLUTE then I would vote to change
 PER_CPU_WATCHDOG_RELATIVE to the same format.

 This simplifies clock_nanosleep logic and generally makes
 code more readable and lowers space for mistakes.

 If we consider 64-bit linear format then we should think about
 conversion to 64+32 bit timespec to overcome 2038 year problem.
 This makes multiplication 64*32->64 which is more complex.
 The most of the upper 32-bits would be discarded in ns64 format.

Re: nanosleep.c remarks

[Gedare Bloom]

On Mon, Aug 1, 2016 at 1:18 AM, Sebastian Huber
 wrote:
> Hello Pavel,
>
> On 30/07/16 19:40, Pavel Pisa wrote:
[...]
>>
>> Then the time stuff.
>>
>> nanosleep_helper() does not distinguish between CLOCK_REALTIME
>> and CLOCK_MONOTONIC when it computes remaining time (rmtp).
>> But the intention of this field is that if you call again
>> nanoslepp/clock_nanosleep with same parameters and rtmp
>> used as time to wait (in case of TIMER_ABSTIME is not set) then
>> the final wake time should be +/- same as if there has been
>> no interruption. If we consider POSIX required behavior/difference
>> between CLOCK_REALTIME and CLOCK_MONOTONIC and possibility
>> to adjust realtime clock then it would not work as expected.
>>
It would be good to add some test cases calling clock_settime() and
delivering signals while a thread nanosleep()s. I don't know that we
have those cases tested yet.

The rmtp is calculated only in consideration of elapsed score ticks.
Maybe it would be better to call the clock functions using the
clock_id.

>> By the way, _Timespec_From_ticks works expected way only for
>> first 1.19 hour after boot if used for absolute time (not used
>> that way in nanosleep).
>> For relative time, If the nanosleep is used for longer delay
>> than 4294 seconds then rtmp the result is complete garbage
>>
>> void _Timespec_From_ticks(
>>uint32_t ticks,
>>struct timespec *time
>> )
>> {
>>uint32_tusecs;
>>
>>usecs = ticks * rtems_configuration_get_microseconds_per_tick();
>>
>>time->tv_sec  = usecs / TOD_MICROSECONDS_PER_SECOND;
>>time->tv_nsec = (usecs % TOD_MICROSECONDS_PER_SECOND) *
>>  TOD_NANOSECONDS_PER_MICROSECOND;
>> }
>
>
> This function is probably superfluous now due to the timekeeping via the
> FreeBSD timecounters. We tried to keep the existing behaviour during the
> introduction of the FreeBSD timecounters. However, some parts of the POSIX
> implementation in RTEMS are not according to POSIX. This must be fixed step
> by step (its not on my current TODO list).
>
I have a small budget remaining for POSIX work. However, I am focusing
on putting together some mman interfaces. If there is a
straightforward coding task for switching away from this
_Timespec_From_ticks I might be able to get it done, but right now I
don't know what it takes.

>>
>> If we consider that crystal oscillator is not perfect then
>> value of rtems_configuration_get_microseconds_per_tick has to be
>> tuned runtime but problem is that to not shift time by change
>> of scale if it is not changed at ticks == 0, it means
>> to use y = a * x + b there and at each time a from a1 to a2
>> is changed change b such that a2 * x + b2 = a1 * x + b1
>> to ensure tick to usec monotonicity for conversion of
>> monotonic time from ticks to timespec.
>>
>> Another problem is that for higher frequency tick or ting time
>> source is the value rtems_configuration_get_microseconds_per_tick
>> is small so relative precision is insufficient.
>>
>> For clock_nanosleep we get to _TOD_Absolute_timeout_to_ticks
>> which calls for CLOCK_MONOTONIC in
>>
>> I have mostly lost track in the call chain there.
>> bintime2timespec is provided by NewLib as part of BSD time
>> framework introduction
>>
>> https://devel.rtems.org/ticket/2271
>> https://www.daemon-systems.org/man/timecounter.9.html
>>
You may also like http://phk.freebsd.dk/pubs/timecounter.pdf

>> Structure struct timecounter seems to be almost sane from
>> the documentation. But u_int64_t tc_frequency without
>> shifting right requires unnecessarily wide multiplication
>> or even worse division and relative resolution can be
>> low for some cases.
>
>
> The tc_frequency is not used in the hot paths, please have a look at
> _Timecounter_Windup().
>
>>
>> I am trying to study the code
>>
>> static inline void _TOD_Get_zero_based_uptime_as_timespec(
>>struct timespec *time
>> )
>> {
>>_Timecounter_Nanouptime( time );
>>--time->tv_sec;
>> }
>>
>> where seconds decrement seems suspicious to me.
>
>
> For FreeBSD compatibility the uptime starts with one second. For RTEMS
> compatibility the uptime starts at zero.
>
Yeah, we had this discussion before. Possibly it makes sense to add a
brief comment there for clarity in the code.

>>
>> There seems to be data structures for precise time computation
>> and synchronization (sys/timeffc.h, etc.) but I  am not sure
>> if some of them are used.
>
>
> The use of ntp_update_second() is currently disabled. This code could be
> easily ported from FreeBSD to RTEMS if someone is interested.
>
>>
>> General rule for POSIX systems is that CLOCK_MONOTONIC and
>> CLOCK_REALTIME scaling is done in sync only the base and
>> step corrections are applied to CLOCK_REALTIME only.
>> But there seem to be two relatively independed paths
>> in the actual sources.
>>
The CLOCK_MONOTONIC uses the uptime, and the CLOCK_REALTIME uses
uptime + boottime corrections are made by 

libbsd: How to add an option for switching off IPv6 (or other BSD Kernel configurations)

[Christian Mauderer]

Hello,

we have a special use case where we want to use the new network stack
but without the IPv6 support. I could need some advice how this could be
integrated into the waf build system. If we find a good solution, this
could also be an example for other BSD Kernel options.


I found multiple places where IPv6 is enabled in libbsd:

If I remove the INET6 option out of the FreeBSD kernel configuration on
a FreeBSD system, this has the effect, that the "opt_inet6.h" is
generated as an empty file instead of with a single define "#define
INET6 1". In the rtems-libbsd the configuration header is located at
rtemsbsd/include/rtems/bsd/local/opt_inet6.h. It has a fixed content
with the define set. This would be the first place where the support
would have to be disabled.

Beneath that, some user space tools have a special option to enable IPv6
which is currently set in libbsd.py. One such example is tcpdump with a
compiler flag '-DINET6' set. As far as I could tell, the kernel and
every application that is included in libbsd currently uses the INET6
macro. But I think this is more of a convention than a general rule.


So I think we would roughly need the following:

If i configure libbsd using

   waf configure --disable-ipv6

the build system would either have to regenerate opt_inet6.h or use an
alternative version of it. Further I would need the ability to set
compiler flags in libbsd.py depending on this configure option.


Are there any better ideas how to implement such an option?

I'm quite inexperienced on how to use waf, so I would need some guidance
how this could be implemented. Are there any hints how I could start
implementing such an option? Some examples or similar code?

Kind regards

Christian Mauderer
-- 

embedded brains GmbH
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

mx6ulevk BSP was: Re: [PATCH] arm: mx6ulevk: Initial BSP support for i.MX 6UltraLite EVK board.

[Thomas Doerfler]

Hi,

just out of curiosity (and because I might need a i.MX6 BSP for an
upcoming project):

What is the current state of the BSP? What are the plans for the near
future?

wkr,

Thomas.


Am 14.04.2016 um 11:49 schrieb Peng Fan:
> Initial BSP support for i.MX 6UltraLite EVK board.
> Add uart driver
> Add gpt driver to service tick function
> 
> The i.MX 6UltraLite is a high performance, ultra-efficient processor
> family featuring an advanced implementation of a single ARM® Cortex®-A7
> core, which operates at speeds up to 528 MHz. The i.MX 6UltraLite
> applications processor includes an integrated power management module
> that reduces the complexity of external power supply and simplifies
> power sequencing.
> 
> Now, clock management module and pinmux module not added,
> so relies the setting in U-Boot.
> ---
>  c/src/lib/libbsp/arm/acinclude.m4  |   2 +
>  c/src/lib/libbsp/arm/mx6ulevk/Makefile.am  | 139 +
>  c/src/lib/libbsp/arm/mx6ulevk/README   |  28 
>  c/src/lib/libbsp/arm/mx6ulevk/bsp_specs|  13 ++
>  c/src/lib/libbsp/arm/mx6ulevk/configure.ac |  34 +
>  .../libbsp/arm/mx6ulevk/console/console-config.c   |  82 +++
>  c/src/lib/libbsp/arm/mx6ulevk/console/imx-uart.c   | 131 
>  c/src/lib/libbsp/arm/mx6ulevk/gpt.c| 164 
> +
>  c/src/lib/libbsp/arm/mx6ulevk/include/bsp.h| 121 +++
>  c/src/lib/libbsp/arm/mx6ulevk/include/imx6-gpt.h   |  48 ++
>  c/src/lib/libbsp/arm/mx6ulevk/include/imx6-uart.h  |  60 
>  c/src/lib/libbsp/arm/mx6ulevk/include/irq.h|  38 +
>  c/src/lib/libbsp/arm/mx6ulevk/include/tm27.h   |  24 +++
>  .../libbsp/arm/mx6ulevk/make/custom/mx6ulevk.cfg   |   9 ++
>  c/src/lib/libbsp/arm/mx6ulevk/preinstall.am| 151 +++
>  c/src/lib/libbsp/arm/mx6ulevk/startup/bspreset.c   |  24 +++
>  c/src/lib/libbsp/arm/mx6ulevk/startup/bspstart.c   |  25 
>  .../libbsp/arm/mx6ulevk/startup/bspstarthooks.c|  70 +
>  .../libbsp/arm/mx6ulevk/startup/linkcmds.mx6ulevk  |  48 ++
>  19 files changed, 1211 insertions(+)
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/Makefile.am
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/README
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/bsp_specs
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/configure.ac
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/console/console-config.c
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/console/imx-uart.c
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/gpt.c
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/include/bsp.h
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/include/imx6-gpt.h
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/include/imx6-uart.h
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/include/irq.h
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/include/tm27.h
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/make/custom/mx6ulevk.cfg
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/preinstall.am
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/startup/bspreset.c
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/startup/bspstart.c
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/startup/bspstarthooks.c
>  create mode 100644 c/src/lib/libbsp/arm/mx6ulevk/startup/linkcmds.mx6ulevk
> 
> diff --git a/c/src/lib/libbsp/arm/acinclude.m4 
> b/c/src/lib/libbsp/arm/acinclude.m4
> index f5ca105..c15dc82 100644
> --- a/c/src/lib/libbsp/arm/acinclude.m4
> +++ b/c/src/lib/libbsp/arm/acinclude.m4
> @@ -26,6 +26,8 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR],
>  AC_CONFIG_SUBDIRS([lpc24xx]);;
>lpc32xx )
>  AC_CONFIG_SUBDIRS([lpc32xx]);;
> +  mx6ulevk )
> +AC_CONFIG_SUBDIRS([mx6ulevk]);;
>raspberrypi )
>  AC_CONFIG_SUBDIRS([raspberrypi]);;
>realview-pbx-a9 )
> diff --git a/c/src/lib/libbsp/arm/mx6ulevk/Makefile.am 
> b/c/src/lib/libbsp/arm/mx6ulevk/Makefile.am
> new file mode 100644
> index 000..517b524
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/mx6ulevk/Makefile.am
> @@ -0,0 +1,139 @@
> +##
> +#
> +# @file
> +#
> +# @brief Makefile of libBSP for the i.MX 6UltraLite EVK platform (Cortex-A7).
> +#
> +
> +ACLOCAL_AMFLAGS = -I ../../../../aclocal
> +
> +include $(top_srcdir)/../../../../automake/compile.am
> +
> +include_bspdir = $(includedir)/bsp
> +include_libcpudir = $(includedir)/libcpu
> +
> +dist_project_lib_DATA = bsp_specs
> +
> +###
> +#  Header
>  #
> +###
> +
> +include_HEADERS = include/bsp.h
> +include_HEADERS += ../../shared/include/tm27.h
> +
> +nodist_include_HEADERS = ../../shared/include/coverhd.h \
> + include/bspopts.h
> +
> +nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h

Corrected a typo in RSB docs

[Sambeet Panigrahi]

From 1ddfd35822be6c99cee644ed62a716f3cb371ddb Mon Sep 17 00:00:00 2001
From: Sambeet Panigrahi 
Date: Mon, 1 Aug 2016 16:43:26 +0530
Subject: [PATCH] Corrected another typo in RSB Documentation

---
 doc/source-builder.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/source-builder.txt b/doc/source-builder.txt
index 967ca1c..b07b129 100644
--- a/doc/source-builder.txt
+++ b/doc/source-builder.txt
@@ -1078,7 +1078,7 @@ A package requires 3 files to be created:
 
 . The second file is an RTEMS version specific configuration file and it
   includes the RSB RTEMS BSP support. These configuration files reside in the
-  +rtems/config+ tree again under the FreeBSP port's path name. For example the
+  +rtems/config+ tree again under the FreeBSD port's path name. For example the
   NTP package is found in the +net+ directory of the FreeBSD ports tree so the
   NTP configuration path is +$$rtems/config/net/ntp-4.2.6p5-1.cfg$$+ for that
   specific version. The configuration file name typically provides version
-- 
1.9.1

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

[PATCH v2] linker set: Allow adding any variable into content

[Christian Mauderer]

From: Christian Mauderer 

The newly created macro allows to add any kind of variable into the
content of a linker set. This allows (for example) saving an execution
state of a function using the following method:

- put a group of different variables into one linker set
- save the memory area containing the group of variables before the
  execution of a function
- restore the memory area after the function has been executed
---
 cpukit/score/include/rtems/linkersets.h|  8 
 testsuites/sptests/splinkersets01/init.c   | 24 ++
 testsuites/sptests/splinkersets01/items.c  |  8 
 testsuites/sptests/splinkersets01/sets.c   |  4 
 testsuites/sptests/splinkersets01/splinkersets01.h | 12 +++
 5 files changed, 56 insertions(+)

diff --git a/cpukit/score/include/rtems/linkersets.h 
b/cpukit/score/include/rtems/linkersets.h
index e40be66..47c210d 100644
--- a/cpukit/score/include/rtems/linkersets.h
+++ b/cpukit/score/include/rtems/linkersets.h
@@ -57,6 +57,10 @@ extern "C" {
   type volatile const _Linker_set_##set##_##item \
   RTEMS_SECTION( ".rtemsroset." #set ".content.1" ) RTEMS_USED
 
+#define RTEMS_LINKER_ROSET_CONTENT( set, decl ) \
+  decl \
+  RTEMS_SECTION( ".rtemsroset." #set ".content" )
+
 #define RTEMS_LINKER_RWSET_DECLARE( set, type ) \
   extern type volatile RTEMS_LINKER_SET_BEGIN( set )[0]; \
   extern type volatile RTEMS_LINKER_SET_END( set )[0]
@@ -89,6 +93,10 @@ extern "C" {
   type volatile _Linker_set_##set##_##item \
   RTEMS_SECTION( ".rtemsrwset." #set ".content.1" ) RTEMS_USED
 
+#define RTEMS_LINKER_RWSET_CONTENT( set, decl ) \
+  decl \
+  RTEMS_SECTION( ".rtemsrwset." #set ".content" )
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/testsuites/sptests/splinkersets01/init.c 
b/testsuites/sptests/splinkersets01/init.c
index 3d35a4e..28c6384 100644
--- a/testsuites/sptests/splinkersets01/init.c
+++ b/testsuites/sptests/splinkersets01/init.c
@@ -130,11 +130,35 @@ static void test(void)
   rtems_test_assert( == sb[2]);
 }
 
+static void test_content(void)
+{
+  void volatile *b_rw = RTEMS_LINKER_SET_BEGIN(test_content_rw);
+  void volatile *e_rw = RTEMS_LINKER_SET_END(test_content_rw);
+
+  void volatile const *b_ro = RTEMS_LINKER_SET_BEGIN(test_content_ro);
+  void volatile const *e_ro = RTEMS_LINKER_SET_END(test_content_ro);
+
+  rtems_test_assert(_rw_1 >= b_rw);
+  rtems_test_assert(_rw_2 >= b_rw);
+  rtems_test_assert(_rw_3 >= b_rw);
+  rtems_test_assert(_rw_1 <= e_rw);
+  rtems_test_assert(_rw_2 <= e_rw);
+  rtems_test_assert(_rw_3 <= e_rw);
+
+  rtems_test_assert(_ro_1 >= b_ro);
+  rtems_test_assert(_ro_2 >= b_ro);
+  rtems_test_assert(_ro_3 >= b_ro);
+  rtems_test_assert(_ro_1 <= e_ro);
+  rtems_test_assert(_ro_2 <= e_ro);
+  rtems_test_assert(_ro_3 <= e_ro);
+}
+
 static void Init(rtems_task_argument arg)
 {
   TEST_BEGIN();
 
   test();
+  test_content();
 
   TEST_END();
   rtems_test_exit(0);
diff --git a/testsuites/sptests/splinkersets01/items.c 
b/testsuites/sptests/splinkersets01/items.c
index 7ca6f53..fde102a 100644
--- a/testsuites/sptests/splinkersets01/items.c
+++ b/testsuites/sptests/splinkersets01/items.c
@@ -21,3 +21,11 @@
 RTEMS_LINKER_RWSET_ITEM_ORDERED(test_rw, const int *, a1, 1) = [1];
 
 RTEMS_LINKER_ROSET_ITEM_ORDERED(test_ro, const int *, ca2, OC) = [2];
+
+int content_rw_1;
+char content_rw_2;
+char content_rw_3;
+
+const int content_ro_1;
+const char content_ro_2;
+const char content_ro_3;
diff --git a/testsuites/sptests/splinkersets01/sets.c 
b/testsuites/sptests/splinkersets01/sets.c
index 0cc1993..1061379 100644
--- a/testsuites/sptests/splinkersets01/sets.c
+++ b/testsuites/sptests/splinkersets01/sets.c
@@ -21,3 +21,7 @@
 RTEMS_LINKER_RWSET(test_rw, const int *);
 
 RTEMS_LINKER_ROSET(test_ro, const int *);
+
+RTEMS_LINKER_RWSET(test_content_rw, char);
+
+RTEMS_LINKER_ROSET(test_content_ro, char);
diff --git a/testsuites/sptests/splinkersets01/splinkersets01.h 
b/testsuites/sptests/splinkersets01/splinkersets01.h
index 5da8ec6..0339154 100644
--- a/testsuites/sptests/splinkersets01/splinkersets01.h
+++ b/testsuites/sptests/splinkersets01/splinkersets01.h
@@ -29,10 +29,22 @@ RTEMS_LINKER_RWSET_DECLARE(test_rw, const int *);
 
 RTEMS_LINKER_ROSET_DECLARE(test_ro, const int *);
 
+RTEMS_LINKER_RWSET_DECLARE(test_content_rw, char);
+
+RTEMS_LINKER_ROSET_DECLARE(test_content_ro, char);
+
 RTEMS_LINKER_RWSET_ITEM_DECLARE(test_rw, const int *, a1);
 
 RTEMS_LINKER_ROSET_ITEM_DECLARE(test_ro, const int *, ca2);
 
+RTEMS_LINKER_RWSET_CONTENT(test_content_rw, extern int content_rw_1);
+RTEMS_LINKER_RWSET_CONTENT(test_content_rw, extern char content_rw_2);
+RTEMS_LINKER_RWSET_CONTENT(test_content_rw, extern char content_rw_3);
+
+RTEMS_LINKER_ROSET_CONTENT(test_content_ro, extern const int content_ro_1);
+RTEMS_LINKER_ROSET_CONTENT(test_content_ro, extern const char content_ro_2);
+RTEMS_LINKER_ROSET_CONTENT(test_content_ro, extern 

[PATCH] linker set: Allow adding any variable into content

[Christian Mauderer]

From: Christian Mauderer 

The newly created macro allows to add any kind of variable into the
content of a linker set. This allows (for example) saving an execution
state of a function using the following method:

- put a group of different variables into one linker set
- save the memory area containing the group of variables before the
  execution of a function
- restore the memory area after the function has been executed
---
 cpukit/score/include/rtems/linkersets.h|  8 
 testsuites/sptests/splinkersets01/init.c   | 22 ++
 testsuites/sptests/splinkersets01/items.c  |  8 
 testsuites/sptests/splinkersets01/sets.c   |  4 
 testsuites/sptests/splinkersets01/splinkersets01.h | 12 
 5 files changed, 54 insertions(+)

diff --git a/cpukit/score/include/rtems/linkersets.h 
b/cpukit/score/include/rtems/linkersets.h
index e40be66..5ab8a75 100644
--- a/cpukit/score/include/rtems/linkersets.h
+++ b/cpukit/score/include/rtems/linkersets.h
@@ -57,6 +57,10 @@ extern "C" {
   type volatile const _Linker_set_##set##_##item \
   RTEMS_SECTION( ".rtemsroset." #set ".content.1" ) RTEMS_USED
 
+#define RTEMS_LINKER_ROSET_CONTENT( set, decl ) \
+  decl \
+  RTEMS_SECTION( ".rtemsroset." #set ".content.2" )
+
 #define RTEMS_LINKER_RWSET_DECLARE( set, type ) \
   extern type volatile RTEMS_LINKER_SET_BEGIN( set )[0]; \
   extern type volatile RTEMS_LINKER_SET_END( set )[0]
@@ -89,6 +93,10 @@ extern "C" {
   type volatile _Linker_set_##set##_##item \
   RTEMS_SECTION( ".rtemsrwset." #set ".content.1" ) RTEMS_USED
 
+#define RTEMS_LINKER_RWSET_CONTENT( set, decl ) \
+  decl \
+  RTEMS_SECTION( ".rtemsrwset." #set ".content.2" )
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/testsuites/sptests/splinkersets01/init.c 
b/testsuites/sptests/splinkersets01/init.c
index 3d35a4e..b1f233d 100644
--- a/testsuites/sptests/splinkersets01/init.c
+++ b/testsuites/sptests/splinkersets01/init.c
@@ -130,11 +130,33 @@ static void test(void)
   rtems_test_assert( == sb[2]);
 }
 
+static void test_content(void)
+{
+  char volatile *b_rw = RTEMS_LINKER_SET_BEGIN(test_content_rw);
+  char volatile *e_rw = RTEMS_LINKER_SET_END(test_content_rw);
+
+  char volatile const *b_ro = RTEMS_LINKER_SET_BEGIN(test_content_ro);
+  char volatile const *e_ro = RTEMS_LINKER_SET_END(test_content_ro);
+
+  rtems_test_assert(_rw_1 == (void *)b_rw);
+  rtems_test_assert(_rw_2 == b_rw + sizeof(content_rw_1));
+  rtems_test_assert(_rw_3 == b_rw + sizeof(content_rw_1) +
+  sizeof(content_rw_2));
+  rtems_test_assert(_rw_3 <= e_rw);
+
+  rtems_test_assert(_ro_1 == (void *)b_ro);
+  rtems_test_assert(_ro_2 == b_ro + sizeof(content_ro_1));
+  rtems_test_assert(_ro_3 == b_ro + sizeof(content_ro_1) +
+  sizeof(content_ro_2));
+  rtems_test_assert(_ro_3 <= e_ro);
+}
+
 static void Init(rtems_task_argument arg)
 {
   TEST_BEGIN();
 
   test();
+  test_content();
 
   TEST_END();
   rtems_test_exit(0);
diff --git a/testsuites/sptests/splinkersets01/items.c 
b/testsuites/sptests/splinkersets01/items.c
index 7ca6f53..fde102a 100644
--- a/testsuites/sptests/splinkersets01/items.c
+++ b/testsuites/sptests/splinkersets01/items.c
@@ -21,3 +21,11 @@
 RTEMS_LINKER_RWSET_ITEM_ORDERED(test_rw, const int *, a1, 1) = [1];
 
 RTEMS_LINKER_ROSET_ITEM_ORDERED(test_ro, const int *, ca2, OC) = [2];
+
+int content_rw_1;
+char content_rw_2;
+char content_rw_3;
+
+const int content_ro_1;
+const char content_ro_2;
+const char content_ro_3;
diff --git a/testsuites/sptests/splinkersets01/sets.c 
b/testsuites/sptests/splinkersets01/sets.c
index 0cc1993..1061379 100644
--- a/testsuites/sptests/splinkersets01/sets.c
+++ b/testsuites/sptests/splinkersets01/sets.c
@@ -21,3 +21,7 @@
 RTEMS_LINKER_RWSET(test_rw, const int *);
 
 RTEMS_LINKER_ROSET(test_ro, const int *);
+
+RTEMS_LINKER_RWSET(test_content_rw, char);
+
+RTEMS_LINKER_ROSET(test_content_ro, char);
diff --git a/testsuites/sptests/splinkersets01/splinkersets01.h 
b/testsuites/sptests/splinkersets01/splinkersets01.h
index 5da8ec6..0339154 100644
--- a/testsuites/sptests/splinkersets01/splinkersets01.h
+++ b/testsuites/sptests/splinkersets01/splinkersets01.h
@@ -29,10 +29,22 @@ RTEMS_LINKER_RWSET_DECLARE(test_rw, const int *);
 
 RTEMS_LINKER_ROSET_DECLARE(test_ro, const int *);
 
+RTEMS_LINKER_RWSET_DECLARE(test_content_rw, char);
+
+RTEMS_LINKER_ROSET_DECLARE(test_content_ro, char);
+
 RTEMS_LINKER_RWSET_ITEM_DECLARE(test_rw, const int *, a1);
 
 RTEMS_LINKER_ROSET_ITEM_DECLARE(test_ro, const int *, ca2);
 
+RTEMS_LINKER_RWSET_CONTENT(test_content_rw, extern int content_rw_1);
+RTEMS_LINKER_RWSET_CONTENT(test_content_rw, extern char content_rw_2);
+RTEMS_LINKER_RWSET_CONTENT(test_content_rw, extern char content_rw_3);
+
+RTEMS_LINKER_ROSET_CONTENT(test_content_ro, extern const int content_ro_1);
+RTEMS_LINKER_ROSET_CONTENT(test_content_ro, extern const char content_ro_2);

Corrected a typo rtems Source Builder Documentation

[Sambeet Panigrahi]

Is this patch in the right format?
From 610e2a1fabc0a5ea70cbb23bba8dc576e9b03b22 Mon Sep 17 00:00:00 2001
From: Sambeet Panigrahi 
Date: Mon, 1 Aug 2016 13:55:57 +0530
Subject: [PATCH] Corrected a Typo

---
 doc/source-builder.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/source-builder.txt b/doc/source-builder.txt
index 43bcf77..967ca1c 100644
--- a/doc/source-builder.txt
+++ b/doc/source-builder.txt
@@ -681,7 +681,7 @@ Project Sets
 
 The RTEMS Source Builder supports project configurations. Project
 configurations can be public or private and can be contained in the RTEMS
-Source Builder project if suitable, other projects they use the RTEM Source
+Source Builder project if suitable, other projects they use the RTEMS Source
 Builder or privately on your local file system.
 
 The configuration file loader searches the macro +_configdir+ and by default
-- 
1.9.1

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

Re: I2C Driver testcase

[punit vara]

Thanks I am currently refering this one only :)



On Mon, Aug 1, 2016 at 10:14 AM, Sebastian Huber
 wrote:
> A good test device for an I2C bus driver is an EEPROM. See also
>
> https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01/init.c#n414
>
>
> On 30/07/16 22:53, punit vara wrote:
>>
>> Hi Sebastian !
>>
>> You have suggested me following i2c drivers which follows /dev/i2c
>> framwork :
>>
>>
>> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/i2c/atsam_i2c_bus.c
>>
>> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/xilinx-zynq/i2c/cadence-i2c.c
>>
>> Can you please provide link to the test case application code for any
>> of above driver ?
>>
>> Thanks,
>> Punit Vara
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel