Re: GSOC 2015: Configuration GUI

[siddharth singh]

Dear Amar,
I have build rtems on my system on my system, went a bit through
docmentation and wikis, wxPython(quite similar to PyQt). I have a query,
Is this project related to this(https://github.com/shubhamsomani/GUI) or it
is a fresh project or its something else?
Secondly, I didn't complete understand the role of waf/GUI, what is
actually 'waf'?

Regards
Siddharth Singh

On Tue, Mar 10, 2015 at 11:38 PM, Amar Takhar  wrote:

> On 2015-03-10 22:59 +0530, siddharth singh wrote:
> > Dear Mentors,
> >
> > I am Siddharth Singh currently pursuing B.Tech at IIIT-Delhi, India.
> >
> > I am willing to contribute to Configuration GUI project, I have a past
> > experience of working on PyQt(GUI) and would like to contribute in the
> same
> > field.
>
> We will be using wxPython located at http://www.wxpython.org/
>
> While it is different from Qt your experience there will help a lot with
> using
> wxWidgets.
>
>
> > Here is my github profile :
> > https://github.com/siddharth7
>
> OK thanks.
>
>
> > It would be good to have some more details on the project from your side
> as the
> > Idea page is not much informative(
> https://devel.rtems.org/wiki/Developer/
> > Projects/ConfigGUI)
>
> Yes, I created that page to make others aware this is a project we want
> students
> to consider.
>
> There aren't many details beyond what I wrote on that page as I wanted to
> leave
> it open for anyone writing a proposal.  If you look on the secondary wiki
> pages
> listed you'll see a list of options in options.py.  These are all typed
> any GUI
> written can use these types and automatically build each panel and do
> bounds
> checking.
>
>
> Amar.
> ___
> 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

GSOC 2015 Monkey HTTP Server

[Sujay Raj]

Hi,
I am interested in working on porting the Monkey HTTP Server to RTEMS
as a GSOC project.

This is the first time I am applying to GSOC and though I have written
a lot of code, it is also my first attempt at working in an Open
Source project.

Some personal projects that I have worked on include developing a
hobby operating system ( following Bran's Kernel Development Tutorial
and osdev ), writing ray tracers, as well as porting the nweb web
server ( 200 lines of C code ) to python ( it was undertaken as an
exercise to learn more about the functioning and implementation of
webservers ). Further I have familiarity with x86 assembly (nasm), not
extraordinary, but fluent.

I have successfully compiled and executed sample programs for
sparc-sis but from what I have read sparc-sis doesn't support TCP/IP.
So I followed the wiki and compiled it for pc386 on QEMU too as it had
networking support.

I was wondering if this may be the required architecture and simulator
for this project.

Further, I would like to mention, that though this may be an approach
with GSOC in mind, but I wish to end up as a full time contributor for
the RTEMS project in time to come as it suits my taste and past
experience.

Kindly point out things I need to do to proceed and other comments.

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

Re: GSOC 2015 Monkey HTTP Server

[Joel Sherrill]

cc'ing Eduardo Silva from the Monkey project. Eduardo,
you may have to subscribe to get messages back to the
RTEMS list.

On 3/11/2015 3:45 PM, Sujay Raj wrote:
> Hi,
> I am interested in working on porting the Monkey HTTP Server to RTEMS
> as a GSOC project.
>
> This is the first time I am applying to GSOC and though I have written
> a lot of code, it is also my first attempt at working in an Open
> Source project.
>
> Some personal projects that I have worked on include developing a
> hobby operating system ( following Bran's Kernel Development Tutorial
> and osdev ), writing ray tracers, as well as porting the nweb web
> server ( 200 lines of C code ) to python ( it was undertaken as an
> exercise to learn more about the functioning and implementation of
> webservers ). Further I have familiarity with x86 assembly (nasm), not
> extraordinary, but fluent.
>
> I have successfully compiled and executed sample programs for
> sparc-sis but from what I have read sparc-sis doesn't support TCP/IP.
> So I followed the wiki and compiled it for pc386 on QEMU too as it had
> networking support.
You either want to use pc386 on qemu or arm/zynq on qemu.
> I was wondering if this may be the required architecture and simulator
> for this project.
>
> Further, I would like to mention, that though this may be an approach
> with GSOC in mind, but I wish to end up as a full time contributor for
> the RTEMS project in time to come as it suits my taste and past
> experience.
>
> Kindly point out things I need to do to proceed and other comments.
Eduardo mentioned that this may not be enough to occupy your entire
summer. So we would need to identify other work to bundle with this.

Monkey for RTEMS should get built as a package inside the RSB. This
is like the BSD ports where it always builds from source. Fetch upstream,
patch as needed and build for the embedded architecture.

Random idea which would need other mentors to buy into. We have an
old IPV4 stack in the current tree. We have a newer IPV4/V6 IP stack
outside the tree. And there is a working LWIP port. My concept long
term has been to divide things into packages:

+ RTEMS (ok done)
+ network stack of choice - done for new IPV4/IPV6 stack. current
   stack is in tree, would need to be pulled out into its own build
   module, LWIP is a candidate for RSB packaging but could get done
  by another student as part of BeagleBone work.
+ network tests - some in the tree, some in network-demos
+ network servers - ftpd, web servers, telnetd, pppd, etc should be
   packages that can be built against your network stack of choice

This idea hasn't been reviewed by anyone so would need feedback
but conceptually, it makes network services an add-on to the RTEMS
core and makes it easier for users to pick a stack. More modular
pieces.

The first step though is getting Monkey ported as a package. The
other steps would need discussing.
> Regards
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985


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

[PATCH] posix/src/nanosleep.c: Address issue when delay is longer than desired

[Joel Sherrill]

This resulted in the elapsed time going below 0 and an arbitrarily large
number returned as the time remaining.

closes #2296.
---
 cpukit/posix/src/nanosleep.c | 43 +++
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/cpukit/posix/src/nanosleep.c b/cpukit/posix/src/nanosleep.c
index 1fbeaa3..39ae84d 100644
--- a/cpukit/posix/src/nanosleep.c
+++ b/cpukit/posix/src/nanosleep.c
@@ -1,12 +1,12 @@
 /**
  * @file
  *
- * @brief Suspends Execution of calling thread until Time elaps
+ * @brief Suspends Execution of calling thread until Time elapses
  * @ingroup POSIXAPI
  */
 
 /*
- *  COPYRIGHT (c) 1989-2007.
+ *  COPYRIGHT (c) 1989-2015.
  *  On-Line Applications Research Corporation (OAR).
  *
  *  The license and distribution terms for this file may be
@@ -29,7 +29,6 @@
 /*
  *  14.2.5 High Resolution Sleep, P1003.1b-1993, p. 269
  */
-
 int nanosleep(
   const struct timespec  *rqtp,
   struct timespec*rmtp
@@ -42,6 +41,7 @@ int nanosleep(
   Thread_Control *executing;
 
   Watchdog_Interval  ticks;
+  Watchdog_Interval  elapsed;
 
 
   /*
@@ -53,6 +53,9 @@ int nanosleep(
   if ( !_Timespec_Is_valid( rqtp ) )
 rtems_set_errno_and_return_minus_one( EINVAL );
 
+  /*
+   * Convert the timespec delay into the appropriate number of clock ticks.
+   */
   ticks = _Timespec_To_ticks( rqtp );
 
   /*
@@ -60,7 +63,6 @@ int nanosleep(
*  This behavior is also beyond the POSIX specification but is
*  consistent with the RTEMS API and yields desirable behavior.
*/
-
   if ( !ticks ) {
 _Thread_Disable_dispatch();
   executing = _Thread_Executing;
@@ -91,24 +93,33 @@ int nanosleep(
 _Watchdog_Insert_ticks( &executing->Timer, ticks );
   _Thread_Enable_dispatch();
 
-  /* calculate time remaining */
+  /*
+   * Calculate the time that passed while we were sleeping and how
+   * much remains from what we requested.
+   */
+  elapsed = executing->Timer.stop_time - executing->Timer.start_time;
+  if ( elapsed >= ticks )
+ticks = 0;
+  else
+ticks -= elapsed;
 
+  /*
+   * If the user wants the time remaining, do the conversion.
+   */
   if ( rmtp ) {
-ticks -= executing->Timer.stop_time - executing->Timer.start_time;
-
 _Timespec_From_ticks( ticks, rmtp );
+  }
 
+  /*
+   *  Only when POSIX is enabled, can a sleep be interrupted.
+   */
+  #if defined(RTEMS_POSIX_API)
 /*
- *  Only when POSIX is enabled, can a sleep be interrupted.
+ *  If there is time remaining, then we were interrupted by a signal.
  */
-#if defined(RTEMS_POSIX_API)
-/*
- *  If there is time remaining, then we were interrupted by a signal.
- */
-if ( ticks )
-  rtems_set_errno_and_return_minus_one( EINTR );
-#endif
-  }
+if ( ticks )
+  rtems_set_errno_and_return_minus_one( EINTR );
+  #endif
 
   return 0;
 }
-- 
1.9.3

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

problem when runing rpi sample on gdb simu

[QIAO YANG]

Hello ,

I was wondering if the raspberry pi samples can run on arm-rtems4.11-gdb. I 
thought I had done the compilations correctly according to Mr Alan's blog, but 
it just stand still when running the sample in the simulator.

I'm not sure if it's my problem or it can only run on a real rpi board.  If 
it's my own problem I'll double check what I've done, if not I've got to wait 
until next week to post my hello demo when the cable arrives.

here's the output of gdb:

Reading symbols from 
./arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/hello.exe...done.
(gdb) tar sim
Connected to the simulator.
(gdb) load
Loading section .start, size 0x340 vma 0x8000
Loading section .text, size 0x17920 vma 0x8340
Loading section .init, size 0x18 vma 0x1fc60
Loading section .fini, size 0x18 vma 0x1fc78
Loading section .rodata, size 0xc30 vma 0x10
Loading section .ARM.exidx, size 0x8 vma 0x100c30
Loading section .eh_frame, size 0x48 vma 0x100c38
Loading section .init_array, size 0x4 vma 0x100c80
Loading section .fini_array, size 0x4 vma 0x100c84
Loading section .jcr, size 0x4 vma 0x100c88
Loading section .data, size 0x5e8 vma 0x100c90
Start address 0x8040
Transfer rate: 817184 bits in <1 sec.
(gdb) r
Starting program: 
/home/yangqiao/development/rtems/build-rtems-rpi/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/hello.exe

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

Re: rtems-source-builder on cygwin/64

[Chris Johns]

On 12/03/2015 4:59 am, emanuel stiebler wrote:

On 2015-03-11 18:40, Joel Sherrill wrote:



On 3/11/2015 12:12 PM, emanuel stiebler wrote:

Hi all,
should it work at the moment?

Since Chris is likely the best one to answer that and he won't be
online for at least a a few hours, give it a try. You will know the
answer before he wakes up. :)


I do not test cygwin but will accept patches if they look ok.

I invested a large amount time last year attempting to get cygwin to 
build native tools and gave up. I just could not get anything close to 
stable and then I really had no idea what I had got cygwin to actually 
install (I suspect that is just my lack of knowledge). I am not sure 
about building cygwin hosted versions of the tools.


I have always built and used native Windows tools and up until recently 
I have been using a Canadian cross (Cxc) build on FreeBSD. Native 
Windows tools run at the best possible speed on Windows because there is 
no POSIX emulation layer and they integrate into other Windows tools, 
such as IDEs, because the paths used are standard Windows paths. When 
combined with waf as a build system the overall performance and 
stability is excellent.


I have recently just pushed changes into the RSB to support MSYS2 and I 
am in the process of updating the RSB documentation to outline what you 
need to do. I have been able to build an ARM compiler tool chain on 
Windows using MSYS2 and this is first for many years. It take a while so 
please be patient. The doco update is:


--
MSYS2

This is a new version of the old MinGW project's original MSYS based 
around the Arch Linux pacman packager. MSYS and MSYS2 are a specific 
fork of the Cygwin project with some fundamental changes in the handling 
of paths and mounts that allow easy interaction between the emulated 
POSIX environment and the native Windows environment.


Install MSYS2 using the installer you can download from 
https://msys2.github.io/. Follow the instructions on the install page 
and make sure you remove any global path entries to any other Cygwin, 
MinGW, MSYS or packages that may uses a Cygwin DLL, for example some 
ports of Git.


To build the tools you need install the following packages using pacman:

 $ pacman -S git cvs bison make texinfo patch unzip diffutils tar \
  mingw64/mingw-w64-x86_64-gcc mingw64/mingw-w64-x86_64-binutils

To build make sure you add '--without-python --jobs=none' to the 
standard RSB command line. MSYS2 has a temp file name issue and so the 
GNU AR steps on itself when running in parallel on SMP hardware which 
means we have to set the jobs option to none.


Install a suitable version of Python from http://www.python.org/ and add 
it to the start of your path. The MSYS2 python does not work with waf.

--

Finally there are a couple of issues we are looking into:

1. The gdb-7.8.2 does not build for Windows. We need gdb-7.9 however 
some local RTEMS patches need updating before we can switch all targets 
to that version. The ARM target has been switched.


2. Building rtems-tools, which happens when building the tools, is 
failing for some Windows users. The RTEMS ticket #2205 details the 
issue. If you can add anything please do.




I'm on cygwin, and it sits after just few hundred lines in

/bin/sh ./libtool --silent --mode=link gcc -O2 -pipe
-I/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/include
-std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -no-undefined
-version-info 7:0:6 -rpath /opt/rtems-4.11/lib
-L/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/lib
-o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo

and cpu usage goes back to 0% ...



At a guess this looks like a make issue with the -j option which is the 
default for the RSB. try '--jobs=none'. I have observed both MinGW MSYS 
and Cygwin suffer from incorrect handling of the wait status returned 
from fork calls in make which results in make stalling and this happening.


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

Re: rtems-source-builder on cygwin/64

[emanuel stiebler]

On 2015-03-12 02:56, Chris Johns wrote:> On 12/03/2015 4:59 am, emanuel 
stiebler wrote:

>> On 2015-03-11 18:40, Joel Sherrill wrote:
>>>
>>>
>>> On 3/11/2015 12:12 PM, emanuel stiebler wrote:
 Hi all,
 should it work at the moment?
>>> Since Chris is likely the best one to answer that and he won't be
>>> online for at least a a few hours, give it a try. You will know the
>>> answer before he wakes up. :)
>
> I do not test cygwin but will accept patches if they look ok.

OK, is there a option which downloads and patches everything and then 
tries do compile?


And, where to change the "-j 8" on the makefiles?
I noticed, that sometimes cygwin doesn't get the "process finished" 
right and waits. So for debugging, "-j 1" should be better ..


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

Re: GSOC 2015 - SMP Projects

[Sebastian Huber]

On 10/03/15 22:20, Joel Sherrill wrote:


On 3/10/2015 4:18 PM, Joel Sherrill wrote:

On 3/10/2015 10:04 AM, Gedare Bloom wrote:

On Tue, Mar 10, 2015 at 10:19 AM, Rohini Kulkarni  wrote:

Hi All,
I am interested in doing a project under SMP  (Improvements to SMP support).
Are there any suitable SMP projects which can be undertaken as part of GSOC.
However,I do not have an experience with such kind of development.


You might like to consider improving the x86-SMP support. Currently
there is no one maintaining it, so there is some maintenance work to
do such as [1], and there may be some improvement as well in the
interrupt handling. This would require some x86 assembly if you know
it or are comfortable learning it.

You could also look into extending the existing SMP support to other
BSPs in SPARC, ARM, or PowerPC, or in porting another architecture to
SMP.

Gedare and I chatted earlier so let me rattle off some ideas:

+ x86 context switch hand off (#2183)


For someone with x86 knowledge this should be a one hour job.


+ x86 proper APIC support
+ rtems_ada_self is broken on SMP (#2289) - switch to pthread keys


The Ada self context is part of the TCB, so a simple wrapper function 
should do it, like __getreent().



+ object extend on SMP (#2280)


The problem with this task is that we don't know which level of support 
we need. It ranges from not supporting object extend on SMP to something 
that uses hazard pointers (patent issues need to be considered).



+ other tickets with SMP in the description or component


I don't see anything suitable for a GSoC project in the SMP area.


Should have mentioned that Thread Local Storage (TLS) may not be
available on all architectures so adding that where supported by
gcc would be beneficial.

Although a lot has been done, there is a lot left to be done. And
a ticket doesn't necessarily equal a bug for us. We are trying to
use tickets to track all ideas for work.

There continues to be a lot of ongoing SMP work documented here [2].
You may like to browse the list and ask if any of those are possibly
good options.

[1] https://devel.rtems.org/ticket/2183
[2] https://devel.rtems.org/wiki/Developer/SMP


Thanks!


___
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


--
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: New source layout.

[Sebastian Huber]

On 09/03/15 18:02, Amar Takhar wrote:

On 2015-03-09 14:18 +0100, Sebastian Huber wrote:

>This is actually a big problem and will break a lot of thinks. Currently
>you use
>
>#include 
>
>and get for example RTEMS_BSP_NETWORK_DRIVER_ATTACH for the network
>configuration.
>
>You find the  via the -B compiler switch.

This will be changed so it is no longer required.  The real problem is that we
have to use multiple -I and -B.

The waf build does not use -B anywhere yet it works perfectly fine.  All I am
proposing is unwinding all the include hacks that I added and being explicit.


We need at least three -I options, one for the BSP headers, one for the 
CPU headers and one for the rest.


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

[PATCH] rtems: Use atomic operation with correct type

[Daniel Cederman]

---
 c/src/lib/libcpu/shared/src/cache_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c/src/lib/libcpu/shared/src/cache_manager.c 
b/c/src/lib/libcpu/shared/src/cache_manager.c
index 7ff1166..89ec88f 100644
--- a/c/src/lib/libcpu/shared/src/cache_manager.c
+++ b/c/src/lib/libcpu/shared/src/cache_manager.c
@@ -189,7 +189,7 @@ _Cache_manager_Send_smp_msg(
 
   _Cache_manager_Process_cache_messages();
 
-  while ( !_Atomic_Load_uint( &node.done, ATOMIC_ORDER_ACQUIRE ) );
+  while ( !_Atomic_Load_ulong( &node.done, ATOMIC_ORDER_ACQUIRE ) );
 }
 #endif
 
-- 
2.2.1

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

Re: New source layout.

[Amar Takhar]

On 2015-03-11 09:44 +0100, Sebastian Huber wrote:
> We need at least three -I options, one for the BSP headers, one for the 
> CPU headers and one for the rest.

The current one uses only one -I because all paths will be explicit.  Right now 
I've hacked around the problem with the header redirectors.


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

Re: GSoC 2015 Introduction - Condition Variables (CV)

[Andrei - Constantin Popescu]

Hello!

As stated here  I have
installed RSB, rtems and compiled the modified Hello, world ! test

The  patch is attached to this mail and you can find the snapshot here
. Next, I'm going to do some research about
what condition variable imply in general and how do they work. If you have
any suggestions on where should I research or if there are any tasks(at
Rtems) I could complete complementary to this project, please let me know.

Also, thank you! The support on IRC has been great !

Regards,
Andrei

2015-03-11 12:03 GMT+02:00 Andrei - Constantin Popescu <
popescu.andrei1...@gmail.com>:

> Hello!
>
> As stated here  I have
> installed RSB, rtems and compile the modified Hello, world ! test
>
> The proofs are attached to this mail. Next, I'm going to do some research
> about what condition variable imply in general and how do they work. If you
> have any suggestions on where should I research or if there are any
> tasks(at Rtems) I could complete complementary to this project, please let
> me know.
>
> Also, thank you! The support on IRC has been great !
>
> Regards,
> Andrei
>
> 2015-03-09 13:54 GMT+02:00 Andrei - Constantin Popescu <
> popescu.andrei1...@gmail.com>:
>
>> Hello!
>>
>> As discussed with Sebastian Huber on IRC , is there someone else
>> able/willing to mentor this project or should I look for a different one ?
>>
>> Kind regards,
>> Andrei
>>
>> 2015-03-09 8:51 GMT+02:00 Andrei - Constantin Popescu <
>> popescu.andrei1...@gmail.com>:
>>
>>> Hello!
>>>
>>> I'm Andrei(Andrei - Constantin Popescu, more exactly),  a Computer
>>> Science graduate at Polytechnic University of Bucharest, Romania. I will
>>> begin my Masters' degree at Vrije University, Amsterdam this fall. During
>>> the undergraduate studies, I pursued a high diversity in computer science
>>> skills, from web development, to kernel development. I  took part in GSoC
>>> 2012 and GSoC 2014, both with BRL-CAD. You can find both the devlogs and my
>>> 2014 proposal here  .
>>> Aside of that, I've also participated with them as  a Google Code-in mentor
>>> for the past three years, so you can say I like open source, specially the
>>> freedom to scratch your own itch.
>>>
>>> I was browsing for a project and I came across RTEMS ideas page and then 
>>> RTEMS
>>> on Wikipedia soon after.  I'm
>>> interested in Operating Systems of any kind, since they're complex software
>>> products on which so many other applications rely on, so I decided to have
>>> a look. Another factor that contributed to my decision that I would like to
>>> code at RTEMS for GSoC 2015 was that my background is helpful in this
>>> aspect. I've been a kernel developer intern for about 8 months at Freescale
>>> and I'm currently employed as a C++ software engineer to a company
>>> producting VoIP software which runs on a RT system.
>>>
>>> The project I decided on is Condition Variables
>>> ,
>>> I have at least a general idea about how monitors and condition variables
>>> work and since RTEMS is a single process, multithreaded system, my
>>> understanding is that it's an useful/important feature. Unfortunately, the 
>>> Resources
>>> URL is broken, but I'll be on IRC most of the time, probably asking
>>> lots of silly questions! I'll (try to) get RTEMS built as soon as
>>> possible.  If you have any suggestions, or tasks  you believe would help me
>>> better understand this project please tell.
>>>
>>> This project, as well as my( probably not entirely correct)
>>> understanding of RTEMS concepts look interesting, I'm excited to be here
>>> and can't wait to build RTEMS to see how it is/how it works. I'm also
>>> curious, on a high level, how RTEMS differs from linux kernel. I hope I'll
>>> be able to tackle this project and complete it succesfully  as it's my
>>> first "close encounter" with a purposely designed rt os!
>>>
>>> Silly question #1, could you tell me a few products that use/rely on
>>> RTEMS? I tried googling for it but was unsuccesful.  Thank you!
>>>
>>> Regards,
>>> Andrei
>>>
>>>
>>>
>>
>
diff --git a/hello/hello_world_c/test.c b/hello/hello_world_c/test.c
index 04a55fe..438d86b 100644
--- a/hello/hello_world_c/test.c
+++ b/hello/hello_world_c/test.c
@@ -11,7 +11,9 @@ rtems_task Init(
 )
 {
   printf( "\n\n*** HELLO WORLD TEST ***\n" );
-  printf( "Hello World\n" );
+  printf( "Hello World, from Andrei\n" );
+  printf( "This is my 2015 GSoC first step as an applicant\n");
+  printf( "You can find me on IRC as andrei_\n");
   printf( "*** END OF HELLO WORLD TEST ***\n" );
   exit( 0 );
 }
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2015 - Raspberry Pi improvements

[Rohini Kulkarni]

Hi,

I am interested in contributing to this project. I referred the page Raspberry
Pi improvements

and also took a look at the work done under GSoc2013
. It
would be great if the mentors could help me with some queries.

[1] Is there any reference for already proposed ideas. On the page Beagle
BSP improvements
 , I
saw a list of missing peripherals. Is there such a list for Raspberry Pi as
well?

[2] What are the requirements and how should I proceed for this project.


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

[PATCH] dosfs: avoid buffer-overread. closes #2292.

[Gedare Bloom]

---
 cpukit/libfs/src/dosfs/msdos_misc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c 
b/cpukit/libfs/src/dosfs/msdos_misc.c
index fdac613..76dff43 100644
--- a/cpukit/libfs/src/dosfs/msdos_misc.c
+++ b/cpukit/libfs/src/dosfs/msdos_misc.c
@@ -1055,8 +1055,8 @@ msdos_get_utf16_string_from_long_entry (
 
 if (is_first_entry) {
 for (chars_in_entry = 0;
- (entry_string_buf[chars_in_entry] != 0x
-  && chars_in_entry < MSDOS_LFN_LEN_PER_ENTRY );
+ (   chars_in_entry < MSDOS_LFN_LEN_PER_ENTRY
+  && entry_string_buf[chars_in_entry] != 0x);
   ++chars_in_entry) {
 ;
 }
-- 
1.9.1

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

Re: GSoC 2015 - Raspberry Pi improvements

[Gedare Bloom]

On Wed, Mar 11, 2015 at 9:52 AM, Rohini Kulkarni  wrote:
> Hi,
>
> I am interested in contributing to this project. I referred the page
> Raspberry Pi improvements and also took a look at the work done under
> GSoc2013. It would be great if the mentors could help me with some queries.
>
> [1] Is there any reference for already proposed ideas. On the page Beagle
> BSP improvements , I saw a list of missing peripherals. Is there such a list
> for Raspberry Pi as well?
>
There was an email thread about this recently, see [1]. I think there
is plenty of work to do.

> [2] What are the requirements and how should I proceed for this project.
>
You need to own a Raspberry Pi, or a Raspberry Pi 2. If you have an
RPi2, you may consider adding it as a BSP variant and getting SMP
working on it as a nice project. You should ideally demonstrate that
you can build the tools and boot RTEMS on the RPi.

[1] https://lists.rtems.org/pipermail/devel/2015-March/010181.html

>
> Thanks!
>
>
>
> ___
> 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

Mentors wanted: raspberry pi and beagleboard

[Gedare Bloom]

Hi,

We are getting quite a few inquiries about Raspberry Pi and
Beagleboard improvement projects, which is great! I'm hoping there
might be some experienced RTEMS users or developers out there who are
interested in either of those boards and would be willing to co-mentor
projects that use them if accepted.

If so, please take the time to fill out a profile on
https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and open
a connection with the RTEMS Project.

And, of course, anyone else who just wants to be a co-mentor is
welcome to join! It is especially helpful to get extra eyes to review
student proposals.

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

[PATCH 1/5] cpukit: Remove old DESCRIPTION: in comments

[Joel Sherrill]

These were remnants of pre-Doxygen comment style.
---
 cpukit/libmisc/capture/capture-cli.c   | 60 --
 cpukit/libmisc/capture/capture-cli.h   |  3 --
 cpukit/libmisc/capture/capture_support.c   |  7 +--
 cpukit/libmisc/fb/fb.h |  3 --
 cpukit/libmisc/fb/mw_uid.c |  9 ++--
 cpukit/rtems/include/rtems/rtems/sem.h |  8 ++--
 cpukit/rtems/src/barrier.c | 28 
 cpukit/rtems/src/semrelease.c  | 16 +--
 cpukit/score/cpu/m68k/rtems/score/m68k.h   | 10 ++---
 cpukit/score/include/rtems/score/coremsgimpl.h |  6 ---
 cpukit/score/include/rtems/score/coresemimpl.h |  3 --
 cpukit/score/src/coremutexsurrender.c  |  2 -
 12 files changed, 24 insertions(+), 131 deletions(-)

diff --git a/cpukit/libmisc/capture/capture-cli.c 
b/cpukit/libmisc/capture/capture-cli.c
index d790b85..b2200bc 100644
--- a/cpukit/libmisc/capture/capture-cli.c
+++ b/cpukit/libmisc/capture/capture-cli.c
@@ -55,11 +55,8 @@ static rtems_capture_timestamp capture_timestamp;
 /*
  * rtems_capture_cli_open
  *
- *  DESCRIPTION:
- *
  * This function opens the capture engine. We need the size of the
  * capture buffer.
- *
  */
 
 static const char* open_usage = "usage: copen [-i] size\n";
@@ -129,10 +126,7 @@ rtems_capture_cli_open (int
argc,
 /*
  * rtems_capture_cli_close
  *
- *  DESCRIPTION:
- *
  * This function closes the capture engine.
- *
  */
 
 static void
@@ -157,10 +151,7 @@ rtems_capture_cli_close (int   
 argc RC_UNUSED,
 /*
  * rtems_capture_cli_enable
  *
- *  DESCRIPTION:
- *
  * This function enables the capture engine.
- *
  */
 
 static void
@@ -185,10 +176,7 @@ rtems_capture_cli_enable (int  
  argc RC_UNUSED,
 /*
  * rtems_capture_cli_disable
  *
- *  DESCRIPTION:
- *
  * This function disables the capture engine.
- *
  */
 
 static void
@@ -253,11 +241,8 @@ rtems_capture_cli_print_task (rtems_tcb *tcb)
 /*
  * rtems_capture_cli_count_tasks
  *
- *  DESCRIPTION:
- *
  * This function is called for each tcb and counts the
  * number of tasks.
- *
  */
 
 static void
@@ -270,10 +255,7 @@ rtems_capture_cli_count_tasks (rtems_tcb *tcb)
 /*
  * rtems_capture_cli_task_list
  *
- *  DESCRIPTION:
- *
  * This function lists the tasks the capture engine knows about.
- *
  */
 
 static void
@@ -298,10 +280,7 @@ rtems_capture_cli_task_list (int   
 argc RC_UNUSED,
 /*
  * rtems_capture_cli_watch_list
  *
- *  DESCRIPTION:
- *
  * This function lists the controls in the capture engine.
- *
  */
 
 static void
@@ -316,10 +295,7 @@ rtems_capture_cli_watch_list (int  
  argc RC_UNUSED,
 /*
  * rtems_capture_cli_get_name_id
  *
- *  DESCRIPTION:
- *
  * This function checks arguments for a name or an id.
- *
  */
 
 static bool
@@ -375,11 +351,8 @@ rtems_capture_cli_get_name_id (char*   arg,
 /*
  * rtems_capture_cli_watch_add
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command that add a watch to the capture
  * engine.
- *
  */
 
 static char const * watch_add_usage = "usage: cwadd [task name] [id]\n";
@@ -438,11 +411,8 @@ rtems_capture_cli_watch_add (int   
 argc,
 /*
  * rtems_capture_cli_watch_del
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command that deletes a watch from the capture
  * engine.
- *
  */
 
 static char const * watch_del_usage = "usage: cwdel [task name] [id]\n";
@@ -501,10 +471,7 @@ rtems_capture_cli_watch_del (int   
 argc,
 /*
  * rtems_capture_cli_watch_control
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command that controls a watch.
- *
  */
 
 static char const * watch_control_usage = "usage: cwctl [task name] [id] 
on/off\n";
@@ -568,10 +535,7 @@ rtems_capture_cli_watch_control (int   
 argc,
 /*
  * rtems_capture_cli_watch_global
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command that sets a global watch.
- *
  */
 
 static char const * watch_global_usage = "usage: cwglob on/off\n";
@@ -622,10 +586,7 @@ rtems_capture_cli_watch_global (int
argc,
 /*
  * rtems_capture_cli_watch_ceiling
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command that sets watch ceiling.
- *
  */
 
 static char const * watch_ceiling_usage = "usage: cwceil priority\n";
@@ -673,10 +634,7 @@ rtems_capture_cli_watch_ceiling (int   
 argc,
 /*
  * rtems_capture_cli_watch_floor
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command that sets watch floor.
- *
  */
 
 static char const * watch_floor_usage = "usage: cwfloor priority\n";
@@ -724,10 +682,7 @@ rtems_capture_cli_watch_floor (int 
   argc,
 /*
  * rtems_capture_cli_trigger_worker
  *
- *  DESCRIPTION:
- *
  * This function is a monitor command t

[PATCH 2/5] cpukit/include/rtems/bspIo.h: Add Doxygen comments

[Joel Sherrill]

---
 cpukit/include/rtems/bspIo.h | 136 ++-
 1 file changed, 107 insertions(+), 29 deletions(-)

diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index df068a1..dde8d94 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -14,6 +14,7 @@
  *  found in the file LICENSE in this distribution or at
  *  http://www.rtems.org/license/LICENSE.
  */
+
 #ifndef _RTEMS_BSPIO_H
 #define _RTEMS_BSPIO_H
 
@@ -21,59 +22,136 @@
 extern "C" {
 #endif
 
-/*
- * All the functions declared as extern after this comment
- * MUST be implemented in each BSP. Using this function,
- * this directory contains shared code that export higher level
- * functionnality described after the next command.
+/**
+ * @defgroup BSPIO Kernel Print Support
+ *
+ * This module contains all methods and support related to providing
+ * kernel level print support.
+ *
+ * The following variables below are declared as extern and
+ * MUST be declared and initialized in each BSP. Using this indirect
+ * function, the functionality in this group is tailored for the BSP.
+ *
+ *  - BSP_output_char
+ *  - BSP_poll_char
+ */
+
+/**
+ * This type defines the prototype for the BSP provided method to
+ * print a single character. It is assumed to be polled.
  */
 typedef void   (*BSP_output_char_function_type)(char c);
+
+/**
+ * This type defines the prototype for the BSP provided method to
+ * input a single character. It is assumed to be polled.
+ */
 typedef int(*BSP_polling_getchar_function_type)(void);
 
+/**
+ * This variable points to the BSP provided method to output a
+ * character for the purposes of debug output.
+ */
 extern BSP_output_char_function_type   BSP_output_char;
-extern BSP_polling_getchar_function_type   BSP_poll_char;
 
-/*
- * All the function declared as extern after this comment
- * are available for each BSP by compiling and linking
- * the files contained in this directory PROVIDED definition
- * and initialisation of the previous variable are done.
+/**
+ * This variable points to the BSP provided method to input a
+ * character for the purposes of debug input.
  */
+extern BSP_polling_getchar_function_type   BSP_poll_char;
+
 #include 
 
 /**
- *  This method polls for a key in the simplest possible fashion
- *  from whatever the debug console device is.
+ * @brief Get Character (kernel I/O)
  *
- *  @return If a character is available, it is returned.  Otherwise
- *  this method returns -1.
+ * This method polls for a key in the simplest possible fashion
+ * from whatever the debug console device is.
  *
- *  @note This method uses the BSP_poll_char pointer to a BSP
- *provided method.
+ * @return If a character is available, it is returned.  Otherwise
+ * this method returns -1.
+ *
+ * @note This method uses the BSP_poll_char pointer to a BSP
+ *   provided method.
  */
 extern int getchark(void);
+
+/**
+ * @brief Variable Argument printk()
+ *
+ * This method allows the user to access printk() functionality
+ * with a va_list style argument.
+ *
+ * @param[in] fmt is a printf()-style format string
+ * @param[in] ap is a va_list pointer to arguments
+ */
 extern void vprintk(const char *fmt, va_list ap);
+
+/**
+ * @brief Kernel Print
+ *
+ * This method allows the user to perform a debug printk().
+ *
+ * @param[in] fmt is a printf()-style format string
+ */
 extern void printk(const char *fmt, ...);
+
+/**
+ * @brief Kernel Put String
+ *
+ * This method allows the user to perform a debug puts().
+ *
+ * @param[in] s is the string to print
+ */
 extern void putk(const char *s);
+
+/**
+ * @brief Kernel Put Character
+ *
+ * This method allows the user to perform a debug putc().
+ *
+ * @param[in] c is the character to print
+ */
 extern void rtems_putc(char c);
 
-/*
- *  This routine is passed into RTEMS reporting functions
- *  that may have their output redirected.  In particular,
- *  the cpu usage, period usage, and stack usage reporting
- *  functions use this.  If the user provides their
- *  own "printf plugin", then they may redirect those reports
- *  as they see fit.
+/**
+ * Type definition for function which can be plugged in to
+ * certain reporting routines to redirect the output.
+ *
+ * Methods following this prototype may be passed into RTEMS reporting
+ * functions that allow their output to be redirected.  In particular,
+ * the cpu usage, period usage, and stack usage reporting
+ * functions use this.
+ *
+ * If the user provides their own "printf plugin", then they may
+ * redirect those reports as they see fit.
+ */
+typedef int (*rtems_printk_plugin_t)(void *, const char *format, ...);
+
+/**
+ * @brief Reporting Methods printk() Plugin
+ *
+ * @param[in] context points to a user defined context.
+ * @param[in] fmt is a printf()-style format string
+ *
+ * @return The number of characters printed.
  */
 extern int printk_plugi

[PATCH 3/5] cpukit/include/rtems/btimer.h: Add DOxygen comments

[Joel Sherrill]

---
 cpukit/include/rtems/btimer.h | 58 +--
 1 file changed, 56 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/btimer.h b/cpukit/include/rtems/btimer.h
index c424e7e..e879a19 100644
--- a/cpukit/include/rtems/btimer.h
+++ b/cpukit/include/rtems/btimer.h
@@ -33,20 +33,74 @@
 extern "C" {
 #endif
 
-typedef uint32_t benchmark_timer_t;
+/**
+ * @defgroup BenchmarkTimer Benchmark Timer Driver Interface
+ *
+ * This module defines the interface for the Benchmark Timer Driver.
+ *
+ * The following methods in this module must be provided by each BSP:
+ *
+ *   - benchmark_timer_initialize
+ *   - benchmark_timer_read
+ *   - benchmark_timer_disable_subtracting_average_overhead
+ *
+ * The units measured are BSP specific but should be at the highest
+ * granularity possible.
+ *
+ * The Benchmark Timer may use the same hardware as the Clock Driver.
+ * No RTEMS Timing Tests will use both drivers at the same time.
+ */
 
-/* functions */
+/**
+ * @brief Benchmark Timer Value Type
+ *
+ * This type is used to contain benchmark times. The units are BSP specific.
+ */ 
+typedef uint32_t benchmark_timer_t;
 
+/**
+ * @brief Initialize the Benchmark Timer
+ *
+ * This method initializes the benchmark timer and resets it to begin
+ * counting.
+ */
 extern void benchmark_timer_initialize( void );
 
+/**
+ * @brief Read the Benchmark Timer
+ *
+ * This method stops the benchmark timer and returns the number of
+ * units that have passed since @a benchmark_timer_initialize was invoked.
+ *
+ * @return This method returns the number of units with the average overhead
+ *  removed. If the value is below the minimum trusted value, zero
+ *  is returned. 
+ */
 extern benchmark_timer_t benchmark_timer_read( void );
 
+/**
+ * @brief Benchmark Timer Empty Function
+ *
+ * This method is used to determine loop overhead.
+ */
 extern rtems_status_code benchmark_timer_empty_function( void );
 
+/**
+ * @brief Disable Average Overhead Removal from the Benchmark Timer
+ *
+ * This method places the benchmark timer in a "raw" mode where it
+ * returns the actual number of units which have passed between
+ * calls to @a benchmark_timer_initialize and @a benchmark_timer_read
+ * counting.
+ *
+ * @param[in] find_flag indicates to enable or disable the mode
+ */
 extern void benchmark_timer_disable_subtracting_average_overhead(
   bool find_flag
 );
 
+/**@}*/
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.9.3

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

[PATCH 5/5] confdefs.h: Improve the Doxygen

[Joel Sherrill]

---
 cpukit/sapi/include/confdefs.h | 883 +++--
 1 file changed, 767 insertions(+), 116 deletions(-)

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 7d9e3b9..8d41dfa 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -8,28 +8,10 @@
  * be instantiated by an application based on the setting of a number
  * of macros.  The macros are documented in the Configuring a System
  * chapter of the Classic API User's Guide
- *
- * The model is to estimate the memory required for each configured item
- * and sum those estimates.  The estimate can be too high or too low for
- * a variety of reasons:
- *
- * Reasons estimate is too high:
- *   + FP contexts (not all tasks are FP)
- *
- * Reasons estimate is too low:
- *   + stacks greater than minimum size
- *   + messages
- *   + application must account for device driver resources
- *   + application must account for add-on library resource requirements
- *
- * NOTE:  Eventually this may be able to take into account some of
- *the above.  This procedure has evolved from just enough to
- *support the RTEMS Test Suites into something that can be
- *used remarkably reliably by most applications.
  */
 
 /*
- *  COPYRIGHT (c) 1989-2014.
+ *  COPYRIGHT (c) 1989-2015.
  *  On-Line Applications Research Corporation (OAR).
  *
  *  The license and distribution terms for this file may be
@@ -69,11 +51,46 @@
 extern "C" {
 #endif
 
+/**
+ * @defgroup Configuration RTEMS Configuration
+ *
+ * This module contains all RTEMS Configuration parameters.
+ *
+ * The model is to estimate the memory required for each configured item
+ * and sum those estimates.  The estimate can be too high or too low for
+ * a variety of reasons:
+ *
+ * Reasons estimate is too high:
+ *   + FP contexts (not all tasks are FP)
+ *
+ * Reasons estimate is too low:
+ *   + stacks greater than minimum size
+ *   + messages
+ *   + application must account for device driver resources
+ *   + application must account for add-on library resource requirements
+ *
+ * NOTE:  Eventually this may be able to take into account some of
+ *the above.  This procedure has evolved from just enough to
+ *support the RTEMS Test Suites into something that can be
+ *used remarkably reliably by most applications.
+ */
+
+/**
+ * This is the Classic API initialization tasks table.
+ */
 extern rtems_initialization_tasks_table Initialization_tasks[];
+
 #if defined(RTEMS_MULTIPROCESSING)
+  /**
+   * This it the distributed multiprocessing configuration table.
+   */
   extern rtems_multiprocessing_table  Multiprocessing_configuration;
 #endif
+
 #ifdef RTEMS_POSIX_API
+  /**
+   * This it the POSIX API configuration table.
+   */
   extern posix_api_configuration_tableConfiguration_POSIX_API;
 #endif
 
@@ -215,48 +232,72 @@ const rtems_libio_helper rtems_fs_init_helper =
  * This sets up the resources for the FIFOs/pipes.
  */
 
+/**
+ * This is specified to configure the maximum number of POSIX FIFOs.
+ */
 #if !defined(CONFIGURE_MAXIMUM_FIFOS)
   #define CONFIGURE_MAXIMUM_FIFOS 0
 #endif
 
+/**
+ * This is specified to configure the maximum number of POSIX named pipes.
+ */
 #if !defined(CONFIGURE_MAXIMUM_PIPES)
   #define CONFIGURE_MAXIMUM_PIPES 0
 #endif
 
+/**
+ * This specifies the number of barriers required for the configured
+ * number of FIFOs and named pipes.
+ *
+ * This is an internal parameter.
+ */
 #if CONFIGURE_MAXIMUM_FIFOS > 0 || CONFIGURE_MAXIMUM_PIPES > 0
   #define CONFIGURE_BARRIERS_FOR_FIFOS \
 (2 * (CONFIGURE_MAXIMUM_FIFOS + CONFIGURE_MAXIMUM_PIPES))
+#else
+  #define CONFIGURE_BARRIERS_FOR_FIFOS   0
+#endif
+
+/**
+ * This specifies the number of semaphores required for the configured
+ * number of FIFOs and named pipes.
+ *
+ * This is an internal parameter.
+ */
+#if CONFIGURE_MAXIMUM_FIFOS > 0 || CONFIGURE_MAXIMUM_PIPES > 0
   #define CONFIGURE_SEMAPHORES_FOR_FIFOS \
 (1 + (CONFIGURE_MAXIMUM_FIFOS + CONFIGURE_MAXIMUM_PIPES))
 #else
-  #define CONFIGURE_BARRIERS_FOR_FIFOS   0
   #define CONFIGURE_SEMAPHORES_FOR_FIFOS 0
 #endif
 
-/*
- *  Filesystems and Mount Table Configuration.
+/**
+ *  @defgroup ConfigFilesystems Filesystems and Mount Table Configuration
+ *
+ *  @ingroup Configuration
  *
  *  Defines to control the file system:
  *
- *   CONFIGURE_APPLICATION_DISABLE_FILESYSTEM:
+ *   - CONFIGURE_APPLICATION_DISABLE_FILESYSTEM:
  * Disable the RTEMS filesystems. You get an empty DEVFS.
  *
- *   CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM:
+ *   - CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM:
  * Use the DEVFS as the root file system. Limited functions are
  * provided when this is used.
  *
- *   CONFIGURE_FILESYSTEM_ALL:
+ *   - CONFIGURE_FILESYSTEM_ALL:
  * Add file filesystems to the default filesystem table.
  *
  *   List of available file systems. You can define as many as you like:
- * CONFIGURE_FILESYSTEM_IM

[PATCH 4/5] mvme147s: Install z8530.h

[Joel Sherrill]

This was missed when the file was moved.
---
 c/src/lib/libbsp/m68k/mvme147s/Makefile.am   | 4 
 c/src/lib/libbsp/m68k/mvme147s/preinstall.am | 9 +
 2 files changed, 13 insertions(+)

diff --git a/c/src/lib/libbsp/m68k/mvme147s/Makefile.am 
b/c/src/lib/libbsp/m68k/mvme147s/Makefile.am
index 933cf75..bd2924f 100644
--- a/c/src/lib/libbsp/m68k/mvme147s/Makefile.am
+++ b/c/src/lib/libbsp/m68k/mvme147s/Makefile.am
@@ -16,6 +16,10 @@ noinst_PROGRAMS =
 
 include_HEADERS += include/coverhd.h
 
+## Zilog component header files
+include_rtems_zilogdir = $(includedir)/rtems/zilog
+include_rtems_zilog_HEADERS = ../../shared/include/zilog/z8530.h
+
 noinst_LIBRARIES = libbspstart.a
 libbspstart_a_SOURCES = ../../m68k/shared/start/start.S
 project_lib_DATA = start.$(OBJEXT)
diff --git a/c/src/lib/libbsp/m68k/mvme147s/preinstall.am 
b/c/src/lib/libbsp/m68k/mvme147s/preinstall.am
index 647b809..234789e 100644
--- a/c/src/lib/libbsp/m68k/mvme147s/preinstall.am
+++ b/c/src/lib/libbsp/m68k/mvme147s/preinstall.am
@@ -57,6 +57,15 @@ $(PROJECT_INCLUDE)/coverhd.h: include/coverhd.h 
$(PROJECT_INCLUDE)/$(dirstamp)
$(INSTALL_DATA) $< $(PROJECT_INCLUDE)/coverhd.h
 PREINSTALL_FILES += $(PROJECT_INCLUDE)/coverhd.h
 
+$(PROJECT_INCLUDE)/rtems/zilog/$(dirstamp):
+   @$(MKDIR_P) $(PROJECT_INCLUDE)/rtems/zilog
+   @: > $(PROJECT_INCLUDE)/rtems/zilog/$(dirstamp)
+PREINSTALL_DIRS += $(PROJECT_INCLUDE)/rtems/zilog/$(dirstamp)
+
+$(PROJECT_INCLUDE)/rtems/zilog/z8530.h: ../../shared/include/zilog/z8530.h 
$(PROJECT_INCLUDE)/rtems/zilog/$(dirstamp)
+   $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/rtems/zilog/z8530.h
+PREINSTALL_FILES += $(PROJECT_INCLUDE)/rtems/zilog/z8530.h
+
 $(PROJECT_LIB)/start.$(OBJEXT): start.$(OBJEXT) $(PROJECT_LIB)/$(dirstamp)
$(INSTALL_DATA) $< $(PROJECT_LIB)/start.$(OBJEXT)
 TMPINSTALL_FILES += $(PROJECT_LIB)/start.$(OBJEXT)
-- 
1.9.3

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

GSOC 2015 Aspirant for Improving the Raspberry Pi BSP for RTEMS

[Saket Sinha]

Hi,

I would like to participate to Google Summer of Code 2015 by
contributing to Improving the Raspberry Pi BSP for RTEMS.

I have tracked the work from previous GSOC on this project and have found
GPIO, SPI and I2C are already covered.

Kindly let me know what  the peripherals that are planned to be supported
in this GSOC for Raspberry PI.

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

GSOC and SOCIS Student Applicants

[Joel Sherrill]

Hi

Just a reminder that you need to fill in a row in the appropriate table.
This helps us keep track of everyone.

https://devel.rtems.org/wiki/GSoC/2015
https://devel.rtems.org/wiki/SOCIS/2015

and begin to work on your proposal as details begin to form. There
is a Google document template listed on the WIki page and it
should provide a good starting spot.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

rtems-source-builder on cygwin/64

[emanuel stiebler]

Hi all,
should it work at the moment?

All the best,
emanuel

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

[PATCH] doc/started: simplify and fix

[Gedare Bloom]

* fix and remove some macros in rtems.texi.in.
* refer to devel mailing list.
* remove reference to Debian packaging in requirements section.
* remove section on prebuilt tools.
* replace toolset build instructions with link to RSB docs.
* Add a note in building RTEMS section about using RSB.
* Fix URLs

Closes #2291.
---
 doc/common/rtems.texi.in |   7 +-
 doc/started/Makefile.am  |  20 +-
 doc/started/binaries.t   | 341 ---
 doc/started/buildc.t | 829 +--
 doc/started/buildrt.t|  28 +-
 doc/started/intro.t  |  37 +--
 doc/started/require.t|   7 -
 doc/started/started.texi |   4 +-
 8 files changed, 47 insertions(+), 1226 deletions(-)
 delete mode 100644 doc/started/binaries.t

diff --git a/doc/common/rtems.texi.in b/doc/common/rtems.texi.in
index 06172cc..063e5e9 100644
--- a/doc/common/rtems.texi.in
+++ b/doc/common/rtems.texi.in
@@ -1,8 +1,5 @@
-@set RTEMSHTTPSITE www.rtems.org
-@set RTEMSUSERSrtems-users@@rtems.com
-@set RTEMSUSERSSUBSCRIBE   rtems-users-subscribe@@rtems.com
-@set RTEMSBUGS http://www.rtems.org/bugzilla
-@set RTEMSFTPURL   ftp://www.rtems.org
+@set RTEMSUSERSusers@@rtems.org
+@set RTEMSDEVELdevel@@rtems.org
 @set RTEMSHTTPURL  http://www.rtems.org
 @set RTEMSPREFIX   @RTEMSPREFIX@
 @set RTEMSAPI  @RTEMSAPI@
diff --git a/doc/started/Makefile.am b/doc/started/Makefile.am
index df74da3..0eef621 100644
--- a/doc/started/Makefile.am
+++ b/doc/started/Makefile.am
@@ -8,7 +8,7 @@ PROJECT = started
 include $(top_srcdir)/project.am
 include $(top_srcdir)/main.am
 
-GENERATED_FILES = binaries.texi buildc.texi buildrt.texi intro.texi nt.texi \
+GENERATED_FILES = buildc.texi buildrt.texi intro.texi nt.texi \
 require.texi nextstep.texi sample.texi
 
 COMMON_FILES += $(top_srcdir)/common/cpright.texi
@@ -24,23 +24,19 @@ intro.texi: intro.t
-n "Requirements" < $< > $@
 
 require.texi: require.t
-   $(BMENU2) -c -p "GCC Mailing Lists" \
+   $(BMENU2) -c -p "RTEMS Mailing Lists" \
-u "Top" \
-   -n "Prebuilt Toolset Executables" < $< > $@
-
-binaries.texi: binaries.t
-   $(BMENU2) -c \
-   -p "GNU/Linux Distributions using Debian Packaging Format" \
-   -u "Top" \
-   -n "Building the GNU Cross Compiler Toolset" < $< > $@
+   -n "Building the GNU Cross Compiler Toolset with RSB" < $< > $@
 
 buildc.texi: buildc.t
-   $(BMENU2) -c -p "Removing Zipped Tar Files" \
+   $(BMENU2) -c \
+   -p "Distribution Independent Potential GNU/Linux Issues" \
-u "Top" \
-n "Building RTEMS" < $< > $@
 
 buildrt.texi: buildrt.t
-   $(BMENU2) -c -p "Error Messages Indicating Configuration Problems" \
+   $(BMENU2) -c \
+   -p "Building the GNU Cross Compiler Toolset with RSB" \
-u "Top" \
-n "Building the Sample Applications" < $< > $@
 
@@ -59,7 +55,7 @@ nt.texi: nt.t
-u "Top" \
-n "" < $< > $@
 
-EXTRA_DIST = binaries.t buildc.t buildrt.t intro.t nextstep.t nt.t require.t \
+EXTRA_DIST = buildc.t buildrt.t intro.t nextstep.t nt.t require.t \
 sample.t
 
 if USE_HTML
diff --git a/doc/started/binaries.t b/doc/started/binaries.t
deleted file mode 100644
index 7616d87..000
--- a/doc/started/binaries.t
+++ /dev/null
@@ -1,341 +0,0 @@
-@c
-@c  COPYRIGHT (c) 1988-2010.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
-
-@chapter Prebuilt Toolset Executables
-
-Precompiled toolsets are available for GNU/Linux and MS-Windows. 
-Other hosts will need to build from source.  Packaged binaries are
-in the following formats:
-
-@itemize @bullet
-@item GNU/Linux - RPM
-@item Cygwin - tar.bz2
-@item Mingw - tar.bz2
-@end itemize
-
-RPM is an acronym for the RPM Package Manager.  RPM is the native package
-installer for many GNU/Linux distributions including RedHat Enterprise
-Linux, Centos, SuSE, and Fedora.
-
-The RTEMS Project maintains a Yum Repository which makes it quite simple
-to install and update RTEMS toolsets.
-
-The prebuilt binaries are intended to be easy to install and
-the instructions are similar regardless of the host environment.  
-There are a few structural issues with the packaging of the RTEMS
-Cross Toolset binaries that you need to be aware of.
-
-@enumerate
-@item There are dependencies between the various packages.  This requires
-that certain packages be installed before others may be.  Some packaging
-formats enforce this dependency.
-
-@item Some packages are target CPU family independent and shared
-across all target architectures.   These are referred to as 
-"base" packages.
-
-@item Pre-built GNU Binary Utilities (binutils) packages are available
-for all RTEMS targets.  These include tools such as the assembler and
-linker and must be installed.
-
-@it

Re: rtems-source-builder on cygwin/64

[Joel Sherrill]

On 3/11/2015 12:12 PM, emanuel stiebler wrote:
> Hi all,
> should it work at the moment?
Since Chris is likely the best one to answer that and he won't be
online for at least a a few hours, give it a try. You will know the
answer before he wakes up. :)

I know there are still a couple of MSYS2 issues but I doubt those
apply to Cygwin. It probably should just work. If it doesn't, report
it.
> All the best,
> emanuel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

Re: GSOC 2015 Aspirant for Improving the Raspberry Pi BSP for RTEMS

[Gedare Bloom]

There was an email thread about this recently, see [1]. I think there
is plenty of work to do. If you have a Rasberry Pi 2, then
you may consider adding it as a BSP variant and getting SMP
working on it as a nice project. You should ideally demonstrate that
you can build the tools and boot RTEMS on the RPi.

I think there is enough work available for up to 3 students to do
Raspberry Pi improvements. We will work with accepted students to
delineate the scope of work for each, but for the proposal phase I
encourage you to investigate the most interesting (to you) projects
for the Pi.

[1] https://lists.rtems.org/pipermail/devel/2015-March/010181.html

Gedare

On Wed, Mar 11, 2015 at 12:56 PM, Saket Sinha  wrote:
> Hi,
>
> I would like to participate to Google Summer of Code 2015 by
> contributing to Improving the Raspberry Pi BSP for RTEMS.
>
> I have tracked the work from previous GSOC on this project and have found
> GPIO, SPI and I2C are already covered.
>
> Kindly let me know what  the peripherals that are planned to be supported in
> this GSOC for Raspberry PI.
>
> Regards,
> Saket Sinha
>
> ___
> 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: rtems-source-builder on cygwin/64

[emanuel stiebler]

On 2015-03-11 18:40, Joel Sherrill wrote:



On 3/11/2015 12:12 PM, emanuel stiebler wrote:

Hi all,
should it work at the moment?

Since Chris is likely the best one to answer that and he won't be
online for at least a a few hours, give it a try. You will know the
answer before he wakes up. :)


I'm on cygwin, and it sits after just few hundred lines in

/bin/sh ./libtool --silent --mode=link gcc -O2 -pipe 
-I/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/include 
-std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes 
-Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -no-undefined 
-version-info 7:0:6 -rpath /opt/rtems-4.11/lib 
-L/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/lib 
-o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo


and cpu usage goes back to 0% ...



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

Re: rtems-source-builder on cygwin/64

[Joel Sherrill]

On 3/11/2015 12:59 PM, emanuel stiebler wrote:
> On 2015-03-11 18:40, Joel Sherrill wrote:
>>
>> On 3/11/2015 12:12 PM, emanuel stiebler wrote:
>>> Hi all,
>>> should it work at the moment?
>> Since Chris is likely the best one to answer that and he won't be
>> online for at least a a few hours, give it a try. You will know the
>> answer before he wakes up. :)
> I'm on cygwin, and it sits after just few hundred lines in
>
> /bin/sh ./libtool --silent --mode=link gcc -O2 -pipe 
> -I/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/include
>  
> -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes 
> -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -no-undefined 
> -version-info 7:0:6 -rpath /opt/rtems-4.11/lib 
> -L/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/lib
>  
> -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
>
> and cpu usage goes back to 0% ...
>
There should be a log file rsb-* with more details. Without that,
we are just guessing.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

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

[PATCH] Add CAN, PWM, ADC and UART1/2/3 support to the LPC176x BSP.

[Martin Galvan]

This patch adds support for the following devices to the LPC176x BSP:

* CAN
* PWM
* ADC

It also adds the probe routines for UART1/2/3 to the console_device_table in 
console-config.c, and enables UART1 in configure.ac.
---
 c/src/lib/libbsp/arm/lpc176x/Makefile.am   |  16 +
 c/src/lib/libbsp/arm/lpc176x/adc/adc.c | 244 ++
 c/src/lib/libbsp/arm/lpc176x/can/can.c | 542 +
 c/src/lib/libbsp/arm/lpc176x/configure.ac  |   3 +
 .../libbsp/arm/lpc176x/console/console-config.c|  42 +-
 c/src/lib/libbsp/arm/lpc176x/include/adc-defs.h|  96 
 c/src/lib/libbsp/arm/lpc176x/include/adc.h |  60 +++
 c/src/lib/libbsp/arm/lpc176x/include/can-defs.h| 183 +++
 c/src/lib/libbsp/arm/lpc176x/include/can.h | 179 +++
 .../lib/libbsp/arm/lpc176x/include/common-types.h  |   1 +
 c/src/lib/libbsp/arm/lpc176x/include/io-defs.h |  19 +
 c/src/lib/libbsp/arm/lpc176x/include/io.h  |  13 +-
 c/src/lib/libbsp/arm/lpc176x/include/lpc176x.h |   8 +-
 c/src/lib/libbsp/arm/lpc176x/include/mbed-pinmap.h |  50 ++
 c/src/lib/libbsp/arm/lpc176x/include/pwmout-defs.h | 105 
 c/src/lib/libbsp/arm/lpc176x/include/pwmout.h  |  73 +++
 c/src/lib/libbsp/arm/lpc176x/misc/io.c |  15 +
 c/src/lib/libbsp/arm/lpc176x/preinstall.am |  28 ++
 c/src/lib/libbsp/arm/lpc176x/pwmout/pwmout.c   | 210 
 c/src/lib/libbsp/shared/include/uart-output-char.h |   4 +-
 20 files changed, 1881 insertions(+), 10 deletions(-)
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/adc/adc.c
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/can/can.c
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/adc-defs.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/adc.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/can-defs.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/can.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/mbed-pinmap.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/pwmout-defs.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/include/pwmout.h
 create mode 100755 c/src/lib/libbsp/arm/lpc176x/pwmout/pwmout.c

diff --git a/c/src/lib/libbsp/arm/lpc176x/Makefile.am 
b/c/src/lib/libbsp/arm/lpc176x/Makefile.am
index 3f60f23..50a7e79 100644
--- a/c/src/lib/libbsp/arm/lpc176x/Makefile.am
+++ b/c/src/lib/libbsp/arm/lpc176x/Makefile.am
@@ -42,6 +42,12 @@ include_bsp_HEADERS += include/io.h
 include_bsp_HEADERS += include/common-types.h
 include_bsp_HEADERS += include/gpio-defs.h
 include_bsp_HEADERS += include/gpio.h
+include_bsp_HEADERS += include/can.h
+include_bsp_HEADERS += include/can-defs.h
+include_bsp_HEADERS += include/pwmout.h
+include_bsp_HEADERS += include/pwmout-defs.h
+include_bsp_HEADERS += include/adc.h
+include_bsp_HEADERS += include/adc-defs.h
 include_bsp_HEADERS += include/timer-defs.h
 include_bsp_HEADERS += include/timer.h
 include_bsp_HEADERS += include/watchdog.h
@@ -50,6 +56,7 @@ include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/lpc176x.h
 include_bsp_HEADERS += include/lpc-clock-config.h
 include_bsp_HEADERS += include/system-clocks.h
+include_bsp_HEADERS += include/mbed-pinmap.h
 
 include_HEADERS += ../../shared/include/tm27.h
 
@@ -126,6 +133,15 @@ libbsp_a_SOURCES += ../../shared/tod.c \
 # GPIO
 libbsp_a_SOURCES += gpio/gpio.c
 
+# CAN
+libbsp_a_SOURCES += can/can.c
+
+# PWMOUT
+libbsp_a_SOURCES += pwmout/pwmout.c
+
+# ADC
+libbsp_a_SOURCES += adc/adc.c
+
 # Timer
 libbsp_a_SOURCES += timer/timer.c
 
diff --git a/c/src/lib/libbsp/arm/lpc176x/adc/adc.c 
b/c/src/lib/libbsp/arm/lpc176x/adc/adc.c
new file mode 100755
index 000..7cf003a
--- /dev/null
+++ b/c/src/lib/libbsp/arm/lpc176x/adc/adc.c
@@ -0,0 +1,244 @@
+/**
+ * @file adc.c
+ *
+ * @ingroup lpc176x
+ *
+ * @brief ADC library for the lpc176x bsp.
+ */
+
+/*
+ * Copyright (c) 2014 Taller Technologies.
+ *
+ * @author  Diaz Marcos (marcos.d...@tallertechnologies.com)
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+#include 
+#include 
+#include 
+
+static lpc176x_adc_device *const adc_device = AD0_BASE_ADDR;
+
+static const lpc176x_adc_pin_map adc_pinmap[ ADC_DEVICES_COUNT ] =
+{
+  {
+.pin_number = 23u,
+.pin_function = LPC176X_PIN_FUNCTION_01
+  },
+  {
+.pin_number = 24u,
+.pin_function = LPC176X_PIN_FUNCTION_01
+  },
+  {
+.pin_number = 25u,
+.pin_function = LPC176X_PIN_FUNCTION_01
+  },
+  {
+.pin_number = 26u,
+.pin_function = LPC176X_PIN_FUNCTION_01
+  },
+  {
+.pin_number = 62u,
+.pin_function = LPC176X_PIN_FUNCTION_11
+  },
+  {
+.pin_number = 63u,
+.pin_function = LPC176X_PIN_FUNCTION_11
+  },
+  {
+.pin_number = 3u,
+.pin_function = LPC176X_PIN_FUNCTION_10
+  },
+  {
+.pin_number = 2u,
+.pin_function = LPC176X_PIN_FUNCTION_10
+  }
+};
+
+/**
+ * @brief Checks for a val