Re: [PATCH v2] Add RTEMS linker sets

2015-12-08 Thread Gedare Bloom 
Push it, if there is problem in the doc we can make a GCI task to fix ;)

Lot of patches may come in with BSP modifications (removal, doxygen),
so feel free to merge relatively quickly

On Tue, Dec 8, 2015 at 1:38 AM, Sebastian Huber
 wrote:
> If nobody complains, then I will commit this tomorrow, since I don't want to
> update this patch each time a BSP is removed.
>
> --
> 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 2/2] score: Delete unused API extensions

2015-12-08 Thread Gedare Bloom 
Seems fine, is there any associated documentation/doxygen to update?

On Tue, Dec 8, 2015 at 2:35 AM, Sebastian Huber
 wrote:
> Update #2408.
> ---
>  cpukit/sapi/src/exinit.c  |  7 ---
>  cpukit/score/include/rtems/score/apiext.h | 28 +---
>  cpukit/score/src/apiext.c | 24 +---
>  3 files changed, 2 insertions(+), 57 deletions(-)
>
> diff --git a/cpukit/sapi/src/exinit.c b/cpukit/sapi/src/exinit.c
> index b29d8c0..794ccb4 100644
> --- a/cpukit/sapi/src/exinit.c
> +++ b/cpukit/sapi/src/exinit.c
> @@ -164,13 +164,6 @@ void rtems_initialize_before_drivers(void)
>#if defined(RTEMS_MULTIPROCESSING)
>  _MPCI_Create_server();
>#endif
> -
> -  #if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
> -/*
> - *  Run the API and BSPs predriver hook.
> - */
> -_API_extensions_Run_predriver();
> -  #endif
>  }
>
>  void rtems_initialize_device_drivers(void)
> diff --git a/cpukit/score/include/rtems/score/apiext.h 
> b/cpukit/score/include/rtems/score/apiext.h
> index 44f16e5..fca47f2 100644
> --- a/cpukit/score/include/rtems/score/apiext.h
> +++ b/cpukit/score/include/rtems/score/apiext.h
> @@ -19,7 +19,6 @@
>  #define _RTEMS_SCORE_APIEXT_H
>
>  #include 
> -#include 
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -39,13 +38,6 @@ extern "C" {
>   */
>  /**@{*/
>
> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
> -  /**
> -   *  This type defines the prototype of the Predriver Hook.
> -   */
> -  typedef void (*API_extensions_Predriver_hook)(void);
> -#endif
> -
>  /**
>   *  This type defines the prototype of the Postdriver Hook.
>   */
> @@ -58,16 +50,7 @@ typedef void (*API_extensions_Postdriver_hook)(void);
>  typedef struct {
>/** This field allows this structure to be used with the Chain Handler. */
>Chain_Node  Node;
> -  #if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
> -/**
> - * This field is the callout invoked during RTEMS initialization after
> - * RTEMS data structures are initialized before device driver 
> initialization
> - * has occurred.
> - *
> - * @note If this field is NULL, no extension is invoked.
> - */
> -API_extensions_Predriver_hook   predriver_hook;
> -  #endif
> +
>/**
> * This field is the callout invoked during RTEMS initialization after
> * RTEMS data structures and device driver initialization has occurred
> @@ -94,15 +77,6 @@ void _API_extensions_Add(
>API_extensions_Control *the_extension
>  );
>
> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
> -/**
> - *  @brief Execute all pre-driver extensions.
> - *
> - *  This routine executes all of the predriver callouts.
> - */
> -  void _API_extensions_Run_predriver( void );
> -#endif
> -
>  /**
>   *  @brief Execute all post-driver extensions.
>   *
> diff --git a/cpukit/score/src/apiext.c b/cpukit/score/src/apiext.c
> index 1d5ce96..fd8ca0f 100644
> --- a/cpukit/score/src/apiext.c
> +++ b/cpukit/score/src/apiext.c
> @@ -30,25 +30,6 @@ void _API_extensions_Add(
>_Chain_Append( &_API_extensions_List, &the_extension->Node );
>  }
>
> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
> -
> -  void _API_extensions_Run_predriver( void )
> -  {
> -Chain_Node *the_node;
> -API_extensions_Control *the_extension;
> -
> -for ( the_node = _Chain_First( &_API_extensions_List );
> - !_Chain_Is_tail( &_API_extensions_List, the_node ) ;
> - the_node = the_node->next ) {
> -
> -  the_extension = (API_extensions_Control *) the_node;
> -
> -  if ( the_extension->predriver_hook )
> -   (*the_extension->predriver_hook)();
> -}
> -  }
> -#endif
> -
>  void _API_extensions_Run_postdriver( void )
>  {
>Chain_Node *the_node;
> @@ -63,9 +44,6 @@ void _API_extensions_Run_postdriver( void )
>  /*
>   *  Currently all APIs configure this hook so it is always non-NULL.
>   */
> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
> -if ( the_extension->postdriver_hook )
> -#endif
> -  (*the_extension->postdriver_hook)();
> +(*the_extension->postdriver_hook)();
>}
>  }
> --
> 1.8.4.5
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] score: Delete unused API extensions

2015-12-08 Thread Gedare Bloom 
Nvm I see the doxy in the patch, didn't at first. OK

On Tue, Dec 8, 2015 at 6:59 AM, Gedare Bloom  wrote:
> Seems fine, is there any associated documentation/doxygen to update?
>
> On Tue, Dec 8, 2015 at 2:35 AM, Sebastian Huber
>  wrote:
>> Update #2408.
>> ---
>>  cpukit/sapi/src/exinit.c  |  7 ---
>>  cpukit/score/include/rtems/score/apiext.h | 28 +---
>>  cpukit/score/src/apiext.c | 24 +---
>>  3 files changed, 2 insertions(+), 57 deletions(-)
>>
>> diff --git a/cpukit/sapi/src/exinit.c b/cpukit/sapi/src/exinit.c
>> index b29d8c0..794ccb4 100644
>> --- a/cpukit/sapi/src/exinit.c
>> +++ b/cpukit/sapi/src/exinit.c
>> @@ -164,13 +164,6 @@ void rtems_initialize_before_drivers(void)
>>#if defined(RTEMS_MULTIPROCESSING)
>>  _MPCI_Create_server();
>>#endif
>> -
>> -  #if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
>> -/*
>> - *  Run the API and BSPs predriver hook.
>> - */
>> -_API_extensions_Run_predriver();
>> -  #endif
>>  }
>>
>>  void rtems_initialize_device_drivers(void)
>> diff --git a/cpukit/score/include/rtems/score/apiext.h 
>> b/cpukit/score/include/rtems/score/apiext.h
>> index 44f16e5..fca47f2 100644
>> --- a/cpukit/score/include/rtems/score/apiext.h
>> +++ b/cpukit/score/include/rtems/score/apiext.h
>> @@ -19,7 +19,6 @@
>>  #define _RTEMS_SCORE_APIEXT_H
>>
>>  #include 
>> -#include 
>>
>>  #ifdef __cplusplus
>>  extern "C" {
>> @@ -39,13 +38,6 @@ extern "C" {
>>   */
>>  /**@{*/
>>
>> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
>> -  /**
>> -   *  This type defines the prototype of the Predriver Hook.
>> -   */
>> -  typedef void (*API_extensions_Predriver_hook)(void);
>> -#endif
>> -
>>  /**
>>   *  This type defines the prototype of the Postdriver Hook.
>>   */
>> @@ -58,16 +50,7 @@ typedef void (*API_extensions_Postdriver_hook)(void);
>>  typedef struct {
>>/** This field allows this structure to be used with the Chain Handler. */
>>Chain_Node  Node;
>> -  #if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
>> -/**
>> - * This field is the callout invoked during RTEMS initialization after
>> - * RTEMS data structures are initialized before device driver 
>> initialization
>> - * has occurred.
>> - *
>> - * @note If this field is NULL, no extension is invoked.
>> - */
>> -API_extensions_Predriver_hook   predriver_hook;
>> -  #endif
>> +
>>/**
>> * This field is the callout invoked during RTEMS initialization after
>> * RTEMS data structures and device driver initialization has occurred
>> @@ -94,15 +77,6 @@ void _API_extensions_Add(
>>API_extensions_Control *the_extension
>>  );
>>
>> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
>> -/**
>> - *  @brief Execute all pre-driver extensions.
>> - *
>> - *  This routine executes all of the predriver callouts.
>> - */
>> -  void _API_extensions_Run_predriver( void );
>> -#endif
>> -
>>  /**
>>   *  @brief Execute all post-driver extensions.
>>   *
>> diff --git a/cpukit/score/src/apiext.c b/cpukit/score/src/apiext.c
>> index 1d5ce96..fd8ca0f 100644
>> --- a/cpukit/score/src/apiext.c
>> +++ b/cpukit/score/src/apiext.c
>> @@ -30,25 +30,6 @@ void _API_extensions_Add(
>>_Chain_Append( &_API_extensions_List, &the_extension->Node );
>>  }
>>
>> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
>> -
>> -  void _API_extensions_Run_predriver( void )
>> -  {
>> -Chain_Node *the_node;
>> -API_extensions_Control *the_extension;
>> -
>> -for ( the_node = _Chain_First( &_API_extensions_List );
>> - !_Chain_Is_tail( &_API_extensions_List, the_node ) ;
>> - the_node = the_node->next ) {
>> -
>> -  the_extension = (API_extensions_Control *) the_node;
>> -
>> -  if ( the_extension->predriver_hook )
>> -   (*the_extension->predriver_hook)();
>> -}
>> -  }
>> -#endif
>> -
>>  void _API_extensions_Run_postdriver( void )
>>  {
>>Chain_Node *the_node;
>> @@ -63,9 +44,6 @@ void _API_extensions_Run_postdriver( void )
>>  /*
>>   *  Currently all APIs configure this hook so it is always non-NULL.
>>   */
>> -#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
>> -if ( the_extension->postdriver_hook )
>> -#endif
>> -  (*the_extension->postdriver_hook)();
>> +(*the_extension->postdriver_hook)();
>>}
>>  }
>> --
>> 1.8.4.5
>>
>> ___
>> 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

Linker Set Based Initialization

2015-12-08 Thread Sebastian Huber 

Hello,

I checked in the support for linker sets 
(https://devel.rtems.org/ticket/2408). Please review the API


https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/linkersets.h

and documentation

https://git.rtems.org/rtems/tree/doc/user/linkersets.t

carefully.  For an example please have a look at

https://git.rtems.org/rtems/tree/testsuites/sptests/splinkersets01

I will change the system initialization to use linker sets in the next 
couple of weeks. Once this is done, the way back is not easy. So, now is 
the best time to address potential issues.


--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: Linker Set Based Initialization

2015-12-08 Thread Joel Sherrill 
What BSPs/architectures have you tested?

Is this something that breaks on a per BSP basis? or per architecture basis?
I am assuming that since it is linker based, each BSP could have broken
linkcmds.
Is that right?

--joel

On Tue, Dec 8, 2015 at 6:59 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I checked in the support for linker sets (
> https://devel.rtems.org/ticket/2408). Please review the API
>
> https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/linkersets.h
>
> and documentation
>
> https://git.rtems.org/rtems/tree/doc/user/linkersets.t
>
> carefully.  For an example please have a look at
>
> https://git.rtems.org/rtems/tree/testsuites/sptests/splinkersets01
>
> I will change the system initialization to use linker sets in the next
> couple of weeks. Once this is done, the way back is not easy. So, now is
> the best time to address potential issues.
>
> --
> 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: Linker Set Based Initialization

2015-12-08 Thread Sebastian Huber 

On 08/12/15 16:03, Joel Sherrill wrote:

What BSPs/architectures have you tested?


I temporarily moved the splinkersets01 test to the samples/ticker and 
tested that all BSPs build and link this test.


I executed the splinkersets01 test on sis, psim and 
arm_realview_pbx_a9_qemu.




Is this something that breaks on a per BSP basis? or per architecture 
basis?
I am assuming that since it is linker based, each BSP could have 
broken linkcmds.

Is that right?


It breaks on a per linker command file basis. Since all the maintained 
BSPs use a linkercmds.base, which shouldn't be a big issue.


For requirements on the linker command file, see new chapter in user 
manual. However BSPs should not deal with this in copy and paste linker 
command files and instead use a linkercmds.base file.


--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: Linker Set Based Initialization

2015-12-08 Thread Sebastian Huber 



On 08/12/15 16:09, Sebastian Huber wrote:
Is this something that breaks on a per BSP basis? or per architecture 
basis?
I am assuming that since it is linker based, each BSP could have 
broken linkcmds.

Is that right?


It breaks on a per linker command file basis. Since all the maintained 
BSPs use a linkercmds.base, which shouldn't be a big issue.


For requirements on the linker command file, see new chapter in user 
manual. However BSPs should not deal with this in copy and paste 
linker command files and instead use a linkercmds.base file. 


Sorry, its "linkcmds.base".

--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: Linker Set Based Initialization

2015-12-08 Thread Joel Sherrill 
On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/12/15 16:03, Joel Sherrill wrote:
>
>> What BSPs/architectures have you tested?
>>
>
> I temporarily moved the splinkersets01 test to the samples/ticker and
> tested that all BSPs build and link this test.
>
> I executed the splinkersets01 test on sis, psim and
> arm_realview_pbx_a9_qemu.
>
>
>> Is this something that breaks on a per BSP basis? or per architecture
>> basis?
>> I am assuming that since it is linker based, each BSP could have broken
>> linkcmds.
>> Is that right?
>>
>
> It breaks on a per linker command file basis. Since all the maintained
> BSPs use a linkercmds.base, which shouldn't be a big issue.
>
>
That means a LOT of the BSPs are broken. You have defined maintained in
your own way.
There are only a handful of architectures with linkcmds.base in them:

./or1k/shared/startup/linkcmds.base
./arm/shared/startup/linkcmds.base
./m68k/shared/startup/linkcmds.base
./powerpc/tqm8xx/startup/linkcmds.base
./powerpc/gen5200/startup/linkcmds.base
./powerpc/shared/startup/linkcmds.base
./sparc/shared/startup/linkcmds.base

I am not sure how many BSPs within arm, m68k, or powerpc actually use the
linkcmds.base.

By my count, 13 of 94 BSP families have linkcmds.base.


> For requirements on the linker command file, see new chapter in user
> manual. However BSPs should not deal with this in copy and paste linker
> command files and instead use a linkercmds.base file.
>
>
So 85% of the BSP families don't use linkcmds.base and by the above
statement,
they must immediately be migrated to linkcmds.base.

Unless you have a plan to address this problem, I am on the side of
rejecting the
part of this patch that changes the initialization.  And the issue must be
addressed
before this can be merged.


>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Linker Set Based Initialization

2015-12-08 Thread Gedare Bloom 
On Tue, Dec 8, 2015 at 10:45 AM, Joel Sherrill  wrote:
>
>
> On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber
>  wrote:
>>
>> On 08/12/15 16:03, Joel Sherrill wrote:
>>>
>>> What BSPs/architectures have you tested?
>>
>>
>> I temporarily moved the splinkersets01 test to the samples/ticker and
>> tested that all BSPs build and link this test.
>>
>> I executed the splinkersets01 test on sis, psim and
>> arm_realview_pbx_a9_qemu.
>>
>>>
>>> Is this something that breaks on a per BSP basis? or per architecture
>>> basis?
>>> I am assuming that since it is linker based, each BSP could have broken
>>> linkcmds.
>>> Is that right?
>>
>>
>> It breaks on a per linker command file basis. Since all the maintained
>> BSPs use a linkercmds.base, which shouldn't be a big issue.
>>
>
> That means a LOT of the BSPs are broken. You have defined maintained in your
> own way.
> There are only a handful of architectures with linkcmds.base in them:
>
> ./or1k/shared/startup/linkcmds.base
> ./arm/shared/startup/linkcmds.base
> ./m68k/shared/startup/linkcmds.base
> ./powerpc/tqm8xx/startup/linkcmds.base
> ./powerpc/gen5200/startup/linkcmds.base
> ./powerpc/shared/startup/linkcmds.base
> ./sparc/shared/startup/linkcmds.base
>
> I am not sure how many BSPs within arm, m68k, or powerpc actually use the
> linkcmds.base.
>
> By my count, 13 of 94 BSP families have linkcmds.base.
>
>>
>> For requirements on the linker command file, see new chapter in user
>> manual. However BSPs should not deal with this in copy and paste linker
>> command files and instead use a linkercmds.base file.
>>
>
> So 85% of the BSP families don't use linkcmds.base and by the above
> statement,
> they must immediately be migrated to linkcmds.base.
>
> Unless you have a plan to address this problem, I am on the side of
> rejecting the
> part of this patch that changes the initialization.  And the issue must be
> addressed
> before this can be merged.
>
How hard to make updating 1 BSP as a GCI task? Sebastian to mentor... ;-)

>>
>>
>> --
>> 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: Linker Set Based Initialization

2015-12-08 Thread Joel Sherrill 
On Tue, Dec 8, 2015 at 9:49 AM, Gedare Bloom  wrote:

> On Tue, Dec 8, 2015 at 10:45 AM, Joel Sherrill  wrote:
> >
> >
> > On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber
> >  wrote:
> >>
> >> On 08/12/15 16:03, Joel Sherrill wrote:
> >>>
> >>> What BSPs/architectures have you tested?
> >>
> >>
> >> I temporarily moved the splinkersets01 test to the samples/ticker and
> >> tested that all BSPs build and link this test.
> >>
> >> I executed the splinkersets01 test on sis, psim and
> >> arm_realview_pbx_a9_qemu.
> >>
> >>>
> >>> Is this something that breaks on a per BSP basis? or per architecture
> >>> basis?
> >>> I am assuming that since it is linker based, each BSP could have broken
> >>> linkcmds.
> >>> Is that right?
> >>
> >>
> >> It breaks on a per linker command file basis. Since all the maintained
> >> BSPs use a linkercmds.base, which shouldn't be a big issue.
> >>
> >
> > That means a LOT of the BSPs are broken. You have defined maintained in
> your
> > own way.
> > There are only a handful of architectures with linkcmds.base in them:
> >
> > ./or1k/shared/startup/linkcmds.base
> > ./arm/shared/startup/linkcmds.base
> > ./m68k/shared/startup/linkcmds.base
> > ./powerpc/tqm8xx/startup/linkcmds.base
> > ./powerpc/gen5200/startup/linkcmds.base
> > ./powerpc/shared/startup/linkcmds.base
> > ./sparc/shared/startup/linkcmds.base
> >
> > I am not sure how many BSPs within arm, m68k, or powerpc actually use the
> > linkcmds.base.
> >
> > By my count, 13 of 94 BSP families have linkcmds.base.
> >
> >>
> >> For requirements on the linker command file, see new chapter in user
> >> manual. However BSPs should not deal with this in copy and paste linker
> >> command files and instead use a linkercmds.base file.
> >>
> >
> > So 85% of the BSP families don't use linkcmds.base and by the above
> > statement,
> > they must immediately be migrated to linkcmds.base.
> >
> > Unless you have a plan to address this problem, I am on the side of
> > rejecting the
> > part of this patch that changes the initialization.  And the issue must
> be
> > addressed
> > before this can be merged.
> >
> How hard to make updating 1 BSP as a GCI task? Sebastian to mentor... ;-)
>
>
Each architecture needs at least one linkcmds.base. I suspect Sebastian
has to create that for each architecture since is harder.

>From there it should be possible for him to write instructions to convert
a single BSP. Doing a single BSP family should make a nice sized GCI
task.

Worst case, if they all don't get done, we have a check list and
instructions
to work through after the holidays.

Someone (hint Sebastian) must write the GCI instructions and do the
base work. Then we need a list of BSP families that need to be converted.
After that, Gedare or I should be able to generate the set of tasks to
import into the GCI website.

I would prefer that Sebastian co-mentor these so he can answer at least
the questions on the initial tasks students do. The questions should be
repetitive after a bit so improving instructions and other mentors knowing
the information should allow others to help.


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

[PATCH 1/2] m68k/mvme136: Remove

2015-12-08 Thread Aun-Ali Zaidi 
updates #2444.
---
 c/src/lib/libbsp/m68k/mvme136/Makefile.am  |  62 ---
 c/src/lib/libbsp/m68k/mvme136/bsp_specs|  13 --
 c/src/lib/libbsp/m68k/mvme136/clock/ckinit.c   | 114 
 c/src/lib/libbsp/m68k/mvme136/configure.ac |  20 ---
 c/src/lib/libbsp/m68k/mvme136/console/console.c| 173 --
 c/src/lib/libbsp/m68k/mvme136/include/bsp.h|  81 -
 c/src/lib/libbsp/m68k/mvme136/include/coverhd.h| 106 ---
 c/src/lib/libbsp/m68k/mvme136/include/tm27.h   |  36 
 .../mvme136/make/custom/mvme136-testsuite.tcfg |   7 -
 .../libbsp/m68k/mvme136/make/custom/mvme136.cfg|  26 ---
 c/src/lib/libbsp/m68k/mvme136/preinstall.am|  76 
 c/src/lib/libbsp/m68k/mvme136/shmsupp/addrconv.c   |  29 ---
 c/src/lib/libbsp/m68k/mvme136/shmsupp/getcfg.c |  82 -
 c/src/lib/libbsp/m68k/mvme136/shmsupp/lock.c   |  71 
 c/src/lib/libbsp/m68k/mvme136/shmsupp/mpisr.c  |  39 
 c/src/lib/libbsp/m68k/mvme136/startup/bspclean.c   |  46 -
 c/src/lib/libbsp/m68k/mvme136/startup/bspstart.c   |  39 
 c/src/lib/libbsp/m68k/mvme136/startup/linkcmds | 199 -
 c/src/lib/libbsp/m68k/mvme136/timer/timer.c|  85 -
 c/src/lib/libbsp/m68k/mvme136/timer/timerisr.S |  36 
 c/src/lib/libbsp/m68k/mvme136/times| 189 ---
 21 files changed, 1529 deletions(-)
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/Makefile.am
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/bsp_specs
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/clock/ckinit.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/configure.ac
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/console/console.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/include/bsp.h
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/include/coverhd.h
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/include/tm27.h
 delete mode 100644 
c/src/lib/libbsp/m68k/mvme136/make/custom/mvme136-testsuite.tcfg
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/make/custom/mvme136.cfg
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/preinstall.am
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/addrconv.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/getcfg.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/lock.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/mpisr.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/startup/bspclean.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/startup/bspstart.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/startup/linkcmds
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/timer/timer.c
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/timer/timerisr.S
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/times

diff --git a/c/src/lib/libbsp/m68k/mvme136/Makefile.am 
b/c/src/lib/libbsp/m68k/mvme136/Makefile.am
deleted file mode 100644
index 2dbaef4..000
--- a/c/src/lib/libbsp/m68k/mvme136/Makefile.am
+++ /dev/null
@@ -1,62 +0,0 @@
-ACLOCAL_AMFLAGS = -I ../../../../aclocal
-
-include $(top_srcdir)/../../../../automake/compile.am
-
-include_bspdir = $(includedir)/bsp
-
-dist_project_lib_DATA = bsp_specs
-
-include_HEADERS = include/bsp.h
-include_HEADERS += include/tm27.h
-
-nodist_include_HEADERS = include/bspopts.h
-nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h
-DISTCLEANFILES = include/bspopts.h
-noinst_PROGRAMS =
-
-include_HEADERS += include/coverhd.h
-
-## Zilog component header files
-include_rtems_zilogdir = $(includedir)/rtems/zilog
-include_rtems_zilog_HEADERS = ../../shared/include/zilog/z8036.h
-
-noinst_LIBRARIES = libbspstart.a
-libbspstart_a_SOURCES = ../../m68k/shared/start/start.S
-project_lib_DATA = start.$(OBJEXT)
-
-dist_project_lib_DATA += startup/linkcmds
-
-noinst_LIBRARIES += libbsp.a
-libbsp_a_SOURCES =
-
-# startup
-libbsp_a_SOURCES += startup/bspclean.c ../../shared/bsplibc.c \
-../../shared/bsppost.c ../../shared/bsppredriverhook.c  \
-startup/bspstart.c ../../shared/bootcard.c \
-../../shared/bsppretaskinghook.c ../../shared/bspgetworkarea.c \
-../../shared/sbrk.c ../../shared/setvec.c
-# gnatsupp
-libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c
-# clock
-libbsp_a_SOURCES += clock/ckinit.c
-# console
-libbsp_a_SOURCES += console/console.c
-# debugio
-libbsp_a_SOURCES += ../../shared/dummy_printk_support.c
-# timer
-libbsp_a_SOURCES += timer/timer.c timer/timerisr.S
-
-if HAS_MP
-# shmsupp
-libbsp_a_SOURCES += shmsupp/addrconv.c shmsupp/getcfg.c shmsupp/lock.c \
-shmsupp/mpisr.c
-endif
-
-libbsp_a_LIBADD = \
-../../../libcpu/@RTEMS_CPU@/shared/cache.rel \
-../../../libcpu/@RTEMS_CPU@/shared/misc.rel
-
-EXTRA_DIST = times
-
-include $(srcdir)/preinstall.am
-include $(top_srcdir)/../../../../automake/local.am
diff --git a/c/src/lib/libbsp/m68k/mvme136/bsp_specs 
b/c/src/lib/libbsp/m68k/mvme136/bsp_specs
deleted file mode 100644
index 51

Re: Linker Set Based Initialization

2015-12-08 Thread Gedare Bloom 
We can also route student questions to here if we don't know the answers.

On Tue, Dec 8, 2015 at 11:07 AM, Joel Sherrill  wrote:
>
>
> On Tue, Dec 8, 2015 at 9:49 AM, Gedare Bloom  wrote:
>>
>> On Tue, Dec 8, 2015 at 10:45 AM, Joel Sherrill  wrote:
>> >
>> >
>> > On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber
>> >  wrote:
>> >>
>> >> On 08/12/15 16:03, Joel Sherrill wrote:
>> >>>
>> >>> What BSPs/architectures have you tested?
>> >>
>> >>
>> >> I temporarily moved the splinkersets01 test to the samples/ticker and
>> >> tested that all BSPs build and link this test.
>> >>
>> >> I executed the splinkersets01 test on sis, psim and
>> >> arm_realview_pbx_a9_qemu.
>> >>
>> >>>
>> >>> Is this something that breaks on a per BSP basis? or per architecture
>> >>> basis?
>> >>> I am assuming that since it is linker based, each BSP could have
>> >>> broken
>> >>> linkcmds.
>> >>> Is that right?
>> >>
>> >>
>> >> It breaks on a per linker command file basis. Since all the maintained
>> >> BSPs use a linkercmds.base, which shouldn't be a big issue.
>> >>
>> >
>> > That means a LOT of the BSPs are broken. You have defined maintained in
>> > your
>> > own way.
>> > There are only a handful of architectures with linkcmds.base in them:
>> >
>> > ./or1k/shared/startup/linkcmds.base
>> > ./arm/shared/startup/linkcmds.base
>> > ./m68k/shared/startup/linkcmds.base
>> > ./powerpc/tqm8xx/startup/linkcmds.base
>> > ./powerpc/gen5200/startup/linkcmds.base
>> > ./powerpc/shared/startup/linkcmds.base
>> > ./sparc/shared/startup/linkcmds.base
>> >
>> > I am not sure how many BSPs within arm, m68k, or powerpc actually use
>> > the
>> > linkcmds.base.
>> >
>> > By my count, 13 of 94 BSP families have linkcmds.base.
>> >
>> >>
>> >> For requirements on the linker command file, see new chapter in user
>> >> manual. However BSPs should not deal with this in copy and paste linker
>> >> command files and instead use a linkercmds.base file.
>> >>
>> >
>> > So 85% of the BSP families don't use linkcmds.base and by the above
>> > statement,
>> > they must immediately be migrated to linkcmds.base.
>> >
>> > Unless you have a plan to address this problem, I am on the side of
>> > rejecting the
>> > part of this patch that changes the initialization.  And the issue must
>> > be
>> > addressed
>> > before this can be merged.
>> >
>> How hard to make updating 1 BSP as a GCI task? Sebastian to mentor... ;-)
>>
>
> Each architecture needs at least one linkcmds.base. I suspect Sebastian
> has to create that for each architecture since is harder.
>
> From there it should be possible for him to write instructions to convert
> a single BSP. Doing a single BSP family should make a nice sized GCI
> task.
>
> Worst case, if they all don't get done, we have a check list and
> instructions
> to work through after the holidays.
>
> Someone (hint Sebastian) must write the GCI instructions and do the
> base work. Then we need a list of BSP families that need to be converted.
> After that, Gedare or I should be able to generate the set of tasks to
> import into the GCI website.
>
> I would prefer that Sebastian co-mentor these so he can answer at least
> the questions on the initial tasks students do. The questions should be
> repetitive after a bit so improving instructions and other mentors knowing
> the information should allow others to help.
>
>>
>> >>
>> >>
>> >> --
>> >> 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

Fwd: [PATCH 1/2] m68k/mvme136: Remove

2015-12-08 Thread Aun-Ali Zaidi 
Made a mistake, ignore this patch.

 Forwarded message 
>From : Aun-Ali Zaidi
To : 
Cc : "Aun-Ali Zaidi" 
Date : Tue, 08 Dec 2015 10:35:51 -0600
Subject : [PATCH 1/2] m68k/mvme136: Remove
 Forwarded message 

updates #2444. 
--- 
 c/src/lib/libbsp/m68k/mvme136/Makefile.am | 62 --- 
 c/src/lib/libbsp/m68k/mvme136/bsp_specs | 13 -- 
 c/src/lib/libbsp/m68k/mvme136/clock/ckinit.c | 114  
 c/src/lib/libbsp/m68k/mvme136/configure.ac | 20 --- 
 c/src/lib/libbsp/m68k/mvme136/console/console.c | 173 -- 
 c/src/lib/libbsp/m68k/mvme136/include/bsp.h | 81 - 
 c/src/lib/libbsp/m68k/mvme136/include/coverhd.h | 106 --- 
 c/src/lib/libbsp/m68k/mvme136/include/tm27.h | 36  
 .../mvme136/make/custom/mvme136-testsuite.tcfg | 7 - 
 .../libbsp/m68k/mvme136/make/custom/mvme136.cfg | 26 --- 
 c/src/lib/libbsp/m68k/mvme136/preinstall.am | 76  
 c/src/lib/libbsp/m68k/mvme136/shmsupp/addrconv.c | 29 --- 
 c/src/lib/libbsp/m68k/mvme136/shmsupp/getcfg.c | 82 - 
 c/src/lib/libbsp/m68k/mvme136/shmsupp/lock.c | 71  
 c/src/lib/libbsp/m68k/mvme136/shmsupp/mpisr.c | 39  
 c/src/lib/libbsp/m68k/mvme136/startup/bspclean.c | 46 - 
 c/src/lib/libbsp/m68k/mvme136/startup/bspstart.c | 39  
 c/src/lib/libbsp/m68k/mvme136/startup/linkcmds | 199 - 
 c/src/lib/libbsp/m68k/mvme136/timer/timer.c | 85 - 
 c/src/lib/libbsp/m68k/mvme136/timer/timerisr.S | 36  
 c/src/lib/libbsp/m68k/mvme136/times | 189 --- 
 21 files changed, 1529 deletions(-) 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/Makefile.am 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/bsp_specs 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/clock/ckinit.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/configure.ac 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/console/console.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/include/bsp.h 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/include/coverhd.h 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/include/tm27.h 
 delete mode 100644 
c/src/lib/libbsp/m68k/mvme136/make/custom/mvme136-testsuite.tcfg 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/make/custom/mvme136.cfg 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/preinstall.am 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/addrconv.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/getcfg.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/lock.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/shmsupp/mpisr.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/startup/bspclean.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/startup/bspstart.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/startup/linkcmds 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/timer/timer.c 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/timer/timerisr.S 
 delete mode 100644 c/src/lib/libbsp/m68k/mvme136/times 
 
diff --git a/c/src/lib/libbsp/m68k/mvme136/Makefile.am 
b/c/src/lib/libbsp/m68k/mvme136/Makefile.am 
deleted file mode 100644 
index 2dbaef4..000 
--- a/c/src/lib/libbsp/m68k/mvme136/Makefile.am 
+++ /dev/null 
@@ -1,62 +0,0 @@ 
-ACLOCAL_AMFLAGS = -I ../../../../aclocal 
- 
-include $(top_srcdir)/../../../../automake/compile.am 
- 
-include_bspdir = $(includedir)/bsp 
- 
-dist_project_lib_DATA = bsp_specs 
- 
-include_HEADERS = include/bsp.h 
-include_HEADERS += include/tm27.h 
- 
-nodist_include_HEADERS = include/bspopts.h 
-nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h 
-DISTCLEANFILES = include/bspopts.h 
-noinst_PROGRAMS = 
- 
-include_HEADERS += include/coverhd.h 
- 
-## Zilog component header files 
-include_rtems_zilogdir = $(includedir)/rtems/zilog 
-include_rtems_zilog_HEADERS = ../../shared/include/zilog/z8036.h 
- 
-noinst_LIBRARIES = libbspstart.a 
-libbspstart_a_SOURCES = ../../m68k/shared/start/start.S 
-project_lib_DATA = start.$(OBJEXT) 
- 
-dist_project_lib_DATA += startup/linkcmds 
- 
-noinst_LIBRARIES += libbsp.a 
-libbsp_a_SOURCES = 
- 
-# startup 
-libbsp_a_SOURCES += startup/bspclean.c ../../shared/bsplibc.c \ 
- ../../shared/bsppost.c ../../shared/bsppredriverhook.c \ 
- startup/bspstart.c ../../shared/bootcard.c \ 
- ../../shared/bsppretaskinghook.c ../../shared/bspgetworkarea.c \ 
- ../../shared/sbrk.c ../../shared/setvec.c 
-# gnatsupp 
-libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c 
-# clock 
-libbsp_a_SOURCES += clock/ckinit.c 
-# console 
-libbsp_a_SOURCES += console/console.c 
-# debugio 
-libbsp_a_SOURCES += ../../shared/dummy_printk_support.c 
-# timer 
-libbsp_a_SOURCES += timer/timer.c timer/timerisr.S 
- 
-if HAS_MP 
-# shmsupp 
-libbsp_a_SOURCES += shmsupp/addrconv.c shmsupp/getcfg.c shmsupp/lock.c \ 
- shmsupp/mpisr.c 
-endif 
- 
-libbsp_a_LIBADD = \ 
- ../../../libcpu/@RTEMS_CPU@/shared/cache.rel \ 
- ../../../libcpu/

Re: Linker Set Based Initialization

2015-12-08 Thread Sebastian Huber 
Hello Joel, 

before you start with wild guessing, please look at the patch: 

https://git.rtems.org/rtems/commit/?id=b618d8cfc54f84d4ed03dc7b7fa510c872e6128a 

- Am 8. Dez 2015 um 16:45 schrieb Joel Sherrill : 

> On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de > wrote:

>> On 08/12/15 16:03, Joel Sherrill wrote:

>>> What BSPs/architectures have you tested?

>> I temporarily moved the splinkersets01 test to the samples/ticker and tested
>> that all BSPs build and link this test.

>> I executed the splinkersets01 test on sis, psim and arm_realview_pbx_a9_qemu.

>>> Is this something that breaks on a per BSP basis? or per architecture basis?
>>> I am assuming that since it is linker based, each BSP could have broken
>>> linkcmds.
>>> Is that right?

>> It breaks on a per linker command file basis. Since all the maintained BSPs 
>> use
>> a linkercmds.base, which shouldn't be a big issue.

> That means a LOT of the BSPs are broken.

Why do you think BSPs are broken? If you look at my commit, then you will see 
that I edited every linker command file by hand! Please note that there are no 
changes for the ARM (except the GBA BSP, which is a removal candidate if you 
ask me), SPARC and i386. They already use the linker sets for the libbsd. 

