From mboxrd@z Thu Jan 1 00:00:00 1970 Resent-Message-ID: <20140612074411.GE18962@lukather> Resent-To: xenomai@xenomai.org Date: Tue, 10 Jun 2014 11:10:28 +0200 From: Maxime Ripard Message-ID: <20140610091028.GH9791@lukather> References: <20140606135912.GJ5765@lukather> <20140606140031.GK5765@lukather> <539322FA.5030004@xenomai.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <539322FA.5030004@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 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? Yes, it does. -- 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: