[Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/10/2014 12:01 PM, Gilles Chanteperdrix wrote:
> On 06/10/2014 11:54 AM, Maxime Ripard wrote:
>> On Tue, Jun 10, 2014 at 11:48:25AM +0200, Gilles Chanteperdrix 
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 06/10/2014 11:40 AM, Maxime Ripard wrote:
>>>> On Sat, Jun 07, 2014 at 04:34:34PM +0200, Gilles
>>>> Chanteperdrix wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> 
>>>>> On 06/06/2014 04:00 PM, Maxime Ripard wrote:
>>>>>> On Fri, Jun 06, 2014 at 03:59:12PM +0200, Maxime Ripard 
>>>>>> wrote:
>>>>>>> Hi Gilles,
>>>>>>> 
>>>>>>> I've been experimenting these days with the i-pipe 3.14
>>>>>>>  kernel, and current xenomai master branch on the Atmel
>>>>>>>  SAMA5D3 SoC.
>>>>>>> 
>>>>>>> There's a few issues there, the first one being that 
>>>>>>> at91_ipipe_early_init crashes because of a NULL pointer
>>>>>>>  dereference. This is due to the clk_get_rate call on
>>>>>>> the clock returned by clk_get(NULL, "mck").
>>>>>>> 
>>>>>>> This clk_get call cannot since 3.14 because the clock 
>>>>>>> code has been rewritten, and you can't use clkdev 
>>>>>>> anymore.
>>>>>>> 
>>>>>>> This is quite simple to fix, and after actually fixing 
>>>>>>> it, you get a more interesting issue: either the
>>>>>>> timers or the interrupts don't work at all.
>>>>>>> 
>>>>>>> The first symptom is that it get stuck at the delay
>>>>>>> loop calibration. Setting the loops per jiffy in the
>>>>>>> command line make the boot go further, until the switch
>>>>>>> to the ipipe_tsc clocksource. This actually makes me
>>>>>>> think that it's more the timers that are broken rather
>>>>>>> than the interrupts. Changing the timer counter block
>>>>>>> doesn't solve anything.
>>>>>>> 
>>>>>>> Do you have an idea of what could be going on?
>>>>>> 
>>>>>> 
>>>>>> Actually, the boot seem just to be *much* slower, so
>>>>>> maybe the timers are working after all, but it's just yet
>>>>>> another issue with the clocks.
>>>>>> 
>>>>> Does __ipipe_tsc_update get called in Linux timer
>>>>> interrupt?
>>>> 
>>>> Here is what's happening: http://pastebin.com/m2mz66pU
>>>> 
>>>> You can see that at line 35, the timer interrupt (a spurious 
>>>> one?) gets called, and calls __ipipe_tsc_update. At that
>>>> point, ipipe_tsc_value seems to be NULL, and hence
>>>> __ipipe_tsc_update returns.
>>>> 
>>>> The thing is, the timer interrupt doesn't seem to be called 
>>>> again. The fact that it was actually called once makes me
>>>> think that it's rather the timer clock that is not running...
>>>> I will dig into it.
>>> 
>>> If you have CONFIG_NO_HZ enabled, try to turn it off.
> 
>> CONFIG_NO_HZ is disabled, here is the full config: 
>> http://pastebin.com/fmVGTX4W
> 
> If you compile the kernel without I-pipe and Xenomai support and 
> enable the tcb_clksrc clocksource driver does it work?

Looking at this code, I see that some AT91s, presumably the recent
ones, have a 32 bits counter. at91_ipipe.c will not work correctly
with these. Could you check in the processor datasheet the width of
its TC?
That said, it should only be a problem for the timer, not for the
clock source, and the timer only starts being used when a Xenomai task
is started, since Linux has its own timer separated from the one of
Xenomai on these processors.

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

iD8DBQFTlt9dGpcgE6m/fboRAn8bAJsG9Y7AsmKy6w9jTgtTqahNSYc/QwCfapta
nOA9PdPD5T9mgnIGSmWz3b4=
=GpC+
-----END PGP SIGNATURE-----