Re: GSOC'16 proposal review

2016-03-24 Thread Gedare Bloom 
Make sure you submit your final PDF to https://summerofcode.withgoogle.com

On Thu, Mar 24, 2016 at 5:34 PM, sane sai charan
 wrote:
> Hello all,
>
>   I completed the Hello World task.I am unable to fill
> the details in students tracking page. Here is my proposal draft. Please
> review it. Any suggestion is helpful.
>
> ___
> 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] [RSB 4.11] Bump OpenRISC versions

2016-03-24 Thread Chris Johns 

On 25/03/2016 9:25 AM, Hesham Almatary wrote:

On Thu, Mar 24, 2016 at 2:39 PM, Chris Johns  wrote:

On 23/03/2016 04:55, Gedare Bloom wrote:



You can check them in. Let Joel/Chris know as they have been release
testing 4.11



Hesham, sorry I have lost track of what is needed. Do clean patches exist to
make the required changes for 4.11 and master?


Yeah both work/apply cleanly, and I tested them.



Fantastic.

Thanks to all involved.

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

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

2016-03-24 Thread Hesham Almatary 
On Fri, Mar 25, 2016 at 7:19 AM, Gedare Bloom  wrote:
> I checked them in.
>
Thanks Gedare
> On Wed, Mar 23, 2016 at 11:39 PM, Chris Johns  wrote:
>> On 23/03/2016 04:55, Gedare Bloom wrote:
>>>
>>>
>>> You can check them in. Let Joel/Chris know as they have been release
>>> testing 4.11
>>>
>>
>> Hesham, sorry I have lost track of what is needed. Do clean patches exist to
>> make the required changes for 4.11 and master?
>>
>> Thanks
>> Chris



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

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

2016-03-24 Thread Hesham Almatary 
On Thu, Mar 24, 2016 at 2:39 PM, Chris Johns  wrote:
> On 23/03/2016 04:55, Gedare Bloom wrote:
>>
>>
>> You can check them in. Let Joel/Chris know as they have been release
>> testing 4.11
>>
>
> Hesham, sorry I have lost track of what is needed. Do clean patches exist to
> make the required changes for 4.11 and master?
>
Yeah both work/apply cleanly, and I tested them.

> Thanks
> Chris



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

Re: GSOC 2016 Project:Porting Rock on RTEMS

2016-03-24 Thread Sambeet Panigrahi 
Hi,
 With the help from Rock members, I could secure some scripts and
documentation from the previous SOCIS project on Porting Rock on RTEMS.
That caused a lot many changes in my proposal.I request everyone to have a
look and comment. My proposal link is

https://docs.google.com/document/d/1Ntfj3X4Tplmpxg7yGkojk5YSuNOjZB7q_2I3tSuf7r4/edit?usp=sharing

Regards
Sambeet

On Sun, Mar 20, 2016 at 6:30 PM, Gedare Bloom  wrote:

> I have a fundamental question. Is Rock the main issue, or does the
> Orocos port that uses RTEMS also need to be updated and verified? Can
> you run Orocos/RTEMS?
>
> On Sun, Mar 20, 2016 at 8:56 AM, Gedare Bloom  wrote:
> > You need to register an account on the wiki, and then edit the page
> > (link at bottom).
> >
> > On Sat, Mar 19, 2016 at 10:35 PM, Sambeet Panigrahi
> >  wrote:
> >> Hi
> >> I am attaching the link to my proposal with this mail This is not a
> final
> >> draft and there's a lot of scope of improvement. I have not yet decided
> what
> >> packages to build. I wanted to update the tracking page but don't know
> how
> >> to do that. I welcome all suggestions for improvement and feedbacks.
> >>
> https://docs.google.com/document/d/1Ntfj3X4Tplmpxg7yGkojk5YSuNOjZB7q_2I3tSuf7r4/edit?usp=docslist_api
> >> Regards
> >> Sambeet
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Participation in GSoC 2016

2016-03-24 Thread Deval Shah 
Great ! I will add this to my application. Parallely I was looking for
some other BSP like this. Looks like last year André added support for
SD card by adding the SDHCI and MMC/SD bus drivers from libBSD
successfully 
(https://devel.rtems.org/wiki/GSoC/2015/Final_Report#AndreMarques:RaspberryPiLowLevelPeripheralsandSDCard).
I will build anyone of them (arm/realview_pbx_a9_qemu or SD card) in
my acceptance waiting period and get familiarised with the build
process.

I think from my side my proposal is ready. You can have a look at
that. Kindly suggest if anything alse is missing.

On Thu, Mar 24, 2016 at 7:13 PM, Alan Cudmore  wrote:
> The Pi 1/B+ would be a good model to start the USB development with.
>
> I have actually not built the BSD lib myself. But I think this is the place
> to start:
> https://git.rtems.org/rtems-libbsd/tree/libbsd.txt
> https://git.rtems.org/rtems-libbsd/tree/README.waf
> Looks like the arm/realview_pbx_a9_qemu BSP is the one use.
>
> I have run some of the SMP examples on qemu with the
> arm/realview_pbx_a9_qemu_smp BSP and it worked well for me.
>
> Alan
>
>
> On Wed, Mar 23, 2016 at 9:03 AM, Deval Shah  wrote:
>>
>> On Tue, Mar 22, 2016 at 10:04 PM, Alan Cudmore 
>> wrote:
>> > Hi Deval,
>> > Your proposal looks good. I would suggest adding a step where you build
>> > a
>> > known BSP with BSD lib support. It will help you become familiar with
>> > the
>> > development process.
>>
>> Thanks for the suggestion, Alan. I will be adding this to my proposal.
>> Also, which BSP would you recommend that I pick up ? Is there any list
>> of currently added BSPs from which I can choose?
>>
>> > You should also address which Raspberry Pi model you will support. Now
>> > that
>> > there are so many Raspberry Pi models, it might make the project more
>> > complicated:
>> > Original raspberry Pi Model A & A+: a single built in USB port in the
>> > BCM2835 CPU. No ethernet or USB hub.
>> > Raspberry Pi Model B & B+: USB hub and Ethernet in LAN9512 chip.
>> > Raspberry Pi 2 Model B: USB hub and Ethernet in LAN9514 chip.
>> > Raspberry Pi 3 Model B:  I would not worry about this one yet.
>> > Raspberry Pi Zero: A single USB OTG port , no ethernet or USB hub.
>> >
>> > I would pick one of them and get it working before seeing if another
>> > model
>> > could be supported.
>> >
>> > If the Raspberry Pi 1/B+ and 2/B Hubs are functionally the same (
>> > LAN9512
>> > vs. LAN9514 ), this would support the widest range of devices out there.
>> >
>> I was also thinking for that. I have a Raspberry PI 1/B+ and a
>> majority of users have either 1/B+ or 2/B. Probably we can start with
>> 1/B+ and then enable the other models.
>>
>> > If you have time, I would love to see USB support for the BCM2835 on the
>> > Pi
>> > Model A+ and especially the Pi Zero.
>>
>> Sure, I had left some buffer time in my proposal, probably if things
>> goes as per plan that time can be used for USB support for the
>> BCM2835.
>>
>> >
>> > Thanks,
>> > Alan
>> >
>> >
>> > On Tue, Mar 22, 2016 at 8:52 AM, Deval Shah 
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> I have updated my draft proposal and shared on the tracking page. I'm
>> >> sharing it here as well. https://goo.gl/QQiAf6
>> >>
>> >> Sorry, I was busy with my Mid-Semester exams, could not update earlier.
>> >>
>> >> Since this is a draft proposal, it may not be completely polished yet.
>> >> I'd appreciate any comments on it, especially regarding the project
>> >> description
>> >> and timeline.
>> >>
>> >> Thank you.
>> >>
>> >> Regards,
>> >> Deval Shah
>> >>
>> >> On Fri, Mar 11, 2016 at 11:02 PM, Deval Shah 
>> >> wrote:
>> >> > On Fri, Mar 11, 2016 at 8:33 PM, Gedare Bloom  wrote:
>> >> >> On Fri, Mar 11, 2016 at 8:19 AM, Deval Shah 
>> >> >> wrote:
>> >> >>> Hello everyone!
>> >> >>>
>> >> >>> I went through the links and blogs of the SD card and USB/Ethernet
>> >> >>> project for Raspberry PI. I would like to work for the USB/Ethernet
>> >> >>> support project.
>> >> >>>
>> >> >>> I have prepared a draft of the timeline as follows:
>> >> >>>
>> >> >>> Acceptance Waiting Period:
>> >> >>> Understanding previous year's GSOC work
>> >> >>>
>> >> >>> First Half:
>> >> >>> completing USB support for RPI
>> >> >>> Testing USB and add drivers for HIDs like Mouse and Keyboard
>> >> >>>
>> >> >>> Second Half:
>> >> >>> Adding Ethernet Support
>> >> >>> Testing (ARP, PING, DHCP, FTP, TFTP)
>> >> >>> Adding support for lwIP (since it is already ported to BBB, this
>> >> >>> should not take more time)
>> >> >>>
>> >> >> Timeline seems good. Is the USB support available from freebsd for
>> >> >> the
>> >> >> libbsd codebase?
>> >> >
>> >> > Yes. libbsd has support for USB.
>> >> > Last year issues were in porting the driver (
>> >> > http://gtament-rtems.blogspot.in/2015/06/my-progress-report.html ).
>> >> >
>> >> >>>

GSOC'16 proposal review

2016-03-24 Thread sane sai charan 
Hello all,

  I completed the Hello World task.I am unable to fill
the details in students tracking page. Here is my proposal draft
. Please review it. Any suggestion is helpful.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-gsoc] Configuration GUI for GSOC 16.

2016-03-24 Thread Gedare Bloom 
OK, please develop your proposal as best you can and submit the final
PDF version to Google officially so that you may be considered. We can
continue to discuss and fine-tune details.

On Thu, Mar 24, 2016 at 9:07 AM, Arpit Srivastava
 wrote:
> Hello,
> As asked in the previous mail, i have finished the task as said and attached
> the screen-shot of it.
> Hope to hear from you soon.
>
> Regards
>
> Arpit Srivastava
> H2015103076P
>
> On Tue, Mar 22, 2016 at 11:04 PM, Amar Takhar  wrote:
>>
>> On 2016-03-22 13:33 -0400, Gedare Bloom wrote:
>> > I don't know why you are having a problem.
>>
>> I do not understand why, either.  Can you try from another device like a
>> phone
>> or outside of the network you are using?
>>
>>
>> Amar.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

2016-03-24 Thread Gedare Bloom 
I checked them in.

On Wed, Mar 23, 2016 at 11:39 PM, Chris Johns  wrote:
> On 23/03/2016 04:55, Gedare Bloom wrote:
>>
>>
>> You can check them in. Let Joel/Chris know as they have been release
>> testing 4.11
>>
>
> Hesham, sorry I have lost track of what is needed. Do clean patches exist to
> make the required changes for 4.11 and master?
>
> Thanks
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 7/8] bsp/motorola_powerpc: Add MPCI support for Qemu

2016-03-24 Thread Joel Sherrill 
On Thu, Mar 24, 2016 at 11:25 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Ok, I should not send patches five minutes before a long weekend.
>
>
:) I hope to do a little of the same before I run out. :)


> - Joel Sherrill  schrieb:
> > Are there any instructions on how you run mptests on this BSP?
>
> I will update the RTEMS testing scripts. You can run two Qemu instances
> connected via a virtual network.  Works pretty good.
>
> I expected that much from the patches.

It looks like this depends on old networking and multiprocessing being
enabled at the same time.
Is that check through the code/build system?

I have a script (rtems-testing/rtems/bit_all_confs) to vary a number of
build flags and build a
BSP over and over. I can try that on it when it is all committed.

FWIW I ran that on psim and leon3 recently.


> --
> 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.huber at 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: [PATCH 7/8] bsp/motorola_powerpc: Add MPCI support for Qemu

2016-03-24 Thread Sebastian Huber 
Ok, I should not send patches five minutes before a long weekend.

- Joel Sherrill  schrieb:
> Are there any instructions on how you run mptests on this BSP?

I will update the RTEMS testing scripts. You can run two Qemu instances 
connected via a virtual network.  Works pretty good.

-- 
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.huber at 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: [PATCH 8/8] confdefs.h hack

2016-03-24 Thread Joel Sherrill 
On Thu, Mar 24, 2016 at 9:57 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Not to be committed. How can we fix this?
>

What's the problem being solved?


> ---
>  cpukit/sapi/include/confdefs.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/sapi/include/confdefs.h
> b/cpukit/sapi/include/confdefs.h
> index 6d67a02..715d4fc 100644
> --- a/cpukit/sapi/include/confdefs.h
> +++ b/cpukit/sapi/include/confdefs.h
> @@ -132,7 +132,7 @@ extern rtems_initialization_tasks_table
> Initialization_tasks[];
>   * are used by calls like open(2) and read(2).
>   */
>  #ifndef CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
> -  #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 3
> +  #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 64
>  #endif
>
>  /**
> @@ -1921,7 +1921,7 @@ extern rtems_initialization_tasks_table
> Initialization_tasks[];
>
>#define CONFIGURE_MULTIPROCESSING_TABLE
> _configuration
>
> -  #define CONFIGURE_MPCI_TASKS 1
> +  #define CONFIGURE_MPCI_TASKS 5
>
>  #endif /* CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE */
>
> --
> 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

[PATCH 2/8] score: Fix CORE mutex RTEMS_MULTIPROCESSING

2016-03-24 Thread Sebastian Huber 
Make sure that the thread proxy is registered as the mutex owner.
---
 cpukit/score/src/coremutexsurrender.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/cpukit/score/src/coremutexsurrender.c 
b/cpukit/score/src/coremutexsurrender.c
index 744adc5..da21d4b 100644
--- a/cpukit/score/src/coremutexsurrender.c
+++ b/cpukit/score/src/coremutexsurrender.c
@@ -187,6 +187,9 @@ CORE_mutex_Status _CORE_mutex_Surrender(
   ) {
 bool unblock;
 
+the_mutex->holder = the_thread;
+the_mutex->nest_count = 1;
+
 /*
  * We must extract the thread now since this will restore its default
  * thread lock.  This is necessary to avoid a deadlock in the
@@ -205,9 +208,6 @@ CORE_mutex_Status _CORE_mutex_Surrender(
 if ( _Objects_Is_local_id( the_thread->Object.id ) )
 #endif
 {
-  the_mutex->holder = the_thread;
-  the_mutex->nest_count = 1;
-
   switch ( the_mutex->Attributes.discipline ) {
 case CORE_MUTEX_DISCIPLINES_FIFO:
 case CORE_MUTEX_DISCIPLINES_PRIORITY:
@@ -237,12 +237,7 @@ CORE_mutex_Status _CORE_mutex_Surrender(
 
 #if defined(RTEMS_MULTIPROCESSING)
 if ( !_Objects_Is_local_id( the_thread->Object.id ) ) {
-
-  the_mutex->holder = NULL;
-  the_mutex->nest_count = 1;
-
   ( *api_mutex_mp_support)( the_thread, id );
-
 }
 
 _Thread_Dispatch_enable( _Per_CPU_Get() );
-- 
1.8.4.5

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

[PATCH 5/8] mpci: Fix _Objects_MP_Is_remote()

2016-03-24 Thread Sebastian Huber 
Bug introduced by be8897644043e4378db7add02c3c9e1ac7fde563.

Update #2555.
---
 cpukit/score/src/objectmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/src/objectmp.c b/cpukit/score/src/objectmp.c
index be55fa7..c8f431f 100644
--- a/cpukit/score/src/objectmp.c
+++ b/cpukit/score/src/objectmp.c
@@ -269,7 +269,7 @@ void _Objects_MP_Is_remote (
 the_global_object = (Objects_MP_Control *) the_node;
 
 if ( _Objects_Are_ids_equal( the_global_object->Object.id, the_id ) ) {
-  _Thread_Unnest_dispatch();
+  _Objects_Allocator_unlock();
   *location   = OBJECTS_REMOTE;
   *the_object = (Objects_Control *) the_global_object;
   return;
-- 
1.8.4.5

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

[PATCH 3/8] mpci: Allow packet receive function to block

2016-03-24 Thread Sebastian Huber 
---
 cpukit/score/src/mpci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cpukit/score/src/mpci.c b/cpukit/score/src/mpci.c
index 132d3e5..76ca4c8 100644
--- a/cpukit/score/src/mpci.c
+++ b/cpukit/score/src/mpci.c
@@ -343,6 +343,8 @@ void _MPCI_Receive_server(
 );
 
 for ( ; ; ) {
+  executing->receive_packet = NULL;
+
   the_packet = _MPCI_Receive_packet();
 
   if ( !the_packet )
-- 
1.8.4.5

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

Re: [PATCH 4/8] mpci: Fix thread proxies

2016-03-24 Thread Joel Sherrill 
The comment is rather weak

On Thu, Mar 24, 2016 at 9:57 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  cpukit/sapi/include/confdefs.h|  4 +++-
>  cpukit/score/src/threadmp.c   | 40
> +--
>  cpukit/score/src/threadqenqueue.c | 11 ++-
>  3 files changed, 43 insertions(+), 12 deletions(-)
>
>
> @@ -74,7 +96,13 @@ Thread_Control *_Thread_MP_Allocate_proxy (
>
>  the_proxy->current_state = _States_Set( STATES_DORMANT, the_state );
>
> -the_proxy->Wait = _Thread_Executing->Wait;
> +the_proxy->Wait.id  = executing->Wait.id;
> +the_proxy->Wait.count   = executing->Wait.count;
> +the_proxy->Wait.return_argument =
> executing->Wait.return_argument;
> +the_proxy->Wait.return_argument_second  =
> executing->Wait.return_argument_second;
> +the_proxy->Wait.option  = executing->Wait.option;
> +the_proxy->Wait.return_code = executing->Wait.return_code;
> +the_proxy->Wait.timeout_code=
> executing->Wait.timeout_code;
>
>  _Chain_Append( &_Thread_MP_Active_proxies, _proxy->Active );
>
> Does this really not line up or is it just the email client?

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

[PATCH 8/8] confdefs.h hack

2016-03-24 Thread Sebastian Huber 
Not to be committed. How can we fix this?
---
 cpukit/sapi/include/confdefs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 6d67a02..715d4fc 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -132,7 +132,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
  * are used by calls like open(2) and read(2).
  */
 #ifndef CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
-  #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 3
+  #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 64
 #endif
 
 /**
@@ -1921,7 +1921,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 
   #define CONFIGURE_MULTIPROCESSING_TABLE_configuration
 
-  #define CONFIGURE_MPCI_TASKS 1
+  #define CONFIGURE_MPCI_TASKS 5
 
 #endif /* CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE */
 
-- 
1.8.4.5

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

[PATCH 4/8] mpci: Fix thread proxies

2016-03-24 Thread Sebastian Huber 
---
 cpukit/sapi/include/confdefs.h|  4 +++-
 cpukit/score/src/threadmp.c   | 40 +--
 cpukit/score/src/threadqenqueue.c | 11 ++-
 3 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 2366c7a..6d67a02 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -1899,7 +1899,9 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 #define CONFIGURE_MP_MAXIMUM_PROXIES32
   #endif
   #define CONFIGURE_MEMORY_FOR_PROXIES(_proxies) \
-_Configure_Object_RAM((_proxies) + 1, sizeof(Thread_Proxy_control) )
+(_Configure_Object_RAM((_proxies) + 1, sizeof(Thread_Proxy_control)) \
+  + _Configure_From_workspace((_proxies) \
+* THREAD_QUEUE_HEADS_SIZE(CONFIGURE_SCHEDULER_COUNT)))
 
   #ifndef CONFIGURE_MP_MPCI_TABLE_POINTER
 #include 
diff --git a/cpukit/score/src/threadmp.c b/cpukit/score/src/threadmp.c
index a084624..993271b 100644
--- a/cpukit/score/src/threadmp.c
+++ b/cpukit/score/src/threadmp.c
@@ -30,6 +30,10 @@ void _Thread_MP_Handler_initialization (
   uint32_tmaximum_proxies
 )
 {
+  Per_CPU_Control  *cpu = _Per_CPU_Get_by_index( 0 );
+  Thread_Proxy_control *proxies;
+  char *thread_queue_heads;
+  uint32_t  i;
 
   _Chain_Initialize_empty( &_Thread_MP_Active_proxies );
 
@@ -38,16 +42,32 @@ void _Thread_MP_Handler_initialization (
 return;
   }
 
+  proxies = _Workspace_Allocate_or_fatal_error(
+maximum_proxies * sizeof( *proxies )
+  );
+
+  thread_queue_heads = _Workspace_Allocate_or_fatal_error(
+maximum_proxies * THREAD_QUEUE_HEADS_SIZE( _Scheduler_Count )
+  );
 
   _Chain_Initialize(
 &_Thread_MP_Inactive_proxies,
-_Workspace_Allocate_or_fatal_error(
-  maximum_proxies * sizeof( Thread_Proxy_control )
-),
+proxies,
 maximum_proxies,
-sizeof( Thread_Proxy_control )
+sizeof( *proxies )
   );
 
+  for ( i = 0 ; i < maximum_proxies ; ++i ) {
+Thread_Control *the_thread = (Thread_Control *) [ i ];
+
+_ISR_lock_Initialize( _thread->Timer.Lock, "Thread Timer" );
+the_thread->Timer.header = >Watchdog.Header[ 
PER_CPU_WATCHDOG_RELATIVE ];
+_Watchdog_Preinitialize( _thread->Timer.Watchdog, cpu );
+
+the_thread->Wait.spare_heads =
+  thread_queue_heads + i * THREAD_QUEUE_HEADS_SIZE( _Scheduler_Count );
+_Thread_queue_Heads_initialize( the_thread->Wait.spare_heads );
+  }
 }
 
 Thread_Control *_Thread_MP_Allocate_proxy (
@@ -60,10 +80,12 @@ Thread_Control *_Thread_MP_Allocate_proxy (
   the_thread = (Thread_Control *)_Chain_Get( &_Thread_MP_Inactive_proxies );
 
   if ( !_Thread_Is_null( the_thread ) ) {
+Thread_Control *executing;
 
+executing = _Thread_Executing;
 the_proxy = (Thread_Proxy_control *) the_thread;
 
-_Thread_Executing->Wait.return_code = THREAD_STATUS_PROXY_BLOCKING;
+executing->Wait.return_code = THREAD_STATUS_PROXY_BLOCKING;
 
 the_proxy->receive_packet = _MPCI_Receive_server_tcb->receive_packet;
 
@@ -74,7 +96,13 @@ Thread_Control *_Thread_MP_Allocate_proxy (
 
 the_proxy->current_state = _States_Set( STATES_DORMANT, the_state );
 
-the_proxy->Wait = _Thread_Executing->Wait;
+the_proxy->Wait.id  = executing->Wait.id;
+the_proxy->Wait.count   = executing->Wait.count;
+the_proxy->Wait.return_argument = executing->Wait.return_argument;
+the_proxy->Wait.return_argument_second  = 
executing->Wait.return_argument_second;
+the_proxy->Wait.option  = executing->Wait.option;
+the_proxy->Wait.return_code = executing->Wait.return_code;
+the_proxy->Wait.timeout_code= executing->Wait.timeout_code;
 
 _Chain_Append( &_Thread_MP_Active_proxies, _proxy->Active );
 
diff --git a/cpukit/score/src/threadqenqueue.c 
b/cpukit/score/src/threadqenqueue.c
index e775135..803b556 100644
--- a/cpukit/score/src/threadqenqueue.c
+++ b/cpukit/score/src/threadqenqueue.c
@@ -58,6 +58,12 @@ void _Thread_queue_Enqueue_critical(
   Per_CPU_Control *cpu_self;
   bool success;
 
+#if defined(RTEMS_MULTIPROCESSING)
+  if ( _Thread_MP_Is_receive( the_thread ) && the_thread->receive_packet ) {
+the_thread = _Thread_MP_Allocate_proxy( state );
+  }
+#endif
+
   _Thread_Lock_set( the_thread, >Lock );
 
   _Thread_Wait_set_queue( the_thread, queue );
@@ -69,11 +75,6 @@ void _Thread_queue_Enqueue_critical(
   cpu_self = _Thread_Dispatch_disable_critical( lock_context );
   _Thread_queue_Queue_release( queue, lock_context );
 
-#if defined(RTEMS_MULTIPROCESSING)
-  if ( _Thread_MP_Is_receive( the_thread ) && the_thread->receive_packet )
-the_thread = _Thread_MP_Allocate_proxy( state );
-  else
-#endif
   /*
*  Set the blocking state for this thread queue in the thread.
*/
-- 
1.8.4.5

[PATCH 1/8] confdefs.h: Account for MPCI task stack

2016-03-24 Thread Sebastian Huber 
---
 cpukit/sapi/include/confdefs.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 89beb23..2366c7a 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -1919,13 +1919,19 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 
   #define CONFIGURE_MULTIPROCESSING_TABLE_configuration
 
+  #define CONFIGURE_MPCI_TASKS 1
+
 #endif /* CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE */
 
   #else
 
 #define CONFIGURE_MULTIPROCESSING_TABLENULL
 
+#define CONFIGURE_MPCI_TASKS 0
+
   #endif /* CONFIGURE_MP_APPLICATION */
+#else
+  #define CONFIGURE_MPCI_TASKS 0
 #endif /* RTEMS_MULTIPROCESSING */
 /**@}*/ /* end of Multiprocessing Configuration */
 
@@ -2066,7 +2072,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
* This is an internal parameter.
*/
   #define CONFIGURE_TASKS \
-(CONFIGURE_MAXIMUM_TASKS + CONFIGURE_LIBBLOCK_TASKS)
+(CONFIGURE_MAXIMUM_TASKS + CONFIGURE_LIBBLOCK_TASKS + CONFIGURE_MPCI_TASKS)
 
   /**
* This macro calculates the memory required for task variables.
@@ -2956,10 +2962,7 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 #ifdef CONFIGURE_MP_APPLICATION
   #define CONFIGURE_MEMORY_FOR_MP \
 (CONFIGURE_MEMORY_FOR_PROXIES(CONFIGURE_MP_MAXIMUM_PROXIES) + \
- CONFIGURE_MEMORY_FOR_GLOBAL_OBJECTS( \
- CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS) + \
- CONFIGURE_MEMORY_FOR_TASKS(1, 1) \
-  )
+ CONFIGURE_MEMORY_FOR_GLOBAL_OBJECTS(CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS))
 #else
   #define CONFIGURE_MEMORY_FOR_MP  0
 #endif
-- 
1.8.4.5

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

[PATCH 6/8] network: Special case for RTEMS_MULTIPROCESSING

2016-03-24 Thread Sebastian Huber 
Allow network tasks to run with priority 0 (PRIORITY_PSEUDO_ISR).
---
 cpukit/libnetworking/rtems/rtems_glue.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/cpukit/libnetworking/rtems/rtems_glue.c 
b/cpukit/libnetworking/rtems/rtems_glue.c
index 1355fbb..b50f734 100644
--- a/cpukit/libnetworking/rtems/rtems_glue.c
+++ b/cpukit/libnetworking/rtems/rtems_glue.c
@@ -284,7 +284,11 @@ rtems_bsdnet_initialize (void)
 */
if (rtems_bsdnet_config.network_task_priority == 0)
networkDaemonPriority = 100;
+#ifdef RTEMS_MULTIPROCESSING
+   else if (rtems_bsdnet_config.network_task_priority != UINT32_MAX)
+#else
else
+#endif
networkDaemonPriority = 
rtems_bsdnet_config.network_task_priority;
 
/*
@@ -694,6 +698,9 @@ rtems_bsdnet_newproc (char *name, int stacksize, 
void(*entry)(void *), void *arg
networkDaemonPriority,
stacksize,

RTEMS_PREEMPT|RTEMS_NO_TIMESLICE|RTEMS_NO_ASR|RTEMS_INTERRUPT_LEVEL(0),
+#ifdef RTEMS_MULTIPROCESSING
+   RTEMS_SYSTEM_TASK |
+#endif
RTEMS_NO_FLOATING_POINT|RTEMS_LOCAL,
);
if (sc != RTEMS_SUCCESSFUL)
-- 
1.8.4.5

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

Re: Participation in GSoC 2016

2016-03-24 Thread Alan Cudmore 
The Pi 1/B+ would be a good model to start the USB development with.

I have actually not built the BSD lib myself. But I think this is the place
to start:
https://git.rtems.org/rtems-libbsd/tree/libbsd.txt
https://git.rtems.org/rtems-libbsd/tree/README.waf
Looks like the arm/realview_pbx_a9_qemu BSP is the one use.

I have run some of the SMP examples on qemu with the
arm/realview_pbx_a9_qemu_smp BSP and it worked well for me.

Alan


On Wed, Mar 23, 2016 at 9:03 AM, Deval Shah  wrote:

> On Tue, Mar 22, 2016 at 10:04 PM, Alan Cudmore 
> wrote:
> > Hi Deval,
> > Your proposal looks good. I would suggest adding a step where you build a
> > known BSP with BSD lib support. It will help you become familiar with the
> > development process.
>
> Thanks for the suggestion, Alan. I will be adding this to my proposal.
> Also, which BSP would you recommend that I pick up ? Is there any list
> of currently added BSPs from which I can choose?
>
> > You should also address which Raspberry Pi model you will support. Now
> that
> > there are so many Raspberry Pi models, it might make the project more
> > complicated:
> > Original raspberry Pi Model A & A+: a single built in USB port in the
> > BCM2835 CPU. No ethernet or USB hub.
> > Raspberry Pi Model B & B+: USB hub and Ethernet in LAN9512 chip.
> > Raspberry Pi 2 Model B: USB hub and Ethernet in LAN9514 chip.
> > Raspberry Pi 3 Model B:  I would not worry about this one yet.
> > Raspberry Pi Zero: A single USB OTG port , no ethernet or USB hub.
> >
> > I would pick one of them and get it working before seeing if another
> model
> > could be supported.
> >
> > If the Raspberry Pi 1/B+ and 2/B Hubs are functionally the same ( LAN9512
> > vs. LAN9514 ), this would support the widest range of devices out there.
> >
> I was also thinking for that. I have a Raspberry PI 1/B+ and a
> majority of users have either 1/B+ or 2/B. Probably we can start with
> 1/B+ and then enable the other models.
>
> > If you have time, I would love to see USB support for the BCM2835 on the
> Pi
> > Model A+ and especially the Pi Zero.
>
> Sure, I had left some buffer time in my proposal, probably if things
> goes as per plan that time can be used for USB support for the
> BCM2835.
>
> >
> > Thanks,
> > Alan
> >
> >
> > On Tue, Mar 22, 2016 at 8:52 AM, Deval Shah 
> wrote:
> >>
> >> Hello,
> >>
> >> I have updated my draft proposal and shared on the tracking page. I'm
> >> sharing it here as well. https://goo.gl/QQiAf6
> >>
> >> Sorry, I was busy with my Mid-Semester exams, could not update earlier.
> >>
> >> Since this is a draft proposal, it may not be completely polished yet.
> >> I'd appreciate any comments on it, especially regarding the project
> >> description
> >> and timeline.
> >>
> >> Thank you.
> >>
> >> Regards,
> >> Deval Shah
> >>
> >> On Fri, Mar 11, 2016 at 11:02 PM, Deval Shah 
> >> wrote:
> >> > On Fri, Mar 11, 2016 at 8:33 PM, Gedare Bloom  wrote:
> >> >> On Fri, Mar 11, 2016 at 8:19 AM, Deval Shah 
> >> >> wrote:
> >> >>> Hello everyone!
> >> >>>
> >> >>> I went through the links and blogs of the SD card and USB/Ethernet
> >> >>> project for Raspberry PI. I would like to work for the USB/Ethernet
> >> >>> support project.
> >> >>>
> >> >>> I have prepared a draft of the timeline as follows:
> >> >>>
> >> >>> Acceptance Waiting Period:
> >> >>> Understanding previous year's GSOC work
> >> >>>
> >> >>> First Half:
> >> >>> completing USB support for RPI
> >> >>> Testing USB and add drivers for HIDs like Mouse and Keyboard
> >> >>>
> >> >>> Second Half:
> >> >>> Adding Ethernet Support
> >> >>> Testing (ARP, PING, DHCP, FTP, TFTP)
> >> >>> Adding support for lwIP (since it is already ported to BBB, this
> >> >>> should not take more time)
> >> >>>
> >> >> Timeline seems good. Is the USB support available from freebsd for
> the
> >> >> libbsd codebase?
> >> >
> >> > Yes. libbsd has support for USB.
> >> > Last year issues were in porting the driver (
> >> > http://gtament-rtems.blogspot.in/2015/06/my-progress-report.html ).
> >> >
> >> >>> If we have wifi support in RTEMS, can support of a USB wifi module
> be
> >> >>> added to the project?
> >> >>>
> >> >> I haven't seen any one using wifi yet.
> >> >>
> >> >>> I'd really appreciate any feedback on my deliverables, especially
> >> >>> regarding the feasibility of doing it in this time frame. If there
> is
> >> >>> anything I may have missed out or anything else I should consider
> as a
> >> >>> part of this, I'd be really glad if someone could point that out, so
> >> >>> as to increase my chances of selection.
> >> >>>
> >> >>> A quick question: How can I add my name to the tracking list @
> >> >>> https://devel.rtems.org/wiki/GSoC/2016 ?
> >> >>>
> >> >> You need to register an account to edit the page through link at the
> >> >> bottom.
> >> >> Okay, Thank you.
> >> >>> Deval Shah
> >> >>>
> >>

GSoC Students must submit Final PDF

2016-03-24 Thread Gedare Bloom 
Potential GSoC Students,

Please make note that you must submit your final PDF and proof of
enrollment to Google before the deadline. If you only submit your
draft proposal as a Google Document, we will not be able to accept
your project.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Request for GPIO Examples

2016-03-24 Thread punit vara 
Thank you Ketul and Worth Burruss that would be really useful for
testing. I am adding these suggestion to my proposal
https://goo.gl/cGCXbS. Any other suggestions are welcome. :-)

On Thu, Mar 24, 2016 at 10:54 AM, Ketul Shah  wrote:
> Hi Punit,
>
> Apart from what Worth Burruss suggested,
>
> First of all setting on off timing and testing on LED would be OK for
> primary testing.
>
> You can always test your PWM signals on DSO/CRO to have a clear picture of
> what is happening over signals.
>
> And if you can manage to have second BBB you can test signals on it too:-
> http://hackaday.com/2015/02/19/turn-your-beagleboneblack-in-to-a-14-channel-100msps-logic-analyzer/
>
> Also thinking towards a bit application side,
>
> Using PWM signals you can very DC motor speed using motor driver IC.
> RGB Led would be a great visual to test it and many more
>
> Hope this helps for your further testing...
>
> Ketul
>
> On 23 March 2016 at 19:51, Worth Burruss  wrote:
>>
>> On 23 Mar 2016 at 0:57, punit vara wrote:
>>
>> > Hi Worth Burruss,
>> >
>> > This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
>> > bone black BSP which includes PWM drivers as well as I2C driver. Could
>> > you please suggest me testing methods to test PWM on BBB ?
>> >
>> > Regards,
>> > Punit
>> >
>>
>> Punit,
>>
>> I will preface this with my solutions tend to be overly complex and I do
>> not know specifically
>> what is available to use to test with in the BBB.  So this may not be what
>> you are looking for.
>> It also depends on the frequency of your PWM signals.
>>
>> When I think of test on hardware, I want to know it is working the way I
>> think it is working
>> (proving correctness).  For PWM, this means the duty cycle is correct.  I
>> would be using
>> another hardware counter timer to measure the High time followed by the
>> Low time and doing
>> the math to prove that the times are correct for the programmed duty
>> cycle.
>>
>> As an alternate, with appropriate selection of PWM frequency and software
>> timers, you can
>> do the High and low counting using the timers.
>>
>> As for me, I would find it hard to see the change in an LED's intensity
>> except in a crude
>> fashion, so would not meet my personal goal of proving correctness.   But
>> you may be
>> thinking of ON and OFF times in seconds, In which case an LED and maybe a
>> stop watch
>> would be appropriate.
>>
>> Hopefully this gives you some ideas.
>>
>> Thank you,
>>
>> Worth Burruss
>>
>>
>>
>>
>> ___
>> 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: Request for GPIO Examples

2016-03-24 Thread punit vara 
On Wed, Mar 23, 2016 at 7:51 PM, Worth Burruss  wrote:
> On 23 Mar 2016 at 0:57, punit vara wrote:
>
>> Hi Worth Burruss,
>>
>> This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
>> bone black BSP which includes PWM drivers as well as I2C driver. Could
>> you please suggest me testing methods to test PWM on BBB ?
>>
>> Regards,
>> Punit
>>
>
> Punit,
>
> I will preface this with my solutions tend to be overly complex and I do not 
> know specifically
> what is available to use to test with in the BBB.  So this may not be what 
> you are looking for.
> It also depends on the frequency of your PWM signals.
>
> When I think of test on hardware, I want to know it is working the way I 
> think it is working
> (proving correctness).  For PWM, this means the duty cycle is correct.  I 
> would be using
> another hardware counter timer to measure the High time followed by the Low 
> time and doing
> the math to prove that the times are correct for the programmed duty cycle.
>
> As an alternate, with appropriate selection of PWM frequency and software 
> timers, you can
> do the High and low counting using the timers.
>
> As for me, I would find it hard to see the change in an LED's intensity 
> except in a crude
> fashion, so would not meet my personal goal of proving correctness.   But you 
> may be
> thinking of ON and OFF times in seconds, In which case an LED and maybe a 
> stop watch
> would be appropriate.
>
> Hopefully this gives you some ideas.
>
> Thank you,
>
> Worth Burruss
>
>
>
>
Did you mean to say ?  General purpose timer that is continuous
increasing can be configured to toggle the PWM output high when a
certain value reached and low when it overflows. I have referred this
from here (

Activating PWM via Timer Registers)

http://elinux.org/BeagleBoardPWM#OMAP_Mux_Configuration
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel