Re: XtratuM BSP

[Joel Sherrill]

On 6/18/2014 9:50 AM, Christian Mauderer wrote:
 Hello,

 there is still the licensing issue with this BSP discussed in an earlier 
 thread.
 So the BSP (most likely) still can not be included into the main repository.

 Anyway it seems to be useful to re-post the last version of the BSP with bug
 fixes, some of the suggested improvements and further adaptions to the current
 git-master. If somehow the licensing issues can be resolved in the near 
 future,
 the last state of the BSP should be available on the mailinglist. Also if it
 should be used somewhere else outside of the official repository, it is not
 necessary to re-fix the same bugs again.
It is also possible to host this as a branch on a private github account
 Kind regards,

 Christian Mauderer


-- 
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: Rtems-test with qemu integration for pc386

[Joel Sherrill]

On 6/25/2014 5:48 PM, Chris Johns wrote:
 On 26/06/2014 5:56 am, Krzysztof Mięsowicz wrote:
 Hi again and sorry for spam. Soon after writing mail to you I found the
 solution (at least I think so :-D ).
 Thanks for posting the solution. The pc is the only qemu bsp I know of 
 with a boot loader making it more complex.

 I created rtems-boot.img using script from
 http://www.rtems.org/wiki/index.php/Building_Grub .
 I wrote grub.cfg with following lines:

 serial --unit=0 --speed=115200
 set root='hd1,msdos1'
 terminal_output serial; terminal_input serial;

 to redirect terminal output and input to serial. Then, I am able to run
 arbitrary executable using following command (example for ticker):

 qemu-system-i386 -m 128 -boot b -hda $HOME/qemu/hd/rtems-boot.img -hdb
 fat:$HOME/qemu/hd -serial stdio -no-reboot -nographic -monitor null
 --exec-trace ticker.exe.cov -kernel
 /home/rtems/development/rtems/src/b-pc386/i386-rtems4.11/c/pc386/testsuites/samples/ticker/ticker.exe
 -append --console=com1;boot
 This is an excellent solution. Well done.
Awesome! Does this work without the -hdb? Just curious what it is
used for. If it can be avoided, then one less option and user setup
requirement.
 This simply boots executable specified as -kernel argument and appends
 --console=com1;boot to grub multiboot specification. This results in
 following output:

 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
 TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
 TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
 TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
 TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
 TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988
 *** END OF TEST CLOCK TICK ***

 Additionaly, ticker.exe.cov is created. I think this is really good
 soultion to use in coverage analysis within rtems-test. The question is
 where rtems-boot.img and grub.cfg should be placed?

 I agree this is the way to go. Please send me the rtems-test patch 
 without the coverage option so I can add this bsp to the supported test 
 bsps. We can add the coverage option in further changes once we have 
 detecting a suitable qemu figured out.
+1
 Chris

-- 
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: PR2183 and affinity migration

[Joel Sherrill]

On Jun 27, 2014 3:04 PM, Sebastian Huber sebastian.hu...@embedded-brains.de 
wrote:

 On 06/27/2014 06:25 PM, Joel Sherrill wrote:
  I see this as two state changes within a single scheduler
  operation but that sounds the same as your double
  migration. We are likely replacing heir twice and tripping
  the same condition.
 
  If you want a test case of this, we can get our code
  cleaned up and push it. Gaisler will have to send their
  test code.

 I work currently an a solution for bug PR2183 since I hit it also in a
 new test case that works without the disabled thread dispatching trick.
 It should be ready next week.

Thanks.

FYI Next week has a national holiday for us.

In our you enjoyed the football game yesterday.

 --
 Sebastian Huber, embedded brains GmbH

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

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

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

Re: [PATCH 0/3] SMP cache manager

[Joel Sherrill]

I don't know why but I don't see any file changes on this.

On 7/3/2014 4:37 AM, Daniel Cederman wrote:
 Adds functions to request cache operations on a set of cores.

 Daniel Cederman (3):
   score: Use consistent type for SMP messages
   score: Add function to send a SMP message to a set of CPUs
   score: Add SMP support to the cache manager

  c/src/lib/libcpu/shared/src/cache_manager.c |  166 
 +++
  cpukit/rtems/include/rtems/rtems/cache.h|   84 ++
  cpukit/score/include/rtems/score/smpimpl.h  |   25 +++-
  cpukit/score/src/smp.c  |   17 ++-
  4 files changed, 287 insertions(+), 5 deletions(-)


-- 
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: [PATCH] RTEMS: Add multilibs for ARM

[Joel Sherrill]

On Jul 4, 2014 1:00 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:

 Hello Sebastian,

 On Tuesday 01 of July 2014 16:58:40 Sebastian Huber wrote:
  On 2014-07-01 16:56, Sebastian Huber wrote:
   gcc/ChangeLog
   2014-07-01  Sebastian Huber  sebastian.hu...@embedded-brains.de
  
* config/arm/t-rtems-eabi: Add
mthumb/march=armv7-r/mfpu=vfpv3-d16/mfloat-abi=hard,
mbig-endian/mthumb/march=armv7-r, and
mbig-endian/mthumb/march=armv7-r/mfpu=vfpv3-d16/mfloat-abi=hard
multilibs.
   ---
 gcc/config/arm/t-rtems-eabi |   84
   +- 1 files changed, 82
   insertions(+), 2 deletions(-)
 
  This is a script generated update which should meet Pavel's requirements:
 
  http://lists.rtems.org/pipermail/devel/2014-June/007232.html

 I have checked updated toolchain with LPC1788 target up
 RTEMS to networking and Premek has tested it with TMS570 RTEMS
 build. We are (unfortuantelly) not at Hello world state but
 BSP start runs quite far. So I think that soft float big-endian
 tootchain with you patch is OK and it would worth to send it
 upstream.

Is there a list of patches and branches you want them on Sebastian? I know a 
couple are pending.

 As for NEWLIB oneliner, we have not got to full toolchain rebuild
 for it yet. We have spent a whole day with RTEMS code and looking
 for some problems in remote GDB/OpenOCD interreaction and finally
 found some problem with SDRAM controller when used for half
 world access. So we have pile of fun left for Monday.

 Should I prepare new patch or somebody from Newlib team
 with better knowledge of compatibility matrix integrates
 .arch  change?

Just submit a revised patch with ChangeLog entry. No one will step up.

 Thanks for support have a nice weekend,

 Pavel

 ___
 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: Misc on RBTree Thread Queue Priority Discipline Changes

[Joel Sherrill]

On 7/9/2014 10:34 AM, Gedare Bloom wrote:
 On Tue, Jul 8, 2014 at 5:37 PM, Joel Sherrill joel.sherr...@oarcorp.com 
 wrote:
 Hi

 If you take the patches in their entirety, most of the tests
 appear to be about 500 bytes smaller on the erc32.

 What is the change in wkspace size? Basically you add 3 pointers +
 enum to each TCB / thd proxy, but remove some space for the control
 node I guess. I would guess the code savings is worth it.
Good question. I was watching code space. :)

Before:

(gdb) p sizeof(Thread_queue_Control)
$1 = 64
(gdb) p sizeof(Thread_Control)
$2 = 360

After:

(gdb) p sizeof(Thread_queue_Control)
$1 = 40
(gdb) p sizeof(Thread_Control)
$2 = 376

Summary:

-24 Thread_queue_Control
+16 Thread_Control

Since thread queues are used in blocking objects, I assume
there will be more of them in a system and this is a net win.

Technically, they could be used in the Scheduler implementations.
When a thread is not blocked, the RBTree_Node is unused.
 None of the tmtests do priority based blocking so I can't
 report any changes there.

 There was historically a subroutine in the threadq calls for a discipline
 specific routine. Using the RBTree, this resulted in only 3-5 lines
 of code unique to the discipline in those discipline files. The other
 20+ lines was duplicated. The last patch folds those subroutines into
 the main methods.

 There is still some room for clean up since the code that is in
 threadblockingoperationcancel.c is open coded there and
 three other places. So there are a total of four copies of this
 code in the tree.

 + rtems/src/eventsurrender.c
 + score/src/threadqdequeue.c
 + score/src/threadqextract.c
 + score/src/threadblockingoperationcancel.c

 I do not see discipline used in threadblockingoperationcancel.c what
 do you mean?
All four of those methods do exactly the same thing AFTER they
deal with the event or threadq specific discipline code. I
have a patch pending with this change.
 Two of those need the debug check code and two do not.
 Also the method name isn't right for all four cases. It indicates
 its use on the resource released in ISR usage not the
 normal clean up from blocking case.

 Suggestions on a new name and whether this should be
 a real subroutine or a static inline is appreciated. Then I
 can rework and reduce the code duplication.

 Propose the code; I'm not sure what you mean to refactor into the new 
 function.
I found a solution and will pose a patch. Two methods. The one
used for undoing on a sync state trigger will be a wrapper for the
one used for normal unblocking.
 -Gedare

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

-- 
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 6/6] Use Shared Method for Thread Unblock Cleanup

[Joel Sherrill]

When a thread is removed from a thread queue or is unblocked
by receiving an event, the same actions are required.

 + timeout watchdog canceled,
 + thread must be unblocked, and
 + (MP only) proxy cleaned up

This patch makes sure there is only one copy of this code.
---
 cpukit/score/include/rtems/score/threadimpl.h|   18 ++
 cpukit/score/src/threadblockingoperationcancel.c |   65 --
 cpukit/score/src/threadqdequeue.c|   18 +-
 cpukit/score/src/threadqextract.c|   22 ++-
 4 files changed, 63 insertions(+), 60 deletions(-)

diff --git a/cpukit/score/include/rtems/score/threadimpl.h 
b/cpukit/score/include/rtems/score/threadimpl.h
index 4971e9d..5327e29 100644
--- a/cpukit/score/include/rtems/score/threadimpl.h
+++ b/cpukit/score/include/rtems/score/threadimpl.h
@@ -403,6 +403,24 @@ void _Thread_blocking_operation_Cancel(
   ISR_Level level
 );
 
+/**
+ *  @brief Finalize a blocking operation.
+ *
+ *  This method is used to finalize a blocking operation that was
+ *  satisfied. It may be used with thread queues or any other synchronization
+ *  object that uses the blocking states and watchdog times for timeout.
+ *
+ *  This method will restore the previous ISR disable level during the cancel
+ *  operation.  Thus it is an implicit _ISR_Enable().
+ *
+ *  @param[in] the_thread is the thread whose blocking is canceled
+ *  @param[in] level is the previous ISR disable level
+ */
+void _Thread_blocking_operation_Finalize(
+  Thread_Control   *the_thread,
+  ISR_Level level
+);
+
 RTEMS_INLINE_ROUTINE Per_CPU_Control *_Thread_Get_CPU(
   const Thread_Control *thread
 )
diff --git a/cpukit/score/src/threadblockingoperationcancel.c 
b/cpukit/score/src/threadblockingoperationcancel.c
index 127d852..b496796 100644
--- a/cpukit/score/src/threadblockingoperationcancel.c
+++ b/cpukit/score/src/threadblockingoperationcancel.c
@@ -24,6 +24,41 @@
 #endif
 #include rtems/score/watchdogimpl.h
 
+void _Thread_blocking_operation_Finalize(
+  Thread_Control   *the_thread,
+  ISR_Level level
+)
+{
+  /*
+   * The thread is not waiting on anything after this completes.
+   */
+  the_thread-Wait.queue = NULL;
+
+  /*
+   *  If the sync state is timed out, this is very likely not needed.
+   *  But better safe than sorry when it comes to critical sections.
+   */
+  if ( _Watchdog_Is_active( the_thread-Timer ) ) {
+_Watchdog_Deactivate( the_thread-Timer );
+_ISR_Enable( level );
+(void) _Watchdog_Remove( the_thread-Timer );
+  } else
+_ISR_Enable( level );
+
+  /*
+   *  Global objects with thread queue's should not be operated on from an
+   *  ISR.  But the sync code still must allow short timeouts to be processed
+   *  correctly.
+   */
+
+  _Thread_Unblock( the_thread );
+
+#if defined(RTEMS_MULTIPROCESSING)
+  if ( !_Objects_Is_local_id( the_thread-Object.id ) )
+_Thread_MP_Free_proxy( the_thread );
+#endif
+}
+
 void _Thread_blocking_operation_Cancel(
 #if defined(RTEMS_DEBUG)
   Thread_blocking_operation_States  sync_state,
@@ -59,33 +94,5 @@ void _Thread_blocking_operation_Cancel(
 }
   #endif
 
-  /*
-   * The thread is not waiting on anything after this completes.
-   */
-  the_thread-Wait.queue = NULL;
-
-  /*
-   *  If the sync state is timed out, this is very likely not needed.
-   *  But better safe than sorry when it comes to critical sections.
-   */
-  if ( _Watchdog_Is_active( the_thread-Timer ) ) {
-_Watchdog_Deactivate( the_thread-Timer );
-_ISR_Enable( level );
-(void) _Watchdog_Remove( the_thread-Timer );
-  } else
-_ISR_Enable( level );
-
-  /*
-   *  Global objects with thread queue's should not be operated on from an
-   *  ISR.  But the sync code still must allow short timeouts to be processed
-   *  correctly.
-   */
-
-  _Thread_Unblock( the_thread );
-
-#if defined(RTEMS_MULTIPROCESSING)
-  if ( !_Objects_Is_local_id( the_thread-Object.id ) )
-_Thread_MP_Free_proxy( the_thread );
-#endif
-
+  _Thread_blocking_operation_Finalize( the_thread, level );
 }
diff --git a/cpukit/score/src/threadqdequeue.c 
b/cpukit/score/src/threadqdequeue.c
index 3b55e52..d745ef2 100644
--- a/cpukit/score/src/threadqdequeue.c
+++ b/cpukit/score/src/threadqdequeue.c
@@ -70,22 +70,10 @@ Thread_Control *_Thread_queue_Dequeue(
 
   /*
* We found a thread to unblock.
+   *
+   * NOTE: This is invoked with interrupts still disabled.
*/
-  the_thread-Wait.queue = NULL;
-  if ( !_Watchdog_Is_active( the_thread-Timer ) ) {
-_ISR_Enable( level );
-  } else {
-_Watchdog_Deactivate( the_thread-Timer );
-_ISR_Enable( level );
-(void) _Watchdog_Remove( the_thread-Timer );
-  }
-
-  _Thread_Unblock( the_thread );
-
-#if defined(RTEMS_MULTIPROCESSING)
-  if ( !_Objects_Is_local_id( the_thread-Object.id ) )
-_Thread_MP_Free_proxy( the_thread );
-#endif
+  _Thread_blocking_operation_Finalize( 

Re: _Configuration_Scheduler_priority_dflt

[Joel Sherrill]

On 7/10/2014 9:53 AM, Sebastian Huber wrote:
 On 2014-07-10 16:43, Gabriel Ibarra wrote:
 Hello, I'm working with a board with a few amount of RAM (lpc1768- 32k), I
 recently updated the last version of RTEMS and now I have more overhead, I
 found that the responsible of this new overhead is an object in the bss
 section:  _Configuration_Scheduler_priority_dflt; So, I want to know what 
 is
 that, is there some documentation of it?, Can I disable it?
 With respect to this item there is no overhead.  Only the memory location 
 moved 
 from the workspace to the BSS section.  You can configure fewer priority 
 levels 
 to save space or use the simple priority scheduler.

Can you see if there are new symbols in the new executable which
we might be surprised to see? It is possible a new dependency was
accidentally introduced.

Did any existing methods get much larger?

Another option is to turn on per function and data sections and see
if that helps. The SPARC BSPs did this. It is a little tricky not not a lot
to do. Then the linker can drop out unreferenced variables and methods.

-- 
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: [PATCH] Add const qualifier in sys/cpuset.h

[Joel Sherrill]

I think today or yesterday is a suitable tag.

Pavel is the arm fix in Newlib CVS?

We can bump it again when openrisc code is merged.

Sebastian did you want a GCC bump also?

On Jul 10, 2014 9:26 PM, Chris Johns chr...@rtems.org wrote:
On 9/07/2014 2:40 am, Joel Sherrill wrote:

 On 7/8/2014 9:59 AM, Sebastian Huber wrote:
 On 2014-07-07 23:27, Joel Sherrill wrote:
 Hi Chris,

 I added this patch to rtems-tools. Attached is a patch to
 RSB to use it for the sparc tools. If this looks OK, should
 I make a similar update to all applicable 4.11 targets?
 Why don't we move to another Newlib snapshot which includes this patch?  
 Pavel
 needs also the recent memchr() fix for its ARM tool chain.

 The default version is 2.1.0 with a few patches. I don't mind if
 the version gets bumped or if we add the memchr() patch.

Version please ? For CVS I need a date.


 But Chris is on holiday for a few more days. Whatever he wants
 is OK with me.


Back (boo hoo).


 There is value in moving to a CVS snapshot given that it is mid-year
 but I don't know if that negatively impacts any odd targets.

I am happy to use CVS when we are not on release branches however if we
move to release 4.11 with CVS referenced we need to capture that version
as a tarball. I would like have users build releases offline.
If we release referencing cvs and we make a tarball (referencing it) it
would be nice to be able to tag newlib's cvs repo.

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

Re: [PATCH] capture01 build broken?

[Joel Sherrill]

On a long weekend but is there a chance Jennifer missed using something like 
rtems_test_assert which also ensures that the call exited OS critical sections?

On Jul 12, 2014 9:35 AM, Ben Gras b...@shrike-systems.com wrote:
All,

After a rebase of my tree capture01 didn't build (see build-error.txt). Adding 
#include assert.h (see assert-patch.txt) fixed it.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: GCC 4.9.1 Released

[Joel Sherrill]

Just passing along.

Sebastian had two patches he wanted to see on the 4.9 branch and
gcc head.

Are there any others?

What issues do we have moving to a 4.9.x release? I recall there being
code generation issues but not the details.

 Original Message 
Subject:GCC 4.9.1 Released
Date:   Wed, 16 Jul 2014 09:16:19 -0500
From:   Jakub Jelinek ja...@redhat.com
Reply-To:   Jakub Jelinek ja...@redhat.com
To: g...@gcc.gnu.org g...@gcc.gnu.org, gcc-annou...@gcc.gnu.org
gcc-annou...@gcc.gnu.org, info-...@gnu.org info-...@gnu.org



The GNU Compiler Collection version 4.9.1 has been released.

 
GCC 4.9.1 is a bug-fix release from the GCC 4.9 branch
containing important fixes for regressions and serious bugs in  
 
GCC 4.9.0 with more than 88 bugs fixed since the previous release.  
 
In addition to that, GCC 4.9.1 release supports OpenMP 4.0 also
in Fortran, rather than just in C and C++.
This release is available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments   
 
about this release.  Instead, use the resources available from  
 
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!



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

Re: Problem with ticker.exe for or1ksim/OpenRISC BSP

[Joel Sherrill]

On 7/17/2014 4:57 AM, Hesham Moustafa wrote:
 Hi,

 I am trying to get ticker.exe working properly for or1ksim BSP but
 there is a problem. When I run ticker, I only get the following output

 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988

 And nothing else. I tried to debug this issue using the following methods:

 1- Set a break point at put_name( Task_name[ task_index ], FALSE );
 line, it always reach this point (with different task ids each time)
 but does not produce any output.

 2- Set a break point at _Watchdog_Tickle function, and it's reached
 every time and decreasing the interval successfully.

 3- Set a break point at _Watchdog_Remove function, and it's always
 reached every time I hit continue.
Then it sounds like you are getting clock ticks, ending the thread
delay, but the
IRQ code does not handle the path when a thread is unblocked and there
needs to be a context switch/preemption at the end of the IRQ processing.

_Watchdog_Remove can be called when a blocking operation doesn't time out
and I think it happens in this test.

_Thread_Delay_ended is the routine which ends the wake after.

_Watchdog_Ticks_since_boot is a handy counter of clock ticks.

On sis, here is a gdb session showing me getting to this point:

(gdb) b Init
Breakpoint 4 at 0x2001328: file
../../../../../../../rtems/c/src/../../testsuites/samples/ticker/init.c,
line 33.
(gdb) r
Starting program:
/home/joel/rtems-4.11-work/b-sis/sparc-rtems4.11/c/sis/testsuites/samples/ticker/ticker.exe


Breakpoint 4, Init (argument=33659712)
at
../../../../../../../rtems/c/src/../../testsuites/samples/ticker/init.c:33
33  TEST_BEGIN();
(gdb) p _Watchdog_Ticks_since_boot
$1 = 0
(gdb) c
Continuing.


*** BEGIN OF TEST CLOCK TICK ***
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988

Breakpoint 3, _Thread_Delay_ended (id=0, arg=0x201c790)
at
../../../../../../rtems/c/src/../../cpukit/score/src/threaddelayended.c:32
warning: Source file is more recent than executable.
32  _Thread_Clear_state(
(gdb) p _Watchdog_Ticks_since_boot
$2 = 500
(gdb)

What you are not doing is the code that is

 4- Set a break point at status = rtems_clock_get_tod( time ); at
 ticker.c, and time.second is always 0, never incremented. I though
 Clock_driver_nanoseconds_since_last_tick is the problem, so I made it
 return a static value to test it (12345 for example), but I got the
 same problem.

 Please note that the previous break points always reached when I hit
 continue every time, the timer interrupt keeps arising and do its work
 never stops, and the problem enters IDLE task.
This definitely sounds like not handling the context switch necessary
part of the
IRQ processing properly so always returning to IDLE. I call this a
simple return.

All ports have a version of this code. no_cpu should have reasonable
pseudo-code.
m68k is likely the easiest to read as real code.

You need to do a simple return if:

(a) IRQ is nested, or
(b) DISPATCH_NEEDED is false

Otherwise, you need to some CPU specific magic to get our of the IRQ and
back to the thread. Make it look like it called _Thread_Dispatch with
sufficient saved registers (e.g. callee destroyed). This is usually called
_ISR_Dispatch.  When the call from _ISR_Dispatch to _Thread_Dispatch
returns, you do the magic needed to return tot he interrupted thread
(IDLE in this case) as if nothing happened.
 I would appreciate any hints or solutions regarding this problem.

 Thanks,
 Hesham
 ___
 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 nios2-*-rtems*

[Joel Sherrill]

---
 gcc/ChangeLog|  6 ++
 gcc/config.gcc   |  6 +-
 gcc/config/nios2/rtems.h | 33 +
 gcc/config/nios2/t-rtems |  3 +++
 4 files changed, 47 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/nios2/rtems.h
 create mode 100644 gcc/config/nios2/t-rtems

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f3a404f..607b915 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2014-07-17  Joel Sherrill joel.sherr...@oarcorp.com
+
+   * config.gcc: Add nios2-*-rtems*.
+   * config/nios2/rtems.h: New file.
+   * gcc/config/nios2/t-rtems: New file.
+
 2014-07-16  David Wohlferd d...@limegreensocks.com
 
PR target/61662
diff --git a/gcc/config.gcc b/gcc/config.gcc
index cfb5014..de216f8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -419,7 +419,7 @@ nds32*)
 nios2-*-*)
cpu_type=nios2
extra_options=${extra_options} g.opt
-   ;;  
+   ;;
 picochip-*-*)
 cpu_type=picochip
 ;;
@@ -2137,6 +2137,10 @@ nios2-*-*)
tm_file=${tm_file} newlib-stdint.h nios2/elf.h
extra_options=${extra_options} nios2/elf.opt
;;
+   nios2-*-rtems*)
+   tm_file=${tm_file} nios2/rtems.h rtems.h
+   tmake_file=${tmake_file} t-rtems nios2/t-rtems
+   ;;
 esac
;;
 pdp11-*-*)
diff --git a/gcc/config/nios2/rtems.h b/gcc/config/nios2/rtems.h
new file mode 100644
index 000..cc5b5d6
--- /dev/null
+++ b/gcc/config/nios2/rtems.h
@@ -0,0 +1,33 @@
+/* Definitions for rtems targeting a NIOS2 using ELF.
+   Contributed by Chris Johns (chr...@rtems.org).
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+http://www.gnu.org/licenses/.  */
+
+/* Specify predefined symbols in preprocessor.  */
+#define TARGET_OS_CPP_BUILTINS()\
+do {\
+  builtin_define (__rtems__); \
+  builtin_define (__USE_INIT_FINI__); \
+  builtin_assert (system=rtems);  \
+} while (0)
+
+/* This toolchain implements the ABI for Linux Systems documented in the
+   Nios II Processor Reference Handbook.
+
+   This is done so RTEMS targets have Thread Local Storage like Linux.  */
+#define TARGET_LINUX_ABI 1
+
diff --git a/gcc/config/nios2/t-rtems b/gcc/config/nios2/t-rtems
new file mode 100644
index 000..48dce34
--- /dev/null
+++ b/gcc/config/nios2/t-rtems
@@ -0,0 +1,3 @@
+# Multilibs for NIOS2 RTEMS targets.
+
+# Use all.
-- 
1.9.3

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

nios2 Build Status

[Joel Sherrill]

Hi

Just posted a gcc patch for gcc's head which should work with 4.9.x.
Feedback appreciated. Hopefully Chris can add this to the RSB.

Based on that toolset, there are two tests that fail to build.

spcache01
tmcontext01

Both are related to missing cache functions. Crunching the log gives
this list.

 undefined reference to `rtems_cache_flush_entire_data'
 undefined reference to `rtems_cache_flush_multiple_data_lines'
 undefined reference to `rtems_cache_get_data_cache_size'
 undefined reference to `rtems_cache_get_data_line_size'
 undefined reference to `rtems_cache_get_instruction_cache_size'
 undefined reference to `rtems_cache_get_instruction_line_size'
 undefined reference to `rtems_cache_invalidate_entire_instruction'
 undefined reference to `rtems_cache_invalidate_multiple_data_lines'
 undefined reference to `rtems_cache_invalidate_multiple_instruction_lines'

I leave it to thsee more familiar with the nios2 to address this.

-- 
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: Problem with ticker.exe for or1ksim/OpenRISC BSP

[Joel Sherrill]

The ASM macro needs to be properly used in rtems/score/cpu.h.

I sent a patch to devel@ but it is really a hack. Things compile but
I wouldn't trust it.

+ ASM should protect C only code from being used in .S code.
And vice-versa.

When I started, there was C code exposed to .S. When I blocked
off a huge block of the code, I discovered two macro constants
in the middle that were needed in .S files. Please check how these
are done in other ports to minimize the number of ifdef's and
to keep things logically together. The area I saw them in looked
like a dumping ground for miscellaneous stuff. Maybe you inherited
it but I don't like it.

Also ...

+ minimum failed to compile in a weird way. Could be a side-effect
of what I did but I don't see how.

+ I don't like your cpu isr disable/enable.  Post the bodies in a
new email thread. I think neither is using the right asm constraints.
And enable seems to be using too many instructions. My guess is
you only need to get the value in a register and move to the spr.
Handling the constraints right will probably reduce this to one
instruction.  We need Christian's help since I don't know or1k asm.

+ disable didn't return the previous level so it couldn't be restored.

+ I (think) I fixed the prototype for _CPU_Initialize_fp.

In general, any warning originating from score/cpu code is very bad
and usually indicates a real problem. It also results in 1000s of
warnings in the build logs.

--joel

On 7/18/2014 3:16 PM, Hesham Moustafa wrote:
 On Fri, Jul 18, 2014 at 4:19 PM, Gedare Bloom ged...@rtems.org wrote:
 I see you are kind of copying the file structure of ARM. I'm not sure
 this is a good example for a simple port. m68k is more
 straightforward.

 Which file?y
 -Gedare

 On Fri, Jul 18, 2014 at 10:17 AM, Gedare Bloom ged...@rtems.org wrote:
 On Fri, Jul 18, 2014 at 1:35 AM, Hesham Moustafa
 heshamelmat...@gmail.com wrote:
 On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 This definitely sounds like not handling the context switch necessary
 part of the
 IRQ processing properly so always returning to IDLE. I call this a
 simple return.

 All ports have a version of this code. no_cpu should have reasonable
 pseudo-code.
 m68k is likely the easiest to read as real code.

 You need to do a simple return if:

 (a) IRQ is nested, or
 (b) DISPATCH_NEEDED is false

 This is a macro that defines the address of the corresponding variable
 within the per cpu config table right? Please correct the following if
 I it's wrong. From assembly (when doing restore after C ISR handler is
 executed), I have to load this variable value, check if it's true
 (greater than zero), and if yes, jump to _ISR_Dispatch. I am a little
 confused what context should be loaded in both cases of: simple
 return, and _ISR_Dispatch; In case of _ISR_Dispatch, should I save
 stack pointer and return address and other context like normal context
 switch (function call)? While in interrupt context (simple return), I
 am saving almost all registers with some other necessary registers
 related to exceptions.

 Please see 
 http://rtems.org/onlinedocs/doc-current/share/rtems/html/porting/Interrupts-Interrupt-Dispatching.html#Interrupts-Interrupt-Dispatching

 Summarizing:

 You need to update a few variables before calling the user ISR:
 _Thread_Dispatch_disable_level += 1
 _ISR_Nest_level += 1

 And decrement them after returning.
 If ISRs are nested you do a simple return.

 Then you need to check if _CPU_ISR_Dispatch_disable is set, if so do a
 simple return.

 Then you need to check if DISPATCH_NEEDED, if so you need to do the
 ISR_Dispatch.


 One thing I have a problem with, is when using some macros like
 DISPATCH_NEEDED (it's a variable address right?) I am normally
 including rtems/score/percpu.h from the assembly file (which does the
 magic) to get these definitions but the compiler suffers. I think I
 have to provide compiler option or something to just include #define
 macros? If yes, where to add it?

 Make sure to include rtems/asm.h before including percpu.h so you get
 the ASM defines instead of C defines, since you are (presumably)
 writing this in assembly. You could also use inline assembly, but then
 you need to use expression operands [1] to provide access to these
 variables instead.

 [1]  https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

 -Gedare

 Otherwise, you need to some CPU specific magic to get our of the IRQ and
 back to the thread. Make it look like it called _Thread_Dispatch with
 sufficient saved registers (e.g. callee destroyed). This is usually called
 _ISR_Dispatch.  When the call from _ISR_Dispatch to _Thread_Dispatch
 returns, you do the magic needed to return tot he interrupted thread
 (IDLE in this case) as if nothing happened.

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

Re: capture engine use of workspace_allocate

[Joel Sherrill]

On July 21, 2014 10:44:15 AM CDT, Gedare Bloom ged...@rtems.org wrote:
Either account for it in workspace sizing or use malloc.

On principle, I guess any dynamic allocated memory that isn't mandatory
to get RTEMS to work should come from malloc.

With one malloc and two workspace allocates, I assumed we should use malloc for 
all three. 

This is too dynamic for the workspace IMO.



-Gedare


On Mon, Jul 21, 2014 at 10:41 AM, Jennifer Averett
jennifer.aver...@oarcorp.com wrote:

The capture engine currently uses a mixture of malloc and 

rtems_workspace_allocate.  We don’t think the workspace

accounts for this, and would like to propose changing it

so that malloc is used for all memory allocation.  Does anyone

see any reason this shouldn’t be done?

 

--jennifer


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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] rbtree: Format

[Joel Sherrill]

 = ( *compare )( the_node, iter_node );
 +while ( iter_node ) {
 +  int compare_result = ( *compare )( the_node, iter_node );
 +
if ( is_unique  _RBTree_Is_equal( compare_result ) )
  return iter_node;
 +
RBTree_Direction dir = !_RBTree_Is_lesser( compare_result );
 -  if (!iter_node-child[dir]) {
 -the_node-child[RBT_LEFT] = the_node-child[RBT_RIGHT] = NULL;
 +
 +  if ( !iter_node-child[ dir ] ) {
 +the_node-child[ RBT_LEFT ] = the_node-child[ RBT_RIGHT ] = NULL;
  the_node-color = RBT_RED;
 -iter_node-child[dir] = the_node;
 +iter_node-child[ dir ] = the_node;
  the_node-parent = iter_node;
  /* update min/max */
  compare_result = ( *compare )(
the_node,
_RBTree_First( the_rbtree, dir )
  );
 -if ( (!dir  _RBTree_Is_lesser(compare_result)) ||
 -  (dir  _RBTree_Is_greater(compare_result)) ) {
 -  the_rbtree-first[dir] = the_node;
 +
 +if (
 +  ( !dir  _RBTree_Is_lesser( compare_result ) )
 +|| ( dir  _RBTree_Is_greater( compare_result ) )
 +) {
 +  the_rbtree-first[ dir ] = the_node;
  }
 +
  break;
} else {
 -iter_node = iter_node-child[dir];
 +iter_node = iter_node-child[ dir ];
}
 -
  } /* while(iter_node) */

  /* verify red-black properties */
 -_RBTree_Validate_insert(the_node);
 +_RBTree_Validate_insert( the_node );
}
 -  return (RBTree_Node*)0;
 +
 +  return (RBTree_Node *) 0;
  }
 diff --git a/cpukit/score/src/rbtreeiterate.c 
 b/cpukit/score/src/rbtreeiterate.c
 index f325567..8b5da1e 100644
 --- a/cpukit/score/src/rbtreeiterate.c
 +++ b/cpukit/score/src/rbtreeiterate.c
 @@ -28,17 +28,17 @@

  void _RBTree_Iterate(
const RBTree_Control *rbtree,
 -  RBTree_Direction dir,
 -  RBTree_Visitor visitor,
 -  void *visitor_arg
 +  RBTree_Direction  dir,
 +  RBTree_Visitorvisitor,
 +  void *visitor_arg
  )
  {
 -  RBTree_Direction opp_dir = _RBTree_Opposite_direction( dir );
 +  RBTree_Direction   opp_dir = _RBTree_Opposite_direction( dir );
const RBTree_Node *current = _RBTree_First( rbtree, opp_dir );
 -  bool stop = false;
 +  bool   stop = false;

while ( !stop  current != NULL ) {
 -stop = (*visitor)( current, dir, visitor_arg );
 +stop = ( *visitor )( current, dir, visitor_arg );

  current = _RBTree_Next( current, dir );
}
 diff --git a/cpukit/score/src/rbtreenext.c b/cpukit/score/src/rbtreenext.c
 index fde0bc6..2128ae5 100644
 --- a/cpukit/score/src/rbtreenext.c
 +++ b/cpukit/score/src/rbtreenext.c
 @@ -29,25 +29,26 @@

  RBTree_Node *_RBTree_Next(
const RBTree_Node *node,
 -  RBTree_Direction dir
 +  RBTree_Direction   dir
  )
  {
RBTree_Direction opp_dir = _RBTree_Opposite_direction( dir );
 -  RBTree_Node *current = node-child [dir];
 -  RBTree_Node *next = NULL;
 +  RBTree_Node *current = node-child[ dir ];
 +  RBTree_Node *next = NULL;

if ( current != NULL ) {
  next = current;
 -while ( (current = current-child [opp_dir]) != NULL ) {
 +
 +while ( ( current = current-child[ opp_dir ] ) != NULL ) {
next = current;
  }
} else {
  RBTree_Node *parent = node-parent;

 -if ( parent-parent  node == parent-child [opp_dir] ) {
 +if ( parent-parent  node == parent-child[ opp_dir ] ) {
next = parent;
  } else {
 -  while ( parent-parent  node == parent-child [dir] ) {
 +  while ( parent-parent  node == parent-child[ dir ] ) {
  node = parent;
  parent = parent-parent;
}
 --
 1.8.1.4

 ___
 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: KICS! brainstorming

[Joel Sherrill]

On 7/22/2014 1:05 PM, Daniel Gutson wrote:
 Hi,

we are working in a very RAM constrained board, and noticed that
 some symbols could be moved to ROM by declaring them const.
Have you been through the configure options like switching scheduler,
lowering
stack sizes, etc.?
 I have a slight idea about creating a consts-candidate detector tool
 KICS! (Keep It Const, St.! :) ), and wanted to hear some other
 people ideas.

 Initial thoughts:
   - one approach could be a gdb script, in which we first read all the
 RAM memory of global objects after initialization (#1), and compare
 the memory at the end (#2), see what remained unchanged; this could
 throw many false positives but would be a starting point.
This could give you a quick list of candidates. Then.. below.
   - another, I think tougher, is some pointer-tracking static analysis
 as a gcc plugin (not sure if it is even possible).
Likely very difficult.
 Other ideas?
Make them const and see if they end up on the right hand side of an
assignment?

When you think you have a candidate, ask on the list if it can be const.
Include a patch, especially if it involves more than changing the const
declaration. Given a candidate, I would expect the developers to have
a pretty quick assessment.

Also in some places, we have gone to a single data structure with
fields which might otherwise be global variables.  This only puts
one symbol in the public name space. It is possible that in some
cases, there may be data items mixed which could be const with
those which can't.

--joel


 (#1) after bsp_start? after rtems_initialize_data_structures?

 (#2) for some user-definition of end, and/or after
 rtems_shutdown_executive or alike?

 Thanks!

Daniel.


-- 
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 nios2-*-rtems* (v2 for gcc head and 4.9)

[Joel Sherrill]

Please review before I send to gcc.

Thanks.

2014-07-17  Sebastian Huber  sebastian.hu...@embedded-brains.de
Chris Johns chr...@rtems.org
Joel Sherrill joel.sherr...@oarcorp.com

* config.gcc: Add nios2-*-rtems*.
* config/nios2/rtems.h: New file.
* gcc/config/nios2/t-rtems: New file.
---
 gcc/ChangeLog|   3 +-
 gcc/config.gcc   |   6 ++-
 gcc/config/nios2/rtems.h |  32 
 gcc/config/nios2/t-rtems | 133 +++
 4 files changed, 171 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/nios2/rtems.h
 create mode 100644 gcc/config/nios2/t-rtems

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ccc2b97..0c4322b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -243,8 +243,7 @@
set_comdat_group to NULL_TREE.
(verify_symtab): Fix diagnostic.
 
-2014-07-16  David Wohlferd  d...@limegreensocks.com
-
+2014-07-16  David Wohlferd d...@limegreensocks.com
PR target/61662
* config/i386/ia32intrin.h: Use __LP64__ to determine size of long.
 
diff --git a/gcc/config.gcc b/gcc/config.gcc
index aa2d1a9..9b3637e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -419,7 +419,7 @@ nds32*)
 nios2-*-*)
cpu_type=nios2
extra_options=${extra_options} g.opt
-   ;;  
+   ;;
 picochip-*-*)
 cpu_type=picochip
 ;;
@@ -2136,6 +2136,10 @@ nios2-*-*)
tm_file=${tm_file} newlib-stdint.h nios2/elf.h
extra_options=${extra_options} nios2/elf.opt
;;
+   nios2-*-rtems*)
+   tm_file=${tm_file} newlib-stdint.h nios2/rtems.h rtems.h
+   tmake_file=${tmake_file} t-rtems nios2/t-rtems
+   ;;
 esac
;;
 pdp11-*-*)
diff --git a/gcc/config/nios2/rtems.h b/gcc/config/nios2/rtems.h
new file mode 100644
index 000..d085980
--- /dev/null
+++ b/gcc/config/nios2/rtems.h
@@ -0,0 +1,32 @@
+/* Definitions for rtems targeting a NIOS2 using ELF.
+   Contributed by Chris Johns (chr...@rtems.org).
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+http://www.gnu.org/licenses/.  */
+
+/* Specify predefined symbols in preprocessor.  */
+#define TARGET_OS_CPP_BUILTINS()\
+do {\
+  builtin_define (__rtems__); \
+  builtin_define (__USE_INIT_FINI__); \
+  builtin_assert (system=rtems);  \
+} while (0)
+
+/* This toolchain implements the ABI for Linux Systems documented in the
+   Nios II Processor Reference Handbook.
+
+   This is done so RTEMS targets have Thread Local Storage like Linux.  */
+#define TARGET_LINUX_ABI 1
diff --git a/gcc/config/nios2/t-rtems b/gcc/config/nios2/t-rtems
new file mode 100644
index 000..f95fa3c
--- /dev/null
+++ b/gcc/config/nios2/t-rtems
@@ -0,0 +1,133 @@
+# Custom RTEMS multilibs
+
+MULTILIB_OPTIONS = mhw-mul mhw-mulx mhw-div mcustom-fadds=253 
mcustom-fdivs=255 mcustom-fmuls=252 mcustom-fsubs=254
+
+# Enumeration of multilibs
+
+# MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254
+MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252
+MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fsubs=254
+# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div
+MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mcustom-fadds

Re: KICS! brainstorming

[Joel Sherrill]

On 7/22/2014 1:05 PM, Daniel Gutson wrote:
 Hi,

we are working in a very RAM constrained board, and noticed that
 some symbols could be moved to ROM by declaring them const.

 I have a slight idea about creating a consts-candidate detector tool
 KICS! (Keep It Const, St.! :) ), and wanted to hear some other
 people ideas.

 Initial thoughts:
   - one approach could be a gdb script, in which we first read all the
 RAM memory of global objects after initialization (#1), and compare
 the memory at the end (#2), see what remained unchanged; this could
 throw many false positives but would be a starting point.

   - another, I think tougher, is some pointer-tracking static analysis
 as a gcc plugin (not sure if it is even possible).

 Other ideas?
A couple other idea without knowing the BSP.

Turn on per function/data items sections. This has been done for the
SPARC BSPs
and had a pretty big impact on the size of the tests. I haven't heard
any reports
on real applications yet. This will require changing gcc and linking
flags and tinkering
with the linker script if it doesn't use * in all the right places for
pattern matching.

Put together a minimal version of your app. Basically just make the
calls you know
you need. Don't worry if it runs. Look through the symbol table and see
if there
are unexpected or undesired capabilities.  For example, some BSPs
unintentionally
put the printk() support in the same file with the real console driver.
Without
per-function sections, something calls printk() and end up with the
console driver
and termios.

If your application has lower requirements than what we think of as a
minimum,
we can refine our definition of minimum capabilities.

All of these are important to us as a project. Knowing unexpected
dependencies,
turning on per item sections, and lowering minimum capabilities based on
user
feedbac.


 (#1) after bsp_start? after rtems_initialize_data_structures?

 (#2) for some user-definition of end, and/or after
 rtems_shutdown_executive or alike?

 Thanks!

Daniel.


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

Tool Upstream Patch Update

[Joel Sherrill]

Hi

I have committed a few patches this week for multiple targets and
wanted to pass along the news for those who care.

+ binutils-gdb:
   - or1k*-*-rtems* builds but requires a pending patch to disable
 gdb until OpenRISC folks submit their gdb port

+ newlib-cvs:
   - adjtime() prototype added.
   - settimeofday() and adjtime() now wrapped as BSD methods

+ gcc:
  - nios2*-*-rtems*: Support added to 4.9 branch and head.
The backend nios2 support is finally upstream. :)
  - arm*-rtems*: Committed patch for Cortex-M4 and Cortex-R
multilibs to 4.8, 4.9, and head

There are pending patches moving through the OpenRISC project
for or1k gcc support. They will be merged as part of the or1k target
support being added.

If anyone has any outstanding tool patches for these repositories
that I missed, ping me.

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

adjtime() changes

[Joel Sherrill]

Hi

I should point out that I am NOT trying to particularly improve the
way we adjust time. I am only

(1) making the code use timestamps not ticks

(2) moving the adjust code to the SCORE

The use of critical sections is exactly as it was before.

The preferable way to adjust TOD is in small increments per clock tick.
If someone is interested in great NTP support for RTEMS, please speak
up. Volunteering or sponsoring some work would be of benefit to
the community.

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

Fermi Finds Transformer Pulsar - RTEMS?

[Joel Sherrill]

Hi

I noticed this cool announcement from Fermi.

http://www.nasa.gov/content/goddard/nasas-fermi-finds-a-transformer-pulsar

I am guessing that was done using the GLAST sensor from SLAC
and thus using RTEMS?  Is that right?

Anyone on the list got any insight they would like to share.

Thanks.

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

Fwd: [ANNOUNCEMENT] GDB 7.8 released!

[Joel Sherrill]

 Original Message 
From: Joel Brobecker brobec...@adacore.com
Sent: July 29, 2014 10:59:39 AM EDT
To: g...@sourceware.org g...@sourceware.org
Subject: [ANNOUNCEMENT] GDB 7.8 released!



GDB 7.8 released!

Release 7.8 of GDB, the GNU Debugger, is now available via anonymous
FTP.  GDB is a source-level debugger for Ada, C, C++, Objective-C,
Pascal and many other languages.  GDB can target (i.e., debug programs
running on) more than a dozen different processor architectures, and GDB
itself can run on most popular GNU/Linux, Unix and Microsoft Windows
variants.

You can download GDB from the GNU FTP server in the directory:

ftp://ftp.gnu.org/gnu/gdb

The vital stats:

  Size   md5sumName
  17MiB  bd958fe9019d7c7896f29f6724a764ed  gdb-7.8.tar.xz
  32MiB  38d816d641093db2e13ba284e26090b4  gdb-7.8.tar.gz

There is a web page for GDB at:

http://www.gnu.org/software/gdb/

That page includes information about GDB mailing lists (an announcement
mailing list, developers discussion lists, etc.), details on how to
access GDB's source repository, locations for development snapshots,
preformatted documentation, and links to related information around
the net.  We will put errata notes and host-specific tips for this release
on-line as any problems come up.  All mailing lists archives are also
browsable via the web.

GDB 7.8 brings new targets, features and improvements, including:

  * Guile scripting support.

  * Python scripting enhancements.

  * New commands:

** guile
** guile-repl
** info auto-load guile-scripts [REGEXP]

  * New options:

** maint ada set ignore-descriptive-types (on|off)
** maint set target-async (on|off)
** set|show auto-load guile-scripts (on|off)
** set|show auto-connect-native-target
** set|show guile print-stack (none|message|full)
** set|show mi-async (on|off)
** set|show print symbol-loading (off|brief|full)
** set|show record btrace replay-memory-access (read-only|read-write)

  * Deprecated commands:

** dll-symbols and its two aliases (add-shared-symbol-files and
   assf). Use the sharedlibrary command instead.
** set|show remotebaud. Use set|show serial baud instead.

  * Remote Protocol:

** The qXfer:btrace:read packet supports a new annex 'delta'.

  * GDB/MI:

** A new option -gdb-set mi-async replaces -gdb-set target-async.

  * New target configurations:

** PowerPC64 GNU/Linux little-endian   powerpc64le-*-linux*

 * btrace enhancements:

** The btrace record target now supports the 'record goto' command.
** The btrace record target supports limited reverse execution and
   replay.

 * ISO C99 variable length automatic arrays support.

 * It is no longer required to set target-async on in order to use
   background execution commands (e.g., c, s, etc.).

 * catch syscall now implemented on s390*-linux* targets.

 * The compare-sections command now works on all targets.

 * The target native command now connects to the native target, and
   can be used to launch native programs, even if set
   auto-connect-native-target is set to off.

For a complete list and more details on each item, please see the
gdb/NEWS file.

-- 
Joel Brobecker

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

Re: [GSoC] OpenRISC port | ISR_Enable/Disable and isr_level

[Joel Sherrill]

On July 31, 2014 8:54:29 AM CDT, Hesham Moustafa heshamelmat...@gmail.com 
wrote:
Hi all,

I was trying to figure out where to increment ISR level related
variables. First, I wanna indicate that the current OpenRISC port only
has two level of interrupts: disable/enable. Given that, does this
mean that the maximum interrupt level is 1?

I noticed that there is some architectures have its own (static)
variable to contain isr_level, other RTEMS portable structures like
per_cpu structure has its own isr_level variable, and some have this
embedded in Context_Control. Maybe one of the previous variables are
just reading from an original one? If so, where it's? I assume it's
all read from one global/static variable which we can get directly
from a call to _CPU_ISR_Disable down to the architecture specific
function (at cpu.h?). If that's right, should _CPU_ISR_Disable (in
case of OpenRISC) just did the magic to disable interrupts in HW, and
always return 1 (or increment a static variable if interrupts are
already disable and do nothing in HW?)
_CPU_ISR_Enable in turn, should check on this level, decrements it,
and only do the HW magic to enable interrupts when level = 1? Please
correct me if I am getting this wrong.

ISR disable and enable should not need to touch any global data or per 
thread/CPU data. They disable maskable interrupts at the CPU level. This 
usually involves a single special status register. Return the value of this 
register before disable to the caller. That value is passed to enable and flash.

Another question is, where/when should this variable be
incremented/decremented? Currently I did that from or1k/cpu.h from the
HW disable/enable interrupts function (which is called from
_ISR_[Disable|Enable]. Also, there are some architectures (like nios2)
increment/decrement it from the _ISR_Handler sometimes hard-coded in
assembly code. And of course, which variable exactly to be incremented
(the static one, the one at per_cpu and using macros for calculating
its address/offset, or where?)
I see also some high-level variable always incremented before every
call to _ISR_Enable, and decremented before _ISR_Disable.

I think you have confused isr disable level and isr nest level. Nest level is 
part of the asm code for irqs.

Thanks in advance,
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: [GSoC Mentors] GSoC 2014 Mentors/Org Admins: Pencils Down and Final Evaluation Dates Approaching

[Joel Sherrill]

Hi

Just a reminder to all students and mentors that we are approaching the end.

-- Forwarded message --
From: 'Carol Smith' via Google Summer of Code Mentors List 
google-summer-of-code-mentors-l...@googlegroups.com
Date: Mon, Aug 4, 2014 at 11:46 AM
Subject: [GSoC Mentors] GSoC 2014 Mentors/Org Admins: Pencils Down and
Final Evaluation Dates Approaching
To: Google Summer of Code Mentors List 
google-summer-of-code-mentors-l...@googlegroups.com


Hi there,

This is a friendly reminder that Monday, 11 August is our soft pencils
down date. We suggest that students have completed their projects by this
date and spend a week writing documentation and wrapping up their projects.
We require that students stop all coding on 18 August.

Monday, 18 August at 19:00 UTC is when final evaluations open. Please
consider this your reminder to submit your final evaluation by 22 August at
19:00 UTC so that you don't delay your students' final payments or possibly
jeopardize your organization's attendance at the reunion.

I have updated the code submission guidelines
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/codeguidelines
and
posted it on Melange for your reference. Code submission begins once
students have received a passing grade on their final evaluations (after 22
August). The deadline is 19 September. One question students ask a lot is
what portion of their code to submit if they made changes to an existing
code base or their code interacts a lot with a system they didn't write.
The answer is: use your best discretion. Have them submit the code that
makes the most sense from a user's perspective. If students need help with
code submission they should contact the Melange team at
melange-soc-...@googlegroups.com.

I have posted the questions for the final evaluations below as well for
your reference.

Cheers,
Carol
---

   1.

   How would you rate the student’s performance on his/her project since
   the midterm evaluations?
   1.

  It has improved since the midterm
  2.

  It has stayed the same since the midterm
  3.

  It has gotten worse since the midterm
  2.

   Considering your student’s original project proposal, how closely does
   the project produced reflect the project proposed?
   1.

  It’s almost exactly the same - there have been very few changes to
  the project
  2.

  It’s similar - there have been some changes over the course of the
  summer
  3.

  It’s different - we changed the goals or scope of the project
  4.

  It’s different - the student diverged from the project plan
  3.

   How much time have you spent on Google Summer of Code since the mid term
   evaluations (again, take into consideration both time mentoring the student
   and working on the program as a whole)?
   1.

  10-15 hours per week
  2.

  15-20 hours per week
  3.

  20-25 hours per week
  4.

  25-30 hours per week
  5.

  30-35 hours per week
  6.

  35-40 hours per week
  7.

  40+ hours per week
  4.

   How does this amount of time spent on the program compare to before the
   midterms?
   1.

  It’s less than before the midterms
  2.

  It’s about the same
  3.

  It’s more than before the midterms
  5.

   How would you rate your student’s performance overall?
   1.

  Excellent - amongst the best performers I’ve ever worked with
  2.

  Strong, solid performance
  3.

  Okay
  4.

  Poor
  6.

   How would you rate your experience with the program overall?
   1.

  Excellent - one of the best programs I’ve ever participated in
  2.

  Very good
  3.

  Okay
  4.

  Poor
  7. If you are failing your student, please answer the next question:


   1.

   Why did you fail the student (check all that apply)
   1.

  the student was uncommunicative with their mentor
  2.

  the student was uncommunicative with the project community
  3.

  student disappeared after midterm
  4.

  the student didn’t complete their project
  5.

  The student did not stick to their timeline or project plan
  6.

  The students’ work was of poor quality, in spite of our/my efforts to
  help them improve
  7.

  other


   1.

   What one thing would you tell mentors for your organization to do in the
   future to help the students’ experience with the program?
   2.

   What was the most rewarding and/or difficult part of the program for you
   this year?
   3.

   Is there additional information we should tell future students before
   applying to future programs?
   4.

   Anything else you’d like to tell us?

 --
You received this message because you are subscribed to the Google Groups
Google Summer of Code Mentors List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to 

Re: [GSoC] OpenRISC port | ISR_Enable/Disable and isr_level

[Joel Sherrill]

On 7/31/2014 9:31 AM, Hesham Moustafa wrote:
 On Thu, Jul 31, 2014 at 4:17 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:

 On July 31, 2014 8:54:29 AM CDT, Hesham Moustafa heshamelmat...@gmail.com 
 wrote:
 Hi all,

 I was trying to figure out where to increment ISR level related
 variables. First, I wanna indicate that the current OpenRISC port only
 has two level of interrupts: disable/enable. Given that, does this
 mean that the maximum interrupt level is 1?

 I noticed that there is some architectures have its own (static)
 variable to contain isr_level, other RTEMS portable structures like
 per_cpu structure has its own isr_level variable, and some have this
 embedded in Context_Control. Maybe one of the previous variables are
 just reading from an original one? If so, where it's? I assume it's
 all read from one global/static variable which we can get directly
 from a call to _CPU_ISR_Disable down to the architecture specific
 function (at cpu.h?). If that's right, should _CPU_ISR_Disable (in
 case of OpenRISC) just did the magic to disable interrupts in HW, and
 always return 1 (or increment a static variable if interrupts are
 already disable and do nothing in HW?)
 _CPU_ISR_Enable in turn, should check on this level, decrements it,
 and only do the HW magic to enable interrupts when level = 1? Please
 correct me if I am getting this wrong.
 ISR disable and enable should not need to touch any global data or per 
 thread/CPU data. They disable maskable interrupts at the CPU level. This 
 usually involves a single special status register. Return the value of this 
 register before disable to the caller. That value is passed to enable and 
 flash.

 So, for or1k port, should or1k_interrupt_disable (at cpu.h) just
 return the value of sr (supervision/status register) before I do
 disable interrupts in HW?
Yes. The level returned is simply the value from the sr and is simply put
back in the sr to restore the previous level.

This nests nicely although we do not intend that it ever does.
 Another question is, where/when should this variable be
 incremented/decremented? Currently I did that from or1k/cpu.h from the
 HW disable/enable interrupts function (which is called from
 _ISR_[Disable|Enable]. Also, there are some architectures (like nios2)
 increment/decrement it from the _ISR_Handler sometimes hard-coded in
 assembly code. And of course, which variable exactly to be incremented
 (the static one, the one at per_cpu and using macros for calculating
 its address/offset, or where?)
 I see also some high-level variable always incremented before every
 call to _ISR_Enable, and decremented before _ISR_Disable.
 I think you have confused isr disable level and isr nest level. Nest level 
 is part of the asm code for irqs.

 Now I know that isr_disable_level should hold the content of the sr
 register (before disabling interrupts in HW) to be used when calling
 _ISR_Enable again.
 So, where is isr_nest_level should be defined and touched (in
 _ISR_Handler)? And for or1k, should this hold maximum value of 1 at a
 given time?
It is in the per cpu information structure.

If you do not have interrupt levels in hardware or a driver reenables
interrupts,
in practice, it will always be 0 when a task is executing and always 1
when in an ISR.

But that is not the general case. If interrupts are reenabled in the ISR
handler or
there are multiple IRQ sources and the CPU/PIC prioritizes them, then
nesting
IRQs is fairly routine.
 Thanks in advance,
 Hesham
 ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel
 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

GCC Head Gives C++ Compile Error with RTEMS

[Joel Sherrill]

Hi

SMP was enabled.

sparc-rtems4.11-g++ -B../../.././lib/ -B../../.././sis/lib/ -specs
bsp_specs -qrtems -DPACKAGE_NAME=\rtems-c-src-librtems++\
-DPACKAGE_TARNAME=\rtems-c-src-librtems++\
-DPACKAGE_VERSION=\4.10.99.0\
-DPACKAGE_STRING=\rtems-c-src-librtems++\ 4.10.99.0\
-DPACKAGE_BUGREPORT=\http://www.rtems.org/bugzilla\; -DPACKAGE_URL=\\
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I.
-I../../../../../rtems/c/src/librtems++  -isystem
../../.././sis/lib/include   -mcpu=cypress -O2 -g -ffunction-sections
-fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
src/librtems___a-rtemsEvent.o -MD -MP -MF
src/.deps/librtems___a-rtemsEvent.Tpo -c -o
src/librtems___a-rtemsEvent.o `test -f 'src/rtemsEvent.cc' || echo
'../../../../../rtems/c/src/librtems++/'`src/rtemsEvent.cc
cc1plus: warning: command line option '-Wmissing-prototypes' is valid
for C/ObjC but not for C++
cc1plus: warning: command line option '-Wimplicit-function-declaration'
is valid for C/ObjC but not for C++
cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
C/ObjC but not for C++
cc1plus: warning: command line option '-Wnested-externs' is valid for
C/ObjC but not for C++
In file included from
/users/joel/test-gcc/install-head/lib/gcc/sparc-rtems4.11/4.10.0/include/c++/atomic:38:0,
 from
../../.././sis/lib/include/rtems/score/cpustdatomic.h:31,
 from ../../.././sis/lib/include/rtems/score/cpuatomic.h:12,
 from ../../.././sis/lib/include/rtems/score/atomic.h:20,
 from ../../.././sis/lib/include/rtems/score/smplock.h:27,
 from ../../.././sis/lib/include/rtems/score/percpu.h:28,
 from ../../.././sis/lib/include/rtems/system.h:23,
 from ../../.././sis/lib/include/rtems.h:29,
 from
../../.././sis/lib/include/rtems++/rtemsStatusCode.h:22,
 from ../../.././sis/lib/include/rtems++/rtemsEvent.h:23,
 from
../../../../../rtems/c/src/librtems++/src/rtemsEvent.cc:19:
/users/joel/test-gcc/install-head/lib/gcc/sparc-rtems4.11/4.10.0/include/c++/bits/c++0x_warning.h:32:2:
error: #error This file requires compiler and library support for the
ISO C++ 2011 standard. This support is currently experimental, and must
be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support for the \

-- 
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: Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Joel Sherrill]

On 8/8/2014 8:54 AM, Gedare Bloom wrote:
 Hi,
 The macro CPU_ISR_PASSES_FRAME_POINTER is part of a cpu port defined
 in cpu.h, but this macro seems to be unused. I don't know what the
 purpose of it was intended. Anyway, it appears to be wrong for some
 architectures (ARM and sparc64 at least, maybe others). Should we
 remove the macro, or find a use for it and make sure it is correctly
 defined for each arch?
The intent is that for simple vectored, some architectures passed a vector
number and some passed a vector number and a pointer to the interrupt
stack frame. This predates the addition of the PIC model.

In general terms, I don't know if all simple vectored architectures
pass one or two parameters.

Is this used anywhere in the tree? Sometimes drivers would use it to
adjust the ISR handler prototype to avoid warnings.
 Gedare
 ___
 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: Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Joel Sherrill]

On 8/8/2014 9:38 AM, Hesham Moustafa wrote:
 On Fri, Aug 8, 2014 at 4:02 PM, Joel Sherrill joel.sherr...@oarcorp.com 
 wrote:
 On 8/8/2014 8:54 AM, Gedare Bloom wrote:
 Hi,
 The macro CPU_ISR_PASSES_FRAME_POINTER is part of a cpu port defined
 in cpu.h, but this macro seems to be unused. I don't know what the
 purpose of it was intended. Anyway, it appears to be wrong for some
 architectures (ARM and sparc64 at least, maybe others). Should we
 remove the macro, or find a use for it and make sure it is correctly
 defined for each arch?
 The intent is that for simple vectored, some architectures passed a vector
 number and some passed a vector number and a pointer to the interrupt
 stack frame. This predates the addition of the PIC model.

 In general terms, I don't know if all simple vectored architectures
 pass one or two parameters.

 Is this used anywhere in the tree? Sometimes drivers would use it to
 adjust the ISR handler prototype to avoid warnings.
 It's used only at isr.h:62

 62 #if (CPU_ISR_PASSES_FRAME_POINTER == 1)
  63 typedef ISR_Handler ( *ISR_Handler_entry )(
  64  ISR_Vector_number,
  65  CPU_Interrupt_frame *
  66  );
  67 #else
  68 typedef ISR_Handler ( *ISR_Handler_entry )(
  69  ISR_Vector_number
  70  );
  71 #endif
But that has rippling implications.  I don't think we want to
change that at the moment. But we could turn it to 1 for
every architecture and see the impact.  But most architectures
have it as single arg. I know the MIPS passes it in so it can
handle FPU exceptions in an RTEMS ISR. To get IEEE FP
on some MIPS, you need the exception handler.

All other ports set this to FALSE/0.

So percpu.h needs to be fixed.
 Gedare
 ___
 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

-- 
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: Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Joel Sherrill]

On 8/8/2014 10:11 AM, Gedare Bloom wrote:
 On Fri, Aug 8, 2014 at 10:52 AM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/8/2014 9:38 AM, Hesham Moustafa wrote:
 On Fri, Aug 8, 2014 at 4:02 PM, Joel Sherrill joel.sherr...@oarcorp.com 
 wrote:
 On 8/8/2014 8:54 AM, Gedare Bloom wrote:
 Hi,
 The macro CPU_ISR_PASSES_FRAME_POINTER is part of a cpu port defined
 in cpu.h, but this macro seems to be unused. I don't know what the
 purpose of it was intended. Anyway, it appears to be wrong for some
 architectures (ARM and sparc64 at least, maybe others). Should we
 remove the macro, or find a use for it and make sure it is correctly
 defined for each arch?
 The intent is that for simple vectored, some architectures passed a vector
 number and some passed a vector number and a pointer to the interrupt
 stack frame. This predates the addition of the PIC model.

 In general terms, I don't know if all simple vectored architectures
 pass one or two parameters.

 Is this used anywhere in the tree? Sometimes drivers would use it to
 adjust the ISR handler prototype to avoid warnings.
 It's used only at isr.h:62

 62 #if (CPU_ISR_PASSES_FRAME_POINTER == 1)
  63 typedef ISR_Handler ( *ISR_Handler_entry )(
  64  ISR_Vector_number,
  65  CPU_Interrupt_frame *
  66  );
  67 #else
  68 typedef ISR_Handler ( *ISR_Handler_entry )(
  69  ISR_Vector_number
  70  );
  71 #endif
 But that has rippling implications.  I don't think we want to
 change that at the moment. But we could turn it to 1 for
 every architecture and see the impact.  But most architectures
 have it as single arg. I know the MIPS passes it in so it can
 handle FPU exceptions in an RTEMS ISR. To get IEEE FP
 on some MIPS, you need the exception handler.

 All other ports set this to FALSE/0.

 Well, so far I've seen that arm, sparc, and sparc64 pass the frame
 pointer. i386 does not.
The setting doesn't seem right for those. I only saw 1/true for MIPS.

It could be wrong for those.
 -Gedare
 So percpu.h needs to be fixed.
 Gedare
 ___
 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
 --
 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


-- 
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: [PATCH] Add support for OpenRISC - Fixed issues

[Joel Sherrill]

OK with me.

It will be easier to address issues once merged anyway. 

I plan to commit, try to build, report, then Hesham can rebase and report.

On August 12, 2014 12:49:10 PM CDT, Gedare Bloom ged...@rtems.org wrote:
OK from me.

On Tue, Aug 12, 2014 at 11:57 AM, Hesham ALMatary
heshamelmat...@gmail.com wrote:
 This work is based on the old or32 port (that has been
 removed back in 2005) authored by Chris Ziomkowski. The patch
includes the
 basic functions every port should implement like: context switch,
exception
 handling, OpenRISC ABI and machine definitions and configurations.

 ---
  cpukit/configure.ac|1 +
  cpukit/score/cpu/Makefile.am   |1 +
  cpukit/score/cpu/or1k/Makefile.am  |   36 +
  cpukit/score/cpu/or1k/cpu.c|  112 +++
  cpukit/score/cpu/or1k/or1k-context-initialize.c|   43 +
  cpukit/score/cpu/or1k/or1k-context-switch.S|  115 +++
  cpukit/score/cpu/or1k/or1k-exception-default.c |   24 +
  cpukit/score/cpu/or1k/or1k-exception-frame-print.c |   22 +
  cpukit/score/cpu/or1k/or1k-exception-handler-low.S |  217 
  cpukit/score/cpu/or1k/rtems/asm.h  |   99 ++
  cpukit/score/cpu/or1k/rtems/score/cpu.h| 1051

  cpukit/score/cpu/or1k/rtems/score/cpu_asm.h|   74 ++
  cpukit/score/cpu/or1k/rtems/score/or1k-utility.h   |  371 +++
  cpukit/score/cpu/or1k/rtems/score/or1k.h   |   49 +
  cpukit/score/cpu/or1k/rtems/score/types.h  |   51 +
  15 files changed, 2266 insertions(+)
  create mode 100644 cpukit/score/cpu/or1k/Makefile.am
  create mode 100644 cpukit/score/cpu/or1k/cpu.c
  create mode 100644 cpukit/score/cpu/or1k/or1k-context-initialize.c
  create mode 100644 cpukit/score/cpu/or1k/or1k-context-switch.S
  create mode 100644 cpukit/score/cpu/or1k/or1k-exception-default.c
  create mode 100644
cpukit/score/cpu/or1k/or1k-exception-frame-print.c
  create mode 100644
cpukit/score/cpu/or1k/or1k-exception-handler-low.S
  create mode 100644 cpukit/score/cpu/or1k/rtems/asm.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/cpu.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/cpu_asm.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/or1k-utility.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/or1k.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/types.h

 diff --git a/cpukit/configure.ac b/cpukit/configure.ac
 index 19e5b81..56815e2 100644
 --- a/cpukit/configure.ac
 +++ b/cpukit/configure.ac
 @@ -382,6 +382,7 @@ score/cpu/m32r/Makefile
  score/cpu/mips/Makefile
  score/cpu/moxie/Makefile
  score/cpu/nios2/Makefile
 +score/cpu/or1k/Makefile
  score/cpu/powerpc/Makefile
  score/cpu/sh/Makefile
  score/cpu/sparc/Makefile
 diff --git a/cpukit/score/cpu/Makefile.am
b/cpukit/score/cpu/Makefile.am
 index 8d28fc2..69abcd6 100644
 --- a/cpukit/score/cpu/Makefile.am
 +++ b/cpukit/score/cpu/Makefile.am
 @@ -14,6 +14,7 @@ DIST_SUBDIRS += mips
  DIST_SUBDIRS += moxie
  DIST_SUBDIRS += nios2
  DIST_SUBDIRS += no_cpu
 +DIST_SUBDIRS += or1k
  DIST_SUBDIRS += powerpc
  DIST_SUBDIRS += sh
  DIST_SUBDIRS += sparc
 diff --git a/cpukit/score/cpu/or1k/Makefile.am
b/cpukit/score/cpu/or1k/Makefile.am
 new file mode 100644
 index 000..b3a8ade
 --- /dev/null
 +++ b/cpukit/score/cpu/or1k/Makefile.am
 @@ -0,0 +1,36 @@
 +include $(top_srcdir)/automake/compile.am
 +
 +CLEANFILES =
 +DISTCLEANFILES =
 +
 +include_rtemsdir = $(includedir)/rtems
 +
 +include_rtems_HEADERS = rtems/asm.h
 +
 +include_rtems_scoredir = $(includedir)/rtems/score
 +
 +include_rtems_score_HEADERS =
 +include_rtems_score_HEADERS += rtems/score/cpu.h
 +include_rtems_score_HEADERS += rtems/score/cpu_asm.h
 +include_rtems_score_HEADERS += rtems/score/types.h
 +include_rtems_score_HEADERS += rtems/score/or1k.h
 +include_rtems_score_HEADERS += rtems/score/or1k-utility.h
 +
 +
 +
 +noinst_LIBRARIES = libscorecpu.a
 +
 +libscorecpu_a_SOURCES =
 +libscorecpu_a_SOURCES += cpu.c
 +libscorecpu_a_SOURCES += or1k-context-switch.S
 +libscorecpu_a_SOURCES += or1k-context-initialize.c
 +libscorecpu_a_SOURCES += or1k-exception-default.c
 +libscorecpu_a_SOURCES += or1k-exception-frame-print.c
 +libscorecpu_a_SOURCES += or1k-exception-handler-low.S
 +
 +libscorecpu_a_CPPFLAGS = $(AM_CPPFLAGS)
 +
 +all-local: $(PREINSTALL_FILES)
 +
 +include $(srcdir)/preinstall.am
 +include $(top_srcdir)/automake/local.am
 diff --git a/cpukit/score/cpu/or1k/cpu.c
b/cpukit/score/cpu/or1k/cpu.c
 new file mode 100644
 index 000..9ba49a5
 --- /dev/null
 +++ b/cpukit/score/cpu/or1k/cpu.c
 @@ -0,0 +1,112 @@
 +/*
 + *  Opencore OR1K CPU Dependent Source
 + *
 + *  COPYRIGHT (c) 2014 Hesham ALMatary heshamelmat...@gmail.com
 + *  COPYRIGHT (c) 1989-1999.
 + *  On-Line Applications Research Corporation (OAR).
 + *
 + *  The license and distribution terms for this file may be
 + *  found in the file LICENSE in this distribution or at
 + *  

Re: [PATCH] Add support for OpenRISC - Fixed issues

[Joel Sherrill]

Feedback after committing:

1) cpukit/score/cpu/or1k/prenstall.am was not in patch. I added
and committed it.

2) Without a BSP to specify, nothing gets built.

See how your tree works now that you can rebase. Then let's
get the BSP reviewed and merged.

--joel

On 8/12/2014 12:49 PM, Gedare Bloom wrote:
 OK from me.

 On Tue, Aug 12, 2014 at 11:57 AM, Hesham ALMatary
 heshamelmat...@gmail.com wrote:
 This work is based on the old or32 port (that has been
 removed back in 2005) authored by Chris Ziomkowski. The patch includes the
 basic functions every port should implement like: context switch, exception
 handling, OpenRISC ABI and machine definitions and configurations.

 ---
  cpukit/configure.ac|1 +
  cpukit/score/cpu/Makefile.am   |1 +
  cpukit/score/cpu/or1k/Makefile.am  |   36 +
  cpukit/score/cpu/or1k/cpu.c|  112 +++
  cpukit/score/cpu/or1k/or1k-context-initialize.c|   43 +
  cpukit/score/cpu/or1k/or1k-context-switch.S|  115 +++
  cpukit/score/cpu/or1k/or1k-exception-default.c |   24 +
  cpukit/score/cpu/or1k/or1k-exception-frame-print.c |   22 +
  cpukit/score/cpu/or1k/or1k-exception-handler-low.S |  217 
  cpukit/score/cpu/or1k/rtems/asm.h  |   99 ++
  cpukit/score/cpu/or1k/rtems/score/cpu.h| 1051 
 
  cpukit/score/cpu/or1k/rtems/score/cpu_asm.h|   74 ++
  cpukit/score/cpu/or1k/rtems/score/or1k-utility.h   |  371 +++
  cpukit/score/cpu/or1k/rtems/score/or1k.h   |   49 +
  cpukit/score/cpu/or1k/rtems/score/types.h  |   51 +
  15 files changed, 2266 insertions(+)
  create mode 100644 cpukit/score/cpu/or1k/Makefile.am
  create mode 100644 cpukit/score/cpu/or1k/cpu.c
  create mode 100644 cpukit/score/cpu/or1k/or1k-context-initialize.c
  create mode 100644 cpukit/score/cpu/or1k/or1k-context-switch.S
  create mode 100644 cpukit/score/cpu/or1k/or1k-exception-default.c
  create mode 100644 cpukit/score/cpu/or1k/or1k-exception-frame-print.c
  create mode 100644 cpukit/score/cpu/or1k/or1k-exception-handler-low.S
  create mode 100644 cpukit/score/cpu/or1k/rtems/asm.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/cpu.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/cpu_asm.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/or1k-utility.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/or1k.h
  create mode 100644 cpukit/score/cpu/or1k/rtems/score/types.h

 diff --git a/cpukit/configure.ac b/cpukit/configure.ac
 index 19e5b81..56815e2 100644
 --- a/cpukit/configure.ac
 +++ b/cpukit/configure.ac
 @@ -382,6 +382,7 @@ score/cpu/m32r/Makefile
  score/cpu/mips/Makefile
  score/cpu/moxie/Makefile
  score/cpu/nios2/Makefile
 +score/cpu/or1k/Makefile
  score/cpu/powerpc/Makefile
  score/cpu/sh/Makefile
  score/cpu/sparc/Makefile
 diff --git a/cpukit/score/cpu/Makefile.am b/cpukit/score/cpu/Makefile.am
 index 8d28fc2..69abcd6 100644
 --- a/cpukit/score/cpu/Makefile.am
 +++ b/cpukit/score/cpu/Makefile.am
 @@ -14,6 +14,7 @@ DIST_SUBDIRS += mips
  DIST_SUBDIRS += moxie
  DIST_SUBDIRS += nios2
  DIST_SUBDIRS += no_cpu
 +DIST_SUBDIRS += or1k
  DIST_SUBDIRS += powerpc
  DIST_SUBDIRS += sh
  DIST_SUBDIRS += sparc
 diff --git a/cpukit/score/cpu/or1k/Makefile.am 
 b/cpukit/score/cpu/or1k/Makefile.am
 new file mode 100644
 index 000..b3a8ade
 --- /dev/null
 +++ b/cpukit/score/cpu/or1k/Makefile.am
 @@ -0,0 +1,36 @@
 +include $(top_srcdir)/automake/compile.am
 +
 +CLEANFILES =
 +DISTCLEANFILES =
 +
 +include_rtemsdir = $(includedir)/rtems
 +
 +include_rtems_HEADERS = rtems/asm.h
 +
 +include_rtems_scoredir = $(includedir)/rtems/score
 +
 +include_rtems_score_HEADERS =
 +include_rtems_score_HEADERS += rtems/score/cpu.h
 +include_rtems_score_HEADERS += rtems/score/cpu_asm.h
 +include_rtems_score_HEADERS += rtems/score/types.h
 +include_rtems_score_HEADERS += rtems/score/or1k.h
 +include_rtems_score_HEADERS += rtems/score/or1k-utility.h
 +
 +
 +
 +noinst_LIBRARIES = libscorecpu.a
 +
 +libscorecpu_a_SOURCES =
 +libscorecpu_a_SOURCES += cpu.c
 +libscorecpu_a_SOURCES += or1k-context-switch.S
 +libscorecpu_a_SOURCES += or1k-context-initialize.c
 +libscorecpu_a_SOURCES += or1k-exception-default.c
 +libscorecpu_a_SOURCES += or1k-exception-frame-print.c
 +libscorecpu_a_SOURCES += or1k-exception-handler-low.S
 +
 +libscorecpu_a_CPPFLAGS = $(AM_CPPFLAGS)
 +
 +all-local: $(PREINSTALL_FILES)
 +
 +include $(srcdir)/preinstall.am
 +include $(top_srcdir)/automake/local.am
 diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c
 new file mode 100644
 index 000..9ba49a5
 --- /dev/null
 +++ b/cpukit/score/cpu/or1k/cpu.c
 @@ -0,0 +1,112 @@
 +/*
 + *  Opencore OR1K CPU Dependent Source
 + *
 + *  COPYRIGHT (c) 2014 Hesham ALMatary heshamelmat...@gmail.com
 + *  COPYRIGHT (c) 1989-1999.
 + *  On-Line Applications Research Corporation (OAR).
 + *
 + *  The license and distribution terms for this file may be
 

Re: Using rtl-host in covor - some questions

[Joel Sherrill]

On 8/13/2014 3:28 PM, Chris Johns wrote:
 Hi,

 Sorry about not responding before now. It had dropped of my list and I 
 had forgotten about it.

 On 12/08/2014 9:58 pm, Krzysztof Mięsowicz wrote:
 Hi,

 I'm currently working on adding symbol generation to covoar. I'm going
 to use rtl::process::execute function to run nm from covoar (as
 suggested by Chris). I do not know exactly how should I use this in
 covoar. Should I build rtl-host as a library and link it to covoar? Or
 maybe there is another, better option?
 This is a really good question. Having covoar and rtems-host work 
 together is a really thing because there is lots of good code to reuse.

 Currently the rtems-host repo is my private area and maybe this need to 
 change. It is difficult to have both work together when in separate 
 repos. Joel, should this code be moved to the rtems-tools.git repo ?
covoar has moved.
rtems-coverage I think is the other directory that would have to move.

It is OK by me.
 As it stands rtems-host builds 3 static libraries and you can use those...

 $ ls build-linux2/*.a
 build-linux2/libelf.a
 build-linux2/libiberty.a
 build-linux2/librld.a
As I recall, we just need to look up the address for a specific symbol.
I assume
libelf.a has that.

I have used covoar with C++ but don't recall how the name mangling was
addressed.
 Chris
 ___
 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: Using rtl-host in covor - some questions

[Joel Sherrill]

On 8/13/2014 3:49 PM, Krzysztof Mięsowicz wrote:
 Hi, 

 Thanks for your replies :-) I didn't see librld.a because I had old
 version of repo and after updating it appears :-) 

 I think for now it would be better to get everything integrated with
 old nm-based approach. I had it working as a separate module, now I
 will integrate it into covoar. I think that one of next steps may be
 generating symbols without nm. 

There are two uses of symbols in covoar.

The first is external and it is generating the symbols of interest for
the run. That
is currently a process that runs over the set of libraries of interest
and lists all the
text symbols in those libraries. Doing that with the Python based code
should be a
snap.

The other part is in covoar itself. As it processes each exe and builds
the internal
database of information, it needs the physical address of each method of
interest
in that particular exe. That is done by an invocation of nm with some
magic processing
afterwards. This could be done with libelf I think.
 But I also wonder if it would not be better to focus on changing flow
 of covoar - to avoid multiple runs (one for each symbol set as it
 would be now), because it takes quite long. I think it should be done
 in such way, that covoar reads symbol sets configuration file, runs
 analysis and takes data for all desired symbols from all sets and
 finally performs multiple reporting part, generating simple, generic
 output for each symbols set. 

Then covoar knows what purpose and scope of the reports are.  As it
stands now, covoar knows NOTHING
about RTEMS. Let's keep it that way.

covoar gets slower as the set of symbols and tests grows. The standard
run now already does at
least two covoar runs. Once for all and one for core. The build and
test execution time dominates.
As we process smaller sets of symbols, covoar will be faster anyway. 
Besides, if it is slow enough,
eventually we will profile and fix it. :)
 Another job I am thinking about doing next is adding more bsps support
 for coverage and getting things working on more bsps. This should be
 quite simple.

This requires the simulator support. But you should be able to do arm
and x86 with qemu.
 There is still one problem waiting for decision :-) What with rtems
 grub boot img for qemu? How should we integrate it into rtems-tools? 

Chris?

 2014-08-13 22:31 GMT+02:00 Chris Johns chr...@rtems.org
 mailto:chr...@rtems.org:

 On 13/08/2014 7:03 pm, Krzysztof Mięsowicz wrote:

 Hi,

 I think we have small misunderstanding here :-) I'm currently
 trying to
 move symbol generation to covoar - previously symbol list was
 generated
 in shell script do_coverage.sh and passed to covoar in
 configuration
 file or as a command line argument. What we want now is to
 allow covoar
 to generate symbols. Chris suggested that use of code in
 rtl-host repo
 to manage symbols (it seems to use elf libraries inside), but
 this was
 said to be out of the scope of this project - I am going to do
 this
 after end of SOCIS. But as the first approximation we decided
 to invoke
 nm from covoar, using functions from rld-process[cpp, h] and
 parse its
 output in covoar. I have it almost done, but currently I added
 building
 rtems-syms from rtl-host as library and use it in covoar. I
 don't know
 if this is right solution and how should it be done better :-)


 Yes this was the discussion and it still make sense if you want to
 follow this path.

 On the other hand ... :)  once you link to librld.a you can
 with a small amount of code open an ELF file and read the symbols
 into a symbol table and get at the data that way. This is how the
 rtems-ld works when linking against an RTEMS kernel base image.

 Chris



 2014-08-13 0:14 GMT+02:00 Joel Sherrill
 joel.sherr...@oarcorp.com mailto:joel.sherr...@oarcorp.com
 mailto:joel.sherr...@oarcorp.com
 mailto:joel.sherr...@oarcorp.com:



 On 8/12/2014 6:58 AM, Krzysztof Mięsowicz wrote:
   Hi,
  
   I'm currently working on adding symbol generation to
 covoar. I'm
 going
   to use rtl::process::execute function to run nm from
 covoar (as
   suggested by Chris). I do not know exactly how should I
 use this in
   covoar. Should I build rtl-host as a library and link it to
 covoar? Or
   maybe there is another, better option?
  
 covoar is in C++ and you would be invoking Python instead
 of nm from C++
 and still producing something that the C++ has to read.

 Ian Taylor suggested using nm over the elf libraries
 because the output
 of nm was stable

Re: Using rtl-host in covor - some questions

[Joel Sherrill]

On 8/13/2014 10:13 PM, Chris Johns wrote:
 On 14/08/2014 7:34 am, Joel Sherrill wrote:
 On 8/13/2014 3:49 PM, Krzysztof Mięsowicz wrote:
 Hi,

 Thanks for your replies :-) I didn't see librld.a because I had old
 version of repo and after updating it appears :-)

 I think for now it would be better to get everything integrated with
 old nm-based approach. I had it working as a separate module, now I
 will integrate it into covoar. I think that one of next steps may be
 generating symbols without nm.

 There are two uses of symbols in covoar.

 The first is external and it is generating the symbols of interest for
 the run. That
 is currently a process that runs over the set of libraries of interest
 and lists all the
 text symbols in those libraries. Doing that with the Python based code
 should be a
 snap.

 What does run over a set of libraries mean ?
This is the user defining the set of symbols that they want to generate
coverage
reports on. For RTEMS, this is just looking at the set of libXXX.a in
the build
tree for each directory we analyze and extracting the symbols.

This is completely external to covoar. How a project generates its
symbol list
is project dependent. covoar only knows that it is to generate reports based
on that set of symbols, the .exe files, and the coverage files.

This is currently done using nm in the script that invokes covoar.
 We have a really good way to get at the symbols via C++ now with 0 
 parsing code or external tools.
OK.

 The other part is in covoar itself. As it processes each exe and builds
 the internal
 database of information, it needs the physical address of each method of
 interest
 in that particular exe. That is done by an invocation of nm with some
 magic processing
 afterwards. This could be done with libelf I think.
 The rtl-host is a wrapper to libelf which is included in the rtl-host 
 code we are not dependent on host specifics or versions.
Currently covoar uses system() to invoke nm (maybe with a sed) and then
process it
using regular file operations.

Personally, I don't see much difference between invoking nm and
rtl-host. Either
will require a system and then loading the symbol set from a file. On a
large set
of executables, this may be a large time consumer. It would be better to
directly
use libelf to read the symbols. It should simplify and speed things up.
 But I also wonder if it would not be better to focus on changing flow
 of covoar - to avoid multiple runs (one for each symbol set as it
 would be now), because it takes quite long. I think it should be done
 in such way, that covoar reads symbol sets configuration file, runs
 analysis and takes data for all desired symbols from all sets and
 finally performs multiple reporting part, generating simple, generic
 output for each symbols set.

 Then covoar knows what purpose and scope of the reports are.  As it
 stands now, covoar knows NOTHING
 about RTEMS. Let's keep it that way.
 Out of interest what is config file format for covoar ? I have added INI 
 file support to the rtl-host repo and it seems stable and flexible.
I think it is just name=value without sections. I honestly don't recall
but it is not fancy.
It could easily be switched to .ini.
 covoar gets slower as the set of symbols and tests grows. The standard
 run now already does at
 least two covoar runs. Once for all and one for core. The build and
 test execution time dominates.
 Where is bottleneck ? The RTL code uses an STL map for symbol look up.
See above. I think executing nm on each exe with whatever filter
commands and
then reading them. Using libelf directly will help a lot.

I don't recall any other hot spots but that there are places where you
have to
cycle over all exe's for all symbols of interest. That is obviously
O( num exes * num syms) but I don't think it is the big issue. I think
the first
issue is just like make vs waf. Avoid doing system() and parsing output
files
500 times (# tests) and just read the symbol table directly. That has to
be a
huge time saver
 As we process smaller sets of symbols, covoar will be faster anyway.
 Besides, if it is slow enough,
 eventually we will profile and fix it. :)
 Another job I am thinking about doing next is adding more bsps support
 for coverage and getting things working on more bsps. This should be
 quite simple.

 This requires the simulator support. But you should be able to do arm
 and x86 with qemu.
 There is still one problem waiting for decision :-) What with rtems
 grub boot img for qemu? How should we integrate it into rtems-tools?

 Chris?
 Ah yes. I think we should download an image from a know spot but I have 
 not looked into how to do this with the RSB.

 Maybe building grub from source is possible but that can be something 
 for another day.

 Chris

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

Re: [PATCH] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

[Joel Sherrill]

On 8/14/2014 3:53 AM, Pavel Pisa wrote:
 Hello Sebastian,

 On Thursday 14 of August 2014 10:07:06 Sebastian Huber wrote:
 On 14/08/14 09:48, Pavel Pisa wrote:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch
 /mips/include/uapi/asm/inst.h?id=refs/tags/v3.15#n486
 My experience with bitfields at this level is that GCC is regularly broken
 in this area.
 Aligned with my feeling that it is dangerous and combined with required
 volatile for regs can lead even to worse code.
I don't think RTEMS has a formal coding convention (yet) for this but I
don't
trust them for any compiler. Ignoring breakages, you don't have as much
control
over the width of the generated accesses. 

I recall ages ago helping someone debug a broken driver where gcc had
generated
a bit set or clear instruction and the device didn't like that.
 But I generally prefer more only defines used for such fields.

 Then it would look something like

TMS570_SCI_SCICLEARINT_XXX

 My notation is to add suffix _m for mask, _b for starting bit
 position if used and where are offset from base _o. The _m and _b
 quite usesfull because C dosenit warn you when starting bit or mask is
 mixed and results of mixing are quite damaging.

 But use of macros leads to quite complex/long lines in the code.
 Yes, I prefer this too.  You may have a look at

 http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/include/arm-pl0
 11-regs.h
 I am OK with single bit masks - BSP_BIT32(7), but I prefer only single
 define per multi bit field. So my own approach is to use macros to find
 field start bit from maks

 /*masked fields macros*/
 #define __val2mfld(mask,val) (((mask)~((mask)1))*(val)(mask))
 #define __mfld2val(mask,val) (((val)(mask))/((mask)~((mask)1)))

 for constant masks they compile optimal way and for variable
 they are usable too if CPU has ffs/clz support.

 http://sourceforge.net/p/ulan/sysless/ci/master/tree/arch/arm/generic/defines/cpu_def.h

 This is how I use it in our bare HW/system-less code

 http://sourceforge.net/p/ulan/sysless/ci/master/tree/libs4c/spi/spi_lpcssp.c#l200

  lpcssp_drv-ssp_regs-CR0 =
  __val2mfld(SSP_CR0_DSS_m, lpcssp_drv-data16_fl? 16 - 1 : 8 - 1) |
  __val2mfld(SSP_CR0_FRF_m, 0) |
  (msg-size_mode  SPI_MODE_CPOL? SSP_CR0_CPOL_m: 0) |
  (msg-size_mode  SPI_MODE_CPHA? SSP_CR0_CPHA_m: 0) |
  __val2mfld(SSP_CR0_SCR_m, 15);

 http://sourceforge.net/p/ulan/sysless/ci/master/tree/arch/arm/mach-lpc17xx/libs/hal/hal_gpio.c#l32

 So I would prefer something like that. But I agree that it can hurt
 someone else eyeballs as well.

 I have seen similar solution in Nvidia driver sources with even
 really interresting (ab)use of ternary C operator.

 But if RTEMS preference is to define all fields twice with SET and GET
 then I would suggest that to Premek.

 Best wishes,

   Pavel
 ___
 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: [PATCH] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

[Joel Sherrill]

Thanks.

I am just worried about reproducibility or the BSP and test results
combined with licensing and redistribution of the TI support
code. As long as everyone is comfortable with that, I am as well.

On 8/14/2014 4:04 AM, Pavel Pisa wrote:
 Hello Joel,

 On Thursday 14 of August 2014 00:40:49 Joel Sherrill wrote:
 On 8/13/2014 2:48 PM, Premysl Houdek wrote:
 --- /dev/null
 +++ b/c/src/lib/libbsp/arm/tms570/README
 @@ -0,0 +1,64 @@
 +Development Board: TMS570LS31x Hercules Development Kit from TI
 ...
 +Execution
 +
 +  There is not used any generic bootloader. Initial complex CPU and
 peripherals +  initialization and self test are not implemented and
 included in RTEMS BSP +  right now. For testing and debuging purposes is
 used simple Ti's HalCoGen +  generated application to setup board and
 then download RTEMS image over +  OpenOCD to internal EEC SRAM or
 external SDRAM.
 This is rough from an English viewpoint.  How about:

 Currently, a bootloader is not used. For test and debug purposes, TI's
 HalCoGen generated
 application is used to set up the board and then the RTEMS application
 image is loaded
 using OpenOCD to internal EEC SRAM or external DRAM. The following
 features are
 not implemented in the BSP:

   + Initial complex CPU and peripheral initialization
   + Self-test

 Can you be more specific about what that first bullet covers?

 Is the generated setup code available? What's the license on it?
 The generated setup is available, see link below

 +  Setup application code is available there:
 +  https://github.com/hornmich/tms570ls3137-hdk-sdram
 +
 +Howto setup TMDS570LS31HDK?
 +
 +   o Unpack board.
 +   o Verify that demo application runs.
 +  o Upload bootloader specified above
 +  o write BSP aplication either to sdram or intram and jump to RTEMS
 start code
 application not aplication
 Internal RAM?
 Yes, thanks for checking, English is neither Premek nor my
 specialty and Pemek.

 There would be happy even to provide build binary to everybody who cares.

 But generally the hardware needs more work to be done.
 Unfortuantelly, flashing to the MCU is quite complicated due
 un-documented algorithm. We have used Ti tools to Flash setup
 code. But we know other working solution, it is possible to
 setup MCU over JTAG and the download flasher code into internal
 RAM. The library with flash algorithm is available from Ti
 in binary form for Cortex-R4F. So our plan is to have small
 loader to allow flash application over CAN or ETHERNET.

 But it is still longer term goal.

 Best wishes,

  Pavel

-- 
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: Console driver that needs extra TIMER

[Joel Sherrill]

On 8/14/2014 9:20 AM, Gedare Bloom wrote:
 On Thu, Aug 14, 2014 at 10:15 AM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/14/2014 9:11 AM, Kolja Waschk wrote:
 Hi,

 I'm developing a DMA-based UART driver for Blackfin. It requires an
 extra timer to trigger data processing after a transmission ended. This
 increases the amount of timers required by every application that uses
 it for the console.
 Don't you get an end of DMA TX interrupt?
 E.g. most of the tests won't even start without modifications. So
 effectively I have to fall back to a polling driver for console if I
 want to run the tests unmodified, or is there any mechanism to generally
 increment the amount of timers for all tests?
 I don't think so. There are some BSP hooks for various features and
 default number
 of termios ports. But nothing specific to an object.

 If you are working with rtems.git, you could probably just add another
 BSP setting in confdefs.h for this and push the patch out for
 inclusion in RTEMS. Something like CONFIGURE_BSP_TIMERS() that gets
 added into CONFIGURE_MAXIMUM_TIMERS(). If you need more guidance how
 to do this just ask.

 I suppose one could be added but for orthogonality, it would make me wonder
 why we wouldn't also let you add a BSP factor on every Classic API object.
 Just thinking out load.
 Joel, what kind of load?
out loud. :)
 There are probably only a few object-types that a BSP might need to
 reserve for use, but it may be worth considering.
Task, semaphore, message queue come to mind. Obviously he needs a timer
but that makes sense, I always use the example of timeouts in communications
protocols.

Hmm.. if we add message queue, we need to remember the buffer side of that.
 -Gedare
 Thanks,
 Kolja





 ___
 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

-- 
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: [PATCH] Add new (first) OpenRISC BSP called or1ksim.

[Joel Sherrill]

 = bsp_section_rodata_end - 
 bsp_section_rodata_begin;
 +  bsp_section_rodata_load_begin = LOADADDR (.rodata);
 +  bsp_section_rodata_load_end = bsp_section_rodata_load_begin + 
 bsp_section_rodata_size;
 +
 +.rwbarrier : ALIGN_WITH_INPUT {
 +. = ALIGN (bsp_section_rwbarrier_align);
 +  }  REGION_DATA AT  REGION_DATA
 +
 +.data : ALIGN_WITH_INPUT {
 +bsp_section_data_begin = .;
 +*(.data .data.* .gnu.linkonce.d.*)
 +SORT(CONSTRUCTORS)
 +  }  REGION_DATA AT  REGION_DATA_LOAD
 +  .data1 : ALIGN_WITH_INPUT {
 +*(.data1)
 +  }  REGION_DATA AT  REGION_DATA_LOAD
 +  .rtemsrwset : ALIGN_WITH_INPUT {
 +KEEP (*(SORT(.rtemsrwset.*)))
 +bsp_section_data_end = .;
 +  }  REGION_DATA AT  REGION_DATA_LOAD
 +  bsp_section_data_size = bsp_section_data_end - bsp_section_data_begin;
 +  bsp_section_data_load_begin = LOADADDR (.data);
 +  bsp_section_data_load_end = bsp_section_data_load_begin + 
 bsp_section_data_size;
 +
 +  .bss : ALIGN_WITH_INPUT {
 +bsp_section_bss_begin = .;
 +*(.dynbss)
 +*(.bss .bss.* .gnu.linkonce.b.*)
 +*(COMMON)
 +bsp_section_bss_end = .;
 +  }  REGION_BSS AT  REGION_BSS
 +  bsp_section_bss_size = bsp_section_bss_end - bsp_section_bss_begin;
 +
 +.work : ALIGN_WITH_INPUT {
 +/*
 + * The work section will occupy the remaining REGION_WORK region and
 + * contains the RTEMS work space and heap.
 + */
 +bsp_section_work_begin = .;
 +. += ORIGIN (REGION_WORK) + LENGTH (REGION_WORK) - ABSOLUTE (.);
 +bsp_section_work_end = .;
 +  }  REGION_WORK AT  REGION_WORK
 +  bsp_section_work_size = bsp_section_work_end - bsp_section_work_begin;
 +
 +  .stack : ALIGN_WITH_INPUT {
 +bsp_section_stack_end = .;
 +  }  REGION_STACK AT  REGION_STACK
 +  bsp_section_stack_begin = 0x1FFDFB8;
 +  bsp_section_stack_size = bsp_section_stack_begin - bsp_section_stack_end;
 +
 +  RamBase = ORIGIN (REGION_WORK);
 +  RamSize = LENGTH (REGION_WORK);
 +  WorkAreaBase = bsp_section_work_begin;
 +  HeapSize = 0;
 +
 +}
 diff --git a/c/src/lib/libbsp/or1k/or1ksim/timer/timer.c 
 b/c/src/lib/libbsp/or1k/or1ksim/timer/timer.c
 new file mode 100644
 index 000..73ee112
 --- /dev/null
 +++ b/c/src/lib/libbsp/or1k/or1ksim/timer/timer.c
 @@ -0,0 +1,63 @@
 +/**
 + * @file
 + *
 + * @ingroup or1ksim
 + *
 + * @brief Benchmark timer support.
 + */
 +
 +/*
 + * Copyright (c) 2014 by Hesham ALMatary
 + *
 + *  The license and distribution terms for this file may be
 + *  found in the file LICENSE in this distribution or at
 + *  http://www.rtems.org/license/LICENSE
 + */
 +
 +#include rtems.h
 +#include rtems/btimer.h
 +#include bsp/or1ksim.h
 +#include rtems/score/or1k-utility.h
 +
 +static bool benchmark_timer_find_average_overhead = false;
 +static uint32_t tick_time;
 +static uint64_t benchmark_timer_base;
 +
 +void benchmark_timer_initialize(void)
 +{
 +  benchmark_timer_base = _OR1K_mfspr(CPU_OR1K_SPR_TTCR);
 +}
 +
 +#define AVG_OVERHEAD  0
 +#define LEAST_VALID   1
 +
 +uint32_t benchmark_timer_read( void )
 +{
 +  uint64_t clicks;
 +  uint64_t total;
 +  uint64_t delta;
 +
 +  /*
 +   *  Read the timer and see how many clicks it has been since we started.
 +   */
 +  clicks = _OR1K_mfspr(CPU_OR1K_SPR_TTCR);
 +
 +  delta = clicks - benchmark_timer_base;
 +
 +  /* total in microseconds */
 +  total = tick_time * (delta);
 +
 +  if ( benchmark_timer_find_average_overhead == true )
 +return total;  /* in nanoseconds microsecond units */
 +  else {
 +if ( total  LEAST_VALID )
 +  return 0;/* below timer resolution */
 +
 +  return (total - AVG_OVERHEAD);
 +  }
 +}
 +
Trailing blank line and what units are these really in? The comments in the
benchmark_timer_read() are very confusing.
 +void benchmark_timer_disable_subtracting_average_overhead(bool find_flag)
 +{
 +  benchmark_timer_find_average_overhead = find_flag;
 +}

 --
 1.9.3

 ___
 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: [GSoC2014] arinc653 on rtems (using pok) patches

[Joel Sherrill]

On 8/19/2014 4:34 PM, Janek van Oirschot wrote:
 On Mon, Aug 18, 2014 at 3:13 PM, Gedare Bloom ged...@rtems.org wrote:
 If you're using git for your development, you can use 'git
 format-patch' to convert a set of commits into a set of patches. Some
 properly formatted git patches can make it easier to review and merge
 your code. Some other notes follow.
 Yeah, I knew git is able to generate patches but I was worried that it
 would also take the virtualpok bsp and paravirt patches along with my
 patches.
When you rebase, you get the list of patches. format-patch will generate
a file for
each of them. Just use git send-email for the ones you want reviewed and
merged first.
When you rebase, they should magically be eliminated.

Worst case, you make a new branch from master and apply the remaining ones.
 virtualpok_arinc653.patch:
 * it seems the only part of this patch specific to the arinc653 code
 is the Makefile.am and preinstall.am changes?
 It seems so, I did include some small edits and adjustments I needed
 to apply to get my RTEMS on POK enviroment running.

 * The virtualizationlayercpu.h is missing. Is this supposed to come
 from another patch already?
 Yeah, I thought it was included by one of the earlier virtualpok BSP
 patches. It's simply the virtualizationlayercpu.h located in
 $POK/examples/rtems-guest/ but can be added to my patch.

 * You comment out a few lines in bspstart.c, are these things that were 
 broken?
 Not so much broken but in my case the rtems on pok enviroment broke
 after a git pull so it got recommended to me at some point to disable
 those as I don't need them for my application.

 * Is the linkcmds change required for running pok-rtems?
 For me, it was required. The old linkcmd script was causing undefined
 TLS errors while building RTEMS.
Please report this. This sounds like an independent issue which needs to
be run down.
 hello_init_c.patch:
 * This would be much improved if you provided a new example instead of
 replacing the existing one, like 'arinc653_test.c' or similar.
 No problem, was working with the default hello world because the setup
 for working with hello world was already there. Now that I know this
 method works to get arinc653 calls working a new and separate example
 program for arinc653 is the next step and definitely on my TODO list.
 :)

 libpok_rtems_arinc653.patch:
 It seems incorrect to remove extern from all of these arrays. Usually
 for global variables in C code, there should be one declaration of the
 variable with the 'extern' attribute in a header file that gets
 included in every c source file that needs that variable, and then one
 definition of the variable without 'extern' in just one of the .c
 files. Please explain your changes.
 The 'extern' variables would cause compilation errors. I also couldn't
 find any definition of those arrays without the 'extern'. I
 temporarily removed them and since I only tested CREATE_* of each
 arinc653 subset so since the scope was one source file this wasn't a
 problem. After some debugging of e.g. CREATE_BLACKBOARD and it works
 without returning an error a better structure for all 'extern'
 variables in combination with rtems will be implemented as then they
 then need to be global.

 Thanks for the feedback,
 Janek
 ___
 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: We should release 4.11

[Joel Sherrill]

On August 20, 2014 1:26:19 AM CDT, Sebastian Huber 
sebastian.hu...@embedded-brains.de wrote:
On 19/08/14 18:38, Gedare Bloom wrote:
 Anything holding it up at the moment?

For the SPARC GCC not all patches are in the GCC upstream, e.g. a
multilib 
update is missing.

Can you provide a link? 

Chris.. We also have some gdb patches to work on upstreaming.

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

Re: We should release 4.11

[Joel Sherrill]

On August 20, 2014 2:09:01 AM CDT, Ben Gras b...@shrike-systems.com wrote:
All,

I'd love the Beagle BSP. I am fighting to find time to polish it,
re-test it, and re-submit the patches.

To decide whether that's feasible, is freezing the code for the release
'any day now' or more like 'any week now'?


It won't be this week. I would like it to be ASAP but know we have some tidying 
up to do.

Has the BSP at least been posted for initial review? Is it warning free? Small 
updates are easy to review.

On Tue, Aug 19, 2014 at 11:43 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


On 8/19/2014 4:34 PM, Chris Johns wrote:
 On 20/08/2014 2:38 am, Gedare Bloom wrote:
 Anything holding it up at the moment?
 It would be good to get a formal tool set definition into
rtems-tools.git.

 I am currently testing a change to newlib 19-Aug-2014 which removes
an
 old patch we had.

We need to make sure that we are on a path for the RSB, Debian and RPMs
to come
from the same tool versions and patches.

Also there is likely a todo list for RTEMS itself. Not sure what that
is
off the top
of my head but a few items:

+ Merge Beagle BSP
+ Merge pending GSOC work
+ 386 context switch SMP synchronization is not right. Others were
updated.

What's the status of the dynamic loader? I suspect it is on its own
independent
release arc.



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

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

Re: feedback on Re: [PATCH v3] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

[Joel Sherrill]

On 8/20/2014 1:45 PM, Pavel Pisa wrote:
 On Wednesday 20 of August 2014 20:17:47 Joel Sherrill wrote:
 Hi

 Initial quick feedback.  I build normally with --enable-rtems-debug
 and the tms570ls3137_hdk variant failed to build with this
 failure:

 arm-rtems4.11-gcc --pipe -DHAVE_CONFIG_H   -I../../..
 -I../../../../cpukit/../../../tms570ls3137_hdk/lib/include  -DASM
 -march=armv7-r -mthumb -mbig-endian -O2 -ggdb3 -DNDEBUG -Wall
 -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
 -Wnested-externs -march=armv7-r -mthumb -mbig-endian -O2 -ggdb3 -DNDEBUG
 -Wall -Wmissing-prototypes -Wimplicit-function-declaration
 -Wstrict-prototypes -Wnested-externs -MT
 libscorecpu_a-arm-context-volatile-clobber.o -MD -MP -MF
 .deps/libscorecpu_a-arm-context-volatile-clobber.Tpo -c -o
 libscorecpu_a-arm-context-volatile-clobber.o `test -f
 'arm-context-volatile-clobber.S' || echo
 '../../../../../../../../rtems/c/src/../../cpukit/score/cpu/arm/'`arm-conte
 xt-volatile-clobber.S mv -f
 .deps/libscorecpu_a-arm-context-volatile-clobber.Tpo
 .deps/libscorecpu_a-arm-context-volatile-clobber.Po
 In file included from
 ../../../../cpukit/../../../tms570ls3137_hdk/lib/include/rtems/score/percpu
 .h:25:0, from
 ../../../../cpukit/../../../tms570ls3137_hdk/lib/include/rtems/system.h:23,
  from
 ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/arm/cpu.c:29:
 ../../../../cpukit/../../../tms570ls3137_hdk/lib/include/rtems/score/isrloc
 k.h: In function '_ISR_lock_ISR_disable_and_acquire':
 ../../../../cpukit/../../../tms570ls3137_hdk/lib/include/rtems/score/assert
 .h:38:46: error: '__ASSERT_FUNC' undeclared (first use in this function)
__assert_func( __FILE__, __LINE__, __ASSERT_FUNC, #_e ) )
   ^

 Since there was some work to add a new ARM variant, I am suspicious that
 a .h file is missing when this is compiled for Rx ARM variants.

 I didn't build other variants and am trying again with debug disabled.
 Hello Joel,

 we need to recheck that.

 We have been using optimized build and our target is build for SDRAM.
 We tested internal RAM as well. The flashing to start RTEMS image
 from address 0 has not been checked yet and cannot work with additional
 initial code implementation.

 There would be problem to build some larger test for internal
 RAM variant because they overflow.
I expect that and the list of tests which do not fit can be put in the
.tcfg file
for the variant.
 I have run ticker test on the board compiled from actual RTEMS mainline
 with next configuration options and everything seems OK for this setup
 on real HW

 ../../../git/rtems/configure --target=arm-rtems4.11 --prefix=/opt/rtems4.11 \
   --enable-rtems-inlines --disable-multiprocessing --enable-cxx \
   --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
   --enable-networking --enable-posix --enable-itron --disable-ada \
   --disable-expada --disable-multilib --disable-docs \
   --enable-rtemsbsp=tms570ls3137_hdk_sdram
Hmmm... tms570ls3137_hdk_sdram also fails on ticker with this:

arm-rtems4.11-gcc -B../../../../../tms570ls3137_hdk_sdram/lib/ -specs
bsp_specs -qrtems -march=armv7-r -mthumb -mbig-endian -O2 -ggdb3
-DNDEBUG -Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs-march=armv7-r -mthumb
-mbig-endian   -o ticker.exe init.o tasks.o
../../../../../tms570ls3137_hdk_sdram/lib/start.o: In function
`bsp_start_vector_table_end':
/users/joel/rtems-4.11-work/b-tms570ls3137_hdk_sdram/arm-rtems4.11/c/tms570ls3137_hdk_sdram/lib/libbsp/arm/tms570/../../../../../../../../rtems/c/src/lib/libbsp/arm/tms570/../shared/start/start.S:229:(.bsp_start_text+0x94):
relocation truncated to fit: R_ARM_THM_JUMP11 against symbol
`bsp_start_hook_0' defined in .text section in
../../../../../tms570ls3137_hdk_sdram/lib/librtemsbsp.a(libbsp_a-bspstarthooks.o)
collect2: error: ld returned 1 exit status

 I expect that inclusion of of assert.h or something similar world help
 to debug case. I look at it now or tomorrow.
I suspect this is just a conditional path that misses an include. Easy
to fix.
 As for regular RTEMS build it would worth to limit it/enable only
 tms570ls3137_hdk_sdram, other variants are more or less
 waste of compilation time for now. On the other hand,
 tms570ls3137_hdk_intram has its use to be tested on board
 without SDRAM and there are many other smaller variants
 of TMS570 MCUs which are suitable for RTEMS in future but
 again these are without external bus interface.
Well it is merged so we all have a common ground to work from.
We could have different tools or something minor could be different
in the two bsps. Who knows? We will find it. :)
 Best wishes,

  Pavel

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

Re: [PATCH v2] bsp/tms570: implemented support functions to satisfy complete tests build requirements.

[Joel Sherrill]

/libbsp/arm/tms570/preinstall.am
 +++ b/c/src/lib/libbsp/arm/tms570/preinstall.am
 @@ -109,6 +109,10 @@ $(PROJECT_INCLUDE)/bsp/tms570-sci-driver.h: 
 include/tms570-sci-driver.h $(PROJEC
   $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/tms570-sci-driver.h
  PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tms570-sci-driver.h
  
 +$(PROJECT_INCLUDE)/bsp/system-clocks.h: include/system-clocks.h 
 $(PROJECT_INCLUDE)/bsp/$(dirstamp)
 + $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/system-clocks.h
 +PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/system-clocks.h
 +
  $(PROJECT_INCLUDE)/tm27.h: ../../shared/include/tm27.h 
 $(PROJECT_INCLUDE)/$(dirstamp)
   $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/tm27.h
  PREINSTALL_FILES += $(PROJECT_INCLUDE)/tm27.h

-- 
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: [PATCH] libchip/dwmac: Make PHY address user configurable.

[Joel Sherrill]

 {
  #endif /* __cplusplus */
  
 +/** @brief DWMAC user configuration structure.
 + *
 + * Gives the user the possibility to overwrite some configuration data.
 + */
 +typedef struct {
 +  int MDIO_BUS_ADDR;
 +} dwmac_user_cfg;
 +
  /** @brief PHY event.
   *
   * Data type to be used for PHY events and event sets.

-- 
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: offlist or1k printf causes crash

[Joel Sherrill]

On 8/21/2014 4:15 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 10:56 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 2:44 PM, Hesham Moustafa wrote:
 Hi,

 I have been debugging since a while or1k code hopefully I'd find
 what's wrong. Here's what I got.
 First I am moving this to devel@ so others can chime in.
 First, I asked about this problem at #openrisc IRC channel, they told
 me the problem might be that I have to take account of the red-zone, I
 asked what's the red-zone and Stefan said the following:
 the first 128 bytes of the stack has to be stepped over, leaf
 functions might use that without modifying the stack pointer, and gcc
 takes advantage of the fact that there is a red zone in non-leaf
 functions prologues too. i.e. it stores things on the stack and *then*
 update the stack pointer
 This is a bug in gcc. We have seen it on the ARM and there was a recent
 dust up from the Linux kernel community because it happened on x86-64.
 My understanding is that there was rework/improvement which triggered
 bugs in backends. But this needs to be fixed.

 The sp must be updated before the memory can be used. This is just
 a bug otherwise.
 He suggested that I add 128 bytes to stack pointer before I jump to
 _ISR_Handler (from start.S). I tried this solution and I was not
 lucky. You may have some ideas where/when this red-zone make problem.
 You probably need to
 Second, I discovered that there is unusual (unalign) exception happens
 when using printf (which does not happen with printk). When I stack, I
 found out the problem happens in rtems_semaphore_obtain(), when trying
 to access the_semaphore data which its pointer is returned (invalid
 pointer) from a call to _Objects_Get_isr_disable(). This exception
 only happens after DISPATCH_NEEDED is true and _ISR_Handler jumps to
 _Thread_Dispatch and make a successful context switch and run the
 first task. The following is a snapshot of the output when
 encountering this problem.
 What's the alignment of the task stack in the port? The stack may not be
 properly aligned for the widest access of the or1k.
 If you mean the following:
 #define CPU_STACK_ALIGNMENT0
 but even if with this macro assigned to 4 or 8, I got the same problem.
 and from linkcmds.base
 bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;
Hmm.. ok .. then we need to know the instruction. 8 is normally a wide
enough alignment since that is the usually like a double or 64-bit access.
 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
 Fatal Error 263572 Halted
 Can you tell what the instruction is? And the address it is trying to
 access.
 The _Objects_Get_isr_disable() function returns a weird address for
 Object (which in tern should be the_semaphore), this address is
 0x8007, it seems like the value of the SR register. All previous
 Object/the_semaphore addresses returned from
 _Objects_Get_isr_disable() are higher addresses, that's why I indicate
 that the last (0x8007) Object address is invalid.
_Objects_Get_isr_disable() will return an address from the RTEMS Workspace
which would tend to be a higher RAM address.

Random thought. Temporarily disable the real hardware clock tick driver
in your BSP and add the simulated clock tick driver. See h8sim BSP's
Makefile
for an example. We need to eliminate that your ISR code is doing the
right thing. You could be getting an interrupt at the wrong time and
just clobbering a register. Doing this will let the test run without
interrupts.

What is the value of _Watchdog_Ticks_since_boot at this fault?

 I set a break point at  a call to _Objects_Get_isr_disable() and
 continued until the call that returns the invalid Object pointer, and
 typed bt to get the following stack:
 Another possibility is that the register/memory constraints on
 enable/disable
 interrupts isn't right and it is confusing gcc. You could be randomly
 clobbering
 registers anytime ISRs are disabled/enabled.

 Christian.. can you review that code?
 
 #0  _Objects_Get_isr_disable (
 information=0x3ba54 _Semaphore_Information,
 id=436273156, location=0x406b4, level_p=0x406b0)
 at 
 ../../../../../../rtems/c/src/../../cpukit/score/src/objectgetisr.c:34
 #1  0x00014294 in _Semaphore_Get_interrupt_disable (
 id=436273156, location=0x406b4, level=0x406b0)
 at 
 ../../cpukit/../../../or1k_or1ksim/lib/include/rtems/rtems/semimpl.h:196
 #2  0x000142e0 in rtems_semaphore_obtain (id=436273156,
 option_set=0, timeout=0)
 at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semobtain.c:47
 #3  0xd648 in rtems_termios_write (arg=0x40730)
 at 
 ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/termios.c:1099
 #4  0x4380 in console_write (major=0, minor=0,
 arg=0x40730)
 at 
 ../../../../../../../../rtems/c/src/lib/libbsp/or1k/or1ksim

Re: offlist or1k printf causes crash

[Joel Sherrill]

On 8/21/2014 5:00 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 11:54 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 4:15 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 10:56 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 2:44 PM, Hesham Moustafa wrote:
 Hi,

 I have been debugging since a while or1k code hopefully I'd find
 what's wrong. Here's what I got.
 First I am moving this to devel@ so others can chime in.
 First, I asked about this problem at #openrisc IRC channel, they told
 me the problem might be that I have to take account of the red-zone, I
 asked what's the red-zone and Stefan said the following:
 the first 128 bytes of the stack has to be stepped over, leaf
 functions might use that without modifying the stack pointer, and gcc
 takes advantage of the fact that there is a red zone in non-leaf
 functions prologues too. i.e. it stores things on the stack and *then*
 update the stack pointer
 This is a bug in gcc. We have seen it on the ARM and there was a recent
 dust up from the Linux kernel community because it happened on x86-64.
 My understanding is that there was rework/improvement which triggered
 bugs in backends. But this needs to be fixed.

 The sp must be updated before the memory can be used. This is just
 a bug otherwise.
 He suggested that I add 128 bytes to stack pointer before I jump to
 _ISR_Handler (from start.S). I tried this solution and I was not
 lucky. You may have some ideas where/when this red-zone make problem.
 You probably need to
 Second, I discovered that there is unusual (unalign) exception happens
 when using printf (which does not happen with printk). When I stack, I
 found out the problem happens in rtems_semaphore_obtain(), when trying
 to access the_semaphore data which its pointer is returned (invalid
 pointer) from a call to _Objects_Get_isr_disable(). This exception
 only happens after DISPATCH_NEEDED is true and _ISR_Handler jumps to
 _Thread_Dispatch and make a successful context switch and run the
 first task. The following is a snapshot of the output when
 encountering this problem.
 What's the alignment of the task stack in the port? The stack may not be
 properly aligned for the widest access of the or1k.
 If you mean the following:
 #define CPU_STACK_ALIGNMENT0
 but even if with this macro assigned to 4 or 8, I got the same problem.
 and from linkcmds.base
 bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;
 Hmm.. ok .. then we need to know the instruction. 8 is normally a wide
 enough alignment since that is the usually like a double or 64-bit access.
 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
 Fatal Error 263572 Halted
 Can you tell what the instruction is? And the address it is trying to
 access.
 The _Objects_Get_isr_disable() function returns a weird address for
 Object (which in tern should be the_semaphore), this address is
 0x8007, it seems like the value of the SR register. All previous
 Object/the_semaphore addresses returned from
 _Objects_Get_isr_disable() are higher addresses, that's why I indicate
 that the last (0x8007) Object address is invalid.
 _Objects_Get_isr_disable() will return an address from the RTEMS Workspace
 which would tend to be a higher RAM address.

 Random thought. Temporarily disable the real hardware clock tick driver
 in your BSP and add the simulated clock tick driver. See h8sim BSP's
 Makefile
 for an example. We need to eliminate that your ISR code is doing the
 right thing. You could be getting an interrupt at the wrong time and
 just clobbering a register. Doing this will let the test run without
 interrupts.

 What is the value of _Watchdog_Ticks_since_boot at this fault?

 5. Pleaes note that I replaced ticker wake_after call (to avoid
 waiting long time) with the following
 status = rtems_task_wake_after(
   task_index * 5
 );

 And it was making the context switch to the first task, the unalign
 happens when task 1 (after the context switch) tries to use printf and
 semaphore obtain.
Either your context switch or ISR code appears to be messing the stack up.
Switching out the real hW tick for the simulated idle task one will help us
figure out which one. Plus you can run most tests with this feature
and see how things go.
 I set a break point at  a call to _Objects_Get_isr_disable() and
 continued until the call that returns the invalid Object pointer, and
 typed bt to get the following stack:
 Another possibility is that the register/memory constraints on
 enable/disable
 interrupts isn't right and it is confusing gcc. You could be randomly
 clobbering
 registers anytime ISRs are disabled/enabled.

 Christian.. can you review that code?
 
 #0  _Objects_Get_isr_disable (
 information=0x3ba54 _Semaphore_Information,
 id=436273156, location=0x406b4, level_p=0x406b0

Re: [PATCH] libchip/dwmac: Make PHY address user configurable.

[Joel Sherrill]

Thanks.


On 8/22/2014 1:53 AM, Christian Mauderer wrote:
 Hi Joel,

 I've changed the name of the structure to a more speaking one and added a few
 lines of example-code to the README of the altcycv-BSP.

 Kind regards

 Christian Mauderer
 ___
 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

arm/nds - cache_manager.c build failure

[Joel Sherrill]

Hi

I am guessing some conditional path isn't being covered right to
get CPU_INSTRUCTION_CACHE_ALIGNMENT defined. Could
someone please take a look at this and fix it?

arm-rtems4.11-gcc --pipe -B../../../../../.././lib/
-B../../../../../.././nds/lib/ -specs bsp_specs -qrtems
-DHAVE_CONFIG_H  
-I../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../shared/include  
-mstructure-size-boundary=8 -mcpu=arm9tdmi -mfpu=vfp -mfloat-abi=soft
-mthumb-interwork  -O2 -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
libbsp_a-cache_manager.o -MD -MP -MF .deps/libbsp_a-cache_manager.Tpo -c
-o libbsp_a-cache_manager.o `test -f
'../../../libcpu/shared/src/cache_manager.c' || echo
'../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/'`../../../libcpu/shared/src/cache_manager.c
../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:
In function '_invalidate_multiple_instruction_lines_no_range_functions':
../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:458:40:
error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this
function)
   i_addr = (void *)((size_t)i_addr  ~(CPU_INSTRUCTION_CACHE_ALIGNMENT
- 1));
^

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

nios2_iss cache_manager.c Build Failure

[Joel Sherrill]

Hi

Similar issue to NDS. Could someone please fix this?

../../../../../../../rtems/c/src/lib/libcpu/nios2/../shared/src/cache_manager.c:
In function '_invalidate_multiple_instruction_lines_no_range_functions':
../../../../../../../rtems/c/src/lib/libcpu/nios2/../shared/src/cache_manager.c:458:
error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this
function)
../../../../../../../rtems/c/src/lib/libcpu/nios2/../shared/src/cache_manager.c:458:
error: (Each undeclared identifier is reported only once

-- 
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: arm/nds - cache_manager.c build failure

[Joel Sherrill]

On 8/22/2014 9:38 AM, Gedare Bloom wrote:
 Looks like this function needs a guard on #if
 defined(CPU_INSTRUCTION_CACHE_ALIGNMENT)


 see rtems_cache_invalidate_multiple_instruction_lines()
Or CPU_INSTRUCTION_CACHE_ALIGNMENT needs to be always defined.
I did a full build of all tests on all BSPs using the latest RSB tools and
only a couple of BSPs failed this way.


 On Fri, Aug 22, 2014 at 10:30 AM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 Hi

 I am guessing some conditional path isn't being covered right to
 get CPU_INSTRUCTION_CACHE_ALIGNMENT defined. Could
 someone please take a look at this and fix it?

 arm-rtems4.11-gcc --pipe -B../../../../../.././lib/
 -B../../../../../.././nds/lib/ -specs bsp_specs -qrtems
 -DHAVE_CONFIG_H
 -I../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../shared/include
 -mstructure-size-boundary=8 -mcpu=arm9tdmi -mfpu=vfp -mfloat-abi=soft
 -mthumb-interwork  -O2 -Wall -Wmissing-prototypes
 -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
 libbsp_a-cache_manager.o -MD -MP -MF .deps/libbsp_a-cache_manager.Tpo -c
 -o libbsp_a-cache_manager.o `test -f
 '../../../libcpu/shared/src/cache_manager.c' || echo
 '../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/'`../../../libcpu/shared/src/cache_manager.c
 ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:
 In function '_invalidate_multiple_instruction_lines_no_range_functions':
 ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:458:40:
 error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this
 function)
i_addr = (void *)((size_t)i_addr  ~(CPU_INSTRUCTION_CACHE_ALIGNMENT
 - 1));
 ^

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

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

or1k build issues

[Joel Sherrill]

Hi

Some basic or1ksim BSP issues:

(1) I can't build what is committed.

gmake[7]: Entering directory
`/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1k_or1ksim-rtems/or1k-rtems4.11/c/or1k_or1ksim/lib/libbsp/or1k'
Makefile:731: *** missing separator.  Stop.

I think this was an issue with the generated preinstall.am. I will be
committing an updated version.

(2) I built with networking on. I assume the soft float is normal
GCC code and thus the format is IEEE 754. I set a conditional
to indicate that in xdr_float.c

(3) Can we rename or1k_or1ksim to just or1ksim?

It seems redundant to have or1k in the name twice. Are you ok
if I rename the make/custom file?

Does this impact anything else that would need to be updated?

(4) Even with NOP addressed, spcache01 doesn't link. It is
missing a few symbols from the cache manager.

(5) tm27.h is not provided by the BSP so none of the tmtests
or psxtmtests will compile. I added the stub version to the
Makefile.am so the tests will at least compile EXCEPT for the
spcache01 noted above.

(6) Is the or1ksim built by RSB now? If so how?

(7) Is the simulator really just called sim? If so, that is a WAY too
generic name. If that's the case, we need to suggest to Christian
that it gets renamed something more or1k specific like or1ksim.

(8) How do you debug with the simulator?

I think I am close to being able to help investigate but this
weekend is the Southern Brewers Festival so I probably shouldn't
touch code too much. :)

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

powerpc/gwlcfm does not compile

[Joel Sherrill]

Hi

More from the overnight build. Could someone fix this?

powerpc-rtems4.11-gcc --pipe -B../../../../.././lib/
-B../../../../.././gwlcfm/lib/ -specs bsp_specs -qrtems
-DPACKAGE_NAME=\rtems-c-src-lib-libcpu-powerpc\
-DPACKAGE_TARNAME=\rtems-c-src-lib-libcpu-powerpc\
-DPACKAGE_VERSION=\4.10.99.0\
-DPACKAGE_STRING=\rtems-c-src-lib-libcpu-powerpc\ 4.10.99.0\
-DPACKAGE_BUGREPORT=\http://www.rtems.org/bugzilla\; -DPACKAGE_URL=\\
-I. -I../../../../../../../rtems/c/src/lib/libcpu/powerpc  -isystem
../../../../.././gwlcfm/lib/include   -mcpu=8540 -meabi -msdata=sysv
-fno-common -msoft-float -D__ppc_generic -mstrict-align -O2 -g
-fno-keep-inline-functions -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
mpc55xx/misc/flash_support.o -MD -MP -MF $depbase.Tpo -c -o
mpc55xx/misc/flash_support.o
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c
\
mv -f $depbase.Tpo $depbase.Po
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:
In function 'mpc55xx_flash_copy_op':
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:482:30:
error: 'volatile struct FLASH_tag' has no member named 'BIUCR'
 flash_biucr_r = FLASH.BIUCR.R;
  ^
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:483:14:
error: 'volatile struct FLASH_tag' has no member named 'BIUCR'
 FLASH.BIUCR.B.PFLIM = 0;
  ^
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:496:9:
warning: passing argument 1 of 'rtems_cache_flush_multiple_data_lines'
discards 'volatile' qualifier from pointer target type [enabled by default]
 rtems_cache_flush_multiple_data_lines(flash, sizeof(flash[0]));

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

powerpc/mpc5668g does not compile

[Joel Sherrill]

Hi

Another from the build. Could someone please fix this?

powerpc-rtems4.11-gcc --pipe -B../../../../../.././lib/
-B../../../../../.././mpc5668g/lib/ -specs bsp_specs -qrtems
-DHAVE_CONFIG_H   -isystem ../../../../../.././mpc5668g/lib/include  
-mcpu=8540 -meabi -msdata=sysv -fno-common -msoft-float -D__ppc_generic
-mstrict-align -O2 -g -fno-keep-inline-functions -Wall
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
-Wnested-externs -MT smsc9218i.o -MD -MP -MF .deps/smsc9218i.Tpo -c -o
smsc9218i.o `test -f 'network/smsc9218i.c' || echo
'../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/'`network/smsc9218i.c
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:
In function 'smsc9218i_interrupt_init':
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9:
error: variable 'direr' has initializer but incomplete type
   union SIU_DIRER_tag direr = MPC55XX_ZERO_FLAGS;
 ^
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9:
error: unknown field 'R' specified in initializer
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9:
warning: excess elements in union initializer [enabled by default]
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9:
warning: (near initialization for 'direr') [enabled by default]
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:23:
error: storage size of 'direr' isn't known
   union SIU_DIRER_tag direr = MPC55XX_ZERO_FLAGS;
   ^

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

powerpc/virtex5 build failure

[Joel Sherrill]

Hi

Looks like the benchmark timer code on the virtex5 is not 100%
right. It is missing a symbol.

/users/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-virtex5-rtems/powerpc-rtems4.11/c/virtex5/lib/libcpu/powerpc/../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/timer/timer.c:77:
undefined reference to `BSP_Convert_decrementer'
../../../../../virtex5/lib/librtemsbsp.a(timer.rel): In function
`Read_long_timer':
/users/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-virtex5-rtems/powerpc-rtems4.11/c/virtex5/lib/libcpu/powerpc/../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/timer/timer.c:85:
undefined reference to `BSP_Convert_decrementer'
collect2: error: ld returned 1 exit status

-- 
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: [PATCH 1/2] rtems: Inline rtems_clock_get_ticks_since_boot()

[Joel Sherrill]

 seconds 
 since epoch
  @item @code{@value{DIRPREFIX}clock_get_ticks_per_second} - Get ticks per 
 second
 -@item @code{@value{DIRPREFIX}clock_get_ticks_since_boot} - Get ticks since 
 boot
 +@item @code{@value{DIRPREFIX}clock_get_ticks_since_boot} - Get current 
 ticks counter value
  @item @code{@value{DIRPREFIX}clock_get_uptime} - Get time since boot
  @item @code{@value{DIRPREFIX}clock_get_uptime_timeval} - Get time since 
 boot in timeval format
  @item @code{@value{DIRPREFIX}clock_get_uptime_seconds} - Get seconds since 
 boot
 @@ -569,19 +569,16 @@ application has configured.

  This directive is callable from an ISR.

 -This directive will not cause the running task to be
 -preempted.  Re-initializing RTEMS causes the system date and
 -time to be reset to an uninitialized state.  Another call to
 -@code{@value{DIRPREFIX}clock_set} is required to re-initialize the
 -system date and time to application specific specifications.
 +This directive will not cause the running task to be preempted.

  @c
  @c
  @c
  @page
 -@subsection CLOCK_GET_TICKS_SINCE_BOOT - Get ticks since boot
 +@subsection CLOCK_GET_TICKS_SINCE_BOOT - Get current ticks counter value

  @cindex obtain ticks since boot
 +@cindex get current ticks counter value

  @subheading CALLING SEQUENCE:

 @@ -604,25 +601,17 @@ NONE

  @subheading DESCRIPTION:

 -This directive returns the number of clock ticks that have elapsed
 -since the system was booted.  This is the historical measure of uptime
 -in an RTEMS system.  The newer service
 -@code{@value{DIRPREFIX}clock_get_uptime} is another and potentially
 -more accurate way of obtaining similar information.
 +This directive returns the current tick counter value.  With a 1ms clock 
 tick,
 +this counter overflows after 50 days since boot.  This is the historical
 +measure of uptime in an RTEMS system.  The newer service
 +@code{@value{DIRPREFIX}clock_get_uptime} is another and potentially more
 +accurate way of obtaining similar information.

  @subheading NOTES:

  This directive is callable from an ISR.

 -This directive will not cause the running task to be
 -preempted.  Re-initializing RTEMS causes the system date and
 -time to be reset to an uninitialized state.  Another call to
 -@code{@value{DIRPREFIX}clock_set} is required to re-initialize the
 -system date and time to application specific specifications.
 -
 -This directive simply returns the number of times the dirivective
 -@code{@value{DIRPREFIX}clock_tick} has been invoked since the
 -system was booted.
 +This directive will not cause the running task to be preempted.

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

-- 
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: BSP Build Failures Appeal

[Joel Sherrill]

On 8/23/2014 10:33 PM, Chris Johns wrote:
 On 23/08/2014 1:57 am, Joel Sherrill wrote:
 The build failures I reported were with the latest RSB tools
 Please pitch in and let's resolve them.

 I have a regression build that includes building all BSPs using ...

 $ rm -rf build rsb-report-* log_*  ../source-builder/sb-set-builder 
 --prefix=$HOME/development/rtems/4.11 --log=log_all_rtems --with-rtems 
 --trace --regression 4.11/rtems-all

 ... running on sync.rtems.org as I am also seeing failures. This should 
 give me a list of error reports with the first failure on an architecture.
Apparently my build with the RSB tools didn't see all those failures. I
repeated
the same build script/configuration with tools from the head and nearly
all BSPs failed. I may have updated RTEMS between those two points in time
and the problem got worse.  This is the configure line for powerpc/psim.
All others were the same with the architecture and BSP replaced:

../rtems/configure --target=powerpc-rtems4.11 \
   --prefix=/home/joel/rtems-4.11-work/bsp-install/
--disable-multiprocessing \
  --disable-cxx --disable-rdbg --enable-maintainer-mode --enable-tests \
  --enable-networking --enable-posix --disable-itron --disable-deprecated \
  --disable-ada --enable-expada --enable-rtemsbsp=psim
 I left a similar build going for the weekend but using the
 head of gcc, newlib, and binutils. Hopefully the results
 are similar.
 Given the churn GSoC patches are creating I think we are still a while 
 away from a freeze before release branching 4.11.
+1 Hopefully not too long though. Most of them are more contained to BSPs,
ports, etc. than in past years where there was score work.
 Chris

-- 
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: [PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general

[Joel Sherrill]

On 8/25/2014 5:10 AM, Sebastian Huber wrote:
 On 25/08/14 11:45, Daniel Cederman wrote:
 ---
   cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++
   1 file changed, 2 insertions(+)

 diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h 
 b/cpukit/score/cpu/sparc/rtems/score/cpu.h
 index 9c38b55..d4c2ef0 100644
 --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
 +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
 @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control 
 *_SPARC_Per_CPU_current __asm__( g6 );

 void _CPU_SMP_Send_interrupt( uint32_t target_processor_index );

 +  #if defined(__leon__)
 void _BSP_Start_multitasking( Context_Control *heir )
   RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
 #define _CPU_Start_multitasking _BSP_Start_multitasking
 +  #endif
 In case it is LEON specific, then it should have a LEON specific name.

What's the overall rationale?

What happens on all other architectures/variants? Can this simply be a
matter of
deferring the selection/implementation to the BSP? We do that for other
cases
where the precise CPU model must be known. The interface from the
score/cpu is
well known and is mostly implemented in score/cpu. But sometimes, it
can't be.

-- 
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: powerpc/gwlcfm does not compile

[Joel Sherrill]

Thanks.

I will start a build sweep again once we have resolved the cache
compilation impact.
On 8/25/2014 2:11 AM, Sebastian Huber wrote:
 Fixed:

 http://git.rtems.org/rtems/commit/?id=0a314839012ab765a70df05eaadc4dba7440223b


-- 
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: [rtems-tools commit] Update readme.

[Joel Sherrill]

Hi

I am thrilled to see this code finally becoming more widely available.
I am now asking questions about productization which is reproducibility,
maintainability, making it available to users, enhancement path, etc.

Would it be possible to update the blog to reflect the current location
of the code?

Chris.. does having this in rtems-tools mean that a standard *-rtems*
gdb will have the Python pretty printers?

Is there an up to date status of which core handlers and managers
have at least an initial pretty printer?

Is there anyway to automate testing these?  I know the gdb macros
that I mostly wrote were a pain in the *%$ to make sure they
stayed up to date and in sync. It was easy to miss them for months
after a change impacted them.

--joel

On 8/24/2014 6:45 PM, Chris Johns wrote:
 Module:rtems-tools
 Branch:master
 Commit:6e75f4ebf5450154231a1f7c1c2ba97e60d2c074
 Changeset: 
 http://git.rtems.org/rtems-tools/commit/?id=6e75f4ebf5450154231a1f7c1c2ba97e60d2c074

 Author:Dhananjay Balan mb.dhanan...@gmail.com
 Date:  Tue Jul  9 22:39:27 2013 +0530

 Update readme.
 Included useage instructions.

 ---

  tools/gdb/python/README.md |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/tools/gdb/python/README.md b/tools/gdb/python/README.md
 index 567c195..8858a4f 100644
 --- a/tools/gdb/python/README.md
 +++ b/tools/gdb/python/README.md
 @@ -2,3 +2,5 @@ rtems-gdb
  =
  
  GDB extenstions to RTEMS.
 +
 +See [this blog post for 
 instructions](http://dbalan.github.io/blog/2013/06/23/debugging-rtems-with-gdb/)

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

-- 
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: [PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general

[Joel Sherrill]

On 8/25/2014 11:44 AM, Sebastian Huber wrote:
 On 08/25/2014 05:04 PM, Joel Sherrill wrote:
 On 8/25/2014 5:10 AM, Sebastian Huber wrote:
 On 25/08/14 11:45, Daniel Cederman wrote:
 ---
cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++
1 file changed, 2 insertions(+)

 diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h 
 b/cpukit/score/cpu/sparc/rtems/score/cpu.h
 index 9c38b55..d4c2ef0 100644
 --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
 +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
 @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control 
 *_SPARC_Per_CPU_current __asm__( g6 );

  void _CPU_SMP_Send_interrupt( uint32_t target_processor_index );

 +  #if defined(__leon__)
  void _BSP_Start_multitasking( Context_Control *heir )
RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
  #define _CPU_Start_multitasking _BSP_Start_multitasking
 +  #endif
 In case it is LEON specific, then it should have a LEON specific name.

 What's the overall rationale?
 If its mandated by the CPU port, e.g. all the stuff defined by 
 no_cpu/cpu.h, then it should be _CPU_*.  In case all BSPs of a CPU port 
 must implement a CPU port function, then it is _BSP_*.  In case only 
 certain multilib variants implement it specifically, then they should 
 have an appropriate multilib specific prefix, e.g. _LEON3_* or 
 _ARMV7M_*.  Does this make sense?  Maybe we should add this stuff to the 
 CPU supplement.

Yeah. I get this part and we do need better rules but what's the issue
with this
one method? The ifdef made it look like only the leon flavor of RTEMS and no
others even had this method.

-- 
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: [PATCH 1/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.

[Joel Sherrill]

On 8/26/2014 9:38 AM, Hesham Moustafa wrote:
 On Tue, Aug 26, 2014 at 4:09 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/26/2014 8:53 AM, Hesham Moustafa wrote:
 Hi,

 On Mon, Aug 25, 2014 at 6:15 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 I pushed all of this set and will be testing soon.

 Great, Thanks!
 No problem. We know this is a work in progress and it is better to
 keep the delta small as progress is made.
 Can you post your simulator configuration file?

 Here it's https://github.com/heshamelmatary/or1k-rtems/blob/master/sim.cfg
 Should I include it part of the or1ksim BSP directory (or anywhere else)?
 In the BSP Readme would be great.  We really need the simulator run
 scripts to
 support this simulator. That also captures the information.

 The whole configuration file (sim.cfg) content into README?
Is it too big? If so, just add a file and reference it from the readme.
 + rtems-testing/sim-scripts
 I can start with this one, would it make sense to make the or1ksim
 script creates a sim.cfg file (with parameterized configurations)?
Look at psim or any of the skyeye based simulators. They have to create
a device
description file.
 + rtems-tools/tester

 I don't expect it to be hard to add to both once the or1ksim is built by
 the RSB.

 FWIW that's what I am waiting for to help debug/test if that gives you
 incentive. :)

 --joel
 --joel

 On 8/22/2014 3:20 PM, Hesham ALMatary wrote:
 ---
  testsuites/sptests/spcache01/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/testsuites/sptests/spcache01/init.c 
 b/testsuites/sptests/spcache01/init.c
 index 2c9d184..ad9b54f 100644
 --- a/testsuites/sptests/spcache01/init.c
 +++ b/testsuites/sptests/spcache01/init.c
 @@ -27,7 +27,11 @@

  const char rtems_test_name[] = SPCACHE 1;

 -#define I() __asm__ volatile (nop)
 +#ifdef __or1k__
 +  #define I() __asm__ volatile (l.nop)
 +#else
 +  #define I() __asm__ volatile (nop)
 +#endif

  #define I8() I(); I(); I(); I(); I(); I(); I(); I()

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

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


-- 
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: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Joel Sherrill]

On 8/26/2014 2:06 PM, Hesham Moustafa wrote:
 Hi,

 On Tue, Aug 26, 2014 at 8:47 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 This looks good except that it is missing a comment for the commit.

 Can you add that and resubmit?

 Done. Is it Ok to submit the sim.cfg and README change for or1ksim BSP too?
Yes. and the sim.cfg should be its own file. It is large. :)
 Thanks.
 On 8/26/2014 12:59 PM, Hesham ALMatary wrote:
 ---
  sim-scripts/Makefile   |   5 +-
  sim-scripts/or1ksim.in | 155 
 +
  2 files changed, 159 insertions(+), 1 deletion(-)
  create mode 100644 sim-scripts/or1ksim.in

 diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
 index 9d9baaf..e45feae 100644
 --- a/sim-scripts/Makefile
 +++ b/sim-scripts/Makefile
 @@ -1,6 +1,6 @@
  INSTALL_DIR=../bin
  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
 -  m32csim m32rsim psim sis simsh v850sim
 +  m32csim m32rsim or1ksim psim sis simsh v850sim
  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye

 @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in 
 m32csim.in
  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
   ./mkrun yes M32R m32r m32rsim

 +or1ksim or1ksim-gdb: or1ksim.in
 + ./mkrun yes OR1K or1k or1ksim
 +
  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
   ./mkrun yes PowerPC powerpc psim

 diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
 new file mode 100644
 index 000..3f59e47
 --- /dev/null
 +++ b/sim-scripts/or1ksim.in
 @@ -0,0 +1,155 @@
 +#
 +#  or1k/or1ksim Support
 +#
 +bspSupportsGDBServerMode=yes
 +runBSP=or32-elf-sim
 +bspTreeFile=sim.cfg
 +
 +runARGS()
 +{
 +  echo -f ${bspTreeFile} ${1}
 +}
 +
 +checkBSPFaults()
 +{
 +  return 0
 +}
 +
 +bspLimit()
 +{
 +  testname=$1
 +  case ${testname} in
 +*stackchk*)limit=5 ;;
 +*fatal*)   limit=1 ;;
 +*minimum*) limit=1 ;;
 +*psxtime*) limit=180 ;;
 +*) limit=60 ;;
 +  esac
 +  echo ${limit}
 +}
 +
 +bspGeneratesGDBCommands=yes
 +
 +gdbServerARGS()
 +{
 +  echo -c ${bspTreeFile}
 +}
 +
 +bspGenerateGDBCommands()
 +{
 +cat EOF
 +tar remote :50001
 +EOF
 +}
 +
 +### Generate the or1ksim device tree based upon the type of application 
 being run
 +bspGenerateDeviceTree()
 +{
 +cat EOF
 +section memory
 +  name =  RAM
 +  random_seed = 12345
 +  type= random
 +  ce   =  0
 +  mc   =  0
 +  baseaddr = 0x
 +  size = 0x0800
 +  delayr   =  1
 +  delayw   =  2
 +end
 +
 +section immu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +
 +section dmmu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +section mc
 +  enabled = 0
 +  baseaddr = 0x9000
 +  POC = 0x000a /* 32 bit SSRAM */
 +  index = 0
 +end
 +
 +section ic
 +  enabled   =   0
 +  nsets = 256
 +  nways =   1
 +  blocksize =  16
 +  hitdelay  =  20
 +  missdelay =  20
 +end
 +
 +section dc
 +  enabled = 0
 +  nsets = 256
 +  nways = 1
 +  blocksize = 16
 +  load_hitdelay = 0
 +  load_missdelay = 0
 +  store_hitdelay = 0
 +  store_missdelay = 0
 +end
 +
 +section pic
 +  enabled = 1
 +  edge_trigger = 1
 +end
 +
 +section sim
 +  verbose  =  1
 +  debug=  0
 +  profile  =  0
 +  history  =  0
 +  clkcycle = 10ns/* 100MHz clock */
 +end
 +
 +section VAPI
 +  enabled = 1
 +  server_port = 5
 +  log_enabled = 1
 +  vapi_log_file = vapi.log
 +end
 +
 +section cpu
 +  ver = 0x12
 +  cfg = 0x00
 +  rev = 0x0001
 +  superscalar = 0
 +  hazards = 0
 +  dependstats = 0
 +  sbuf_len = 100
 +end
 +
 +section debug
 + enabled = 1
 + rsp_enabled = 1
 + rsp_port = 50001
 +end
 +
 +section uart
 +  enabled  = 1
 +  baseaddr = 0x9000
 +  #channel = xterm
 +  channel = file:uart0.rx,uart0.tx
 +  irq = 2
 +  16550= 1
 +end
 +
 +section pm
 +  enabled = 1
 +end
 +EOF
 +}
 +bspGeneratesDeviceTree=yes
 --
 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


-- 
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: [PATCH] sim-scripts: Add new or1ksim OpenRISC simulator script.

[Joel Sherrill]

This is merged.

You should now be able to run all tests with or1ksim `find . -name *.exe`

But you may also want to specify the time limit argument (-l seconds) since
many may not run correctly.

If you know abort/error messages where the simulator reports that the code
barfs but doesn't exit, those can be added.

Next RSB support for or1ksim. :)

And them rtems-tester

--joel
On 8/26/2014 2:09 PM, Joel Sherrill wrote:
 On 8/26/2014 2:06 PM, Hesham Moustafa wrote:
 Hi,

 On Tue, Aug 26, 2014 at 8:47 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 This looks good except that it is missing a comment for the commit.

 Can you add that and resubmit?

 Done. Is it Ok to submit the sim.cfg and README change for or1ksim BSP too?
 Yes. and the sim.cfg should be its own file. It is large. :)
 Thanks.
 On 8/26/2014 12:59 PM, Hesham ALMatary wrote:
 ---
  sim-scripts/Makefile   |   5 +-
  sim-scripts/or1ksim.in | 155 
 +
  2 files changed, 159 insertions(+), 1 deletion(-)
  create mode 100644 sim-scripts/or1ksim.in

 diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile
 index 9d9baaf..e45feae 100644
 --- a/sim-scripts/Makefile
 +++ b/sim-scripts/Makefile
 @@ -1,6 +1,6 @@
  INSTALL_DIR=../bin
  GDBSIM_SCRIPTS=bf537Stamp ezkit533 gdbarmsim h8sim jmr3904 lm32_evr \
 -  m32csim m32rsim psim sis simsh v850sim
 +  m32csim m32rsim or1ksim psim sis simsh v850sim
  SKYEYE_SCRIPTS=ant5206 bf537Stamp-skyeye csb337 csb350 csb360 edb7312 \
ezkit533-skyeye gumstix rtl22xx smdk2410 leon2-skyeye

 @@ -130,6 +130,9 @@ m32csim m32csim-gdb: gdb-sim-run.in gdb-sim.in 
 m32csim.in
  m32rsim m32rsim-gdb: gdb-sim-run.in gdb-sim.in m32rsim.in
   ./mkrun yes M32R m32r m32rsim

 +or1ksim or1ksim-gdb: or1ksim.in
 + ./mkrun yes OR1K or1k or1ksim
 +
  psim psim-gdb: gdb-sim-run.in gdb-sim.in psim.in
   ./mkrun yes PowerPC powerpc psim

 diff --git a/sim-scripts/or1ksim.in b/sim-scripts/or1ksim.in
 new file mode 100644
 index 000..3f59e47
 --- /dev/null
 +++ b/sim-scripts/or1ksim.in
 @@ -0,0 +1,155 @@
 +#
 +#  or1k/or1ksim Support
 +#
 +bspSupportsGDBServerMode=yes
 +runBSP=or32-elf-sim
 +bspTreeFile=sim.cfg
 +
 +runARGS()
 +{
 +  echo -f ${bspTreeFile} ${1}
 +}
 +
 +checkBSPFaults()
 +{
 +  return 0
 +}
 +
 +bspLimit()
 +{
 +  testname=$1
 +  case ${testname} in
 +*stackchk*)limit=5 ;;
 +*fatal*)   limit=1 ;;
 +*minimum*) limit=1 ;;
 +*psxtime*) limit=180 ;;
 +*) limit=60 ;;
 +  esac
 +  echo ${limit}
 +}
 +
 +bspGeneratesGDBCommands=yes
 +
 +gdbServerARGS()
 +{
 +  echo -c ${bspTreeFile}
 +}
 +
 +bspGenerateGDBCommands()
 +{
 +cat EOF
 +tar remote :50001
 +EOF
 +}
 +
 +### Generate the or1ksim device tree based upon the type of application 
 being run
 +bspGenerateDeviceTree()
 +{
 +cat EOF
 +section memory
 +  name =  RAM
 +  random_seed = 12345
 +  type= random
 +  ce   =  0
 +  mc   =  0
 +  baseaddr = 0x
 +  size = 0x0800
 +  delayr   =  1
 +  delayw   =  2
 +end
 +
 +section immu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +
 +section dmmu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +section mc
 +  enabled = 0
 +  baseaddr = 0x9000
 +  POC = 0x000a /* 32 bit SSRAM */
 +  index = 0
 +end
 +
 +section ic
 +  enabled   =   0
 +  nsets = 256
 +  nways =   1
 +  blocksize =  16
 +  hitdelay  =  20
 +  missdelay =  20
 +end
 +
 +section dc
 +  enabled = 0
 +  nsets = 256
 +  nways = 1
 +  blocksize = 16
 +  load_hitdelay = 0
 +  load_missdelay = 0
 +  store_hitdelay = 0
 +  store_missdelay = 0
 +end
 +
 +section pic
 +  enabled = 1
 +  edge_trigger = 1
 +end
 +
 +section sim
 +  verbose  =  1
 +  debug=  0
 +  profile  =  0
 +  history  =  0
 +  clkcycle = 10ns/* 100MHz clock */
 +end
 +
 +section VAPI
 +  enabled = 1
 +  server_port = 5
 +  log_enabled = 1
 +  vapi_log_file = vapi.log
 +end
 +
 +section cpu
 +  ver = 0x12
 +  cfg = 0x00
 +  rev = 0x0001
 +  superscalar = 0
 +  hazards = 0
 +  dependstats = 0
 +  sbuf_len = 100
 +end
 +
 +section debug
 + enabled = 1
 + rsp_enabled = 1
 + rsp_port = 50001
 +end
 +
 +section uart
 +  enabled  = 1
 +  baseaddr = 0x9000
 +  #channel = xterm
 +  channel = file:uart0.rx,uart0.tx
 +  irq = 2
 +  16550= 1
 +end
 +
 +section pm
 +  enabled = 1
 +end
 +EOF
 +}
 +bspGeneratesDeviceTree=yes
 --
 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


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

Re: [PATCH] Add or1ksim (sim.cfg) configuration file and edit README.

[Joel Sherrill]

Now committed.

Thanks.
On 8/26/2014 2:42 PM, Hesham ALMatary wrote:
 OpenRISC/or1ksim BSP: The new sim.cfg file configures or1ksim emulator with HW
 capabilities that the current RTEMS/or1ksim BSP supports.

 README: HOWTO run the or1ksim simulator.
 ---
  c/src/lib/libbsp/or1k/or1ksim/README  |  20 ++-
  c/src/lib/libbsp/or1k/or1ksim/sim.cfg | 104 
 ++
  2 files changed, 123 insertions(+), 1 deletion(-)
  create mode 100644 c/src/lib/libbsp/or1k/or1ksim/sim.cfg

 diff --git a/c/src/lib/libbsp/or1k/or1ksim/README 
 b/c/src/lib/libbsp/or1k/or1ksim/README
 index 43b4703..dfa3cb1 100644
 --- a/c/src/lib/libbsp/or1k/or1ksim/README
 +++ b/c/src/lib/libbsp/or1k/or1ksim/README
 @@ -14,4 +14,22 @@ Configuration file sim.cfg should be provided for 
 complex board
  configurations at the current directory (which you run or1ksim from) or at
  ~/.or1k/
  
 -sim -f sim.cfg hello.exe
 +The current sim.cfg file that configures or1ksim emulator to RTEMS/or1ksim 
 BSP
 +is at the same directory as this README. You can also use or1ksim script 
 from 
 +rtems-tools/sim-scripts.
 +
 +From command line type:
 +
 +sim -f sim.cfg $PATH_TO_RTEMS_EXE
 +
 +or (if you use a stable or1ksim release)
 +
 +or32-elf-sim -f sim.cfg $PATH_TO_RTEMS_EXE
 +
 +from sim-scripts:
 +
 +or1ksim $PATH_TO_RTEMS_EXE
 +
 +and then attach GDB to or1ksim from another terminal by running 
 +
 +or1ksim-gdb $PATH_TO_RTEMS_EXE
 diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg 
 b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg
 new file mode 100644
 index 000..cfc3d2b
 --- /dev/null
 +++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg
 @@ -0,0 +1,104 @@
 +section memory
 +  name =  RAM
 +  random_seed = 12345
 +  type= random
 +  ce   =  0
 +  mc   =  0
 +  baseaddr = 0x
 +  size = 0x0800
 +  delayr   =  1
 +  delayw   =  2
 +end
 +
 +section immu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +
 +section dmmu
 +  enabled = 0
 +  nsets = 64
 +  nways = 1
 +  pagesize = 8192
 +  hitdelay = 0
 +  missdelay = 0
 +end
 +section mc
 +  enabled = 0 
 +  baseaddr = 0x9000
 +  POC = 0x000a /* 32 bit SSRAM */
 +  index = 0
 +end
 +
 +section ic
 +  enabled   =   0 
 +  nsets = 256
 +  nways =   1
 +  blocksize =  16
 +  hitdelay  =  20
 +  missdelay =  20
 +end
 +
 +section dc
 +  enabled = 0
 +  nsets = 256
 +  nways = 1
 +  blocksize = 16
 +  load_hitdelay = 0
 +  load_missdelay = 0
 +  store_hitdelay = 0
 +  store_missdelay = 0
 +end
 +
 +section pic
 +  enabled = 1
 +  edge_trigger = 1
 +end
 +
 +section sim
 +  verbose  =  1 
 +  debug=  0 
 +  profile  =  0
 +  history  =  0
 +  clkcycle = 10ns/* 100MHz clock */
 +end
 +
 +section VAPI
 +  enabled = 1 
 +  server_port = 5
 +  log_enabled = 1
 +  vapi_log_file = vapi.log
 +end
 +
 +section cpu
 +  ver = 0x12
 +  cfg = 0x00
 +  rev = 0x0001
 +  superscalar = 0
 +  hazards = 0
 +  dependstats = 0
 +  sbuf_len = 100 
 +end
 +
 +section debug
 + enabled = 1 
 + rsp_enabled = 1
 + rsp_port = 50001
 +end
 +
 +section uart
 +  enabled  = 1
 +  baseaddr = 0x9000
 + #channel = xterm
 +  channel = file:uart0.rx,uart0.tx
 +  irq = 2
 +  16550= 1
 +end
 +
 +section pm
 +  enabled = 1
 +end

-- 
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: Remaining BSP Build Failures

[Joel Sherrill]

On 8/27/2014 10:54 AM, Hesham Moustafa wrote:
 Hi,

 On Wed, Aug 27, 2014 at 5:02 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 Hi

 Hesham.. or1k is missing a method.

 Yes, I am aware of that, I will add missing methods just after I
 submit another RSB patch for or1ksim.
I figured you knew about it. Just reporting. :)

And I just committed a fix for the arm/nds.

That leaves the nios2 as likely an RSB issue. My gcc was 4.1.2 which doesn't
seem to match the 4.9.x I think the RSB should build for this.

And hopefully Ric can provide a fix for the virtex5.

The avr is a gcc bug. I could disable optimization and it may continue
building.
 Ric.. any chance you can fix the virtex5 compile failure?

 Others  please review and see what you can help with.

 I attempted to build all BSPs over night with this configuration:

 ../rtems/configure --target=@CPU@-rtems4.11 \
   --prefix=/home/joel/rtems-4.11-work/bsp-install/ \
   --disable-multiprocessing --disable-cxx --disable-rdbg \
   --enable-maintainer-mode --enable-tests --enable-networking \
   --enable-posix --disable-itron --disable-deprecated \
   --disable-ada --disable-expada --enable-rtemsbsp=@BSP@

 Although not printed, SMP was enabled in the configure command
 echoed in the output. :(

 The results were better than last time:

 arm/nds:

 ../../../../../nds/lib/librtemsbsp.a(startup.rel): In function `boot_card':
 :(.text+0x19c): multiple definition of `boot_card'
 init.o:init.c:(.text+0x70): first defined here
 collect2: error: ld returned 1 exit status
 gmake[6]: *** [spinternalerror01.exe] Error 1

 I think that's because it makes a set of .rel's and ends up pulling in
 a chunk of binary instead of individual files for the BSP. I think I
 can fix this one.

 avr/avrtest: Compiler error. Reported as
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62284

 nios2/nios2_iss: Compilation error which I think means that
 the newlib version needs to be bumped in the RSB.

 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function
 'dwmac_desc_enh_destroy_tx_desc':
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:
 warning: implicit declaration of function '__DEVOLATILE'
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:
 warning: nested extern declaration of '__DEVOLATILE'
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: error:
 expected expression before 'void'
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:
 warning: initialization makes pointer from integer without a cast
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function
 'dwmac_desc_enh_release_tx_bufs':
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:850: error:
 expected expression before 'void'

 or1k/or1ksim:  Port Missing methods
 /users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/testsuites/sptests/spcontext01/../../../../../../../rtems/c/src/../../testsuites/sptests/spcontext01/init.c:42:
 undefined reference to `_CPU_Context_validate'
 init.o: In function `clobber_and_switch_timer':
 /users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/testsuites/sptests/spcontext01/../../../../../../../rtems/c/src/../../testsuites/sptests/spcontext01/init.c:118:
 undefined reference to `_CPU_Context_volatile_clobber'

 powerpc/virtex5: BSP missing method

 /users/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-virtex5-rtems/powerpc-rtems4.11/c/virtex5/lib/libcpu/powerpc/../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/timer/timer.c:85:
 undefined reference to `BSP_Convert_decrementer'

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


-- 
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: Remaining BSP Build Failures

[Joel Sherrill]

On 8/27/2014 11:34 AM, Ric Claus wrote:
 Hi Joel,

   Sorry, but unfortunately I no longer have the ability or time to work on 
 Virtex5 since we moved to Zynqs.  If someone else can't take it over, I think 
 you have no choice but to deprecate it.
I understand. This may not be hard to remember though. It is really a simple
method. It looks like the clock tick was using the shared decrementer
driver.
If so, then this from the beatnik BSP should work:

#define BSP_Convert_decrementer( _value ) \
  ((unsigned long long) unsigned long long)BSP_time_base_divisor) *
100ULL) /((unsigned long long) BSP_bus_frequency)) * ((unsigned long
long) (_value)))



   Ric

 On Aug 27, 2014, at 8:02 AM, Joel Sherrill wrote:

 Hi

 Hesham.. or1k is missing a method.

 Ric.. any chance you can fix the virtex5 compile failure?

 Others  please review and see what you can help with.

 I attempted to build all BSPs over night with this configuration:

 ../rtems/configure --target=@CPU@-rtems4.11 \
  --prefix=/home/joel/rtems-4.11-work/bsp-install/ \
  --disable-multiprocessing --disable-cxx --disable-rdbg \
  --enable-maintainer-mode --enable-tests --enable-networking \
  --enable-posix --disable-itron --disable-deprecated \
  --disable-ada --disable-expada --enable-rtemsbsp=@BSP@

 Although not printed, SMP was enabled in the configure command
 echoed in the output. :(

 The results were better than last time:

 arm/nds:

 ../../../../../nds/lib/librtemsbsp.a(startup.rel): In function `boot_card':
 :(.text+0x19c): multiple definition of `boot_card'
 init.o:init.c:(.text+0x70): first defined here
 collect2: error: ld returned 1 exit status
 gmake[6]: *** [spinternalerror01.exe] Error 1

 I think that's because it makes a set of .rel's and ends up pulling in
 a chunk of binary instead of individual files for the BSP. I think I
 can fix this one.

 avr/avrtest: Compiler error. Reported as
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62284

 nios2/nios2_iss: Compilation error which I think means that
 the newlib version needs to be bumped in the RSB.

 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function
 'dwmac_desc_enh_destroy_tx_desc':
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:
 warning: implicit declaration of function '__DEVOLATILE'
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:
 warning: nested extern declaration of '__DEVOLATILE'
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: error:
 expected expression before 'void'
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:
 warning: initialization makes pointer from integer without a cast
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function
 'dwmac_desc_enh_release_tx_bufs':
 ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:850: error:
 expected expression before 'void'

 or1k/or1ksim:  Port Missing methods
 /users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/testsuites/sptests/spcontext01/../../../../../../../rtems/c/src/../../testsuites/sptests/spcontext01/init.c:42:
 undefined reference to `_CPU_Context_validate'
 init.o: In function `clobber_and_switch_timer':
 /users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/testsuites/sptests/spcontext01/../../../../../../../rtems/c/src/../../testsuites/sptests/spcontext01/init.c:118:
 undefined reference to `_CPU_Context_volatile_clobber'

 powerpc/virtex5: BSP missing method

 /users/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-virtex5-rtems/powerpc-rtems4.11/c/virtex5/lib/libcpu/powerpc/../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/timer/timer.c:85:
 undefined reference to `BSP_Convert_decrementer'

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


-- 
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: [rtems commit] preinstall: Regenerated files differ from the repo.

[Joel Sherrill]

When I bootstrap -p from the top, it looks like every other 
preinstall.am in the tree  has this difference.

Big commit following to deal with this.

--joel
On 8/27/2014 7:54 PM, Chris Johns wrote:
 Module:rtems
 Branch:master
 Commit:5826a1b284450778be4b73276560a48ccd0cd9a7
 Changeset: 
 http://git.rtems.org/rtems/commit/?id=5826a1b284450778be4b73276560a48ccd0cd9a7

 Author:Chris Johns chr...@rtems.org
 Date:  Thu Aug 28 10:08:00 2014 +1000

 preinstall: Regenerated files differ from the repo.

 ---

  .../lib/libbsp/arm/altera-cyclone-v/preinstall.am  |   12 ++--
  c/src/lib/libbsp/or1k/or1ksim/preinstall.am|   13 +++--
  c/src/lib/libbsp/or1k/preinstall.am|1 +
  c/src/lib/libcpu/or1k/preinstall.am|7 ---
  4 files changed, 18 insertions(+), 15 deletions(-)

 diff --git a/c/src/lib/libbsp/arm/altera-cyclone-v/preinstall.am 
 b/c/src/lib/libbsp/arm/altera-cyclone-v/preinstall.am
 index 768c01d..5b6b9fd 100644
 --- a/c/src/lib/libbsp/arm/altera-cyclone-v/preinstall.am
 +++ b/c/src/lib/libbsp/arm/altera-cyclone-v/preinstall.am
 @@ -5,18 +5,18 @@ $(srcdir)/preinstall.am: Makefile.am
   $(AMPOLISH3) $(srcdir)/Makefile.am  $(srcdir)/preinstall.am
  endif
  
 -all-am: $(PREINSTALL_FILES)
 -
 -PREINSTALL_FILES =
 -CLEANFILES = $(PREINSTALL_FILES)
 -
  PREINSTALL_DIRS =
  DISTCLEANFILES += $(PREINSTALL_DIRS)
  
  all-local: $(TMPINSTALL_FILES)
  
  TMPINSTALL_FILES =
 -CLEANFILES += $(TMPINSTALL_FILES)
 +CLEANFILES = $(TMPINSTALL_FILES)
 +
 +all-am: $(PREINSTALL_FILES)
 +
 +PREINSTALL_FILES =
 +CLEANFILES += $(PREINSTALL_FILES)
  
  $(PROJECT_LIB)/$(dirstamp):
   @$(MKDIR_P) $(PROJECT_LIB)
 diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am 
 b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am
 index cbdf3df..2569864 100644
 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am
 +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am
 @@ -8,15 +8,15 @@ endif
  PREINSTALL_DIRS =
  DISTCLEANFILES += $(PREINSTALL_DIRS)
  
 -all-am: $(PREINSTALL_FILES)
 -
 -PREINSTALL_FILES =
 -CLEANFILES = $(PREINSTALL_FILES)
 -
  all-local: $(TMPINSTALL_FILES)
  
  TMPINSTALL_FILES =
 -CLEANFILES += $(TMPINSTALL_FILES)
 +CLEANFILES = $(TMPINSTALL_FILES)
 +
 +all-am: $(PREINSTALL_FILES)
 +
 +PREINSTALL_FILES =
 +CLEANFILES += $(PREINSTALL_FILES)
  
  $(PROJECT_LIB)/$(dirstamp):
   @$(MKDIR_P) $(PROJECT_LIB)
 @@ -117,3 +117,4 @@ TMPINSTALL_FILES += $(PROJECT_LIB)/linkcmds
  $(PROJECT_LIB)/linkcmds.base: ../shared/startup/linkcmds.base 
 $(PROJECT_LIB)/$(dirstamp)
   $(INSTALL_DATA) $ $(PROJECT_LIB)/linkcmds.base
  TMPINSTALL_FILES += $(PROJECT_LIB)/linkcmds.base
 +
 diff --git a/c/src/lib/libbsp/or1k/preinstall.am 
 b/c/src/lib/libbsp/or1k/preinstall.am
 index 1143c2e..dba6cc4 100644
 --- a/c/src/lib/libbsp/or1k/preinstall.am
 +++ b/c/src/lib/libbsp/or1k/preinstall.am
 @@ -4,3 +4,4 @@ if AMPOLISH3
  $(srcdir)/preinstall.am: Makefile.am
   $(AMPOLISH3) $(srcdir)/Makefile.am  $(srcdir)/preinstall.am
  endif
 +
 diff --git a/c/src/lib/libcpu/or1k/preinstall.am 
 b/c/src/lib/libcpu/or1k/preinstall.am
 index 9670596..ee9d0da 100644
 --- a/c/src/lib/libcpu/or1k/preinstall.am
 +++ b/c/src/lib/libcpu/or1k/preinstall.am
 @@ -5,14 +5,14 @@ $(srcdir)/preinstall.am: Makefile.am
   $(AMPOLISH3) $(srcdir)/Makefile.am  $(srcdir)/preinstall.am
  endif
  
 +PREINSTALL_DIRS =
 +DISTCLEANFILES += $(PREINSTALL_DIRS)
 +
  all-am: $(PREINSTALL_FILES)
  
  PREINSTALL_FILES =
  CLEANFILES += $(PREINSTALL_FILES)
  
 -PREINSTALL_DIRS =
 -DISTCLEANFILES += $(PREINSTALL_DIRS)
 -
  $(PROJECT_INCLUDE)/libcpu/$(dirstamp):
   @$(MKDIR_P) $(PROJECT_INCLUDE)/libcpu
   @:  $(PROJECT_INCLUDE)/libcpu/$(dirstamp)
 @@ -21,3 +21,4 @@ PREINSTALL_DIRS += $(PROJECT_INCLUDE)/libcpu/$(dirstamp)
  $(PROJECT_INCLUDE)/libcpu/cache.h: ../shared/include/cache.h 
 $(PROJECT_INCLUDE)/libcpu/$(dirstamp)
   $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/libcpu/cache.h
  PREINSTALL_FILES += $(PROJECT_INCLUDE)/libcpu/cache.h
 +

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

-- 
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: Remaining BSP Build Failures + Adding eth linker script section for arm bsp.

[Joel Sherrill]

 a git bisect.
 So we do not need any Ti tools for board setup now and when setup/loader
 code is implemented, we do not need CSS and HalCoGen even for
 initial MCU setup code build. That binary can be flashed by OpenOCD
 already if you do not fear much about bugs and possible target smashing.
:) Progress.
 Best wishes,

   Pavel

-- 
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: TOD/RTC questions

[Joel Sherrill]

On 8/29/2014 10:38 AM, Alan Cudmore wrote:
 I was able to get the ds1307 i2c part working on the Pi. The tod.c 
 driver shell was calling setRealTimeToRTEMS() but it was failing in 
 rtems_clock_set because my driver was not returning the correct 
 rtems_tod format.
 Now when I boot the Pi, the rtems time is synced to the battery backed RTC.
That's great news!

--joel
 Thanks,
 Alan

 On 8/28/2014 1:26 PM, Joel Sherrill wrote:
 On 8/28/2014 12:16 PM, Alan Cudmore wrote:
 I am testing out the Raspberry Pi I2C interface by implementing a
 DS1307 RTC driver.

 I started with the libchip/rtc/ds1375.c driver, since it is very close
 to the 1307.

 In the Raspberry Pi BSP, I added code to i2c_init.c to create a raw
 device node for the RTC device, then I added the tod/todcfg.h similar
 to the powerpc/mvme3100 BSP.

 Using the test functions I can read and write the device, but is there
 anything else I need to do in order to tie it to the RTEMS time functions?

 For example:
 In the shell ( main_date.c ) , the time() function just returns the
 1998 epoch. Also, the shell rtc command ( main_rtc.c ) calls
 rtems_clock_get_tod, but returns a error. If I use the RTC command and
 set the time, it does try to write to my device and subsequent calls
 to rtems_clock_tod do not return an error.

 Am I missing any setup here?

 Finally, is RTC the same as TOD for RTEMS?

 It is a source to set the TOD from. There are some ugly APIs provided
 by the RTC driver shell code. They really need new names but I haven't
 had any good ideas. :(

 See libbsp/shared/tod.c.

 setRealTimeFromRTEMS() is probably the missing call you are looking
 for.
 Thanks,
 Alan

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

ARM folks speak up - was Re: CMSIS?

[Joel Sherrill]

Hi

Since I will admit not knowing what CMSIS was until I Google'd
this, I decided to give this thread a prod.  The link to ARM's
documentation on this is:

http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

Maybe that will help.

--joel
On 8/29/2014 12:04 PM, Daniel Gutson wrote:
 absent answer means NO?

 Thanks,

 Daniel.

 On Thu, Aug 28, 2014 at 11:31 AM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
 Hi,

is there any precedent regarding a CMSIS abstraction layer
 implementation on RTEMS?

 Thanks,

Daniel.

 --

 Daniel F. Gutson
 Chief Engineering Officer, SPD


 San Lorenzo 47, 3rd Floor, Office 5

 Córdoba, Argentina


 Phone: +54 351 4217888 / +54 351 4218211

 Skype: dgutson



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

C++ cdtest Build Failure

[Joel Sherrill]

Hi

Any suggestions?

In file included from
../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:29:0:
/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:
In function 'long long int std::abs(long long int)':
/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:174:20:
error: declaration of C function 'long long int std::abs(long long int)'
conflicts with
   abs(long long __x) { return __builtin_llabs (__x); }
^
/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:166:3:
error: previous declaration 'long int std::abs(long int)' here
   abs(long __i) { return __builtin_labs(__i); }
   ^
../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc: At
global scope:
../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:216:1:
error: expected '}' at end of input
 }
 ^

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

or1ksim from RSB - OK

[Joel Sherrill]

Hi

Just a quick note to say that this built on Fedora 20 from the RSB.

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

or1ksim fails to build

[Joel Sherrill]

Hi

I think something isn't quite right.  I don't know if gcc isn't including
these or the bsp_specs isn't picking them up. It is a long holiday weekend
and I just wanted to throw this out since I don't have time to investigate.

or1k-rtems4.11-gcc -B../../../../../or1ksim/lib/ -specs bsp_specs
-qrtems -O2 -O0 -g -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs   
-O2   -o nsecs.exe init.o empty.o
../../../../../or1ksim/lib/librtemscpu.a(libscore_a-threadhandler.o): In
function `_Thread_Handler':
/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/cpukit/score/../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:181:
undefined reference to `_init'
../../../../../or1ksim/lib/librtemscpu.a(libcsupport_a-newlibc_exit.o):
In function `_exit':
/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:43:
undefined reference to `_fini'
collect2: error: ld returned 1 exit status

-- 
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: or1ksim fails to build

[Joel Sherrill]

I will try to get to this soon. But it is a holiday weekend and tomorrow is my 
wife's birthday so I have priorities :)

--Joel

On August 29, 2014 4:32:05 PM CDT, Hesham Moustafa heshamelmat...@gmail.com 
wrote:
I have removed the entire or1k-rtems4.11-* and built a vanilla
toolchain from latest RSB. Then I cloned latest RTEMS from the git
HEAD, configured and built it, and I did not come across this error.
MY configure line is:
~/rtems/configure --target=or1k-rtems4.11 --enable-rtemsbsp=or1ksim
--enable-networking --enable-tests


On Fri, Aug 29, 2014 at 10:15 PM, Hesham Moustafa
heshamelmat...@gmail.com wrote:

 On Aug 29, 2014 10:10 PM, Joel Sherrill joel.sherr...@oarcorp.com
wrote:


 On 8/29/2014 2:24 PM, Hesham Moustafa wrote:
  On Fri, Aug 29, 2014 at 9:19 PM, Joel Sherrill
  joel.sherr...@oarcorp.com wrote:
  Hi
 
  I think something isn't quite right.  I don't know if gcc isn't
  including
  these or the bsp_specs isn't picking them up. It is a long
holiday
  weekend
  and I just wanted to throw this out since I don't have time to
  investigate.
 
  or1k-rtems4.11-gcc -B../../../../../or1ksim/lib/ -specs bsp_specs
  -qrtems -O2 -O0 -g -Wall -Wmissing-prototypes
  -Wimplicit-function-declaration -Wstrict-prototypes
-Wnested-externs
  -O2   -o nsecs.exe init.o empty.o
 
../../../../../or1ksim/lib/librtemscpu.a(libscore_a-threadhandler.o):
  In
  function `_Thread_Handler':
 
 
