RTEMS Installation & Configuration

[Noble N. Nkwocha]

Hi everyone,

My name is Noble N. Nkwocha and I am new to and with RTEMS.

I was successful "I believe", in installing and Configuring RTEMS 4.10.2 for the i386 and PowerPC target processors.   I used the pre-built tools and binary versions.    Would someone please help with the following questions?


1.       Where is the resulting RTEMS Kernel after a successful configuration?   What is its filename?   Should I expect to have a file named "i386-rtems4.10-run" and another one named "powerpc-rtems4.10-run" after the successful build of RTEMS4.10.2?



2.       Why is it that I cannot not get a successful RTEMS configuration for "powerpc" and "rad750" as target and BSP options respectively?   I get an error message indicating that a branch for the BSP (rad750) was not found.   The same problem occurs when I try "qemuprep" for a "powerpc" BSP.     The RTEMS Documentations I have, state that both the "rad750" and "qemuprep" are included in the standard RTEMS PowerPC BSPs distribution.   What am I not doing correct, here?


3.       Why do I get the System Error message below, each time I try the following:



$ i386-rtems4.10-gdb `find  . -name  ticker.exe`

[cid:image003.png at 01CF11E2.C6AA62D0]


This the command I used for my configurations.  "powerpc" and "psim" were substituted for the target and BSP for our successful PowerPC configuration

    ../rtems-4.10.2/configure --target=i386-rtems4.10 --enable-rtemsbsp=i386ex --enable-cxx --enable-tests=samples
    make all
    make install

Thank you,

Noble N. Nkwocha
(681) 753-5218 Work
(304) 816-3718 Home
(505) 238-5927 Cellular (Evenings, Nights and Weekends ONLY)
Noble.N.Nkwocha at NASA.Gov<mailto:Noble.N.Nkwocha at nasa.gov>

From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] On Behalf Of Joel Sherrill
Sent: Monday, January 06, 2014 12:24 PM
To: John Harwell; rtems-users at rtems.org
Subject: Re: RTEMS Posix lock failure


On 1/6/2014 10:58 AM, John Harwell wrote:
Hello,

When RTEMS entries the Internal_error_Occurred() routine, it is within the context of an ISR, according to the value of _ISR_Nest_level.
After reading the documentation on rtems_fire_after() here<http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ClassicTimer.html#gad9785a6bd78ab5a591a134d147b2bdd3>, I realized that because my function attempts to acquire a global
mutex lock within an ISR context, RTEMS will correctly lockup. Now that I know the cause, restructuring my code should be
relatively simple.
You could use the timer server version of the calls but acquiring a lock potentially could
potentially negatively impact other timers managed by the server.

Thanks for your help,
--
John Harwell
Engineer
High Reliability Software Section
Communications and Embedded Systems Department

john.harwell at swri.org<mailto:john.harwell at swri.org>
Office: 210-522-5965
Southwest Research Institute (SwRI)
6220 Culebra Road, San Antonio, TX 78238-5166



--

Joel Sherrill, Ph.D.             Director of Research & Development

joel.sherrill at OARcorp.com<mailto:joel.sherrill at OARcorp.com>        On-Line Applications Research

Ask me about RTEMS: a free RTOS  Huntsville AL 35805

Support Available                (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140115/04383898/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 21067 bytes
Desc: image003.png
URL: <http://lists.rtems.org/pipermail/users/attachments/20140115/04383898/attachment.png>