<span style="border-collapse:collapse;color:rgb(34, 34, 34);font-family:arial, sans-serif;font-size:13px">Dear Joel,<br><br>
First of all, I would like to thank you for your help. Your answer indeed clarifies me how resources are managed in RTEMS.<br><br>Now the execution continues until a ioctl SIOCGICONF failed in onmiORB, but that's another story, and I feel I'm pretty close to get<br>
Rock running on top of RTEMS :)<br><br>Regarding the binary size, sorry, 32 mb is the output of ls -l (not really indicative). Below is the output of i386-rtems-size:<br><br>i386-rtems-size -x -A message_producer_test<br>
message_producer_test :<br>section size addr<br>.text 0x479764 0x100000<br>.init 0xd 0x579764<br>.fini 0x8 0x579771<br>.rodata 0xc0d20 0x579780<br>
.eh_frame 0x126ce8 0x63a4a0<br>.gcc_except_table 0x5988c 0x761188<br>.ctors 0x2c4 0x7bb000<br>.dtors 0x298 0x7bb2c4<br>.jcr 0x4 0x7bb55c<br>
.data 0x5500 0x7bb560<br>
.bss 0xad20 0x7c0a60<br>.stab 0x653610 0x0<br>.stabstr 0xf3dc93 0x0<br>.comment 0x2b 0x0<br>Total 0x1c5c45b<br><br>Much smaller, although still too big for the Xilinx FPGAs with LEON2. But I'll worry about that later.<br>
<br>Thank you and kind regards,<br>Ana</span><div><font color="#222222" face="arial, sans-serif"><span style="border-collapse:collapse"><br>
</span></font><br><div class="gmail_quote">On Fri, Sep 16, 2011 at 8:47 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@gmail.com" target="_blank">joel.sherrill@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, Sep 16, 2011 at 4:45 AM, Anita <<a href="mailto:ana.vazquez.alonso@gmail.com" target="_blank">ana.vazquez.alonso@gmail.com</a>> wrote:<br>
</div><div>> Hi,<br>
><br>
> I managed to compile and link all the dependencies libraries together<br>
> with RTEMS 4.10.1 and Newlib, producing a final binary of about 32Mb.<br>
<br>
</div>That's rather large. Is that the output of "size" or the file size (e.g. ls -l)<br>
<div><br>
> I run it with QEMU but a problem in runtime arose:<br>
><br>
> The problem happens inside a c++ constructor, called from<br>
> __do_global_ctors_aux (which if I understand it correctly, basically<br>
> call all the constructors from the table of pointers to constructor<br>
> defined in the .ctors section (i386-rtems-objdump -s -j .ctors<br>
> message_producer_test | vim -)).<br>
><br>
> __do_global_ctors_aux is called from RTEMS (_Thread_Handler<br>
> ->INIT_NAME -> _init).<br>
><br>
> The constructor is part of omniORB, omni_mutex::omni_mutex<br>
> (<a href="http://pastebin.com/Pcd50Bni" target="_blank">http://pastebin.com/Pcd50Bni</a>). Inside this constructor, a call to<br>
> pthread_mutex_init is produced.<br>
><br>
> From the gdb log (<a href="http://pastebin.com/QrRxWxse" target="_blank">http://pastebin.com/QrRxWxse</a>) I fear that the<br>
> problem is allocating resources inside pthread_mutex_init, actually in<br>
> objectallocate.c -> chainget.c -> chain.inl.<br>
><br>
> At first, I though the problem was related to RTEMS running out of<br>
> memory (and even tried to increase QEMU memory), but after taking a<br>
> look to chain.inl, I think that the problem may be the omni_mutex<br>
> constructor calling pthread_mutex_init and therefore allocating<br>
> resources before RTEMS is completly ready. Although, RTEMS is the one<br>
> calling __do_global_ctors_aux.<br>
><br>
> I hope any of you can spread some light. In the meantime, what I have<br>
> in mind is modify omniORB and delay the pthread_mutex_init call in<br>
> omni_mutex.<br>
<br>
</div>RTEMS != Linux. :-D<br>
<br>
I am sure that didn't help at all but it is a lead in to try to explain<br>
the philosophical difference between RTEMS and Linux that<br>
lead you to get this error. The error is in fact an out of resources<br>
error. RTEMS was designed for to target systems with hard<br>
resource requirements. In this design view, it is better to preallocate<br>
as much as possible so you don't have to deal with running out<br>
of resources at run-time. This makes the resulting system<br>
safer and less likely to have a weird failure mode in this situation.<br>
<br>
In RTEMS you configure the maximum number of each type of<br>
object you want. The defaults tend to be 0. Memory is reserved<br>
for RTEMS separate from the C Program Heap based upon your<br>
cofniguration requests. The sample in testsuites/samples/ticker<br>
has the following configuration in the file system.h<br>
<br>
============================================<br>
#include <bsp.h> /* for device driver prototypes */<br>
<br>
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER<br>
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER<br>
#define CONFIGURE_MAXIMUM_TASKS 4<br>
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE<br>
#define CONFIGURE_EXTRA_TASK_STACKS (3 * RTEMS_MINIMUM_STACK_SIZE)<br>
<br>
#include <rtems/confdefs.h><br>
============================================<br>
<br>
The application says is needs a console (stdio) and clock tick (time<br>
passage) device drivers. It has 4 Classic API tasks maximum.<br>
It is using a Classic API style initialization task -- the alternative<br>
is a POSIX Threads initialization thread. And each of the tasks<br>
it is creating has a stack larger than the minimum required. So<br>
we reserve some extra memory for those. See the rtems_task_create()<br>
calls in init.c for the stack sizing.<br>
<br>
If you looked at the hello world sample, it wouldn't have the Clock<br>
driver and would only have one task.<br>
<br>
In your case, you need to define CONFIGURE_MAXIMUM_POSIX_MUTEXES<br>
to however many is required.<br>
<br>
With all that background on the hard limit focus on RTEMS configuration,<br>
RTEMS also has an "unlimited object mode" and "unified workspace" option.<br>
This is probably more useful for you at this stage. This lets you configure<br>
that you want a potentially unlimited number of a class of objects and that<br>
you want RTEMS Workspace and the C Program Heap to be the same<br>
pool of memory.<br>
<br>
#define CONFIGURE_MAXIMUM_POSIX_MUTEXES \<br>
rtems_resource_unlimited( 5 )<br>
#defined CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES \<br>
rtems_resource_unlimited( 5 )<br>
#define CONFIGURE_UNIFIED_WORK_AREAS<br>
<br>
That says that POSIX mutexes and condition variables are "unlimited"<br>
but the set is extended 5 instances at a time. Create the sixth and<br>
instances 6-10 will be added to the inactive pool for that object class.<br>
<br>
The full set configuration macros are (hopefully) well documented here:<br>
<br>
<a href="http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/c_user00416.html" target="_blank">http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/c_user00416.html</a><br>
<br>
Also .. any time you see a call from _Objects_Allocate() fail, it is either<br>
a maximum objects issue or not accounting for variable memory like<br>
stack space or message buffers which must be allocated when the<br>
object instance is created.<br>
<br>
Since you are porting a software package, let me throw out another<br>
thought. There is likely a fixed base set of objects the package creates<br>
such as for global mutexes or message queues. A user of package X<br>
will create instances of objects that it defines. So if the package X has<br>
a macaroni object that requires a mutex, condition variable, and<br>
a message queue, then you can let the end user of package X know that<br>
for each macaroni instance, they need to reserve A, B, and C. For certain<br>
cases, like the tasking in Ada and Go, we provide higher level configuration<br>
helpers like CONFIGURE_MAXIMUM_ADA_TASKS to encapsulate this<br>
configuration information.<br>
<br>
I know my answer is a bit over the top but I want you to really understand this<br>
part of RTEMS. Figuring out how many of each kind of object when porting a<br>
software package is always a challenge. Embedded developers focused on<br>
safe, reliable systems don't like surprises and using various techniques to<br>
avoid running out of resources at run-time is a big part of it. It is<br>
not uncommon<br>
for malloc() to be forbidden after system initialization.<br>
<br>
FWIW I would like to clean this up and make it a blog entry for RTEMS.<br>
So if anything is unclear, let's make it clear to you. :)<br>
<font color="#888888"><br>
--joel sherrill<br>
RTEMS<br>
</font><div><div></div><div><br>
<br>
> Kind regards,<br>
> Ana<br>
><br>
> P.S. In order to simplify the understanding of the problem, I attach<br>
> the code from mutexinit.c (<a href="http://pastebin.com/cC6G2UjF" target="_blank">http://pastebin.com/cC6G2UjF</a>), and since<br>
> _Thread_Disable_dispatch(), _POSIX_Mutex_Allocate() and<br>
> _Thread_Enable_dispatch() are inline functions, I also attached the<br>
> unrolled version (<a href="http://pastebin.com/MxwXCCj5" target="_blank">http://pastebin.com/MxwXCCj5</a>).<br>
><br>
</div></div></blockquote></div><br></div>