From mboxrd@z Thu Jan 1 00:00:00 1970 Resent-Message-ID: <20140612074411.GG18962@lukather> Resent-To: xenomai@xenomai.org Date: Tue, 10 Jun 2014 11:54:22 +0200 From: Maxime Ripard Message-ID: <20140610095422.GK9791@lukather> References: <20140606135912.GJ5765@lukather> <20140606140031.GK5765@lukather> <539322FA.5030004@xenomai.org> <20140610094057.GJ9791@lukather> <5396D469.7060701@xenomai.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5396D469.7060701@xenomai.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Michael Opdenacker , Thomas Petazzoni , Boris Brezillon , Alexandre Belloni , xenomai@xenomai.org, Antoine =?iso-8859-1?Q?T=E9nart?= 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 -- 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: