[Xenomai] Support of Beagleboard xm rev C on 3.14-ipipe

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Thu Jun 26 13:08:17 CEST 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/26/2014 09:56 AM, Arnaud Degroote wrote:
> On 26/Jun - 00:23, Gilles Chanteperdrix wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/25/2014 11:47 AM, Arnaud Degroote wrote:
>>> On 25/Jun - 10:37, Gilles Chanteperdrix wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> On 06/25/2014 10:11 AM, Arnaud Degroote wrote:
>>>>> On 24/Jun - 20:31, Gilles Chanteperdrix wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>> 
>>>>>> On 06/24/2014 02:21 PM, Arnaud Degroote wrote:
>>>>>>> On 24/Jun - 08:29, Gilles Chanteperdrix wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>>>> 
>>>>>>>> On 06/24/2014 08:23 AM, Arnaud Degroote wrote:
>>>>>>>>> On 24/Jun - 01:45, Gilles Chanteperdrix wrote:
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>>>>>> 
>>>>>>>>>> On 06/23/2014 01:18 PM, Arnaud Degroote wrote:
>>>>>>>>>>> On 23/Jun - 11:22, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 06/23/2014 11:08 AM, Arnaud Degroote
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi list,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm trying to deploy a 3.14 kernel on my 
>>>>>>>>>>>>> BeagleBoard XM rev C but got several
>>>>>>>>>>>>> issues. So, first question, it is supposed
>>>>>>>>>>>>> to be supported or am I somewhere in a grey
>>>>>>>>>>>>> zone ?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Let describe more precisely the
>>>>>>>>>>>>> configuration and the symptom. -
>>>>>>>>>>>>> linux-ipipe branch ipipe-3.14 - xenomai
>>>>>>>>>>>>> 2.6.3 + some patches from 2.6 branch
>>>>>>>>>>>>> (including 
>>>>>>>>>>>>> d1d00e0acd29bb5f9023494a883a7fa0def40917 
>>>>>>>>>>>>> 41cb1f73814d1094e0ea75ccbbd23ff01280787e 
>>>>>>>>>>>>> 7a48019268d7e1157ebb072b88f6683425f0c7c5 
>>>>>>>>>>>>> f00d22eca6277e780c19a5d5ecd2ed0e23dabafe )
>>>>>>>>>>>> 
>>>>>>>>>>>> It is supposed to work, could you try again
>>>>>>>>>>>> with the xenomai 2.6 git?
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi Gilles,
>>>>>>>>>>> 
>>>>>>>>>>> I just tested against 2.6-git and observe the
>>>>>>>>>>> same behaviours.
>>>>>>>>>>> 
>>>>>>>>>>> Best regards,
>>>>>>>>>>> 
>>>>>>>>>> Could you post your configuration?
>>>>>>>>> 
>>>>>>>>> Sure, see the attached defconfig. It is basically 
>>>>>>>>> yocto base arm kernel + xenomai (and some kernel 
>>>>>>>>> hacking option).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> Could you try to turn off CONFIG_NO_HZ ?
>>>>>>> 
>>>>>>> Without CONFIG_NO_HZ, it hangs repeatably during the
>>>>>>> boot (in the same place than with CONFIG_NO_HZ without
>>>>>>>  CONFIG_DEBUG_LOCK_ALLOC, so this last option is more
>>>>>>> a timing workaround than a "real fix"). See the
>>>>>>> attached defconfig and boot log.
>>>>>> 
>>>>>> Do you have the same problem if you boot using NFS
>>>>>> instead of an SD card?
>>>>>> 
>>>>> 
>>>>> Using root on nfs does not seem to change the problem. It 
>>>>> still hangs in the same place.
>>>> 
>>>> Ok, could you disable FTRACE, then enable the I-pipe debugs 
>>>> except the I-pipe tracer? And enable all the xenomai debugs?
>>>> 
>>> 
>>> Without FTRACE, the kernel seems to boot successfully quite
>>> often (I won't say always still). Moreover, the clocktest now
>>> terminates. Still, the latency hangs, without much debug
>>> information (maybe I miss some options in the kernel
>>> configuration or at runtime). At this moment,
>>> /proc/xenomai/sched shows
>>> 
>>> root at beagleboard:~# cat /proc/xenomai/sched CPU  PID    CLASS
>>> PRI TIMEOUT   TIMEBASE   STAT       NAME 0  0      idle    -1
>>> - master     R          ROOT 0  391    rt       0      - master
>>> X          switchtest 0  392    rt       0      - master     X
>>> switchtest 0  405    rt       0      - master     X
>>> display-393 0  406    rt      99      481us master     Dt
>>> sampling-393 0  0      rt       1      - master     Wl
>>> rtk1/0 0  0      rt       1      - master     Wl         rtk2/0
>>> 0  0      rt       1      - master     Wlf        rtk3/0 0  0
>>> rt       1      - master     Wlf        rtk4/0 0  0      rt
>>> 1      - master     Wlf        rtk5/0 0  0      rt       1
>>> - master     Wlf        rtk6/0 0  0      rt       1      - 
>>> master     Wl         rtk1/0 0  0      rt       1      - master
>>> Wl         rtk2/0 0  0      rt       1      - master     Wlf
>>> rtk3/0 0  0      rt       1      - master     Wlf        rtk4/0
>>> 0  0      rt       1      - master     Wlf        rtk5/0 0  0
>>> rt       1      - master     Wlf        rtk6/0 0  417    rt
>>> 1      - master     Wl         rtup0-7 0  419    rt       1
>>> - master     Wl         rtup0-7 0  420    rt       1      - 
>>> master     Wl         rtup0-8 0  421    rt       1      - 
>>> master     Wl         rtup0-8 0  422    rt       1      - 
>>> master     Wl         rtup_ufpp0-9 0  423    rt       1      - 
>>> master     Wl         rtup_ufpp0-9 0  424    rt       1      - 
>>> master     Wl         rtup_ufpp0-10 0  426    rt       1
>>> - master     Wl         rtup_ufpp0-10 0  427    rt       1
>>> - master     X          rtus0-11 0  428    rt       1      - 
>>> master     X          rtus0-11 0  429    rt       1      - 
>>> master     X          rtus0-12 0  430    rt       1      - 
>>> master     X          rtus0-12 0  432    rt       1      - 
>>> master     X          rtus_ufps0-13 0  433    rt       1
>>> - master     X          rtus_ufps0-13 0  434    rt       1
>>> - master     X          rtus_ufps0-14 0  435    rt       1
>>> - master     X          rtus_ufps0-14 0  436    rt       1
>>> - master     X          rtuo0-15 0  437    rt       1      - 
>>> master     X          rtuo0-15 0  438    rt       1      - 
>>> master     X          rtuo0-16 0  439    rt       1      - 
>>> master     X          rtuo0-16 0  440    rt       1      - 
>>> master     X          rtuo_ufpp0-17 0  441    rt       1
>>> - master     X          rtuo_ufpp0-17 0  442    rt       1
>>> - master     Wl         rtuo_ufpp0-18 0  443    rt       1
>>> - master     X          rtuo_ufpp0-18 0  444    rt       1
>>> - master     Wl         rtuo_ufps0-19 0  445    rt       1
>>> - master     X          rtuo_ufps0-19 0  446    rt       1
>>> - master     Wl         rtuo_ufps0-20 0  447    rt       1
>>> - master     X          rtuo_ufps0-20 0  448    rt       1
>>> - master     Wl         rtuo_ufpp_ufps0-21 0  450    rt
>>> 1 -         master     X          rtuo_ufpp_ufps0-21 0  451
>>> rt 1      -         master     Wl         rtuo_ufpp_ufps0-22 0
>>> 452 rt       1      -         master     X
>>> rtuo_ufpp_ufps0-22
>> 
>> You are not just running latency, you are running latency and
>> switchtest.
>> 
>> Could you try and run the latency test alone? Please proceed one
>> step at a time.
> 
> Yes, sorry for that, I use xeno-regression-test directly.
> 
> latency seems to work properly. switchtest with the default
> argument hangs quite fast. switchtest -s 1000 seems to survive long
> time.
> 
> Concerning your previous mail, any easy way to test GP timer I'm
> not aware about or must I write some kind of test kernel module ?
> 
If the latency test works, the GP timer works, no need to test it.

switchtest is another story. Does switchtest hang, or does the system
completely freeze?

- -- 
                                                                Gilles.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iD8DBQFTq/8gGpcgE6m/fboRAgdJAJ9k6eNKf4PPg8D7FnPBTkyhjpHQwQCdENSi
J7NFzAo9wo+TVn3nlGEUbUM=
=LFtL
-----END PGP SIGNATURE-----




More information about the Xenomai mailing list