Re: [Xenomai-help] Problems when cross-compiling Xenomai

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Felipe Brandão Cavalcanti wrote:
> 2010/2/11 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
>> Felipe Brandão Cavalcanti wrote:
>>> 2010/2/11 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.orgom>
>>>
>>>> Felipe Brandão Cavalcanti wrote:
>>>>> 2010/2/11 Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org>
>>>>>> Felipe Brandão Cavalcanti wrote:
>>>>>>> Sending the boot log and the xeno-test output as attachments.
>>>>>> [    0.000000] OMAP clockevent source: GPTIMER12 at 32768 Hz
>>>>>>
>>>>>> Definitely not OK. We do not want this unprecise clockevent source.
>>>>>> Disable it in the kernel configuration (option CONFIG_OMAP_32K_TIMER).
>>>>>>
>>>>>>
>>>>> This is very interesting - this option doesnt seem to be set in my
>>>> current
>>>>> kernel config. Ive attached my .config.
>>>> Selecting GPTIMER 1 should work. But if you get lockups or thing like
>>>> that, please try with a vanilla 2.6.30 to see if you get them.
>>>>
>>>>
>>> Great - changing GPTIMER to 1 did the trick! Gilles, thank you very much!
>>>
>>> Here are the results of the first latency test, under 100% load:
>>>
>>> RTT|  00:08:46  (periodic user-mode task, 1000 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
>>> worst
>>> RTD|     12.999|     13.769|     18.846|       0|     0|     12.538|
>>> 44.692
>>> RTD|     13.076|     13.769|     20.692|       0|     0|     12.538|
>>> 44.692
>>> RTD|     12.923|     13.769|     18.076|       0|     0|     12.538|
>>> 44.692
>>> RTD|     12.846|     13.769|     20.153|       0|     0|     12.538|
>>> 44.692
>>> RTD|     12.999|     13.769|     18.692|       0|     0|     12.538|
>>> 44.692
>>> RTD|     12.999|     13.769|     19.230|       0|     0|     12.538|
>>> 44.692
>>> RTD|     13.076|     13.769|     18.769|       0|     0|     12.538|
>>> 44.692
>>> RTD|     13.076|     13.769|     19.153|       0|     0|     12.538|
>>> 44.692
>>> RTD|     12.846|     13.769|     19.999|       0|     0|     12.538|
>>> 44.692
>>>
>>> BTW, the system does seem a lot more stable now - no random errors. I
>> will
>>> run some more tests, and will send in the results later - I will document
>>> the procedure and post it online once we get Xenomai running well in the
>>> IGEPv2.
>> Ok. Good news. I would have liked to find out what was this building
>> issue of yours, at least to be able to use your rootfs build system
>> instead of building xenomai manually.
>>
>>
> In the end, I did get it to work with my build system (bitbake, running on
> the standard IGEP virtual machine) - I modified the configuration files so
> the
> ASNEEDED = "-Wl,--as-needed"
> became
> ASNEEDED = ""

Could you try re-enabling --as-needed with the following patch?

diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
index f4826ac..09944f5 100755
--- a/scripts/wrap-link.sh
+++ b/scripts/wrap-link.sh
@@ -34,7 +34,14 @@ add_linker_flag() {
        stage1_args="$stage1_args -Wl,--wrap $@"
        next_is_wrapped_symbol=false
     else
-       add_2stages "$@"
+       case "$@" in
+       *--as-needed*)
+               stage2_args="$stage2_args $@"
+               ;;
+       *)
+               add_2stages "$@"
+               ;;
+       esac
     fi
 }


> 
> Xenomai builds cleanly afterwards, even with the modified optimization
> flags.
> I am attaching the bitbake file I used for reference.
> 
> The challenge is getting the IGEP running cleanly now - if the network is
> connected, the systems becomes unstable and crashes randomly, and MMC/SDIO
> (and therefore, Wifi) support is disabled. I am attempting to get the
> patches individually from the folks at ISEE (the makers of the IGEP board)
> so I can get a clean system running. I need a rock-solid system for this
> project - our lab is building a small UAV, and the IGEP with Xenomai is
> going to be the central controller.

Ok. Please test the I-pipe patch for 2.6.30. In another mail which you
may have missed, I sent you a patch which adds basic IGEP support to
2.6.32. You can probably use that patch to get basic IGEP support on
2.6.30. This is not a definitive solution, it is just a test to see if
either something in the android kernel is incompatible with Xenomai, or
if you are having a problem with the I-pipe patch for 2.6.28.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com