> You have defined maintained in your own way.

You can use other definitions and end up likely with the same set of BSPs. 

> There are only a handful of architectures with linkcmds.base in them:

> ./or1k/shared/startup/linkcmds.base
> ./arm/shared/startup/linkcmds.base
> ./m68k/shared/startup/linkcmds.base
> ./powerpc/tqm8xx/startup/linkcmds.base
> ./powerpc/gen5200/startup/linkcmds.base
> ./powerpc/shared/startup/linkcmds.base
> ./sparc/shared/startup/linkcmds.base

> I am not sure how many BSPs within arm, m68k, or powerpc actually use the
> linkcmds.base.

> By my count, 13 of 94 BSP families have linkcmds.base.

>> For requirements on the linker command file, see new chapter in user manual.
>> However BSPs should not deal with this in copy and paste linker command files
>> and instead use a linkercmds.base file.

> So 85% of the BSP families don't use linkcmds.base and by the above statement,
> they must immediately be migrated to linkcmds.base.

No, nothing must be migrated. In fact such a migration would be very risky. You 
just need two section descriptions in the linker command file (see user manual 
chapter). 

> Unless you have a plan to address this problem, I am on the side of rejecting
> the
> part of this patch that changes the initialization. And the issue must be
> addressed
> before this can be merged.

I am not aware of any issues, except the dependency on the GNU linker. 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Linker Set Based Initialization

2015-12-08 Thread Sebastian Huber 
- Am 8. Dez 2015 um 16:03 schrieb Joel Sherrill : 

> What BSPs/architectures have you tested?

I will test the with the attached patch tomorrow on all BSPs. This patch adds a 
link time test to ticker. This test verifies that the linker command file 
modifications for the RTEMS linker sets are all right. I verified by hand that 
it detects a missing KEEP(), SORT() or section description. 

I think the linker set based initialization is very beneficial. For example 
with it we no longer need a build time option to disable/enable the POSIX API. 
We can enable it all the time with virtually no overhead for applications which 
don't use it. 
From b9f91864e72418409e27c3a59704c47516a5b886 Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Tue, 8 Dec 2015 21:01:55 +0100
Subject: [PATCH] Hack: Link time test for linker sets

---
 testsuites/samples/ticker/Makefile.am| 2 ++
 testsuites/samples/ticker/init.c | 8 
 testsuites/samples/ticker/linkersets.txt | 8 
 3 files changed, 18 insertions(+)
 create mode 100644 testsuites/samples/ticker/linkersets.txt

diff --git a/testsuites/samples/ticker/Makefile.am b/testsuites/samples/ticker/Makefile.am
index 25c3764..c0b030a 100644
--- a/testsuites/samples/ticker/Makefile.am
+++ b/testsuites/samples/ticker/Makefile.am
@@ -18,5 +18,7 @@ LINK_LIBS = $(ticker_LDLIBS)
 ticker$(EXEEXT): $(ticker_OBJECTS) $(ticker_DEPENDENCIES)
 	@rm -f ticker$(EXEEXT)
 	$(make-exe)
+	$(NM) ticker$(EXEEXT) | grep _Linker_set | sort | cut -d ' ' -f 3 > actual-linkersets.txt
+	diff $(srcdir)/linkersets.txt actual-linkersets.txt
 
 include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/samples/ticker/init.c b/testsuites/samples/ticker/init.c
index 3f3cbd8..80f2fb4 100644
--- a/testsuites/samples/ticker/init.c
+++ b/testsuites/samples/ticker/init.c
@@ -6,6 +6,14 @@
  *  found in the file LICENSE in this distribution or at
  *  http://www.rtems.org/license/LICENSE.
  */
+#include 
+
+RTEMS_LINKER_ROSET_ITEM_ORDERED(test_ro, const int *, roo, 0);
+RTEMS_LINKER_RWSET_ITEM_ORDERED(test_rw, const int *, rwo, 0);
+RTEMS_LINKER_ROSET_ITEM(test_ro, const int *, rou);
+RTEMS_LINKER_RWSET_ITEM(test_rw, const int *, rwu);
+RTEMS_LINKER_RWSET(test_rw, const int *);
+RTEMS_LINKER_ROSET(test_ro, const int *);
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"
diff --git a/testsuites/samples/ticker/linkersets.txt b/testsuites/samples/ticker/linkersets.txt
new file mode 100644
index 000..5f7dfb5
--- /dev/null
+++ b/testsuites/samples/ticker/linkersets.txt
@@ -0,0 +1,8 @@
+_Linker_set_test_ro_begin
+_Linker_set_test_ro_roo
+_Linker_set_test_ro_rou
+_Linker_set_test_ro_end
+_Linker_set_test_rw_begin
+_Linker_set_test_rw_rwo
+_Linker_set_test_rw_rwu
+_Linker_set_test_rw_end
-- 
2.1.4

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

Re: Linker Set Based Initialization

2015-12-08 Thread Joel Sherrill 
Sorry. I didn't see that patch get committed this morning and didn't realize
it addressed the issue. When you said, BSPs needed to use linkcmds.base
and not cut and paste, I took that to mean you hadn't touched any other
BSPs.

I will try to test some on BSPs you didn't.

Is the ticker addition just a temporary thing to get us through this
testing phase?

--joel

On Tue, Dec 8, 2015 at 11:13 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> before you start with wild guessing, please look at the patch:
>
>
> https://git.rtems.org/rtems/commit/?id=b618d8cfc54f84d4ed03dc7b7fa510c872e6128a
>
> - Am 8. Dez 2015 um 16:45 schrieb Joel Sherrill :
>
>
>
> On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 08/12/15 16:03, Joel Sherrill wrote:
>>
>>> What BSPs/architectures have you tested?
>>>
>> I temporarily moved the splinkersets01 test to the samples/ticker and
>> tested that all BSPs build and link this test.
>>
>> I executed the splinkersets01 test on sis, psim and
>> arm_realview_pbx_a9_qemu.
>>
>>
>>> Is this something that breaks on a per BSP basis? or per architecture
>>> basis?
>>> I am assuming that since it is linker based, each BSP could have broken
>>> linkcmds.
>>> Is that right?
>>>
>> It breaks on a per linker command file basis. Since all the maintained
>> BSPs use a linkercmds.base, which shouldn't be a big issue.
>>
>>
> That means a LOT of the BSPs are broken.
>
>
> Why do you think BSPs are broken? If you look at my commit, then you will
> see that I edited every linker command file by hand! Please note that there
> are no changes for the ARM (except the GBA BSP, which is a removal
> candidate if you ask me), SPARC and i386. They already use the linker sets
> for the libbsd.
>
> You have defined maintained in your own way.
>
>
> You can use other definitions and end up likely with the same set of BSPs.
>
> There are only a handful of architectures with linkcmds.base in them:
>
> ./or1k/shared/startup/linkcmds.base
> ./arm/shared/startup/linkcmds.base
> ./m68k/shared/startup/linkcmds.base
> ./powerpc/tqm8xx/startup/linkcmds.base
> ./powerpc/gen5200/startup/linkcmds.base
> ./powerpc/shared/startup/linkcmds.base
> ./sparc/shared/startup/linkcmds.base
>
> I am not sure how many BSPs within arm, m68k, or powerpc actually use the
> linkcmds.base.
>
> By my count, 13 of 94 BSP families have linkcmds.base.
>
>> For requirements on the linker command file, see new chapter in user
>> manual. However BSPs should not deal with this in copy and paste linker
>> command files and instead use a linkercmds.base file.
>>
>>
> So 85% of the BSP families don't use linkcmds.base and by the above
> statement,
> they must immediately be migrated to linkcmds.base.
>
>
> No, nothing must be migrated. In fact such a migration would be very
> risky. You just need two section descriptions in the linker command file
> (see user manual chapter).
>
>
> Unless you have a plan to address this problem, I am on the side of
> rejecting the
> part of this patch that changes the initialization.  And the issue must be
> addressed
> before this can be merged.
>
>
> I am not aware of any issues, except the dependency on the GNU linker.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Linker Set Based Initialization

2015-12-08 Thread Sebastian Huber 


- Am 8. Dez 2015 um 21:24 schrieb Joel Sherrill j...@rtems.org:

> Sorry. I didn't see that patch get committed this morning and didn't realize
> it addressed the issue. When you said, BSPs needed to use linkcmds.base
> and not cut and paste, I took that to mean you hadn't touched any other
> BSPs.

I meant that it would be nice if all architectures could use a linkcmds.base.  
Editing all these slightly different files was no real fun.

> 
> I will try to test some on BSPs you didn't.
> 
> Is the ticker addition just a temporary thing to get us through this
> testing phase?

Good question, my quick and dirty patch is a good test, but it requires several 
host tools, e.g.

sparc-rtems4.12-nm ticker.exe | grep _Linker_set | sort | cut -d ' ' -f 3 > 
actual-linkersets.txt
diff /home/sh/rtems-4.12/c/src/../../testsuites/samples/ticker/linkersets.txt 
actual-linkersets.txt

I am not sure if this would add new requirements on the development host. Not a 
big deal on Linux, but ...
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems/bit_rtems: Remove reference to score603e.

2015-12-08 Thread Ralph Holmes 
Closes #2458.
---
 rtems/bit_all_bsps | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/bit_all_bsps b/rtems/bit_all_bsps
index fb30675..d0bbb1a 100755
--- a/rtems/bit_all_bsps
+++ b/rtems/bit_all_bsps
@@ -145,7 +145,7 @@ get_bsps()
   mips)all_bsps="jmr3904 genmongoosev csb350 hurricane"
all_bsps="${all_bsps} rbtx4925 rbtx4938" ;;
   nios2)   all_bsps="nios2_iss" ;;
