[Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

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?

You'll find the boot logs here: http://pastebin.com/58N20Xxs

Thanks,
Maxime

-- 
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/20140606/f4df2197/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

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.

-- 
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/20140606/c0fe2f80/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

On 06/06/2014 03:59 PM, 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.

Well, it works on AT91. (RM9200 and SMA9263). What you are doing with
SAMA5D3 here is actually a port to a new platform.

> 
> 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?

See:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting


-- 
                                                                Gilles.

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

On 06/06/2014 08:03 PM, Alexandre Belloni wrote:
> Hi,
> 
> On 06/06/2014 at 19:52:13 +0200, Gilles Chanteperdrix wrote :
>> On 06/06/2014 03:59 PM, 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.
>>
>> Well, it works on AT91. (RM9200 and SMA9263). What you are doing with
>> SAMA5D3 here is actually a port to a new platform.
>>
> 
> Hum, I'm currently finishing to port both rm9200 and 9263 to the common
> clock framework. It is then totally possible that this will also break
> on those platforms...

We will cross that bridge when we come to it. Adapting to this kind of
changes is what means maintaining the I-pipe for an architecture. Doing
a one-shot port of the I-pipe patch is easy, maintaining it is the hard
part of the job, not hard as in tricky, but hard as in boringly Sisyphean.

> 
> Side question: do you actually own/have access to an rm9200 based board?
> 
Yes, I do, a Cogent CSB637 which was donated by Bill Gatliff. Every
Xenomai release is tested on it.

-- 
                                                                Gilles.

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

-----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?

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

iD8DBQFTkyL6GpcgE6m/fboRAgY7AJ9hrv0rlm8Ro3QtkPzGo8PkI7PuiwCgiByo
aRY9b5jrrJWATnnoji9ybpY=
=1K3F
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/06/2014 03:59 PM, 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.

Maybe the cortex A5 has some integrated timers, like A9, which would
be certainly more interesting to use than a TC. The TC is a 16 bits
free-running counter which we have to run at a low frequency (as close
as possible to 1 MHz) to avoid it to wrap too fast.

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

iD8DBQFTlGUsGpcgE6m/fboRAvsAAJ9+uXUZ65m6ugesmxrtcftEusWiBACfV9H3
JcUDQU0g2fnyiaALPJU6uos=
=2Hdm
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Fri, Jun 06, 2014 at 07:52:13PM +0200, Gilles Chanteperdrix wrote:
> On 06/06/2014 03:59 PM, 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.
> 
> Well, it works on AT91. (RM9200 and SMA9263). What you are doing with
> SAMA5D3 here is actually a port to a new platform.

Not really. The SAMA5D3 is the latest evolution of the AT91, and the
only major difference is that it's now using a Cortex-A5, but it's
mostly the same.

The only major difference I can find is that like all the recent AT91
SoCs, it's using the common clock framework in Linux, while the 9200
and the 9263 are still using the old API.

Maxime

-- 
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/20140610/cfb987d4/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/10/2014 10:19 AM, Maxime Ripard wrote:
> On Fri, Jun 06, 2014 at 07:52:13PM +0200, Gilles Chanteperdrix
> wrote:
>> On 06/06/2014 03:59 PM, 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.
>> 
>> Well, it works on AT91. (RM9200 and SMA9263). What you are doing
>> with SAMA5D3 here is actually a port to a new platform.
> 
> Not really. The SAMA5D3 is the latest evolution of the AT91, and
> the only major difference is that it's now using a Cortex-A5, but
> it's mostly the same.
> 
> The only major difference I can find is that like all the recent
> AT91 SoCs, it's using the common clock framework in Linux, while
> the 9200 and the 9263 are still using the old API.

What I mean is that from the I-pipe patch point of view, this is a new
processor, and you should not presume too much. Also note that since
3.14, the I-pipe patch uses the atmel tclib
(drivers/misc/atmel_tclib.c), which uses clk_get and friends, so, if
clk_get does not work for this new processor, the tclib will not work
either.


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

iD8DBQFTlsZkGpcgE6m/fboRAuTkAJ4/nRXsSenQLiY1Itg0Zi9P4kzjBACfX6vl
WP6TyMkZUC7ZG2W31q/EG6k=
=WXmJ
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

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: <http://www.xenomai.org/pipermail/xenomai/attachments/20140610/74ed7cfb/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

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.

Maxime

-- 
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/20140610/74ddf006/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

-----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.


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

iD8DBQFTltRpGpcgE6m/fboRAosdAKCakVEIzo8EFCOdul4jF4T15U6mFgCfe/0J
gRIPB/0xWXk4/UiUyrn10N8=
=HcDt
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

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: <http://www.xenomai.org/pipermail/xenomai/attachments/20140610/c1fb2581/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

-----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?

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

iD8DBQFTlteAGpcgE6m/fboRAlMrAJ9Vbi6jmURQNiUg0jo6pYABOYaXGgCeMw8p
2hdc5SX8OG0SYPaUI/OGQI0=
=LG2j
-----END PGP SIGNATURE-----

Re: [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-----

Re: [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>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/11/2014 11:25 AM, Maxime Ripard wrote:
> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles Chanteperdrix
> wrote:
>> 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.
> 
Read again, I am not insterested in exactly the same config, I am
interested in the a config with tcb_clksrc clocksource, which is
disabled by CONFIG_IPIPE. Only if you enable this clocksource do you
get to use the atmel_tclib code.

Also, it would be nice if you could subscribe to the mailing list,
(and bounce all the messages you have sent so far to the mailing
list), so that mailing list users do not read only my answers.
Otherwise what you do is equivalent to using my personal e-mail
address for Xenomai questions, and usually, I do not answer such
questions.

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

iD8DBQFTmJzvGpcgE6m/fboRAtk8AJ9H4b3KDZJgQ57p0cHXHgs+oe4laQCeJ8nx
mTHbu4RuHYCDbUYkvevG0MY=
=9GGv
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/11/2014 08:16 PM, Gilles Chanteperdrix wrote:
> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles Chanteperdrix 
>> wrote:
>>> 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.
> 
> Read again, I am not insterested in exactly the same config, I am 
> interested in the a config with tcb_clksrc clocksource, which is 
> disabled by CONFIG_IPIPE. Only if you enable this clocksource do
> you get to use the atmel_tclib code.

The corresponding config option is:
CONFIG_ATMEL_TCB_CLKSRC

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

iD8DBQFTmKYdGpcgE6m/fboRAjAeAJ9TgL0dxVm0pUl+jOCber1VGy5K7QCdFTRS
L55laOAlOFDmhzGeYx7o5mw=
=1JO0
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
> > On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles Chanteperdrix
> > wrote:
> >> 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.
> > 
> Read again, I am not insterested in exactly the same config, I am
> interested in the a config with tcb_clksrc clocksource, which is
> disabled by CONFIG_IPIPE. Only if you enable this clocksource do you
> get to use the atmel_tclib code.

Let me rephrase then. It works with the exact same config, with
CONFIG_IPIPE and CONFIG_XENOMAI disabled, and CONFIG_ATMEL_TCB_CLKSRC
enabled.

> Also, it would be nice if you could subscribe to the mailing list,
> (and bounce all the messages you have sent so far to the mailing
> list), so that mailing list users do not read only my answers.
> Otherwise what you do is equivalent to using my personal e-mail
> address for Xenomai questions, and usually, I do not answer such
> questions.

Done.

-- 
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/20140612/d33fe2e2/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/12/2014 09:54 AM, Maxime Ripard wrote:
> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles Chanteperdrix 
>>> wrote:
>>>> 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.
>>> 
>> Read again, I am not insterested in exactly the same config, I
>> am interested in the a config with tcb_clksrc clocksource, which
>> is disabled by CONFIG_IPIPE. Only if you enable this clocksource
>> do you get to use the atmel_tclib code.
> 
> Let me rephrase then. It works with the exact same config, with 
> CONFIG_IPIPE and CONFIG_XENOMAI disabled, and
> CONFIG_ATMEL_TCB_CLKSRC enabled.

Then I would tend to think that the clocksource is not your problem
and repeat that you should check everything else in the porting guide.

> 
>> Also, it would be nice if you could subscribe to the mailing
>> list, (and bounce all the messages you have sent so far to the
>> mailing list), so that mailing list users do not read only my
>> answers. Otherwise what you do is equivalent to using my personal
>> e-mail address for Xenomai questions, and usually, I do not
>> answer such questions.
> 
> Done.


Thanks.


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

iD8DBQFTmWa3GpcgE6m/fboRAje5AKCaWLggwYx8nCybNJOEKyiLXva23QCgmzVh
Zv2PM8L9khkowVFrqQYNz1A=
=Sy3S
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
> > On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
> >>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles Chanteperdrix 
> >>> wrote:
> >>>> 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.
> >>> 
> >> Read again, I am not insterested in exactly the same config, I
> >> am interested in the a config with tcb_clksrc clocksource, which
> >> is disabled by CONFIG_IPIPE. Only if you enable this clocksource
> >> do you get to use the atmel_tclib code.
> > 
> > Let me rephrase then. It works with the exact same config, with 
> > CONFIG_IPIPE and CONFIG_XENOMAI disabled, and
> > CONFIG_ATMEL_TCB_CLKSRC enabled.
> 
> Then I would tend to think that the clocksource is not your problem
> and repeat that you should check everything else in the porting guide.

Ok. I will.

-- 
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/20140612/e06defff/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/12/2014 05:03 PM, Maxime Ripard wrote:
> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix 
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles
>>>>> Chanteperdrix wrote:
>>>>>> 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.
>>>>> 
>>>> Read again, I am not insterested in exactly the same config,
>>>> I am interested in the a config with tcb_clksrc clocksource,
>>>> which is disabled by CONFIG_IPIPE. Only if you enable this
>>>> clocksource do you get to use the atmel_tclib code.
>>> 
>>> Let me rephrase then. It works with the exact same config, with
>>>  CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
>>> CONFIG_ATMEL_TCB_CLKSRC enabled.
>> 
>> Then I would tend to think that the clocksource is not your
>> problem and repeat that you should check everything else in the
>> porting guide.
> 
> Ok. I will.
> 

On my side, I will try and remove the need for at91_ipipe_early_init,
and get the timer working for 32 bits (I will need you to test the
changes though).

Regards.

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

iD8DBQFTmeoHGpcgE6m/fboRArhMAJ40cqsbhicNdGy+lPS3Nly9kOA8mACeOgej
AXzD+c4QrabVxI1rU16xzpA=
=628w
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/12/2014 07:57 PM, Gilles Chanteperdrix wrote:
> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
>> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix 
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
>>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles
>>>> Chanteperdrix wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> 
>>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles 
>>>>>> Chanteperdrix wrote:
>>>>>>> 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.
>>>>>> 
>>>>> Read again, I am not insterested in exactly the same
>>>>> config, I am interested in the a config with tcb_clksrc
>>>>> clocksource, which is disabled by CONFIG_IPIPE. Only if you
>>>>> enable this clocksource do you get to use the atmel_tclib
>>>>> code.
>>>> 
>>>> Let me rephrase then. It works with the exact same config,
>>>> with CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
>>>> CONFIG_ATMEL_TCB_CLKSRC enabled.
>>> 
>>> Then I would tend to think that the clocksource is not your 
>>> problem and repeat that you should check everything else in
>>> the porting guide.
> 
>> Ok. I will.
> 
> 
> On my side, I will try and remove the need for
> at91_ipipe_early_init, and get the timer working for 32 bits (I
> will need you to test the changes though).

I have pushed these changes in the for-ipipe-3.14.0 branch in the
ipipe-gch.git repository.

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

iD8DBQFTmjCpGpcgE6m/fboRAsixAJ9btQ1BUrjESV8KA+9WN694v982YACeOw1B
Glx+PBux74mGWtB3U24o7RE=
=S5v3
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/12/2014 05:03 PM, Maxime Ripard wrote:
> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix 
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles
>>>>> Chanteperdrix wrote:
>>>>>> 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.
>>>>> 
>>>> Read again, I am not insterested in exactly the same config,
>>>> I am interested in the a config with tcb_clksrc clocksource,
>>>> which is disabled by CONFIG_IPIPE. Only if you enable this
>>>> clocksource do you get to use the atmel_tclib code.
>>> 
>>> Let me rephrase then. It works with the exact same config, with
>>>  CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
>>> CONFIG_ATMEL_TCB_CLKSRC enabled.
>> 
>> Then I would tend to think that the clocksource is not your
>> problem and repeat that you should check everything else in the
>> porting guide.
> 
> Ok. I will.
> 
Looking rapidly at the code, at least the irq controller and pic
muting need fixing.

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

iD8DBQFTm0qFGpcgE6m/fboRArm4AJ9JKm3PgeI/U2k5vqeUupLJAIbZggCfclJI
aTIR7vlfV+L81Zo9B3Ym2bo=
=y0HF
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Fri, Jun 13, 2014 at 09:01:25PM +0200, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
> > On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
> >>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix 
> >>> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>> 
> >>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
> >>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles
> >>>>> Chanteperdrix wrote:
> >>>>>> 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.
> >>>>> 
> >>>> Read again, I am not insterested in exactly the same config,
> >>>> I am interested in the a config with tcb_clksrc clocksource,
> >>>> which is disabled by CONFIG_IPIPE. Only if you enable this
> >>>> clocksource do you get to use the atmel_tclib code.
> >>> 
> >>> Let me rephrase then. It works with the exact same config, with
> >>>  CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
> >>> CONFIG_ATMEL_TCB_CLKSRC enabled.
> >> 
> >> Then I would tend to think that the clocksource is not your
> >> problem and repeat that you should check everything else in the
> >> porting guide.
> > 
> > Ok. I will.
> > 
> Looking rapidly at the code, at least the irq controller and pic
> muting need fixing.

Yep, we've been adapting the irq controller code for the AIC5
yesterday, and it indeed boots up to the userspace.

However, during heavy loads, the system just hangs. I'll take a look
at this and the pic muting next week.

Maxime 

-- 
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/20140617/9b010d45/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Fri, Jun 13, 2014 at 09:01:25PM +0200, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
> > On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
> >>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles Chanteperdrix 
> >>> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>> 
> >>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
> >>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles
> >>>>> Chanteperdrix wrote:
> >>>>>> 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.
> >>>>> 
> >>>> Read again, I am not insterested in exactly the same config,
> >>>> I am interested in the a config with tcb_clksrc clocksource,
> >>>> which is disabled by CONFIG_IPIPE. Only if you enable this
> >>>> clocksource do you get to use the atmel_tclib code.
> >>> 
> >>> Let me rephrase then. It works with the exact same config, with
> >>>  CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
> >>> CONFIG_ATMEL_TCB_CLKSRC enabled.
> >> 
> >> Then I would tend to think that the clocksource is not your
> >> problem and repeat that you should check everything else in the
> >> porting guide.
> > 
> > Ok. I will.
> > 
> Looking rapidly at the code, at least the irq controller and pic
> muting need fixing.

Ok, so, a bit of news on this one.

After fixing the irq controller to work on the AIC5, and disabling the
pic muting, I get almost 100% of the time a system freeze when running:
http://git.free-electrons.com/training-materials/tree/lab-data/realtime/rttest/data/rttest.c

The TCB timer is still ticking, at a rate around 1Hz, while, when the
system hangs, the PIT interrupt isn't firing anymore (which explains
the freeze). So there's probably something wrong related to the ipipe
I guess, or the interrupt being masked and not unmasked at some point.

Maxime

-- 
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/20140623/04d18955/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/23/2014 04:05 PM, Maxime Ripard wrote:
> On Fri, Jun 13, 2014 at 09:01:25PM +0200, Gilles Chanteperdrix
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
>>> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix 
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
>>>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles
>>>>> Chanteperdrix wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>> 
>>>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles 
>>>>>>> Chanteperdrix wrote:
>>>>>>>> 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.
>>>>>>> 
>>>>>> Read again, I am not insterested in exactly the same
>>>>>> config, I am interested in the a config with tcb_clksrc
>>>>>> clocksource, which is disabled by CONFIG_IPIPE. Only if
>>>>>> you enable this clocksource do you get to use the
>>>>>> atmel_tclib code.
>>>>> 
>>>>> Let me rephrase then. It works with the exact same config,
>>>>> with CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
>>>>> CONFIG_ATMEL_TCB_CLKSRC enabled.
>>>> 
>>>> Then I would tend to think that the clocksource is not your 
>>>> problem and repeat that you should check everything else in
>>>> the porting guide.
>>> 
>>> Ok. I will.
>>> 
>> Looking rapidly at the code, at least the irq controller and pic 
>> muting need fixing.
> 
> Ok, so, a bit of news on this one.
> 
> After fixing the irq controller to work on the AIC5, and disabling
> the pic muting, I get almost 100% of the time a system freeze when
> running: 
> http://git.free-electrons.com/training-materials/tree/lab-data/realtime/rttest/data/rttest.c
>
>  The TCB timer is still ticking, at a rate around 1Hz, while, when
> the system hangs, the PIT interrupt isn't firing anymore (which
> explains the freeze). So there's probably something wrong related
> to the ipipe I guess, or the interrupt being masked and not
> unmasked at some point.

Well:
- - the existing at91 I test also use a PIT and they do not hang
- - if you disabled the pic muting, noone is disabling the PIT interrupt.

So, I would suggest looking carefully at the sama5 code.


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

iD8DBQFTqLvWGpcgE6m/fboRAp5FAJ9y5zAf4XepeniEnTiJaC+v0agd2ACeJ+Ik
kdQm/r7vdpSbsWQ7RYxJjCo=
=ix8/
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/24/2014 01:44 AM, Gilles Chanteperdrix wrote:
> On 06/23/2014 04:05 PM, Maxime Ripard wrote:
>> On Fri, Jun 13, 2014 at 09:01:25PM +0200, Gilles Chanteperdrix 
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
>>>> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles
>>>> Chanteperdrix wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> 
>>>>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
>>>>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles 
>>>>>> Chanteperdrix wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>>> 
>>>>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>>>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles 
>>>>>>>> Chanteperdrix wrote:
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>> Read again, I am not insterested in exactly the same 
>>>>>>> config, I am interested in the a config with
>>>>>>> tcb_clksrc clocksource, which is disabled by
>>>>>>> CONFIG_IPIPE. Only if you enable this clocksource do
>>>>>>> you get to use the atmel_tclib code.
>>>>>> 
>>>>>> Let me rephrase then. It works with the exact same
>>>>>> config, with CONFIG_IPIPE and CONFIG_XENOMAI disabled,
>>>>>> and CONFIG_ATMEL_TCB_CLKSRC enabled.
>>>>> 
>>>>> Then I would tend to think that the clocksource is not your
>>>>>  problem and repeat that you should check everything else
>>>>> in the porting guide.
>>>> 
>>>> Ok. I will.
>>>> 
>>> Looking rapidly at the code, at least the irq controller and
>>> pic muting need fixing.
> 
>> Ok, so, a bit of news on this one.
> 
>> After fixing the irq controller to work on the AIC5, and
>> disabling the pic muting, I get almost 100% of the time a system
>> freeze when running: 
>> http://git.free-electrons.com/training-materials/tree/lab-data/realtime/rttest/data/rttest.c
>
>>  The TCB timer is still ticking, at a rate around 1Hz, while,
>> when the system hangs, the PIT interrupt isn't firing anymore
>> (which explains the freeze). So there's probably something wrong
>> related to the ipipe I guess, or the interrupt being masked and
>> not unmasked at some point.
> 
> Well: - the existing at91 I test also use a PIT and they do not
> hang - if you disabled the pic muting, noone is disabling the PIT
> interrupt.
> 
> So, I would suggest looking carefully at the sama5 code.

You could also post this code for review, BTW. Unless I am mistaken
about your company, you do not want to keep it secret anyway ;-)

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

iD8DBQFTqRcnGpcgE6m/fboRAvB+AJ4rZEZV99GYI7PF/HIQbyLA/WsxCgCfXtRL
j4qfz3wQSKh43WbqQqeYf00=
=5WYK
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Tue, Jun 24, 2014 at 01:44:22AM +0200, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/23/2014 04:05 PM, Maxime Ripard wrote:
> > On Fri, Jun 13, 2014 at 09:01:25PM +0200, Gilles Chanteperdrix
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
> >>> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles Chanteperdrix 
> >>> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>> 
> >>>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
> >>>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles
> >>>>> Chanteperdrix wrote:
> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>>> 
> >>>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
> >>>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles 
> >>>>>>> Chanteperdrix wrote:
> >>>>>>>> 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.
> >>>>>>> 
> >>>>>> Read again, I am not insterested in exactly the same
> >>>>>> config, I am interested in the a config with tcb_clksrc
> >>>>>> clocksource, which is disabled by CONFIG_IPIPE. Only if
> >>>>>> you enable this clocksource do you get to use the
> >>>>>> atmel_tclib code.
> >>>>> 
> >>>>> Let me rephrase then. It works with the exact same config,
> >>>>> with CONFIG_IPIPE and CONFIG_XENOMAI disabled, and 
> >>>>> CONFIG_ATMEL_TCB_CLKSRC enabled.
> >>>> 
> >>>> Then I would tend to think that the clocksource is not your 
> >>>> problem and repeat that you should check everything else in
> >>>> the porting guide.
> >>> 
> >>> Ok. I will.
> >>> 
> >> Looking rapidly at the code, at least the irq controller and pic 
> >> muting need fixing.
> > 
> > Ok, so, a bit of news on this one.
> > 
> > After fixing the irq controller to work on the AIC5, and disabling
> > the pic muting, I get almost 100% of the time a system freeze when
> > running: 
> > http://git.free-electrons.com/training-materials/tree/lab-data/realtime/rttest/data/rttest.c
> >
> >  The TCB timer is still ticking, at a rate around 1Hz, while, when
> > the system hangs, the PIT interrupt isn't firing anymore (which
> > explains the freeze). So there's probably something wrong related
> > to the ipipe I guess, or the interrupt being masked and not
> > unmasked at some point.
> 
> Well:
> - - the existing at91 I test also use a PIT and they do not hang
> - - if you disabled the pic muting, noone is disabling the PIT interrupt.
> 
> So, I would suggest looking carefully at the sama5 code.

Ok, that's good to know. I'll look a bit more at this and what we did
for the AIC5 then.

Thanks again!
Maxime

-- 
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/20140625/8d54ee08/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Maxime Ripard]

On Tue, Jun 24, 2014 at 08:13:59AM +0200, Gilles Chanteperdrix wrote:
> >> After fixing the irq controller to work on the AIC5, and
> >> disabling the pic muting, I get almost 100% of the time a system
> >> freeze when running: 
> >> http://git.free-electrons.com/training-materials/tree/lab-data/realtime/rttest/data/rttest.c
> >
> >>  The TCB timer is still ticking, at a rate around 1Hz, while,
> >> when the system hangs, the PIT interrupt isn't firing anymore
> >> (which explains the freeze). So there's probably something wrong
> >> related to the ipipe I guess, or the interrupt being masked and
> >> not unmasked at some point.
> > 
> > Well: - the existing at91 I test also use a PIT and they do not
> > hang - if you disabled the pic muting, noone is disabling the PIT
> > interrupt.
> > 
> > So, I would suggest looking carefully at the sama5 code.
> 
> You could also post this code for review, BTW. Unless I am mistaken
> about your company, you do not want to keep it secret anyway ;-)

Yeah, I was willing to first make it work, but the final plan was of
course to submit it.

I'll clean that up and post it then.

Maxime

-- 
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/20140625/57e21e1c/attachment.sig>

Re: [Xenomai] Xenomai on Atmel SAMA5D3 with a 3.14 kernel

[Gilles Chanteperdrix]

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

On 06/25/2014 07:13 PM, Maxime Ripard wrote:
> On Tue, Jun 24, 2014 at 01:44:22AM +0200, Gilles Chanteperdrix
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 06/23/2014 04:05 PM, Maxime Ripard wrote:
>>> On Fri, Jun 13, 2014 at 09:01:25PM +0200, Gilles Chanteperdrix 
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> On 06/12/2014 05:03 PM, Maxime Ripard wrote:
>>>>> On Thu, Jun 12, 2014 at 10:37:11AM +0200, Gilles
>>>>> Chanteperdrix wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>> 
>>>>>> On 06/12/2014 09:54 AM, Maxime Ripard wrote:
>>>>>>> On Wed, Jun 11, 2014 at 08:16:15PM +0200, Gilles 
>>>>>>> Chanteperdrix wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>>>> 
>>>>>>>> On 06/11/2014 11:25 AM, Maxime Ripard wrote:
>>>>>>>>> On Tue, Jun 10, 2014 at 12:01:36PM +0200, Gilles 
>>>>>>>>> Chanteperdrix wrote:
>>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>> Read again, I am not insterested in exactly the same 
>>>>>>>> config, I am interested in the a config with
>>>>>>>> tcb_clksrc clocksource, which is disabled by
>>>>>>>> CONFIG_IPIPE. Only if you enable this clocksource do
>>>>>>>> you get to use the atmel_tclib code.
>>>>>>> 
>>>>>>> Let me rephrase then. It works with the exact same
>>>>>>> config, with CONFIG_IPIPE and CONFIG_XENOMAI disabled,
>>>>>>> and CONFIG_ATMEL_TCB_CLKSRC enabled.
>>>>>> 
>>>>>> Then I would tend to think that the clocksource is not
>>>>>> your problem and repeat that you should check everything
>>>>>> else in the porting guide.
>>>>> 
>>>>> Ok. I will.
>>>>> 
>>>> Looking rapidly at the code, at least the irq controller and
>>>> pic muting need fixing.
>>> 
>>> Ok, so, a bit of news on this one.
>>> 
>>> After fixing the irq controller to work on the AIC5, and
>>> disabling the pic muting, I get almost 100% of the time a
>>> system freeze when running: 
>>> http://git.free-electrons.com/training-materials/tree/lab-data/realtime/rttest/data/rttest.c
>>>
>>>
>>> 
The TCB timer is still ticking, at a rate around 1Hz, while, when
>>> the system hangs, the PIT interrupt isn't firing anymore
>>> (which explains the freeze). So there's probably something
>>> wrong related to the ipipe I guess, or the interrupt being
>>> masked and not unmasked at some point.
>> 
>> Well: - - the existing at91 I test also use a PIT and they do not
>> hang - - if you disabled the pic muting, noone is disabling the
>> PIT interrupt.
>> 
>> So, I would suggest looking carefully at the sama5 code.
> 
> Ok, that's good to know. I'll look a bit more at this and what we
> did for the AIC5 then.

I can make the AIC5 changes on my side and ask you to test, if you prefer.


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

iD8DBQFTqw8JGpcgE6m/fboRAn2pAJ9sR2kDd4TF7ZF32C19PTOQnyEnMgCeMrTy
E64SP8AiYPlJzSaNi5uuq1M=
=YGOP
-----END PGP SIGNATURE-----