[Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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?

Yep, with the exact same config, except for CONFIG_IPIPE and
CONFIG_XENOMAI being disabled, it boots fine.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140611/6f791842/attachment.sig>