-  powerpc) all_bsps="psim score603e mcp750 mvme2100 mvme2307 mvme3100"
+  powerpc) all_bsps="psim mcp750 mvme2100 mvme2307 mvme3100"
all_bsps="${all_bsps} mpc8260ads ss555 mvme5500 ep1a"
all_bsps="${all_bsps} pm520_cr825 pm520_ze30"
all_bsps="${all_bsps} mbx821_001 mbx821_002 mbx821_002b"
-- 
2.3.5

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

[PATCH] powerpc/score603e: Remove (obselete).

2015-12-08 Thread Ralph Holmes 
Updates #2458.
---
 c/src/lib/libbsp/powerpc/acinclude.m4  |   2 -
 c/src/lib/libbsp/powerpc/score603e/Makefile.am |  77 
 c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.c   | 102 -
 c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h   |  42 --
 c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c | 108 -
 .../libbsp/powerpc/score603e/PCI_bus/universe.c| 255 ---
 c/src/lib/libbsp/powerpc/score603e/README  |  53 ---
 c/src/lib/libbsp/powerpc/score603e/bsp_specs   |  13 -
 c/src/lib/libbsp/powerpc/score603e/configure.ac|  84 
 c/src/lib/libbsp/powerpc/score603e/console/85c30.c | 422 --
 c/src/lib/libbsp/powerpc/score603e/console/85c30.h |  52 ---
 .../lib/libbsp/powerpc/score603e/console/console.c | 413 -
 .../libbsp/powerpc/score603e/console/consolebsp.h  | 146 --
 .../libbsp/powerpc/score603e/console/tbl85c30.c| 194 
 c/src/lib/libbsp/powerpc/score603e/include/bsp.h   | 199 -
 c/src/lib/libbsp/powerpc/score603e/include/gen2.h  | 209 -
 c/src/lib/libbsp/powerpc/score603e/include/tm27.h  |  68 ---
 c/src/lib/libbsp/powerpc/score603e/irq/FPGA.c  | 180 
 c/src/lib/libbsp/powerpc/score603e/irq/irq.c   | 495 -
 c/src/lib/libbsp/powerpc/score603e/irq/irq.h   | 153 ---
 c/src/lib/libbsp/powerpc/score603e/irq/irq_init.c  | 131 --
 c/src/lib/libbsp/powerpc/score603e/irq/no_pic.c|  82 
 .../powerpc/score603e/make/custom/score603e.cfg|  29 --
 c/src/lib/libbsp/powerpc/score603e/preinstall.am   | 103 -
 c/src/lib/libbsp/powerpc/score603e/start/start.S   | 126 --
 .../libbsp/powerpc/score603e/startup/Hwr_init.c| 142 --
 .../libbsp/powerpc/score603e/startup/bspstart.c| 232 --
 .../lib/libbsp/powerpc/score603e/startup/genpvec.c | 166 ---
 .../lib/libbsp/powerpc/score603e/startup/linkcmds  | 248 ---
 .../lib/libbsp/powerpc/score603e/startup/vmeintr.c |  48 --
 c/src/lib/libbsp/powerpc/score603e/timer/timer.c   |  77 
 c/src/lib/libbsp/powerpc/score603e/tod/tod.c   | 172 ---
 c/src/lib/libbsp/powerpc/score603e/vme/VMEConfig.h |  97 
 33 files changed, 4920 deletions(-)
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/Makefile.am
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/PCI_bus/universe.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/README
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/bsp_specs
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/configure.ac
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/console/85c30.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/console/85c30.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/console/console.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/console/consolebsp.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/console/tbl85c30.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/include/bsp.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/include/gen2.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/include/tm27.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/irq/FPGA.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/irq/irq.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/irq/irq.h
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/irq/irq_init.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/irq/no_pic.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/make/custom/score603e.cfg
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/preinstall.am
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/start/start.S
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/startup/Hwr_init.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/startup/bspstart.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/startup/genpvec.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/startup/linkcmds
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/startup/vmeintr.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/timer/timer.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/tod/tod.c
 delete mode 100644 c/src/lib/libbsp/powerpc/score603e/vme/VMEConfig.h

diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4 
b/c/src/lib/libbsp/powerpc/acinclude.m4
index 6442399..4dfb84d 100644
--- a/c/src/lib/libbsp/powerpc/acinclude.m4
+++ b/c/src/lib/libbsp/powerpc/acinclude.m4
@@ -30,8 +30,6 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR],
 AC_CONFIG_SUBDIRS([qemuppc]);;
   qoriq )
 AC_CONFIG_SUBDIRS([qoriq]);;
-  score603e )
-AC_CONFIG_SUBDIRS([score603e]);;
   ss555 )
 AC_CONFIG_SUBDIRS([ss555]);;
   t32mppc )
diff --git a/c/src/lib/libbsp/powerpc/score603e/Makefile.am 
b/c/src/lib/libbsp/po

[PATCH] rtems/bit_all_bsps: Remove ep1a reference

2015-12-08 Thread Aun-Ali Zaidi 
closes #2457.
---
 rtems/bit_all_bsps | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/bit_all_bsps b/rtems/bit_all_bsps
index d0bbb1a..5a6e024 100755
--- a/rtems/bit_all_bsps
+++ b/rtems/bit_all_bsps
@@ -146,7 +146,7 @@ get_bsps()
all_bsps="${all_bsps} rbtx4925 rbtx4938" ;;
   nios2)   all_bsps="nios2_iss" ;;
   powerpc) all_bsps="psim mcp750 mvme2100 mvme2307 mvme3100"
-   all_bsps="${all_bsps} mpc8260ads ss555 mvme5500 ep1a"
+   all_bsps="${all_bsps} mpc8260ads ss555 mvme5500"
all_bsps="${all_bsps} pm520_cr825 pm520_ze30"
all_bsps="${all_bsps} mbx821_001 mbx821_002 mbx821_002b"
all_bsps="${all_bsps} mbx860_1b mbx860_001b mbx860_002"
-- 
2.1.4


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.
  

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

Re: [PATCH] powerpc/ep1a: Remove

2015-12-08 Thread Sebastian Huber 

Hello Aun-Ali,

thanks, I committed the patch with a slight modification.

On 09/12/15 05:01, Aun-Ali Zaidi wrote:

@@ -38,12 +36,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR],
  AC_CONFIG_SUBDIRS([t32mppc]);;
tqm8xx )
  AC_CONFIG_SUBDIRS([tqm8xx]);;
-  virtex )
-AC_CONFIG_SUBDIRS([virtex]);;
virtex4 )
  AC_CONFIG_SUBDIRS([virtex4]);;
virtex5 )
  AC_CONFIG_SUBDIRS([virtex5]);;
+  virtex )
+AC_CONFIG_SUBDIRS([virtex]);;
*)
  AC_MSG_ERROR([Invalid BSP]);;
esac


Please don't include unrelated changes in one patch.

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