GSoC 2017: Live tracing project status

[vivek kukreja]

Hello Chris, all,

This is in response to Gedare's mail regarding project ideas for GSoC
2017. I am looking forward to applying under RTEMS as a student again
this year. I
am currently updating my previous code(for CTF integration and
ethernet transport) with the mainline repo changes and preparing a
detailed doc. I couldn't commit much time this year but i hope to
cover up before summer. I would like you to please review my work so i
can further improve the code.

Also, i wanted to enquire about the status of the Live tracing project
this year.
I am investigating libDWARF support for RTEMS and
further improvements to support live tracing and make the tracing
support more automated. I wanted to clarify whether this is a priority
before i start working on my proposal. I'm excited to explore other
related open projects too.

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

Re: [PATCH] c-user: Add self-contained objects chapter

[Gedare Bloom]

On Wed, Feb 1, 2017 at 5:17 AM, Sebastian Huber
 wrote:
> Update #2843.
> ---
>  c-user/index.rst  |   1 +
>  c-user/self_contained_objects.rst | 337 
> ++
>  2 files changed, 338 insertions(+)
>  create mode 100644 c-user/self_contained_objects.rst
>
> diff --git a/c-user/index.rst b/c-user/index.rst
> index 7937042..4b7fe22 100644
> --- a/c-user/index.rst
> +++ b/c-user/index.rst
> @@ -62,6 +62,7 @@ to the Community Project hosted at http://www.rtems.org/.
> board_support_packages
> user_extensions
> configuring_a_system
> +   self_contained_objects
> multiprocessing
> symmetric_multiprocessing_services
> pci_library
> diff --git a/c-user/self_contained_objects.rst 
> b/c-user/self_contained_objects.rst
> new file mode 100644
> index 000..76c2a64
> --- /dev/null
> +++ b/c-user/self_contained_objects.rst
> @@ -0,0 +1,337 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. COMMENT: Copyright (c) 2014, 2017.
> +.. COMMENT: embedded brains GmbH.
> +.. COMMENT: All rights reserved.
> +
> +Self-Contained Objects
> +**
> +
> +Introduction
> +
> +
> +One of the original design goals of RTEMS was the support for heterogeneous
> +computing based on message passing.  This was realized by synchronization
> +objects with an architecture-independent identifier provided by the system
> +during object creation (a 32-bit unsigned integer used as a bitfield) and a
> +user-defined four character name.  This approach in the so called Classic API
> +has some weaknesses:
> +
> +* Dynamic memory (the workspace) is used to allocate object pools.  This
> +  requires a complex configuration with heavy use of the C pre-processor.
> +  Dynamic memory is forbidden by some coding standards, e.g. MISRA C:2012
> +  :cite:`MISRA:2012:C`.
> +
> +* Objects are created via function calls which return an object identifier.
> +  The object operations use this identifier and map it internally to an 
> object
> +  representation.
> +
> +* The object identifier is only known at run-time.  This hinders compiler
> +  optimizations and static analysis.
> +
> +* The objects reside in a table, e.g. they are suspect to false sharing of
> +  cache lines :cite:`Drepper:2007:Memory`.
> +
> +* The object operations use a rich set of options and attributes.  For each
> +  object operation these parameters must be evaluated and validated at 
> run-time
> +  to figure out what to do exactly for this operation.
> +
> +For applications that use fine grained locking the mapping of the identifier 
> to
> +the object representation and the parameter evaluation are a significant
> +overhead that may degrade the performance dramatically.  An example is the 
> `new
> +network stack (libbsd) `_ which uses
> +hundreds of locks in a basic setup and the OpenMP support.
> +
> +To overcome these issues new self-contained objects are available in RTEMS 
> 4.12
> +via the Newlib supplied :file:``, :file:`` and
> +:file:`` header files.  The following synchronization objects are
> +provided
> +
> +* POSIX spinlocks,
> +
> +* mutexes,
> +
> +* recursive mutexes,
> +
> +* condition variables,
> +
> +* counting semaphores,
> +
> +* binary semaphores, and
> +
> +* Futex synchronization :cite:`Franke:2002:Futex`.
> +
> +This allows much better performance in SMP configurations as well as in
> +uni-processor configurations.  The application configuration is significantly
> +simplified, since it is no longer necessary to account for lock objects used 
> by
> +Newlib and GCC.  The Newlib defined self-contained objects can be a 
> statically
> +initialized and reside in the ``.bss`` section.  Destruction is a 
> no-operation.
> +
> +Self-Contained Objects API
> +==
> +
> +To give the RTEMS users access to self-contained objects an API is necessary.
> +One option is to use the POSIX threads API (pthreads) and change its
> +implementation to use self-contained objects.  However, there are some other
> +things to consider.  Users of the Classic API may want to run their
> +applications with different RTEMS versions.  Since the POSIX threads API is
> +optional it may be not available at all, for example in a stripped down space
> +qualified version.  The POSIX threads API has a lot of options that need
> +run-time evaluation, so that optimal performance is not achievable.  There 
> are
> +a variety of error conditions.  This is a problem in combination with some
> +coding standards, e.g.  MISRA C:2012.  APIs used by Linux (e.g.
> +`
> +`_) or the 
> FreeBSD
> +kernel (e.g.
> +`MUTEX(9) `_) are
> +better suited as a template for high-performance synchronization objects.
> +
> +The API defined in the following sections should be implementable via the
> +Classic A

Re: [PATCH] c-user: Add self-contained objects chapter

[Sebastian Huber]

On 02/02/17 16:26, Gedare Bloom wrote:

On Wed, Feb 1, 2017 at 5:17 AM, Sebastian Huber
 wrote:

Update #2843.
---
  c-user/index.rst  |   1 +
  c-user/self_contained_objects.rst | 337 ++
  2 files changed, 338 insertions(+)
  create mode 100644 c-user/self_contained_objects.rst

diff --git a/c-user/index.rst b/c-user/index.rst
index 7937042..4b7fe22 100644
--- a/c-user/index.rst
+++ b/c-user/index.rst
@@ -62,6 +62,7 @@ to the Community Project hosted at http://www.rtems.org/.
 board_support_packages
 user_extensions
 configuring_a_system
+   self_contained_objects
 multiprocessing
 symmetric_multiprocessing_services
 pci_library
diff --git a/c-user/self_contained_objects.rst 
b/c-user/self_contained_objects.rst
new file mode 100644
index 000..76c2a64
--- /dev/null
+++ b/c-user/self_contained_objects.rst
@@ -0,0 +1,337 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. COMMENT: Copyright (c) 2014, 2017.
+.. COMMENT: embedded brains GmbH.
+.. COMMENT: All rights reserved.
+
+Self-Contained Objects
+**
+
+Introduction
+
+
+One of the original design goals of RTEMS was the support for heterogeneous
+computing based on message passing.  This was realized by synchronization
+objects with an architecture-independent identifier provided by the system
+during object creation (a 32-bit unsigned integer used as a bitfield) and a
+user-defined four character name.  This approach in the so called Classic API
+has some weaknesses:
+
+* Dynamic memory (the workspace) is used to allocate object pools.  This
+  requires a complex configuration with heavy use of the C pre-processor.
+  Dynamic memory is forbidden by some coding standards, e.g. MISRA C:2012
+  :cite:`MISRA:2012:C`.
+
+* Objects are created via function calls which return an object identifier.
+  The object operations use this identifier and map it internally to an object
+  representation.
+
+* The object identifier is only known at run-time.  This hinders compiler
+  optimizations and static analysis.
+
+* The objects reside in a table, e.g. they are suspect to false sharing of
+  cache lines :cite:`Drepper:2007:Memory`.
+
+* The object operations use a rich set of options and attributes.  For each
+  object operation these parameters must be evaluated and validated at run-time
+  to figure out what to do exactly for this operation.
+
+For applications that use fine grained locking the mapping of the identifier to
+the object representation and the parameter evaluation are a significant
+overhead that may degrade the performance dramatically.  An example is the `new
+network stack (libbsd) `_ which uses
+hundreds of locks in a basic setup and the OpenMP support.
+
+To overcome these issues new self-contained objects are available in RTEMS 4.12
+via the Newlib supplied :file:``, :file:`` and
+:file:`` header files.  The following synchronization objects are
+provided
+
+* POSIX spinlocks,
+
+* mutexes,
+
+* recursive mutexes,
+
+* condition variables,
+
+* counting semaphores,
+
+* binary semaphores, and
+
+* Futex synchronization :cite:`Franke:2002:Futex`.
+
+This allows much better performance in SMP configurations as well as in
+uni-processor configurations.  The application configuration is significantly
+simplified, since it is no longer necessary to account for lock objects used by
+Newlib and GCC.  The Newlib defined self-contained objects can be a statically
+initialized and reside in the ``.bss`` section.  Destruction is a no-operation.
+
+Self-Contained Objects API
+==
+
+To give the RTEMS users access to self-contained objects an API is necessary.
+One option is to use the POSIX threads API (pthreads) and change its
+implementation to use self-contained objects.  However, there are some other
+things to consider.  Users of the Classic API may want to run their
+applications with different RTEMS versions.  Since the POSIX threads API is
+optional it may be not available at all, for example in a stripped down space
+qualified version.  The POSIX threads API has a lot of options that need
+run-time evaluation, so that optimal performance is not achievable.  There are
+a variety of error conditions.  This is a problem in combination with some
+coding standards, e.g.  MISRA C:2012.  APIs used by Linux (e.g.
+`
+`_) or the FreeBSD
+kernel (e.g.
+`MUTEX(9) `_) are
+better suited as a template for high-performance synchronization objects.
+
+The API defined in the following sections should be implementable via the
+Classic API, the self-contained objects present in RTEMS 4.12 and the POSIX
+API.  Timed operations are not available since the timeout semantics of the
+Classic API and the POSIX threads API are quite different.
+
+Mut

Re: Regarding a beginner friendly bug

[Gedare Bloom]

On Thu, Feb 2, 2017 at 2:41 AM, Tanu Hari Dixit  wrote:
> Thank you for pointing these out to me. I had a question, though. Why
> isn't the proposed patch applied in
> https://devel.rtems.org/ticket/2353 ?
>
I made a comment there about the proposed patch.

> Regards,
> Tanu Hari Dixit.
>
> On Wed, Feb 1, 2017 at 11:41 AM, Sebastian Huber
>  wrote:
>> Hello Tanu Hari Dixit,
>>
>> On 31/01/17 19:15, Tanu Hari Dixit wrote:
>>>
>>> Hello all,
>>> Is there a beginner friendly bug that I can be assigned? I would like
>>> to get involved and learn more about RTEMS.
>>
>>
>> these three bugs are close to being beginner friendly:
>>
>> https://devel.rtems.org/ticket/2375
>>
>> https://devel.rtems.org/ticket/2353
>>
>> https://devel.rtems.org/ticket/2550
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Add self-contained objects chapter

[Gedare Bloom]

On Thu, Feb 2, 2017 at 10:30 AM, Sebastian Huber
 wrote:
>
>
> On 02/02/17 16:26, Gedare Bloom wrote:
>>
>> On Wed, Feb 1, 2017 at 5:17 AM, Sebastian Huber
>>  wrote:
>>>
>>> Update #2843.
>>> ---
>>>   c-user/index.rst  |   1 +
>>>   c-user/self_contained_objects.rst | 337
>>> ++
>>>   2 files changed, 338 insertions(+)
>>>   create mode 100644 c-user/self_contained_objects.rst
>>>
>>> diff --git a/c-user/index.rst b/c-user/index.rst
>>> index 7937042..4b7fe22 100644
>>> --- a/c-user/index.rst
>>> +++ b/c-user/index.rst
>>> @@ -62,6 +62,7 @@ to the Community Project hosted at
>>> http://www.rtems.org/.
>>>  board_support_packages
>>>  user_extensions
>>>  configuring_a_system
>>> +   self_contained_objects
>>>  multiprocessing
>>>  symmetric_multiprocessing_services
>>>  pci_library
>>> diff --git a/c-user/self_contained_objects.rst
>>> b/c-user/self_contained_objects.rst
>>> new file mode 100644
>>> index 000..76c2a64
>>> --- /dev/null
>>> +++ b/c-user/self_contained_objects.rst
>>> @@ -0,0 +1,337 @@
>>> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
>>> +
>>> +.. COMMENT: Copyright (c) 2014, 2017.
>>> +.. COMMENT: embedded brains GmbH.
>>> +.. COMMENT: All rights reserved.
>>> +
>>> +Self-Contained Objects
>>> +**
>>> +
>>> +Introduction
>>> +
>>> +
>>> +One of the original design goals of RTEMS was the support for
>>> heterogeneous
>>> +computing based on message passing.  This was realized by
>>> synchronization
>>> +objects with an architecture-independent identifier provided by the
>>> system
>>> +during object creation (a 32-bit unsigned integer used as a bitfield)
>>> and a
>>> +user-defined four character name.  This approach in the so called
>>> Classic API
>>> +has some weaknesses:
>>> +
>>> +* Dynamic memory (the workspace) is used to allocate object pools.  This
>>> +  requires a complex configuration with heavy use of the C
>>> pre-processor.
>>> +  Dynamic memory is forbidden by some coding standards, e.g. MISRA
>>> C:2012
>>> +  :cite:`MISRA:2012:C`.
>>> +
>>> +* Objects are created via function calls which return an object
>>> identifier.
>>> +  The object operations use this identifier and map it internally to an
>>> object
>>> +  representation.
>>> +
>>> +* The object identifier is only known at run-time.  This hinders
>>> compiler
>>> +  optimizations and static analysis.
>>> +
>>> +* The objects reside in a table, e.g. they are suspect to false sharing
>>> of
>>> +  cache lines :cite:`Drepper:2007:Memory`.
>>> +
>>> +* The object operations use a rich set of options and attributes.  For
>>> each
>>> +  object operation these parameters must be evaluated and validated at
>>> run-time
>>> +  to figure out what to do exactly for this operation.
>>> +
>>> +For applications that use fine grained locking the mapping of the
>>> identifier to
>>> +the object representation and the parameter evaluation are a significant
>>> +overhead that may degrade the performance dramatically.  An example is
>>> the `new
>>> +network stack (libbsd) `_ which uses
>>> +hundreds of locks in a basic setup and the OpenMP support.
>>> +
>>> +To overcome these issues new self-contained objects are available in
>>> RTEMS 4.12
>>> +via the Newlib supplied :file:``, :file:`` and
>>> +:file:`` header files.  The following synchronization
>>> objects are
>>> +provided
>>> +
>>> +* POSIX spinlocks,
>>> +
>>> +* mutexes,
>>> +
>>> +* recursive mutexes,
>>> +
>>> +* condition variables,
>>> +
>>> +* counting semaphores,
>>> +
>>> +* binary semaphores, and
>>> +
>>> +* Futex synchronization :cite:`Franke:2002:Futex`.
>>> +
>>> +This allows much better performance in SMP configurations as well as in
>>> +uni-processor configurations.  The application configuration is
>>> significantly
>>> +simplified, since it is no longer necessary to account for lock objects
>>> used by
>>> +Newlib and GCC.  The Newlib defined self-contained objects can be a
>>> statically
>>> +initialized and reside in the ``.bss`` section.  Destruction is a
>>> no-operation.
>>> +
>>> +Self-Contained Objects API
>>> +==
>>> +
>>> +To give the RTEMS users access to self-contained objects an API is
>>> necessary.
>>> +One option is to use the POSIX threads API (pthreads) and change its
>>> +implementation to use self-contained objects.  However, there are some
>>> other
>>> +things to consider.  Users of the Classic API may want to run their
>>> +applications with different RTEMS versions.  Since the POSIX threads API
>>> is
>>> +optional it may be not available at all, for example in a stripped down
>>> space
>>> +qualified version.  The POSIX threads API has a lot of options that need
>>> +run-time evaluation, so that optimal performance is not achievable.
>>> There are
>>> +a variety of error conditions.  This is a problem in combination with
>>> some

Re: Using helper functions

[punit vara]

Hi

Which file system API you are talking about ? Can you please send me
the file location ?

I have used some of GPIO APIs for BBB board. Have a look at this example

https://github.com/punitvara/rtems_gsoc16/blob/master/gpio/init.c

Similarly you can create application for any APIs.

P.S. Always add devel mailing list as CC so that other person also can
help you :)

Thanks
PV

On Wed, Feb 1, 2017 at 11:25 PM, Tanu Hari Dixit  wrote:
> Hello Punit,
> I have been reading the docs as you suggested. But I want to execute
> the various directives and helper functions and test for myself in an
> isolated example. For example I want to test the various API functions
> available for the filesystem (In memory Filesystem) in RTEMS. How do I
> go about doing that?
> Thanks,
> Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using helper functions

[Gedare Bloom]

see rtems.git/testsuites/fstests for examples of some filesystem usage.

On Thu, Feb 2, 2017 at 12:03 PM, punit vara  wrote:
> Hi
>
> Which file system API you are talking about ? Can you please send me
> the file location ?
>
> I have used some of GPIO APIs for BBB board. Have a look at this example
>
> https://github.com/punitvara/rtems_gsoc16/blob/master/gpio/init.c
>
> Similarly you can create application for any APIs.
>
> P.S. Always add devel mailing list as CC so that other person also can
> help you :)
>
> Thanks
> PV
>
> On Wed, Feb 1, 2017 at 11:25 PM, Tanu Hari Dixit  
> wrote:
>> Hello Punit,
>> I have been reading the docs as you suggested. But I want to execute
>> the various directives and helper functions and test for myself in an
>> isolated example. For example I want to test the various API functions
>> available for the filesystem (In memory Filesystem) in RTEMS. How do I
>> go about doing that?
>> Thanks,
>> Tanu Hari Dixit.
> ___
> 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

Build error on rtems master

[Kirspel, Kevin]

I'm getting a build error with the latest master due to the changes removing 
CONFIGURE_SMP_APPLICATION.  The default-configuration.c file sets 
CONFIGURE_SMP_MAXIMUM_PROCESSORS to 32 thus enabling the internal 
_CONFIGURE_SMP_APPLICATION define on targets without SMP.  I had to add a

#if defined(RTEMS_SMP)

guard around

#if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
  #define _CONFIGURE_SMP_APPLICATION
#endif

to get it to compile.  I was building for the xilinx_zynq_a9_qemu BSP.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

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

Re: Build error on rtems master

[Joel Sherrill]

That sounds like a reasonable error and fix. Please send a patch
to the mailing list.

I assume the build of all BSPs I just started is likely to fail if
I didn't enable SMP. :)

--joel

On Thu, Feb 2, 2017 at 1:07 PM, Kirspel, Kevin 
wrote:

> I’m getting a build error with the latest master due to the changes
> removing CONFIGURE_SMP_APPLICATION.  The default-configuration.c file sets
> CONFIGURE_SMP_MAXIMUM_PROCESSORS to 32 thus enabling the internal
> _CONFIGURE_SMP_APPLICATION define on targets without SMP.  I had to add a
>
>
>
> #if defined(RTEMS_SMP)
>
>
>
> guard around
>
>
>
> #if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
>
>   #define _CONFIGURE_SMP_APPLICATION
>
> #endif
>
>
>
> to get it to compile.  I was building for the xilinx_zynq_a9_qemu BSP.
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642 <(770)%20510->
>
> Direct: (770)-688-1642 <(770)%20688-1642>
>
> Fax: (770)-510-4445 <(770)%20510-4445>
>
>
>
> ___
> 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

libdebugger documentation

[Gedare Bloom]

Is there documentation on how to use / extend the new gdb server / libdebugger?

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

Re: Build error on rtems master

[Gedare Bloom]

Maybe the default-configuration.c should set max processors to 1?

On Thu, Feb 2, 2017 at 2:51 PM, Joel Sherrill  wrote:
> That sounds like a reasonable error and fix. Please send a patch
> to the mailing list.
>
> I assume the build of all BSPs I just started is likely to fail if
> I didn't enable SMP. :)
>
> --joel
>
> On Thu, Feb 2, 2017 at 1:07 PM, Kirspel, Kevin 
> wrote:
>>
>> I’m getting a build error with the latest master due to the changes
>> removing CONFIGURE_SMP_APPLICATION.  The default-configuration.c file sets
>> CONFIGURE_SMP_MAXIMUM_PROCESSORS to 32 thus enabling the internal
>> _CONFIGURE_SMP_APPLICATION define on targets without SMP.  I had to add a
>>
>>
>>
>> #if defined(RTEMS_SMP)
>>
>>
>>
>> guard around
>>
>>
>>
>> #if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
>>
>>   #define _CONFIGURE_SMP_APPLICATION
>>
>> #endif
>>
>>
>>
>> to get it to compile.  I was building for the xilinx_zynq_a9_qemu BSP.
>>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510- ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Build error on rtems master

[Joel Sherrill]

On Thu, Feb 2, 2017 at 1:52 PM, Gedare Bloom  wrote:

> Maybe the default-configuration.c should set max processors to 1?
>
>
I would prefer it not be set at all in non-SMP builds.


> On Thu, Feb 2, 2017 at 2:51 PM, Joel Sherrill  wrote:
> > That sounds like a reasonable error and fix. Please send a patch
> > to the mailing list.
> >
> > I assume the build of all BSPs I just started is likely to fail if
> > I didn't enable SMP. :)
> >
> > --joel
> >
> > On Thu, Feb 2, 2017 at 1:07 PM, Kirspel, Kevin 
> > wrote:
> >>
> >> I’m getting a build error with the latest master due to the changes
> >> removing CONFIGURE_SMP_APPLICATION.  The default-configuration.c file
> sets
> >> CONFIGURE_SMP_MAXIMUM_PROCESSORS to 32 thus enabling the internal
> >> _CONFIGURE_SMP_APPLICATION define on targets without SMP.  I had to add
> a
> >>
> >>
> >>
> >> #if defined(RTEMS_SMP)
> >>
> >>
> >>
> >> guard around
> >>
> >>
> >>
> >> #if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
> >>
> >>   #define _CONFIGURE_SMP_APPLICATION
> >>
> >> #endif
> >>
> >>
> >>
> >> to get it to compile.  I was building for the xilinx_zynq_a9_qemu BSP.
> >>
> >>
> >>
> >> Kevin Kirspel
> >>
> >> Electrical Engineer - Sr. Staff
> >>
> >> Idexx Roswell
> >>
> >> 235 Hembree Park Drive
> >>
> >> Roswell GA 30076
> >>
> >> Tel: (770)-510- ext. 81642
> >>
> >> Direct: (770)-688-1642
> >>
> >> Fax: (770)-510-4445
> >>
> >>
> >>
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libdebugger documentation

[Joel Sherrill]

On Thu, Feb 2, 2017 at 1:51 PM, Gedare Bloom  wrote:

> Is there documentation on how to use / extend the new gdb server /
> libdebugger?
>
> Is there a wish list/TODO for it? Since it is new, it might be a source of
projects.


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

[PATCH] Disable defining _CONFIGURE_SMP_APPLICATION if RTEMS_SMP is not defined

[Kevin Kirspel]

---
 cpukit/sapi/include/confdefs.h | 2 ++
 1 file changed, 2 insertions(+)
 mode change 100644 => 100755 cpukit/sapi/include/confdefs.h

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
old mode 100644
new mode 100755
index c931fda..adccc72
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -214,9 +214,11 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
  * An internal define to indicate that this is an SMP application
  * configuration.
  */
+#if defined(RTEMS_SMP)
 #if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
   #define _CONFIGURE_SMP_APPLICATION
 #endif
+#endif
 
 #ifdef CONFIGURE_SMP_APPLICATION
   #warning "CONFIGURE_SMP_APPLICATION is obsolete since RTEMS 4.12"
-- 
1.9.1

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

Re: Build error on rtems master

[Joel Sherrill]

I have confirmed that as expected this breaks all BSPS.

--joel

On Thu, Feb 2, 2017 at 3:08 PM, Joel Sherrill  wrote:

>
>
> On Thu, Feb 2, 2017 at 1:52 PM, Gedare Bloom  wrote:
>
>> Maybe the default-configuration.c should set max processors to 1?
>>
>>
> I would prefer it not be set at all in non-SMP builds.
>
>
>> On Thu, Feb 2, 2017 at 2:51 PM, Joel Sherrill  wrote:
>> > That sounds like a reasonable error and fix. Please send a patch
>> > to the mailing list.
>> >
>> > I assume the build of all BSPs I just started is likely to fail if
>> > I didn't enable SMP. :)
>> >
>> > --joel
>> >
>> > On Thu, Feb 2, 2017 at 1:07 PM, Kirspel, Kevin > >
>> > wrote:
>> >>
>> >> I’m getting a build error with the latest master due to the changes
>> >> removing CONFIGURE_SMP_APPLICATION.  The default-configuration.c file
>> sets
>> >> CONFIGURE_SMP_MAXIMUM_PROCESSORS to 32 thus enabling the internal
>> >> _CONFIGURE_SMP_APPLICATION define on targets without SMP.  I had to
>> add a
>> >>
>> >>
>> >>
>> >> #if defined(RTEMS_SMP)
>> >>
>> >>
>> >>
>> >> guard around
>> >>
>> >>
>> >>
>> >> #if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
>> >>
>> >>   #define _CONFIGURE_SMP_APPLICATION
>> >>
>> >> #endif
>> >>
>> >>
>> >>
>> >> to get it to compile.  I was building for the xilinx_zynq_a9_qemu BSP.
>> >>
>> >>
>> >>
>> >> Kevin Kirspel
>> >>
>> >> Electrical Engineer - Sr. Staff
>> >>
>> >> Idexx Roswell
>> >>
>> >> 235 Hembree Park Drive
>> >>
>> >> Roswell GA 30076
>> >>
>> >> Tel: (770)-510- ext. 81642
>> >>
>> >> Direct: (770)-688-1642
>> >>
>> >> Fax: (770)-510-4445
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket #2897

[Kirspel, Kevin]

I have created a ticket to update TERMIOS to include support for LIBBSD.  The 
changes will allow the TTY driver in LIBBSD to work with few modifications.  I 
am almost done with a LIBBSD port for the USB serial driver stack.  This port 
requires the use of LIBBSD's TTY kernel driver and the current port has a lot 
of "#ifndef __rtems__" guards for fixing up difference between RTEMS termios 
and LIBBSD termios.  All the legacy RTEMS termios features are present except 
for the storage of the input and output baud rates (thus the need to fixup a 
lot of BSPs).  Please review the patch and test it on as many BSPs as possible.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

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