/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/cpukit/score/../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:181:
  undefined reference to `_init'
 
../../../../../or1ksim/lib/librtemscpu.a(libcsupport_a-newlibc_exit.o):
  In function `_exit':
 
 
/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/cpukit/libcsupport/../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:43:
  undefined reference to `_fini'
  collect2: error: ld returned 1 exit status
 
  What's the configure line you used to build? I used to
--disable-posix
  and --disable-itron to avoid some of building errors.
 ITRON is no longer in the tree so that doesn't matter at all. :)

 POSIX was on. With it off, I get the same.

 I built a new toolset with the RSB just in case and got the same
result.

 It is a long holiday weekend here. Heading out and not sure what is
 broken. Usually this indicates an issue with the linkcmds or
 the bsp_specs. But if it works for you, then it must be something
 else or all changes are not submitted.

 Are your tools fresh?

 There is no problem with RTEMS because I use the RTEMS git repo and
not
 mine.
 I believe my tools are fresh, but I will build it again now and
report the
 results.


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

 --
 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: C++ cdtest Build Failure

[Joel Sherrill]

Not sure. Today is Michele's birthday and it's a long weekend. Cleaned tools 
directory and left them building. Will see.

I only reported it because Chris mentioned many c++ build failures.

On August 30, 2014 9:02:24 AM CDT, Gedare Bloom ged...@rtems.org wrote:
Is it only on or1k?

On Fri, Aug 29, 2014 at 3:14 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
 Hi

 Any suggestions?

 In file included from

../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:29:0:

/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:
 In function 'long long int std::abs(long long int)':

/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:174:20:
 error: declaration of C function 'long long int std::abs(long long
int)'
 conflicts with
abs(long long __x) { return __builtin_llabs (__x); }
 ^

/users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/cstdlib:166:3:
 error: previous declaration 'long int std::abs(long int)' here
abs(long __i) { return __builtin_labs(__i); }
^

../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:
At
 global scope:

../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:216:1:
 error: expected '}' at end of input
  }
  ^

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

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

Re: CMSIS?

[Joel Sherrill]

On 9/2/2014 9:52 AM, Daniel Gutson wrote:
 On Tue, Sep 2, 2014 at 11:51 AM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 This is the license.

 The big problem I see first is the typical use only on our hardware
 and that in order to redistribute, we must ensure that it is only
 used on ARM hardware.

 This is a common restriction on vendor provided software and I
 honestly don't know how to address including anything which
 wants an open source project to ensure that anyone downloading
 only uses it on the appropriate hardware.

 We have seen similar licenses from at least four vendors.

 If someone is able to crack this nut and find a way to not incur
 liability for the RTEMS Project, I am open to ideas. But skeptical.
 Would this mean that an implementation from scratch would be the best choice?
Unfortunately, that's the solution we have always arrived at. If the
specification
itself doesn't have restrictions on implementations.

With that said, if there is an independent open source implementation
which is
portable, we have sometimes had luck in going that route. Even when it
required
asking for a license change.

DISCLAIMER: I have no idea what the specification says technically. I
looked at the
figure and the license. Seems useful enough for cross-platform ARM code.
And
if some of those features are appropriate, this would allow
cross-platform to
non-ARM targets. But that is clearly not in ARM's best interests for
their own
implementation.

--joel

 --joel

 

 END USER LICENCE AGREEMENT FOR THE CORTEX MICROCONTROLLER SOFTWARE
 INTERFACE STANDARD (CMSIS) SPECIFICATION AND SOFTWARE

 THIS END USER LICENCE AGREEMENT (LICENCE) IS A LEGAL AGREEMENT BETWEEN
 YOU (EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED
 (ARM) FOR THE USE OF THE CMSIS SPECIFICATION, EXAMPLE CODE, DSP
 LIBRARY SPECIFICATION AND DSP LIBRARY IMPLEMENTATION AS SUCH TERMS ARE
 DEFINED BELOW (COLLECTIVELY, THE ARM DELIVERABLES). ARM IS ONLY
 WILLING TO LICENSE THE ARM DELIVERABLES TO YOU ON CONDITION THAT YOU
 ACCEPT ALL OF THE TERMS IN THIS LICENCE. BY CLICKING I AGREE, OR BY
 INSTALLING OR OTHERWISE USING OR COPYING THE ARM DELIVERABLES YOU
 INDICATE THAT YOU AGREE TO BE BOUND BY ALL THE TERMS OF THIS LICENCE. IF
 YOU DO NOT AGREE TO THE TERMS OF THIS LICENCE, ARM IS UNWILLING TO
 LICENSE YOU TO USE THE ARM DELIVERABLES AND YOU MAY NOT INSTALL, USE OR
 COPY THE ARM DELIVERABLES.

 CMSIS Specification means any documentation and C programming language
 files defining the application programming interface, naming and coding
 conventions of the Cortex Microcontroller Software Interface Standard
 (CMSIS) as well as the System View Description (SVD) documentation and
 associated XML schema file. Notwithstanding the foregoing, CMSIS
 Specification shall not include (i) the implementation of other
 published specifications referenced in the CMSIS Specification; (ii) any
 enabling technologies that may be necessary to make or use any product
 or portion thereof that complies with the CMSIS Specification, but are
 not themselves expressly set forth in the CMSIS Specification (e.g.
 compiler front ends, code generators, back ends, libraries or other
 compiler, assembler or linker technologies; validation or debug software
 or hardware; applications, operating system or driver software; RISC
 architecture; processor microarchitecture); (iii) maskworks and physical
 layouts of integrated circuit designs; or (iv) RTL or other high level
 representations of integrated circuit designs.

 DSP Library Implementation means any C programming language source
 code implementing the functionality of the digital signal processor
 (DSP) algorithms and the application programming interface as defined in
 the DSP Library Specification. The DSP Library Implementation makes use
 of CMSIS application programming interface and therefore is targeted at
 Cortex-M class processors.

 DSP Library Specification means the DSP library documentation and C
 programming language file defining the application programming interface
 of the DSP Library Implementation. Notwithstanding the foregoing, DSP
 Library Specification shall not include (i) the implementation of other
 published specifications referenced in the DSP Library Specification;
 (ii) any enabling technologies that may be necessary to make or use any
 product or portion thereof that complies with the DSP Library
 Specification, but are not themselves expressly set forth in the DSP
 Library Specification (e.g. compiler front ends, code generators, back
 ends, libraries or other compiler, assembler or linker technologies;
 validation or debug software or hardware; applications, operating system
 or driver software; RISC architecture; processor microarchitecture);
 (iii) maskworks and physical layouts of integrated circuit designs; or
 (iv) RTL or other high level representations of integrated circuit designs.

 Example Code means any

Warnings on Head

[Joel Sherrill]

Hi

Doing some greps and mangling on the build logs from every BSP, I
discovered we have ~2350 unique warnings output by gcc.

- ~1250 of these only occur once.
- ~1900 occur less than 5 times.
- ~2270 occur less than 10 times.

These are almost certainly in BSP specific code built for variants.
My hope is that folks take a few minutes, remove warnings from
the BSP they are using and submit a patch.

That leaves about 100 warning lines that are reported in over
ten BSP builds.

At the high end, we have a handful that show up on over 100 BSP
variants. My hope is that we can eliminate these, then focus on the
next set which impact over 50 BSP variants.   I can post the full
list if someone wants to tackle a class of warnings like unused
variables, missing prototypes, etc. 

Here are the warnings which occur more than 100 times:

200 c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4: warning:
format '%lc' expects argument of type 'wint_t', but argument 4 has type
'wchar_t' [-Wformat=]
180 c/src/../../cpukit/posix/src/mprotect.c:34:5: warning: no
previous prototype for 'mprotect' [-Wmissing-prototypes]
180 c/src/../../cpukit/libmisc/shell/main_cp.c:108:1: warning:
'rtems_shell_cp_exit' defined but not used [-Wunused-function]
180 c/src/../../cpukit/libfs/src/rfs/rtems-rfs-inode.c:346:11:
warning: variable 'rrc' set but not used [-Wunused-but-set-variable]
178 c/src/../../cpukit/posix/src/keyrundestructors.c:70:11: warning:
assignment discards 'const' qualifier from pointer target type [enabled
by default]
178 c/src/../../cpukit/posix/src/keygetspecific.c:55:18: warning:
assignment discards 'const' qualifier from pointer target type [enabled
by default]
178 c/src/../../cpukit/libfs/src/rfs/rtems-rfs-rtems.c:524:19:
warning: assignment makes integer from pointer without a cast [enabled
by default]
178 c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:104:15:
warning: assignment discards 'const' qualifier from pointer target type
[enabled by default]
130 c/src/../../testsuites/sptests/spintr_err01/init.c:23:21:
warning: unused variable 'status' [-Wunused-variable]

I don't know how we have 200. There are 182 BSP log files.

Help definitely appreciated. Hopefully we can all pitch in
and reduce warnings.

Thanks.

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

tms570 and networking

[Joel Sherrill]

Hi

The tms570 has what appears to be a partial set of Makefile.am
entries for a network driver but none is present so the BSP fails
to build when networking is enabled. It appears to be missing
the line which would specify a source file anyway.

I have commented out the section locally. Should I delete it
until a network driver is submitted?

-- 
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: BSPs which define NDEBUG in CFLAGS

[Joel Sherrill]

On September 3, 2014 6:41:45 AM CDT, Federico Casares 
federico.casa...@tallertechnologies.com wrote:
Hi Joel,

We did the lpc1768* BSPs. If we remove the NDEBUG... which will be the
procedure to disable ASSERTS for production builds?

Ultimately you (end user) select the flags you want to deploy with. :)

My goal is just ensure builds work with and without it defined.

regards.



On Tue, Sep 2, 2014 at 6:57 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:

Hi

The following BSPs define NDEBUG in their CFLAGS and thus fail
to compile when RTEMS debug is enabled:

mvme136
lpc1768_mbed_ahb_ram
lpc1768_mbed
rtl22xx

I have tracked this down to newlib's assert.h (correctly) not
defining __ASSERT_FUNC when NDEBUG is defined.  This trips
up the RTEMS assert definitions which rely on that definition
of __ASSERT_FUNC.

I can fix this by using the logic in newlib's assert.h to define
__RTEMS_ASSERT_FUNC for our own assert's use.

Any objections to this approach?

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




-- 

 
Casares, Federico

Sr. Software Engineer

Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

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

Re: CMSIS?

[Joel Sherrill]

I hate to reply to my own post but need to in this case.

https://mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/

Code is available and BSD licensed. Last comment gives link to
blog making code available.

We weren't the only ones with a problem with their license.
On 9/3/2014 9:30 AM, Joel Sherrill wrote:
 On 9/3/2014 6:47 AM, Sebastian Huber wrote:
 Hello,

 there are also BSD licensed CMSIS versions:

 http://comments.gmane.org/gmane.comp.lib.libopencm3/361

 The original ARM license makes it pretty useless for us.

 Interestingly, these are from ARM but are really BSD licensed.

 I am not opposed to us using them as long as we review each file
 for appropriate licensing.

 Someone from the RTEMS Community would also need to step up
 and make sure we get updates periodically. Basically help out the
 guy with the github site. Nothing is worse that importing third party
 source without an upstream connection and feedback loop.


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

Upcoming Set of Patches

[Joel Sherrill]

Hi

I am about to post 23 small patches which remove a lot of warnings.
Most are correction of format specifiers, elimination of set
but not used warnings, and using the expected type for a variable
in pattern code. Two BSPs had warnings when linking any
executable and I addressed those.

Hopefully nothing too controversial and I can commit soon.

-- 
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 08/23] lpc24xx/.../bspreset.c: Eliminate warning for set not used variable

[Joel Sherrill]

---
 c/src/lib/libbsp/arm/lpc24xx/startup/bspreset.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/c/src/lib/libbsp/arm/lpc24xx/startup/bspreset.c 
b/c/src/lib/libbsp/arm/lpc24xx/startup/bspreset.c
index d98f907..cb63431 100644
--- a/c/src/lib/libbsp/arm/lpc24xx/startup/bspreset.c
+++ b/c/src/lib/libbsp/arm/lpc24xx/startup/bspreset.c
@@ -31,6 +31,7 @@ BSP_START_TEXT_SECTION __attribute__((flatten)) void 
bsp_reset(void)
 {
   rtems_interrupt_level level;
 
+  (void) level;
   rtems_interrupt_disable(level);
 
   #if defined(ARM_MULTILIB_ARCH_V4)
-- 
1.9.3

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

[PATCH 02/23] csb337/.../bspreset.c: Eliminate warning for set not used variable

[Joel Sherrill]

---
 c/src/lib/libbsp/arm/csb337/startup/bspreset.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c 
b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
index 940ff7f..1167d92 100644
--- a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
+++ b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
@@ -17,7 +17,6 @@ void bsp_reset(void)
 {
   rtems_interrupt_level level;
 
-  (void) level;
   rtems_interrupt_disable(level);
 
   /* Enable the watchdog timer, then wait for the world to end. */
-- 
1.9.3

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

[PATCH 17/23] score603e/start/start.S: Add start symbol to eliminate warning

[Joel Sherrill]

---
 c/src/lib/libbsp/powerpc/score603e/start/start.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/c/src/lib/libbsp/powerpc/score603e/start/start.S 
b/c/src/lib/libbsp/powerpc/score603e/start/start.S
index c67e598..d58d42c 100644
--- a/c/src/lib/libbsp/powerpc/score603e/start/start.S
+++ b/c/src/lib/libbsp/powerpc/score603e/start/start.S
@@ -51,8 +51,11 @@ FUNC_NAME(__atexit): /* tell C's eabi-ctor's 
we have an atexit function */
 .Lptr:
.long .LCTOC1-.Laddr
 
+   .globl  start
.globl  _start
+   .type   start,@function
.type   _start,@function
+start:
 _start:
b   past_constants
/* Set MSR */
-- 
1.9.3

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

[PATCH 12/23] lpc23xx_tli800-testsuite.tcfg: Add tests which do not link with debug enabled

[Joel Sherrill]

---
 .../lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg 
b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg
index a678ca2..b63ed50 100644
--- a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg
+++ b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg
@@ -10,6 +10,7 @@ fileio
 flashdisk01
 fsdosfsformat01
 fsdosfsname01
+fsdosfswrite01
 fsrfsbitmap01
 ftp01
 iostream
@@ -23,6 +24,7 @@ jffs2_fstime
 loopback
 mdosfs_fserror
 mghttpd01
+monitor
 monitor02
 mrfs_fserror
 mrfs_fsfpathconf
@@ -33,8 +35,10 @@ mrfs_fsrdwr
 mrfs_fssymlink
 mrfs_fstime
 mdosfs_fsrdwr
+mdosfs_fspatheval
 paranoia
 pppd
+psxmsgq01
 rtems++
 sptls02
 spstkalloc02
-- 
1.9.3

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

[PATCH 15/23] rtems/score/assert.h: Rework to allow use of NDEBUG

[Joel Sherrill]

---
 cpukit/score/include/rtems/score/assert.h | 56 ---
 1 file changed, 43 insertions(+), 13 deletions(-)

diff --git a/cpukit/score/include/rtems/score/assert.h 
b/cpukit/score/include/rtems/score/assert.h
index b8d9463..43ec2d0 100644
--- a/cpukit/score/include/rtems/score/assert.h
+++ b/cpukit/score/include/rtems/score/assert.h
@@ -30,22 +30,52 @@ extern C {
  * NDEBUG.
  */
 #if defined( RTEMS_DEBUG )
+
+  /**
+   * @brief Macro with method name used in assert output
+   *
+   * Given the variations in compilers and standards, we have to poke a bit.
+   *
+   * @note This is based on the code in newlib's assert.h.
+   */
+  #ifndef __RTEMS_ASSERT_FUNCTION
+/* Use g++'s demangled names in C++.  */
+#if defined __cplusplus  defined __GNUC__
+  #define __RTEMS_ASSERT_FUNCTION __PRETTY_FUNCTION__
+
+/* C99 requires the use of __func__.  */
+#elif __STDC_VERSION__ = 199901L
+  #define __RTEMS_ASSERT_FUNCTION __func__
+
+/* Older versions of gcc don't have __func__ but can use __FUNCTION__.  */
+#elif __GNUC__ = 2
+  #define __RTEMS_ASSERT_FUNCTION __FUNCTION__
+
+/* failed to detect __func__ support.  */
+#else
+  #define __RTEMS_ASSERT_FUNCTION ((char *) 0)
+#endif
+  #endif /* !__RTEMS_ASSERT_FUNCTION */
+
   #if !defined( RTEMS_SCHEDSIM )
-/* __ASSERT_FUNC is newlib. */
+/* normal build is newlib. */
+
+void __assert_func(const char *, int, const char *, const char *)
+  RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
+
+#define _Assert( _e ) \
+   ( ( _e ) ? \
+ ( void ) 0 : \
+   __assert_func( __FILE__, __LINE__, __RTEMS_ASSERT_FUNCTION, #_e ) )
+
+  #elif defined(__linux__)
+/* Scheduler simulator has only beed tested on glibc. */
 #define _Assert( _e ) \
-  ( ( _e ) ? \
-( void ) 0 : \
-  __assert_func( __FILE__, __LINE__, __ASSERT_FUNC, #_e ) )
+ ( ( _e ) ? \
+   ( void ) 0 : \
+ __assert_fail( #_e, __FILE__, __LINE__, __RTEMS_ASSERT_FUNCTION ) )
   #else
-/* __ASSERT_FUNCTION is glibc. */
-#if defined(__ASSERT_FUNCTION)
-  #define _Assert( _e ) \
-   ( ( _e ) ? \
- ( void ) 0 : \
-   __assert_fail( #_e, __FILE__, __LINE__, __ASSERT_FUNCTION ) )
-#else
-   #error What does assert.h use?
-#endif
+#error Implement RTEMS assert support for this C Library
   #endif
 
 #else
-- 
1.9.3

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

[PATCH 19/23] rtems-rfs-buffer.c: Correct printf() format specifiers to eliminate warnings

[Joel Sherrill]

---
 cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c 
b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
index 3d89f5f..4192b21 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
@@ -52,13 +52,12 @@ rtems_rfs_scan_chain (rtems_chain_control*   chain,
 buffer = (rtems_rfs_buffer*) node;
 
 if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
-  printf (% PRIuPTR  , ((intptr_t) buffer-user));
+  printf (%p , buffer-user);
 
 if (((rtems_rfs_buffer_block) ((intptr_t)(buffer-user))) == block)
 {
   if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
-printf (: found block=% PRIuPTR \n,
-((intptr_t)(buffer-user)));
+printf (: found block=%p\n, buffer-user);
 
   (*count)--;
   rtems_chain_extract_unprotected (node);
-- 
1.9.3

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

[PATCH 22/23] Misc psxtmtests: Use uint32_t not long for end_time to match printf() format expectations

[Joel Sherrill]

---
 testsuites/psxtmtests/psxtmcond01/init.c   |  8 
 testsuites/psxtmtests/psxtmcond02/init.c   |  4 ++--
 testsuites/psxtmtests/psxtmcond03/init.c   |  2 +-
 testsuites/psxtmtests/psxtmcond04/init.c   |  8 
 testsuites/psxtmtests/psxtmcond05/init.c   |  4 ++--
 testsuites/psxtmtests/psxtmcond06/init.c   |  2 +-
 testsuites/psxtmtests/psxtmcond08/init.c   |  2 +-
 testsuites/psxtmtests/psxtmthread02/init.c |  2 +-
 testsuites/psxtmtests/psxtmthread04/init.c | 16 
 testsuites/psxtmtests/psxtmthread05/init.c |  3 ++-
 testsuites/psxtmtests/psxtmthread06/init.c |  2 +-
 11 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/testsuites/psxtmtests/psxtmcond01/init.c 
b/testsuites/psxtmtests/psxtmcond01/init.c
index 7f1f820..c4dd630 100644
--- a/testsuites/psxtmtests/psxtmcond01/init.c
+++ b/testsuites/psxtmtests/psxtmcond01/init.c
@@ -30,8 +30,8 @@ pthread_cond_t mycondvar;
 
 void benchmark_create_cond_var(void)
 {
-  long end_time;
-  int  status;
+  uint32_t end_time;
+  int  status;
 
   benchmark_timer_initialize();
   status = pthread_cond_init(mycondvar, NULL);
@@ -49,8 +49,8 @@ void benchmark_create_cond_var(void)
 
 void benchmark_destroy_cond_var(void)
 {
-  long end_time;
-  int  status;
+  uint32_t end_time;
+  int  status;
 
   benchmark_timer_initialize();
   status = pthread_cond_destroy(mycondvar);
diff --git a/testsuites/psxtmtests/psxtmcond02/init.c 
b/testsuites/psxtmtests/psxtmcond02/init.c
index 7621517..668bb43 100644
--- a/testsuites/psxtmtests/psxtmcond02/init.c
+++ b/testsuites/psxtmtests/psxtmcond02/init.c
@@ -26,8 +26,8 @@ pthread_cond_t CondID;
 
 void benchmark_signal(void)
 {
-  long end_time;
-  int  status;
+  uint32_t end_time;
+  int  status;
 
   benchmark_timer_initialize();
 
diff --git a/testsuites/psxtmtests/psxtmcond03/init.c 
b/testsuites/psxtmtests/psxtmcond03/init.c
index f901878..795c8d4 100644
--- a/testsuites/psxtmtests/psxtmcond03/init.c
+++ b/testsuites/psxtmtests/psxtmcond03/init.c
@@ -52,7 +52,7 @@ void *POSIX_Init(
 {
   intstatus;
   pthread_t  threadId;
-  long   end_time;
+  uint32_t   end_time;
   struct sched_param param;
   int policy;
 
diff --git a/testsuites/psxtmtests/psxtmcond04/init.c 
b/testsuites/psxtmtests/psxtmcond04/init.c
index eb28230..2c16dfa 100644
--- a/testsuites/psxtmtests/psxtmcond04/init.c
+++ b/testsuites/psxtmtests/psxtmcond04/init.c
@@ -33,10 +33,10 @@ void *Blocker(
 )
 {
 
-  long end_time;
-  struct sched_param param;
-  int policy;
-  int status;
+  uint32_t end_time;
+  struct   sched_param param;
+  int  policy;
+  int  status;
 
   status = pthread_mutex_lock(MutexID);
   rtems_test_assert( status == 0 );
diff --git a/testsuites/psxtmtests/psxtmcond05/init.c 
b/testsuites/psxtmtests/psxtmcond05/init.c
index 1e74c21..ab15fc3 100644
--- a/testsuites/psxtmtests/psxtmcond05/init.c
+++ b/testsuites/psxtmtests/psxtmcond05/init.c
@@ -26,8 +26,8 @@ pthread_cond_t CondID;
 
 void benchmark_broadcast(void)
 {
-  long end_time;
-  int  status;
+  uint32_t end_time;
+  int  status;
 
   benchmark_timer_initialize();
   status = pthread_cond_broadcast(CondID);
diff --git a/testsuites/psxtmtests/psxtmcond06/init.c 
b/testsuites/psxtmtests/psxtmcond06/init.c
index 3717926..91bef6c 100644
--- a/testsuites/psxtmtests/psxtmcond06/init.c
+++ b/testsuites/psxtmtests/psxtmcond06/init.c
@@ -52,7 +52,7 @@ void *POSIX_Init(
   void *argument
 )
 {
-  longend_time;
+  uint32_tend_time;
   int status;
   int i;
   pthread_t   threadId;
diff --git a/testsuites/psxtmtests/psxtmcond08/init.c 
b/testsuites/psxtmtests/psxtmcond08/init.c
index 3da351c..49ad0d7 100644
--- a/testsuites/psxtmtests/psxtmcond08/init.c
+++ b/testsuites/psxtmtests/psxtmcond08/init.c
@@ -50,7 +50,7 @@ void *Low(
   void *argument
 )
 {
-  long end_time;
+  uint32_t end_time;
 
   end_time = benchmark_timer_read();
 
diff --git a/testsuites/psxtmtests/psxtmthread02/init.c 
b/testsuites/psxtmtests/psxtmthread02/init.c
index 4357938..bafa2ac 100644
--- a/testsuites/psxtmtests/psxtmthread02/init.c
+++ b/testsuites/psxtmtests/psxtmthread02/init.c
@@ -53,7 +53,7 @@ void *thread(
   void *argument
 )
 {
-  long end_time;
+  uint32_t end_time;
 
   end_time = benchmark_timer_read();
   put_time(
diff --git a/testsuites/psxtmtests/psxtmthread04/init.c 
b/testsuites/psxtmtests/psxtmthread04/init.c
index 28e1833..dc1290c 100644
--- a/testsuites/psxtmtests/psxtmthread04/init.c
+++ b/testsuites/psxtmtests/psxtmthread04/init.c
@@ -26,10 +26,10 @@ void *POSIX_Init(void *argument);
 
 void benchmark_pthread_getschedparam(void)
 {
-  long end_time;
-  int  status;
-  int policy;
-  struct sched_param param;
+  uint32_tend_time;
+  int status;
+  int policy;
+  struct sched_param  param;
 
   benchmark_timer_initialize();
   status = pthread_getschedparam( pthread_self(), policy, param );
@@ -48,10 +48,10 @@ 

[PATCH 21/23] spfreechain01/init.c: Use %zd for size_t to eliminate warning

[Joel Sherrill]

---
 testsuites/sptests/spfreechain01/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/testsuites/sptests/spfreechain01/init.c 
b/testsuites/sptests/spfreechain01/init.c
index 434c126..8f5e10f 100644
--- a/testsuites/sptests/spfreechain01/init.c
+++ b/testsuites/sptests/spfreechain01/init.c
@@ -51,7 +51,7 @@ bool my_freechain_extend_heap( Freechain_Control *freechain )
   test_node *nodes = malloc(size);
 
   if (!nodes) {
-printf( INIT - Unable to allocate free chain of size: %d\n, size );
+printf( INIT - Unable to allocate free chain of size: %zd\n, size );
 return NULL;
   }
 
@@ -74,7 +74,7 @@ bool my_freechain_extend_workspace( Freechain_Control 
*freechain )
   test_node *nodes = _Workspace_Allocate(size);
 
   if (!nodes) {
-printf( INIT - Unable to allocate free chain of size: %d\n, size );
+printf( INIT - Unable to allocate free chain of size: %zd\n, size );
 return NULL;
   }
 
-- 
1.9.3

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

[PATCH 20/23] shell.c: Add cast to match printf() expectations for width specifier

[Joel Sherrill]

---
 cpukit/libmisc/shell/shell.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index a94724f..eeb60dc 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -306,7 +306,12 @@ static int rtems_shell_line_editor(
 
 case 7: /* Control-G */
   if (output) {
-fprintf(out,\r%s%*c, prompt, strlen (line), ' ');
+/*
+ * The (int) cast is needed because the width specifier (%*)
+ * must be an int, but strlen() returns a size_t. Without
+ * the case, the result is a printf() format warning.
+ */
+fprintf(out,\r%s%*c, prompt, (int) strlen (line), ' ');
 fprintf(out,\r%s\x7, prompt);
   }
   memset (line, '\0', strlen(line));
-- 
1.9.3

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

[PATCH 13/23] tms570/Makefile.am: Remove bad networking build info

[Joel Sherrill]

---
 c/src/lib/libbsp/arm/tms570/Makefile.am | 14 --
 1 file changed, 14 deletions(-)

diff --git a/c/src/lib/libbsp/arm/tms570/Makefile.am 
b/c/src/lib/libbsp/arm/tms570/Makefile.am
index e66cf79..ab2914c 100644
--- a/c/src/lib/libbsp/arm/tms570/Makefile.am
+++ b/c/src/lib/libbsp/arm/tms570/Makefile.am
@@ -130,20 +130,6 @@ libbsp_a_CPPFLAGS += 
-I$(srcdir)/../../../libcpu/arm/shared/include
 # Start hooks
 libbsp_a_SOURCES += startup/bspstarthooks.c
 
-# Network
-
-if HAS_NETWORKING
-
-noinst_PROGRAMS = network.rel
-
-network_rel_CPPFLAGS = $(AM_CPPFLAGS)
-network_rel_CPPFLAGS += -D__INSIDE_RTEMS_BSD_TCPIP_STACK__ -D__BSD_VISIBLE
-network_rel_LDFLAGS = $(RTEMS_RELLDFLAGS)
-
-libbsp_a_LIBADD += network.rel
-
-endif
-
 # 
 # --  Special Rules
 # 
-- 
1.9.3

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

[PATCH 24/24] nios2_iss/Makefile.am: Add cache

[Joel Sherrill]

---
 c/src/lib/libbsp/nios2/nios2_iss/Makefile.am | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/c/src/lib/libbsp/nios2/nios2_iss/Makefile.am 
b/c/src/lib/libbsp/nios2/nios2_iss/Makefile.am
index 1094826..c10cd80 100644
--- a/c/src/lib/libbsp/nios2/nios2_iss/Makefile.am
+++ b/c/src/lib/libbsp/nios2/nios2_iss/Makefile.am
@@ -25,13 +25,22 @@ dist_project_lib_DATA += startup/linkcmds
 
 noinst_LIBRARIES += libbsp.a
 libbsp_a_SOURCES =
+libbsp_a_CPPFLAGS = 
 
 # startup
-libbsp_a_SOURCES += ../../shared/bspclean.c ../../shared/bsplibc.c \
-../../shared/bspreset_loop.c ../../shared/bsppost.c startup/bspstart.c \
-../../shared/bsppretaskinghook.c ../../shared/bspgetworkarea.c \
-../../shared/bootcard.c ../../shared/sbrk.c startup/setvec.c \
-../../shared/gnatinstallhandler.c ../../shared/bsppredriverhook.c
+libbsp_a_SOURCES += ../../shared/bspclean.c
+libbsp_a_SOURCES += ../../shared/bsplibc.c
+libbsp_a_SOURCES += ../../shared/bspreset_loop.c
+libbsp_a_SOURCES += ../../shared/bsppost.c
+libbsp_a_SOURCES += startup/bspstart.c
+libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c
+libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
+libbsp_a_SOURCES += ../../shared/bootcard.c
+libbsp_a_SOURCES += ../../shared/sbrk.c
+libbsp_a_SOURCES += startup/setvec.c
+libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c
+libbsp_a_SOURCES += ../../shared/bsppredriverhook.c
+
 # clock
 libbsp_a_SOURCES += clock/clock.c ../../../shared/clockdrv_shell.h
 # console
@@ -39,5 +48,8 @@ libbsp_a_SOURCES += console/console.c 
../../shared/console-polled.c
 # timer
 libbsp_a_SOURCES += timer/timer.c
 
+# Cache
+libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/cache.rel
+
 include $(srcdir)/preinstall.am
 include $(top_srcdir)/../../../../automake/local.am
-- 
1.9.3

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

Re: Capture Engine - Addition of capture task information to the capture buffer

[Joel Sherrill]

On 9/4/2014 12:57 PM, Jennifer Averett wrote:

 Chris suggested the following approach:

  

 Another approach could involve adding the task data to the trace
 buffer when the first reference

  to the task is added to the trace buffer. You would add the task
 data tagging it with some sort of id.

  When added events related to the task the id is used. The trace
 buffer decoder extracts the task data

  building a suitable table to decode the following id references.
 There is a small extra bump filling the

  trace buffer with the task details but this is the cost of tracing
 in software. This approach helps solves

  the problem of off board streaming of the trace data.

  

 Using this approach are there any suggestions for how the capture
 control information currently

 accessed through the capture task would be handled?

  

Piling on... most of the information in the capture engine's task
control blocks
can be logged statically on task create. BUT... there is also trigger
information
in there. Where should that be now?

Jennifer is plowing ahead logging variable length records and eliminating
fields in the capture task control but we don't see how to get rid of
all of it.

-- 
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: OpenRISC/or1ksim RTEMS Tester results

[Joel Sherrill]

Not bad for a first run. :)

Now look at timeouts and see if they can be addressed easily. May just need 
more run time. Or the failures?

On September 6, 2014 6:07:50 PM CDT, Hesham Moustafa heshamelmat...@gmail.com 
wrote:
Hi all,

Just want to share with you the results I got from running RTEMS
Tester on or1ksim BSP and qemu.

Passed:   356
Failed:13
Timeouts: 134
Invalid:0
Total:503
Average test time: 0:00:22.316492
Testing time : 3:07:05.195857

Regards,
Hesham
___
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] [RTEMS TESTER] Add new OpenRISC/or1ksim BSP script using qemu

[Joel Sherrill]

On September 7, 2014 6:18:53 PM CDT, Hesham Moustafa heshamelmat...@gmail.com 
wrote:

On Sep 8, 2014 12:40 AM, Chris Johns chr...@rtems.org wrote:

 On 7/09/2014 4:25 pm, Hesham Moustafa wrote:


 The test results improved a little bit from yesterday. Here are the
results:

 Passed:   365
 Failed: 6
 Timeouts: 130
 Invalid:2
 Total:503
 Average test time: 0:00:22.877361
 Testing time : 3:11:47.312905

 The full log file is attached.


 If you run one of the timed out tests, say fsdosfsname01.exe from the
command line does it complete and if so how long ?
No it doesn't, some fs tests go to sleep and do not wake up again. 

Run in the debugger.. Break.. See where it is.. Continue.. Repeat a few times. 

Test could be in an unreported fault or something slow or something 
misconfigured in hardware.


 Chris
 ___
 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 1/7] score: Add RTEMS_DECONST|DEVOLATILE|DEQUALIFY()

[Joel Sherrill]

On September 8, 2014 2:44:39 AM CDT, Jan Engelhardt jeng...@inai.de wrote:

On Monday 2014-09-08 08:08, Sebastian Huber wrote:

 I think we should eventually use -Werror, so it is important to get
rid of
 warnings.  I am in favour of macros, since this makes it easier to
deal with
 compiler dependencies.

-Werror is a bad idea. Your users may be using a different compiler 
and/or compiler version which emits new warnings, and then they run
into 
errors. This is especially annoying for distributions — it probably
does 
not matter for RTEMS, but it does with respect to general software — as

the most often encountered warnings are petty things like (a) unused 
variables that stem from conditional #if/#endif pairs, (b) comparing 
sign-different types, (c) conversion losing precision/narrowing types, 
which are not nearly as important as crashes due to (d) whacky 
type-punning and integral_type-pointer_type conversions, (e) use of 
implicitly declared things.

I would like to see -Werror on a subset of critical directories. But from a 
practical viewpoint, it is nearly impossible to get and keep the tree warning 
free on 18 target architectures.

Right now there are about 2000 unique warnings when I crunch the build logs. 
Some BSPs only have a handful, others have up to 100. Some of these are easy to 
fix bit others are involved. The printf format warning I fixed and Gedare 
questioned the patch is turning into a delicate bug in inttypes.h which may end 
up requiring a new CPP predefine in GCC. 

I want to do a little more clean up myself and then plan a community 
beautification week where (hopefully) users take some time to help clean up 
warnings. 

If warnings get lost in your compile logs, perhaps using 
automake's silent-rules option can be of help. [Similar 
tunables may exist in cmake, etc.]

Autoconf.. :(

So, please, no -Werror.

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

Current Warnings Report

[Joel Sherrill]

Hi

Attached is a report based on the warnings in the current
head of RTEMS (plus a couple of local patches). The count
is the number of BSPs that report this warning.

The float/double printf format appears to be a gcc false
positive on targets where sizeof(float) == sizeof(double).
I have started a thread on that.

Help is requested in shrinking this list.

Thanks.

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



warnings-20140910.txt.bz2
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] dosfs: Check error status

[Joel Sherrill]

Assuming this fixes a warning, commit it.

I will review the logs and answer your other question when I get to the 
workshop this morning. That requires a computer.

I will also revert my change to rfs and start another build sweep so please 
commit this.

On September 11, 2014 7:06:17 AM EDT, Sebastian Huber 
sebastian.hu...@embedded-brains.de wrote:
---
cpukit/libfs/src/dosfs/msdos_misc.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c
b/cpukit/libfs/src/dosfs/msdos_misc.c
index c09aa19..03ec38f 100644
--- a/cpukit/libfs/src/dosfs/msdos_misc.c
+++ b/cpukit/libfs/src/dosfs/msdos_misc.c
@@ -2001,20 +2001,22 @@ msdos_find_name_in_fat_file (
   retval = -1;
   break;
 }
-retval = msdos_add_file (
-buffer,
-name_type,
-fs_info,
-fat_fd,
-bts2rd,
-fat_entries,
-name_dir_entry,
-dir_pos,
-dir_offset,
-empty_space_offset,
-empty_space_entry,
-empty_space_count
-);
+
+if (retval == RC_OK)
+retval = msdos_add_file (
+buffer,
+name_type,
+fs_info,
+fat_fd,
+bts2rd,
+fat_entries,
+name_dir_entry,
+dir_pos,
+dir_offset,
+empty_space_offset,
+empty_space_entry,
+empty_space_count
+);
 }
 
 return retval;

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