Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[gilles.chanteperdrix]

---------- Debut du message initial -----------

De     : xenomai-core-bounces@domain.hid
A      : niklaus.giger@domain.hid
Copies : xenomai@xenomai.org
Date   : Tue, 26 Sep 2006 16:21:18 +0200
Objet  : Re: [Xenomai-core] Problem with periodic timer on
PPC40x solved

> > On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> > > > Am Montag, 25. September 2006 17:57 schrieb Philippe
Gerum:
> > > > > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang
Grandegger wrote:
> > > > > > Niklaus Giger wrote:
> > <..>
> > > > Is the output of lines like "Xenomai: Switching
display-3238 to secondary
> > > > mode after exception #1025 from user-space at
0x100033c4 (pid 3240)"
> > > > harmless or the result of a activated
CONFIG_XENO_OPT_DEBUG<..> option?
>
> A known hw issue seems to exist with the 405GP (revD), which
causes the
> ESR to be incorrectly set upon FPU emulation trap, which
would in turn
> cause the spurious exception to be relayed to the nucleus by
Adeos. The
> patch below is _not_ the final fix, but rather a way to
check if this
> message is indeed related to the FPU emulation on your
board. Does it
> silence the exception without breaking the box?

The FPU fault may be the result of the latency display thread
using the
FPU: on systems with emulated FPU, this looks normal.

--
                 Gilles Chanteperdrix

Accédez au courrier électronique de La Poste
sur www.laposte.net ou sur 3615 LAPOSTENET (0,34€ TTC /mn)
1 Giga de stockage gratuit – Antispam et antivirus intégrés

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
> ---------- Debut du message initial -----------
> 
> De     : xenomai-core-bounces@domain.hid
> A      : niklaus.giger@domain.hid
> Copies : xenomai@xenomai.org
> Date   : Tue, 26 Sep 2006 16:21:18 +0200
> Objet  : Re: [Xenomai-core] Problem with periodic timer on
> PPC40x solved
> 
> > > On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> > > > > Am Montag, 25. September 2006 17:57 schrieb Philippe
> Gerum:
> > > > > > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang
> Grandegger wrote:
> > > > > > > Niklaus Giger wrote:
> > > <..>
> > > > > Is the output of lines like "Xenomai: Switching
> display-3238 to secondary
> > > > > mode after exception #1025 from user-space at
> 0x100033c4 (pid 3240)"
> > > > > harmless or the result of a activated
> CONFIG_XENO_OPT_DEBUG<..> option?
> > 
> > A known hw issue seems to exist with the 405GP (revD), which
> causes the
> > ESR to be incorrectly set upon FPU emulation trap, which
> would in turn
> > cause the spurious exception to be relayed to the nucleus by
> Adeos. The
> > patch below is _not_ the final fix, but rather a way to
> check if this
> > message is indeed related to the FPU emulation on your
> board. Does it
> > silence the exception without breaking the box?
> 
> The FPU fault may be the result of the latency display thread
> using the
> FPU: on systems with emulated FPU, this looks normal.
> 

This said, we should not switch the task to secondary mode, but rather
emulate the FPU ops in primary mode. To this end, we need to make sure
that do_mathemu() is not going to choke over this context (e.g.
preemption count check issues over CONFIG_PREEMPT when running
unmodified uaccess routines). We additionally need to fix the program
check exception handler to give the math emulation code a chance to
handle the fault before we complain loudly at the nucleus.

-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Philippe Gerum wrote:
> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
>> ---------- Debut du message initial -----------
>>
>> De     : xenomai-core-bounces@domain.hid
>> A      : niklaus.giger@domain.hid
>> Copies : xenomai@xenomai.org
>> Date   : Tue, 26 Sep 2006 16:21:18 +0200
>> Objet  : Re: [Xenomai-core] Problem with periodic timer on
>> PPC40x solved
>>
>>>> On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
>>>>>> Am Montag, 25. September 2006 17:57 schrieb Philippe
>> Gerum:
>>>>>>> On Sun, 2006-09-24 at 23:07 +0200, Wolfgang
>> Grandegger wrote:
>>>>>>>> Niklaus Giger wrote:
>>>> <..>
>>>>>> Is the output of lines like "Xenomai: Switching
>> display-3238 to secondary
>>>>>> mode after exception #1025 from user-space at
>> 0x100033c4 (pid 3240)"
>>>>>> harmless or the result of a activated
>> CONFIG_XENO_OPT_DEBUG<..> option?
>>> A known hw issue seems to exist with the 405GP (revD), which
>> causes the
>>> ESR to be incorrectly set upon FPU emulation trap, which
>> would in turn
>>> cause the spurious exception to be relayed to the nucleus by
>> Adeos. The
>>> patch below is _not_ the final fix, but rather a way to
>> check if this
>>> message is indeed related to the FPU emulation on your
>> board. Does it
>>> silence the exception without breaking the box?
>> The FPU fault may be the result of the latency display thread
>> using the
>> FPU: on systems with emulated FPU, this looks normal.
>>
> 
> This said, we should not switch the task to secondary mode, but rather
> emulate the FPU ops in primary mode. To this end, we need to make sure
> that do_mathemu() is not going to choke over this context (e.g.
> preemption count check issues over CONFIG_PREEMPT when running
> unmodified uaccess routines). We additionally need to fix the program
> check exception handler to give the math emulation code a chance to
> handle the fault before we complain loudly at the nucleus.

OK, but in general, soft-float emulation should be used on systems 
without FPU and this is even more important for real-time. This is a 
tool chain issue. Niklaus, what tool chain are you using?

Wolfgang.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

On Tue, 2006-09-26 at 18:28 +0200, Wolfgang Grandegger wrote:
> Philippe Gerum wrote:
> > On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
> >> ---------- Debut du message initial -----------
> >>
> >> De     : xenomai-core-bounces@domain.hid
> >> A      : niklaus.giger@domain.hid
> >> Copies : xenomai@xenomai.org
> >> Date   : Tue, 26 Sep 2006 16:21:18 +0200
> >> Objet  : Re: [Xenomai-core] Problem with periodic timer on
> >> PPC40x solved
> >>
> >>>> On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> >>>>>> Am Montag, 25. September 2006 17:57 schrieb Philippe
> >> Gerum:
> >>>>>>> On Sun, 2006-09-24 at 23:07 +0200, Wolfgang
> >> Grandegger wrote:
> >>>>>>>> Niklaus Giger wrote:
> >>>> <..>
> >>>>>> Is the output of lines like "Xenomai: Switching
> >> display-3238 to secondary
> >>>>>> mode after exception #1025 from user-space at
> >> 0x100033c4 (pid 3240)"
> >>>>>> harmless or the result of a activated
> >> CONFIG_XENO_OPT_DEBUG<..> option?
> >>> A known hw issue seems to exist with the 405GP (revD), which
> >> causes the
> >>> ESR to be incorrectly set upon FPU emulation trap, which
> >> would in turn
> >>> cause the spurious exception to be relayed to the nucleus by
> >> Adeos. The
> >>> patch below is _not_ the final fix, but rather a way to
> >> check if this
> >>> message is indeed related to the FPU emulation on your
> >> board. Does it
> >>> silence the exception without breaking the box?
> >> The FPU fault may be the result of the latency display thread
> >> using the
> >> FPU: on systems with emulated FPU, this looks normal.
> >>
> > 
> > This said, we should not switch the task to secondary mode, but rather
> > emulate the FPU ops in primary mode. To this end, we need to make sure
> > that do_mathemu() is not going to choke over this context (e.g.
> > preemption count check issues over CONFIG_PREEMPT when running
> > unmodified uaccess routines). We additionally need to fix the program
> > check exception handler to give the math emulation code a chance to
> > handle the fault before we complain loudly at the nucleus.
> 
> OK, but in general, soft-float emulation should be used on systems 
> without FPU and this is even more important for real-time.

Makes sense. So maybe we should make this a more explicit and formal
warning, to catch missing soft float emulation, actually.

>  This is a 
> tool chain issue. Niklaus, what tool chain are you using?
> 
> Wolfgang.
> 
> 
> 
-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Philippe Gerum wrote:
> On Tue, 2006-09-26 at 18:28 +0200, Wolfgang Grandegger wrote:
>> Philippe Gerum wrote:
>>> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
>>>> ---------- Debut du message initial -----------
>>>>
>>>> De     : xenomai-core-bounces@domain.hid
>>>> A      : niklaus.giger@domain.hid
>>>> Copies : xenomai@xenomai.org
>>>> Date   : Tue, 26 Sep 2006 16:21:18 +0200
>>>> Objet  : Re: [Xenomai-core] Problem with periodic timer on
>>>> PPC40x solved
>>>>
>>>>>> On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
>>>>>>>> Am Montag, 25. September 2006 17:57 schrieb Philippe
>>>> Gerum:
>>>>>>>>> On Sun, 2006-09-24 at 23:07 +0200, Wolfgang
>>>> Grandegger wrote:
>>>>>>>>>> Niklaus Giger wrote:
>>>>>> <..>
>>>>>>>> Is the output of lines like "Xenomai: Switching
>>>> display-3238 to secondary
>>>>>>>> mode after exception #1025 from user-space at
>>>> 0x100033c4 (pid 3240)"
>>>>>>>> harmless or the result of a activated
>>>> CONFIG_XENO_OPT_DEBUG<..> option?
>>>>> A known hw issue seems to exist with the 405GP (revD), which
>>>> causes the
>>>>> ESR to be incorrectly set upon FPU emulation trap, which
>>>> would in turn
>>>>> cause the spurious exception to be relayed to the nucleus by
>>>> Adeos. The
>>>>> patch below is _not_ the final fix, but rather a way to
>>>> check if this
>>>>> message is indeed related to the FPU emulation on your
>>>> board. Does it
>>>>> silence the exception without breaking the box?
>>>> The FPU fault may be the result of the latency display thread
>>>> using the
>>>> FPU: on systems with emulated FPU, this looks normal.
>>>>
>>> This said, we should not switch the task to secondary mode, but rather
>>> emulate the FPU ops in primary mode. To this end, we need to make sure
>>> that do_mathemu() is not going to choke over this context (e.g.
>>> preemption count check issues over CONFIG_PREEMPT when running
>>> unmodified uaccess routines). We additionally need to fix the program
>>> check exception handler to give the math emulation code a chance to
>>> handle the fault before we complain loudly at the nucleus.
>> OK, but in general, soft-float emulation should be used on systems 
>> without FPU and this is even more important for real-time.
> 
> Makes sense. So maybe we should make this a more explicit and formal
> warning, to catch missing soft float emulation, actually.

We could already print a compiler warning when the kernel is built with 
MATH_EMULATION=y. There are a few corner-case where it might make sense 
to have math emulation enabled e.g. you need to run a binary with hard 
FP instructions because you are unable to rebuild it from the sources.

> 
>>  This is a 
>> tool chain issue. Niklaus, what tool chain are you using?
>>
>> Wolfgang.
>>
>>
>>

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger:
> Philippe Gerum wrote:
> > On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
> OK, but in general, soft-float emulation should be used on systems
> without FPU and this is even more important for real-time. This is a
> tool chain issue. Niklaus, what tool chain are you using?
>
In my .config I have 
MATH_EMULATION=y

The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan 
Kegel crosstool (Version 0.42 if I remember exactly).

Shall I switch to another one?

-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger:
>> Philippe Gerum wrote:
>>> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
>> OK, but in general, soft-float emulation should be used on systems
>> without FPU and this is even more important for real-time. This is a
>> tool chain issue. Niklaus, what tool chain are you using?
>>
> In my .config I have 
> MATH_EMULATION=y

You seem to need that because your compiler generates code with hard FP 
instructions. You could check this with:

  $ ppc-linux-objdump -d prog|egrep ":\s*[e-f]"

> The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan 
> Kegel crosstool (Version 0.42 if I remember exactly).
> 
> Shall I switch to another one?

The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de).
Choose  v3.1.1 for Linux 2.4 and v4 for Linux 2.6.

Wolfgang.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger:
> Niklaus Giger wrote:
> > Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger:
> >> Philippe Gerum wrote:
> >>> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
> >>
> >> OK, but in general, soft-float emulation should be used on systems
> >> without FPU and this is even more important for real-time. This is a
> >> tool chain issue. Niklaus, what tool chain are you using?
> >
> > In my .config I have
> > MATH_EMULATION=y
>
> You seem to need that because your compiler generates code with hard FP
> instructions. You could check this with:
>
>   $ ppc-linux-objdump -d prog|egrep ":\s*[e-f]"
This does not return any match on my system.

But looking at the disassembly of the latency program I have code like:
100081bc <_restfpr_28_x>:
100081bc:       cb 8b ff e0     lfd     f28,-32(r11)
or
1000798c <__floatsidf>:
1000798c:       7c 08 02 a6     mflr    r0
10007990:       2f 83 00 00     cmpwi   cr7,r3,0
10007994:       94 21 ff c0     stwu    r1,-64(r1)
10007998:       90 01 00 44     stw     r0,68(r1)
1000799c:       54 60 0f fe     rlwinm  r0,r3,1,31,31
100079a0:       90 01 00 14     stw     r0,20(r1)
100079a4:       40 9e 00 24     bne-    cr7,100079c8 <__floatsidf+0x3c>

> > The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using
> > Dan Kegel crosstool (Version 0.42 if I remember exactly).
> >
> > Shall I switch to another one?
>
> The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de).
> Choose  v3.1.1 for Linux 2.4 and v4 for Linux 2.6.

I am breathing only PowerPC code on my Mac PowerBook (running Debian) and 
never managed to installed ELDK on it. (And even Detlev as a Debian developer 
couldn't recommend a simple way.) 

But I assume that I specifying GLIBC_EXTRA_CONFIG="--without-fp" in the 
powerpc-405.dat should be enough to make Dan Kegels crosstool emit Soft-FPU 
emulation.

I will try to run the tests at work where I have installed ELDK 4.0, but not 
yet a fully working environment. Therefore it may take some time to report a 
result back.

-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger:
>> Niklaus Giger wrote:
>>> Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger:
>>>> Philippe Gerum wrote:
>>>>> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
>>>> OK, but in general, soft-float emulation should be used on systems
>>>> without FPU and this is even more important for real-time. This is a
>>>> tool chain issue. Niklaus, what tool chain are you using?
>>> In my .config I have
>>> MATH_EMULATION=y
>> You seem to need that because your compiler generates code with hard FP
>> instructions. You could check this with:
>>
>>   $ ppc-linux-objdump -d prog|egrep ":\s*[e-f]"
> This does not return any match on my system.

Oops, then your compiler seems _not_ to create hard FP instruction, 
otherwise you would get:

   ppc_82xx-objdump -d latency|egrep ":\s*[e-f]"
   latency:     file format elf32-powerpc
   100036ac:       fc 21 f8 28     fsub    f1,f1,f31
   100036b4:       fc 42 f8 28     fsub    f2,f2,f31
   100036c4:       fc 63 f8 28     fsub    f3,f3,f31
   100036cc:       fc 21 f0 24     fdiv    f1,f1,f30
   100036dc:       fc 84 f8 28     fsub    f4,f4,f31
   ...

> But looking at the disassembly of the latency program I have code like:
> 100081bc <_restfpr_28_x>:
> 100081bc:       cb 8b ff e0     lfd     f28,-32(r11)
> or
> 1000798c <__floatsidf>:
> 1000798c:       7c 08 02 a6     mflr    r0
> 10007990:       2f 83 00 00     cmpwi   cr7,r3,0
> 10007994:       94 21 ff c0     stwu    r1,-64(r1)
> 10007998:       90 01 00 44     stw     r0,68(r1)
> 1000799c:       54 60 0f fe     rlwinm  r0,r3,1,31,31
> 100079a0:       90 01 00 14     stw     r0,20(r1)
> 100079a4:       40 9e 00 24     bne-    cr7,100079c8 <__floatsidf+0x3c>

That's from soft float emulation.

>>> The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using
>>> Dan Kegel crosstool (Version 0.42 if I remember exactly).
>>>
>>> Shall I switch to another one?

Maybe (likely) there is nothing wrong with your tool chain.

>> The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de).
>> Choose  v3.1.1 for Linux 2.4 and v4 for Linux 2.6.
> 
> I am breathing only PowerPC code on my Mac PowerBook (running Debian) and 
> never managed to installed ELDK on it. (And even Detlev as a Debian developer 
> couldn't recommend a simple way.) 

I remember Detlev's pain and frustration.

> But I assume that I specifying GLIBC_EXTRA_CONFIG="--without-fp" in the 
> powerpc-405.dat should be enough to make Dan Kegels crosstool emit Soft-FPU 
> emulation.

See above.

> I will try to run the tests at work where I have installed ELDK 4.0, but not 
> yet a fully working environment. Therefore it may take some time to report a 
> result back.

I'm now a bit puzzled why a FP exception occurs. What happens if you 
disable MATH_EMULATION
in your kernel (that's what I normally have). It will try the latency 
test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap.

Wolfgang.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Wolfgang Grandegger wrote:
> Niklaus Giger wrote:
>> Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger:
>>> Niklaus Giger wrote:
>>>> Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger:
>>>>> Philippe Gerum wrote:
>>>>>> On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote:
>>>>> OK, but in general, soft-float emulation should be used on systems
>>>>> without FPU and this is even more important for real-time. This is a
>>>>> tool chain issue. Niklaus, what tool chain are you using?
>>>> In my .config I have
>>>> MATH_EMULATION=y
>>> You seem to need that because your compiler generates code with hard FP
>>> instructions. You could check this with:
>>>
>>>   $ ppc-linux-objdump -d prog|egrep ":\s*[e-f]"
>> This does not return any match on my system.
> 
> Oops, then your compiler seems _not_ to create hard FP instruction, 
> otherwise you would get:
> 
>   ppc_82xx-objdump -d latency|egrep ":\s*[e-f]"
>   latency:     file format elf32-powerpc
>   100036ac:       fc 21 f8 28     fsub    f1,f1,f31
>   100036b4:       fc 42 f8 28     fsub    f2,f2,f31
>   100036c4:       fc 63 f8 28     fsub    f3,f3,f31
>   100036cc:       fc 21 f0 24     fdiv    f1,f1,f30
>   100036dc:       fc 84 f8 28     fsub    f4,f4,f31
>   ...
> 
>> But looking at the disassembly of the latency program I have code like:
>> 100081bc <_restfpr_28_x>:
>> 100081bc:       cb 8b ff e0     lfd     f28,-32(r11)
>> or
>> 1000798c <__floatsidf>:
>> 1000798c:       7c 08 02 a6     mflr    r0
>> 10007990:       2f 83 00 00     cmpwi   cr7,r3,0
>> 10007994:       94 21 ff c0     stwu    r1,-64(r1)
>> 10007998:       90 01 00 44     stw     r0,68(r1)
>> 1000799c:       54 60 0f fe     rlwinm  r0,r3,1,31,31
>> 100079a0:       90 01 00 14     stw     r0,20(r1)
>> 100079a4:       40 9e 00 24     bne-    cr7,100079c8 <__floatsidf+0x3c>
> 
> That's from soft float emulation.
> 
>>>> The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built 
>>>> using
>>>> Dan Kegel crosstool (Version 0.42 if I remember exactly).
>>>>
>>>> Shall I switch to another one?
> 
> Maybe (likely) there is nothing wrong with your tool chain.
> 
>>> The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de).
>>> Choose  v3.1.1 for Linux 2.4 and v4 for Linux 2.6.
>>
>> I am breathing only PowerPC code on my Mac PowerBook (running Debian) 
>> and never managed to installed ELDK on it. (And even Detlev as a 
>> Debian developer couldn't recommend a simple way.) 
> 
> I remember Detlev's pain and frustration.
> 
>> But I assume that I specifying GLIBC_EXTRA_CONFIG="--without-fp" in 
>> the powerpc-405.dat should be enough to make Dan Kegels crosstool emit 
>> Soft-FPU emulation.
> 
> See above.
> 
>> I will try to run the tests at work where I have installed ELDK 4.0, 
>> but not yet a fully working environment. Therefore it may take some 
>> time to report a result back.
> 
> I'm now a bit puzzled why a FP exception occurs. What happens if you 
> disable MATH_EMULATION
> in your kernel (that's what I normally have). It will try the latency 
> test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap.

I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14:

   CPU:   AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66,
          EBC=66 MHz)
          Internal PCI arbiter enabled, PCI async ext clock used
          16 kB I-Cache 16 kB D-Cache
   Board: Sycamore - AMCC PPC405GPr Evaluation Board

Wolfgang.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Am Mittwoch, 27. September 2006 20:19 schrieb Wolfgang Grandegger:
<..>
> > I'm now a bit puzzled why a FP exception occurs. What happens if you
> > disable MATH_EMULATION
> > in your kernel (that's what I normally have). It will try the latency
> > test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap.
>
> I'm unable to reproduce the problem of our Sycamore board with Linux
> 2.6.14:
Can I you send me (maybe offline) your .config. I will also rebuild my rootfs 
from scratch. At work I have also a walnut board where I could run the tests.
>    CPU:   AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66,
>           EBC=66 MHz)
>           Internal PCI arbiter enabled, PCI async ext clock used
>           16 kB I-Cache 16 kB D-Cache
>    Board: Sycamore - AMCC PPC405GPr Evaluation Board
>
Thanks for trying to reproduce the problem.

-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

Niklaus Giger wrote:
> Am Mittwoch, 27. September 2006 20:19 schrieb Wolfgang Grandegger:
> <..>
>>> I'm now a bit puzzled why a FP exception occurs. What happens if you
>>> disable MATH_EMULATION
>>> in your kernel (that's what I normally have). It will try the latency
>>> test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap.
>> I'm unable to reproduce the problem of our Sycamore board with Linux
>> 2.6.14:
> Can I you send me (maybe offline) your .config. I will also rebuild my rootfs 
> from scratch. At work I have also a walnut board where I could run the tests.

See attachment. And I tested with a Sycamore Evaluation Board, which 
uses the same processor as you have. Likely, it has nothing to do with 
the board. Does your kernel boot with MATH_EMULATION disabled? Can you 
then run user-space applications using FP.

>>    CPU:   AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66,
>>           EBC=66 MHz)
>>           Internal PCI arbiter enabled, PCI async ext clock used
>>           16 kB I-Cache 16 kB D-Cache
>>    Board: Sycamore - AMCC PPC405GPr Evaluation Board
>>
> Thanks for trying to reproduce the problem.
> 


[-- Attachment #2: linux-xeno-2.6.14-sycamore.config --]
[-- Type: text/plain, Size: 19687 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14
# Wed Sep 27 14:21:27 2006
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
# CONFIG_XENO_OPT_RPIDISABLE is not set
CONFIG_XENO_OPT_SECURITY_ACCESS=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
CONFIG_XENO_OPT_DEBUG_BHEAP=y
# CONFIG_XENO_OPT_WATCHDOG is not set

#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_PERIOD=0
CONFIG_XENO_OPT_TIMING_TIMERLAT=0
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0

#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set

#
# Shared interrupts
#
# CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
# CONFIG_XENO_OPT_SHIRQ_EDGE is not set

#
# Machine
#

#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=y
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_FILDES=128
# CONFIG_XENO_OPT_DEBUG_RTDM is not set

#
# Drivers
#

#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set

#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=y
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
CONFIG_XENO_DRIVERS_SWITCHTEST=y

#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_RTCAN is not set

#
# Processor
#
# CONFIG_6xx is not set
CONFIG_40x=y
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
CONFIG_4xx=y
# CONFIG_WANT_EARLY_SERIAL is not set

#
# IBM 4xx options
#
# CONFIG_BUBINGA is not set
# CONFIG_CPCI405 is not set
# CONFIG_EP405 is not set
# CONFIG_PPChameleonEVB is not set
# CONFIG_REDWOOD_5 is not set
# CONFIG_REDWOOD_6 is not set
CONFIG_SYCAMORE=y
# CONFIG_WALNUT is not set
# CONFIG_XILINX_ML300 is not set
CONFIG_IBM_OCP=y
CONFIG_BIOS_FIXUP=y
CONFIG_405GPR=y
# CONFIG_PPC4xx_DMA is not set
CONFIG_PPC_GEN550=y
CONFIG_UART0_TTYS0=y
# CONFIG_UART0_TTYS1 is not set
CONFIG_NOT_COHERENT_CACHE=y

#
# Platform options
#
# CONFIG_PC_KEYBOARD is not set
CONFIG_IPIPE=y
# CONFIG_HIGHMEM is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="ip=on"
# CONFIG_PM is not set
# CONFIG_SOFTWARE_SUSPEND is not set
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y

#
# Bus options
#
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set

#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x00400000

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_WALNUT=y
CONFIG_MTD_UBOOT_PARTITIONS=y
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBM_EMAC=y
CONFIG_IBM_EMAC_RXB=64
CONFIG_IBM_EMAC_TXB=8
CONFIG_IBM_EMAC_POLL_WEIGHT=32
CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
# CONFIG_IBM_EMAC_DEBUG is not set
# CONFIG_NET_PCI is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_IBM_IIC is not set
# CONFIG_I2C_MPC is not set
# CONFIG_I2C_MPC8260 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8563 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_M41T00 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# SN Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# IBM 40x options
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_SERIAL_TEXT_DEBUG is not set
CONFIG_PPC_OCP=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

[Xenomai-core] Problem with periodic timer on PPC40x identified

[Niklaus Giger]

Hi

Finally I got some time to debug the whole problem with my BDI.
I see that in hal.c thal_set_local_cpu_timer the PIT is loaded with a value of 
568 which is far too low, as the PIT is running at 400 MHz. So it will 
trigger an interrupt every 1,4 microsecond and therefore overload the system.

I am not sure about the time units stored in __ipipe_decr_ticks. I tried to 
use 400 as my board is running at 400 MHz.
A quick breakpoint in ppc4xx_calibrate_decr in the file 
arch/syslib/ppc4xx_setup.c verified that bdinfo has the correct value of 
400'000'000 as frequency.

In hal.c and ipipe-core are two occurences of
    mtspr(SPRN_PIT, __ipipe_decr_ticks); 
which I replaced by the above computed constant
    mtspr(SPRN_PIT, __ipipe_decr_ticks * 400); 

Now the the board comes up, but calling in the vxworks skin 
taskDelay(sysClkRateGet()*10) delays me only about 5 seconds and not 10 as 
expected.

I have one possible explanation that the value of 568 is the result of a 
implicit truncation to 32 bits in ipipe_tune_timer. tb_ticks_per_jiffy is 
1600000, sysClkRate is 10000. Therefore a maximal delay of 1 ms = 1000*1000 
ns leads to 1000*1000*16000 = 0x25'40BE'4000.

If would be nice if somebode could shed some light on this issue.

My preliminary patch looked like this, but I am sure that we need quite a 
different solution.

+++ ksrc/arch/powerpc/hal.c	(Arbeitskopie)
@@ -81,7 +81,9 @@
  */
 static void rthal_set_local_cpu_timer(void)
 {
+#ifndef CONFIG_40x
     long ticks;
+#endif
     rthal_declare_cpuid;
 
     rthal_load_cpuid();
@@ -90,7 +92,7 @@
 #ifdef CONFIG_40x
     /* Enable and set auto-reload. */
     mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
-    mtspr(SPRN_PIT, __ipipe_decr_ticks);
+    mtspr(SPRN_PIT, __ipipe_decr_ticks * 400); /* TODO: How do we get this 
value from the board info */
 #else /* !CONFIG_40x */
     ticks = (long)(__ipipe_decr_next[cpuid] - __ipipe_read_timebase());
     set_dec(ticks > 0 ? ticks : 0);
Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
===================================================================
--- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	(Revision 
1650)
+++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	
(Arbeitskopie)
@@ -3581,7 +3581,8 @@
 +#ifdef CONFIG_40x
 +	/* Enable and set auto-reload. */
 +	mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
-+	mtspr(SPRN_PIT, __ipipe_decr_ticks);
++	mtspr(SPRN_PIT, __ipipe_decr_ticks * 400 ); /* TODO: How do we get this 
value from the board info */
+
 +#else	/* !CONFIG_40x */
 +	__ipipe_decr_next[cpuid] = __ipipe_read_timebase() + __ipipe_decr_ticks;
 +	set_dec(__ipipe_decr_ticks);

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x identified

[Wolfgang Grandegger]

Hi Niklaus,
Niklaus Giger wrote:
> Hi
> 
> Finally I got some time to debug the whole problem with my BDI.
> I see that in hal.c thal_set_local_cpu_timer the PIT is loaded with a value of 
> 568 which is far too low, as the PIT is running at 400 MHz. So it will 
> trigger an interrupt every 1,4 microsecond and therefore overload the system.
> 
> I am not sure about the time units stored in __ipipe_decr_ticks. I tried to 
> use 400 as my board is running at 400 MHz.
> A quick breakpoint in ppc4xx_calibrate_decr in the file 
> arch/syslib/ppc4xx_setup.c verified that bdinfo has the correct value of 
> 400'000'000 as frequency.
> 
> In hal.c and ipipe-core are two occurences of
>     mtspr(SPRN_PIT, __ipipe_decr_ticks); 
> which I replaced by the above computed constant
>     mtspr(SPRN_PIT, __ipipe_decr_ticks * 400); 
> 
> Now the the board comes up, but calling in the vxworks skin 
> taskDelay(sysClkRateGet()*10) delays me only about 5 seconds and not 10 as 
> expected.
> 
> I have one possible explanation that the value of 568 is the result of a 
> implicit truncation to 32 bits in ipipe_tune_timer. tb_ticks_per_jiffy is 
> 1600000, sysClkRate is 10000. Therefore a maximal delay of 1 ms = 1000*1000 
> ns leads to 1000*1000*16000 = 0x25'40BE'4000.
> 
> If would be nice if somebode could shed some light on this issue.

I briefly look why the value of __ipipe_decr_ticks is bogus. Maybe the 
calculation fails due to 32-bit constraints in 
arch/ppc/kernel/ipipe-core.c:pipe_tune_timer():

   int ipipe_tune_timer(unsigned long ns, int flags)
   {
         unsigned long x, ticks;

         if (flags & IPIPE_RESET_TIMER)
                 ticks = tb_ticks_per_jiffy;
         else {
                 ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
  		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 if (ticks > tb_ticks_per_jiffy)
                         return -EINVAL;
         }
 

         x = ipipe_critical_enter(&__ipipe_set_decr); /* Sync with all
                                                         CPUs */
         __ipipe_decr_ticks = ticks;
         __ipipe_set_decr();
         ipipe_critical_exit(x);
 

          return 0;
  }
 

Does replacing the calculation of ticks with

         ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);

help. A proper calculation might use mulhwu or rthal_imuldiv.

Wolfgang.


> 
> My preliminary patch looked like this, but I am sure that we need quite a 
> different solution.
> 
> +++ ksrc/arch/powerpc/hal.c	(Arbeitskopie)
> @@ -81,7 +81,9 @@
>   */
>  static void rthal_set_local_cpu_timer(void)
>  {
> +#ifndef CONFIG_40x
>      long ticks;
> +#endif
>      rthal_declare_cpuid;
>  
>      rthal_load_cpuid();
> @@ -90,7 +92,7 @@
>  #ifdef CONFIG_40x
>      /* Enable and set auto-reload. */
>      mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
> -    mtspr(SPRN_PIT, __ipipe_decr_ticks);
> +    mtspr(SPRN_PIT, __ipipe_decr_ticks * 400); /* TODO: How do we get this 
> value from the board info */
>  #else /* !CONFIG_40x */
>      ticks = (long)(__ipipe_decr_next[cpuid] - __ipipe_read_timebase());
>      set_dec(ticks > 0 ? ticks : 0);
> Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
> ===================================================================
> --- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	(Revision 
> 1650)
> +++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	
> (Arbeitskopie)
> @@ -3581,7 +3581,8 @@
>  +#ifdef CONFIG_40x
>  +	/* Enable and set auto-reload. */
>  +	mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
> -+	mtspr(SPRN_PIT, __ipipe_decr_ticks);
> ++	mtspr(SPRN_PIT, __ipipe_decr_ticks * 400 ); /* TODO: How do we get this 
> value from the board info */
> +
>  +#else	/* !CONFIG_40x */
>  +	__ipipe_decr_next[cpuid] = __ipipe_read_timebase() + __ipipe_decr_ticks;
>  +	set_dec(__ipipe_decr_ticks);
> 
> Best regards
> 

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Am Samstag, 23. September 2006 22:55 schrieb Wolfgang Grandegger:
> Hi Niklaus,
>
> Niklaus Giger wrote:
<..>
>          if (flags & IPIPE_RESET_TIMER)
>                  ticks = tb_ticks_per_jiffy;
>          else {
>                  ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
>   		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                  if (ticks > tb_ticks_per_jiffy)
>                          return -EINVAL;
<..>
> Does replacing the calculation of ticks with
>
>          ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
>
> help. A proper calculation might use mulhwu or rthal_imuldiv.
Yes. I does. There are two occurrences fixed with the attached patch (+ one 
small ifdef to eliminate a compiler warning in the PPC40x case).
Timing is okay as tested with a small vxworks test program.

Could someone please apply it?

Thanks for your cooperation. 

Best regards

-- 
Niklaus Giger

[-- Attachment #2: ppc40x_periodic.patch --]
[-- Type: text/x-diff, Size: 1261 bytes --]

Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
===================================================================
--- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	(Revision 1650)
+++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	(Arbeitskopie)
@@ -3595,7 +3595,7 @@
 +	if (flags & IPIPE_RESET_TIMER)
 +		ticks = tb_ticks_per_jiffy;
 +	else {
-+		ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
++		ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
 +
 +		if (ticks > tb_ticks_per_jiffy)
 +			return -EINVAL;
Index: ksrc/arch/powerpc/hal.c
===================================================================
--- ksrc/arch/powerpc/hal.c	(Revision 1650)
+++ ksrc/arch/powerpc/hal.c	(Arbeitskopie)
@@ -81,7 +81,9 @@
  */
 static void rthal_set_local_cpu_timer(void)
 {
+#ifndef CONFIG_40x
     long ticks;
+#endif
     rthal_declare_cpuid;
 
     rthal_load_cpuid();
@@ -110,7 +112,7 @@
     if (ns == 0)
         ticks = tb_ticks_per_jiffy;
     else {
-        ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
+	ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
 
         if (ticks > tb_ticks_per_jiffy) {
             DBG("rthal_set_cpu_timers_unsafe: -EINVAL (%lu)\n", ticks);

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Samstag, 23. September 2006 22:55 schrieb Wolfgang Grandegger:
>> Hi Niklaus,
>>
>> Niklaus Giger wrote:
> <..>
>>          if (flags & IPIPE_RESET_TIMER)
>>                  ticks = tb_ticks_per_jiffy;
>>          else {
>>                  ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
>>   		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>                  if (ticks > tb_ticks_per_jiffy)
>>                          return -EINVAL;
> <..>
>> Does replacing the calculation of ticks with
>>
>>          ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
>>
>> help. A proper calculation might use mulhwu or rthal_imuldiv.
> Yes. I does. There are two occurrences fixed with the attached patch (+ one 
> small ifdef to eliminate a compiler warning in the PPC40x case).
> Timing is okay as tested with a small vxworks test program.
> 
> Could someone please apply it?
> 
> Thanks for your cooperation. 
> 
> Best regards
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
> ===================================================================
> --- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	(Revision 1650)
> +++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch	(Arbeitskopie)
> @@ -3595,7 +3595,7 @@
>  +	if (flags & IPIPE_RESET_TIMER)
>  +		ticks = tb_ticks_per_jiffy;
>  +	else {
> -+		ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
> ++		ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
>  +
>  +		if (ticks > tb_ticks_per_jiffy)
>  +			return -EINVAL;
> Index: ksrc/arch/powerpc/hal.c
> ===================================================================
> --- ksrc/arch/powerpc/hal.c	(Revision 1650)
> +++ ksrc/arch/powerpc/hal.c	(Arbeitskopie)
> @@ -81,7 +81,9 @@
>   */
>  static void rthal_set_local_cpu_timer(void)
>  {
> +#ifndef CONFIG_40x
>      long ticks;
> +#endif
>      rthal_declare_cpuid;
>  
>      rthal_load_cpuid();
> @@ -110,7 +112,7 @@
>      if (ns == 0)
>          ticks = tb_ticks_per_jiffy;
>      else {
> -        ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
> +	ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
>  
>          if (ticks > tb_ticks_per_jiffy) {
>              DBG("rthal_set_cpu_timers_unsafe: -EINVAL (%lu)\n", ticks);

My suggested fix was just to locate the source of the problem. As 
Philippe suggested, we should use mulhwu (or mulhwu_scale_factor). Have 
a look to arch/ppc/kernel/time.c for further information.

Wolfgang.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> Niklaus Giger wrote:
> >  static void rthal_set_local_cpu_timer(void)
> >  {
> > +#ifndef CONFIG_40x
> >      long ticks;
> > +#endif
> >      rthal_declare_cpuid;
> >  
> >      rthal_load_cpuid();
> > @@ -110,7 +112,7 @@
> >      if (ns == 0)
> >          ticks = tb_ticks_per_jiffy;
> >      else {
> > -        ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
> > +	ticks = ns * (tb_ticks_per_jiffy / 10000) / (100000 / HZ);
> >  
> >          if (ticks > tb_ticks_per_jiffy) {
> >              DBG("rthal_set_cpu_timers_unsafe: -EINVAL (%lu)\n", ticks);
> 
> My suggested fix was just to locate the source of the problem. As 
> Philippe suggested, we should use mulhwu (or mulhwu_scale_factor). Have 
> a look to arch/ppc/kernel/time.c for further information.

Ok, we can go for the lazy fix here, since this code is poised to
disappear anyway. I've merged a variant of the above we already use for
the ARM port, which scales down the period to microseconds instead of
losing precision on the count of timebase ticks per jiffy.

- ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
+ ticks = (ns / 1000) * tb_ticks_per_jiffy / (1000000 / HZ);

-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
> On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> > Niklaus Giger wrote:
<..>
> Ok, we can go for the lazy fix here, since this code is poised to
> disappear anyway. I've merged a variant of the above we already use for
> the ARM port, which scales down the period to microseconds instead of
> losing precision on the count of timebase ticks per jiffy.
>
> - ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
> + ticks = (ns / 1000) * tb_ticks_per_jiffy / (1000000 / HZ);
Thanks for finding this solution. I tried to understand mulhwu and 
mulhwu_scale_factor but couldn't figure out a correct solution in a short 
time.

The buildbot cannot presently power on and off my PPC405 target board, as the 
my power outlet switching device is broken and has been sent back for a 
remplacement.

I did however run some tests manually and have the following questions about 
the output:
Why do I get negative values for latenciy values?
Is the output of lines like "Xenomai: Switching display-3238 to secondary mode 
after exception #1025 from user-space at 0x100033c4 (pid 3240)" harmless or 
the result of a activated CONFIG_XENO_OPT_DEBUG<..> option?

Mon Sep 25 20:20:33 UTC 2006
running: ./run -- -T 5 -t2 # latency
*
*
* Type ^C to stop this application.
*
Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
user-space at 0x100033c4 (pid 3240)
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      -5.108|      -4.754|      -0.905|       0|      -5.108|      -0.905
RTD|      -4.963|      -4.871|       1.155|       0|      -5.108|       1.155
Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
user-space at 0xfda9638 (pid 3240)
RTD|      -4.963|      -4.758|      16.020|       0|      -5.108|      16.020
RTD|      -6.313|      -4.861|      10.980|       0|      -6.313|      16.020
Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
user-space at 0xfe7c1c4 (pid 3240)
---|------------|------------|------------|--------|-------------------------
RTS|      -6.313|      -4.811|      16.020|       0|    00:00:05/00:00:05
Xenomai: stopping RTDM services.

Best regards
-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
> > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> > > Niklaus Giger wrote:
> <..>
> > Ok, we can go for the lazy fix here, since this code is poised to
> > disappear anyway. I've merged a variant of the above we already use for
> > the ARM port, which scales down the period to microseconds instead of
> > losing precision on the count of timebase ticks per jiffy.
> >
> > - ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
> > + ticks = (ns / 1000) * tb_ticks_per_jiffy / (1000000 / HZ);
> Thanks for finding this solution. I tried to understand mulhwu and 
> mulhwu_scale_factor but couldn't figure out a correct solution in a short 
> time.
> 
> The buildbot cannot presently power on and off my PPC405 target board, as the 
> my power outlet switching device is broken and has been sent back for a 
> remplacement.
> 
> I did however run some tests manually and have the following questions about 
> the output:
> Why do I get negative values for latenciy values?

Because the timer shot anticipation in /proc/xenomai/latency is too
large for the target, which in fact has a lower intrinsic latency than
expected. The default calibration values are obtained from
include/asm-*/calibration.h.

> Is the output of lines like "Xenomai: Switching display-3238 to secondary mode 
> after exception #1025 from user-space at 0x100033c4 (pid 3240)" harmless or 
> the result of a activated CONFIG_XENO_OPT_DEBUG<..> option?
> 

Oops. It's bad news. A memory access error occured while running the
test. Which Xenomai/Adeos combo are you currently running on the 4xx?

> Mon Sep 25 20:20:33 UTC 2006
> running: ./run -- -T 5 -t2 # latency
> *
> *
> * Type ^C to stop this application.
> *
> Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
> user-space at 0x100033c4 (pid 3240)
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      -5.108|      -4.754|      -0.905|       0|      -5.108|      -0.905
> RTD|      -4.963|      -4.871|       1.155|       0|      -5.108|       1.155
> Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
> user-space at 0xfda9638 (pid 3240)
> RTD|      -4.963|      -4.758|      16.020|       0|      -5.108|      16.020
> RTD|      -6.313|      -4.861|      10.980|       0|      -6.313|      16.020
> Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
> user-space at 0xfe7c1c4 (pid 3240)
> ---|------------|------------|------------|--------|-------------------------
> RTS|      -6.313|      -4.811|      16.020|       0|    00:00:05/00:00:05
> Xenomai: stopping RTDM services.
> 
> Best regards
-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Am Montag, 25. September 2006 22:59 schrieb Philippe Gerum:
> On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> > Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
> > > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> > > > Niklaus Giger wrote:
<..>
> > Is the output of lines like "Xenomai: Switching display-3238 to secondary
> > mode after exception #1025 from user-space at 0x100033c4 (pid 3240)"
> > harmless or the result of a activated CONFIG_XENO_OPT_DEBUG<..> option?
>
> Oops. It's bad news. A memory access error occured while running the
> test. Which Xenomai/Adeos combo are you currently running on the 4xx?

adeos-ipipe-2.6.14-ppc-1.4-00.patch

Shall I use my BDI (tomorrow evening) to get a stack trace of it? Or something 
else you would like to see?
 
Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

On Mon, 2006-09-25 at 23:15 +0200, Niklaus Giger wrote:
> Am Montag, 25. September 2006 22:59 schrieb Philippe Gerum:
> > On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> > > Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
> > > > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> > > > > Niklaus Giger wrote:
> <..>
> > > Is the output of lines like "Xenomai: Switching display-3238 to secondary
> > > mode after exception #1025 from user-space at 0x100033c4 (pid 3240)"
> > > harmless or the result of a activated CONFIG_XENO_OPT_DEBUG<..> option?
> >
> > Oops. It's bad news. A memory access error occured while running the
> > test. Which Xenomai/Adeos combo are you currently running on the 4xx?
> 
> adeos-ipipe-2.6.14-ppc-1.4-00.patch
> 
> Shall I use my BDI (tomorrow evening) to get a stack trace of it? Or something 
> else you would like to see?

It would be great if you could first run the very same Xenomai config
over Adeos 1.3-07 instead of 1.4-00, just to see if the issue is still
there on the 4xx. After that, a BDI trace would be nice to have when
time permits.

>  
> Best regards
> 
-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

> On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> > > Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
> > > > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> > > > > Niklaus Giger wrote:
> <..>
> > > Is the output of lines like "Xenomai: Switching display-3238 to secondary
> > > mode after exception #1025 from user-space at 0x100033c4 (pid 3240)"
> > > harmless or the result of a activated CONFIG_XENO_OPT_DEBUG<..> option?

A known hw issue seems to exist with the 405GP (revD), which causes the
ESR to be incorrectly set upon FPU emulation trap, which would in turn
cause the spurious exception to be relayed to the nucleus by Adeos. The
patch below is _not_ the final fix, but rather a way to check if this
message is indeed related to the FPU emulation on your board. Does it
silence the exception without breaking the box?

--- arch/ppc/kernel/traps.c~	2006-09-25 17:10:48.000000000 +0200
+++ arch/ppc/kernel/traps.c	2006-09-26 16:14:30.000000000 +0200
@@ -638,9 +638,6 @@
 	unsigned int reason = get_reason(regs);
 	extern int do_mathemu(struct pt_regs *regs);
 
-	if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
-	    	return;
-
 #ifdef CONFIG_MATH_EMULATION
 	/* (reason & REASON_ILLEGAL) would be the obvious thing here,
 	 * but there seems to be a hardware bug on the 405GP (RevD)
@@ -655,6 +652,9 @@
 	}
 #endif /* CONFIG_MATH_EMULATION */
 
+	if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
+	    	return;
+
 	if (reason & REASON_FP) {
 		/* IEEE FP exception */
 		int code = 0;
-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Am Dienstag, 26. September 2006 16:21 schrieb Philippe Gerum:
> > On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
> > > > Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
> > > > > On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
> > > > > > Niklaus Giger wrote:
> >
> > <..>
> >
> > > > Is the output of lines like "Xenomai: Switching display-3238 to
> > > > secondary mode after exception #1025 from user-space at 0x100033c4
> > > > (pid 3240)" harmless or the result of a activated
> > > > CONFIG_XENO_OPT_DEBUG<..> option?
>
> A known hw issue seems to exist with the 405GP (revD), which causes the
> ESR to be incorrectly set upon FPU emulation trap, which would in turn
> cause the spurious exception to be relayed to the nucleus by Adeos. The
> patch below is _not_ the final fix, but rather a way to check if this
> message is indeed related to the FPU emulation on your board. Does it
> silence the exception without breaking the box?
>
> --- arch/ppc/kernel/traps.c~	2006-09-25 17:10:48.000000000 +0200
> +++ arch/ppc/kernel/traps.c	2006-09-26 16:14:30.000000000 +0200
> @@ -638,9 +638,6 @@
>  	unsigned int reason = get_reason(regs);
>  	extern int do_mathemu(struct pt_regs *regs);
>
> -	if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
> -	    	return;
> -
>  #ifdef CONFIG_MATH_EMULATION
>  	/* (reason & REASON_ILLEGAL) would be the obvious thing here,
>  	 * but there seems to be a hardware bug on the 405GP (RevD)
> @@ -655,6 +652,9 @@
>  	}
>  #endif /* CONFIG_MATH_EMULATION */
>
> +	if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
> +	    	return;
> +
>  	if (reason & REASON_FP) {
>  		/* IEEE FP exception */
>  		int code = 0;
Tried your patch against adeos-ipipe 1.3. But I still get the same behaviour. 
Here is my proc/cpuinfo.

$ cat /proc/cpuinfo
processor       : 0
cpu             : 405GPr
clock           : 400MHz
revision        : 9.81 (pvr 5091 0951)
bogomips        : 398.33
machine         : Netstal HCU3
plb bus clock   : 133MHz

U-Boot printed the following info:
CPU:   AMCC PowerPC 405GPr Rev. B at 400 MHz (PLB=133, OPB=33, EBC=33 MHz)
, PCI sync clock at 33 MHz       16 kB I-Cache 16 kB D-Cache

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Niklaus Giger]

Here is the stack with adeos-ipipe 1.3 after applying your patch 

(gdb) info stack
#0  xnpod_fault_handler (fltinfo=0xc1489e18) at 
kernel/xenomai/nucleus/pod.c:216
#1  0xc004bad4 in xnpod_trap_fault (fltinfo=0x73) at 
kernel/xenomai/nucleus/pod.c:2907
#2  0xc0043ee8 in xnarch_trap_fault (event=115, domid=0, data=0xc01a9435) at 
include/asm/xenomai/bits/init.h:46
#3  0xc012dc38 in exception_event (event=3223286668, ipd=0x0, data=0xc01a9435) 
at arch/ppc/xenomai/hal.c:385
#4  0xc003fe18 in __ipipe_dispatch_event (event=0, data=0xc1489f50) at 
kernel/ipipe/core.c:665
#5  0xc000aecc in do_page_fault (regs=0xc1489f50, address=268448708, 
error_code=0) at include/linux/ipipe.h:445
#6  0xc0003258 in handle_page_fault ()
Previous frame inner to this frame (corrupt stack?)
(gdb) 

Hope it helps you
-- 
Niklaus Giger

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Philippe Gerum]

On Tue, 2006-09-26 at 21:34 +0200, Niklaus Giger wrote:
> Here is the stack with adeos-ipipe 1.3 after applying your patch 
> 
> (gdb) info stack
> #0  xnpod_fault_handler (fltinfo=0xc1489e18) at 
> kernel/xenomai/nucleus/pod.c:216
> #1  0xc004bad4 in xnpod_trap_fault (fltinfo=0x73) at 
> kernel/xenomai/nucleus/pod.c:2907
> #2  0xc0043ee8 in xnarch_trap_fault (event=115, domid=0, data=0xc01a9435) at 
> include/asm/xenomai/bits/init.h:46
> #3  0xc012dc38 in exception_event (event=3223286668, ipd=0x0, data=0xc01a9435) 
> at arch/ppc/xenomai/hal.c:385
> #4  0xc003fe18 in __ipipe_dispatch_event (event=0, data=0xc1489f50) at 
> kernel/ipipe/core.c:665
> #5  0xc000aecc in do_page_fault (regs=0xc1489f50, address=268448708, 
> error_code=0) at include/linux/ipipe.h:445
> #6  0xc0003258 in handle_page_fault ()

The function parameters look weird, but the backtrace seems ok. This
tells us that it's not related to FPU emulation, but rather to an
invalid memory access.

> Previous frame inner to this frame (corrupt stack?)
> (gdb) 
> 
> Hope it helps you
-- 
Philippe.

Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
>> On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
>>> Niklaus Giger wrote:
> <..>
>> Ok, we can go for the lazy fix here, since this code is poised to
>> disappear anyway. I've merged a variant of the above we already use for
>> the ARM port, which scales down the period to microseconds instead of
>> losing precision on the count of timebase ticks per jiffy.
>>
>> - ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);
>> + ticks = (ns / 1000) * tb_ticks_per_jiffy / (1000000 / HZ);
> Thanks for finding this solution. I tried to understand mulhwu and 
> mulhwu_scale_factor but couldn't figure out a correct solution in a short 
> time.

I took me also some time to understand the meaning. mulhwu(a,b) returns 
the high 32 bits (32..63) of a*b. A possible quick fix could be:

   if (mulhwu(ns, tb_ticks_per_jiffy) > 0)
	ticks = (ns / 1000) * tb_ticks_per_jiffy / (1000000 / HZ);
   else
	ticks = ns * tb_ticks_per_jiffy / (1000000000 / HZ);

But Philippe already applied a reasonable fix.

> 
> The buildbot cannot presently power on and off my PPC405 target board, as the 
> my power outlet switching device is broken and has been sent back for a 
> remplacement.
> 
> I did however run some tests manually and have the following questions about 
> the output:
> Why do I get negative values for latenciy values?
> Is the output of lines like "Xenomai: Switching display-3238 to secondary mode 
> after exception #1025 from user-space at 0x100033c4 (pid 3240)" harmless or 
> the result of a activated CONFIG_XENO_OPT_DEBUG<..> option?
> 
> Mon Sep 25 20:20:33 UTC 2006
> running: ./run -- -T 5 -t2 # latency
> *
> *
> * Type ^C to stop this application.
> *
> Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
> user-space at 0x100033c4 (pid 3240)
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      -5.108|      -4.754|      -0.905|       0|      -5.108|      -0.905
> RTD|      -4.963|      -4.871|       1.155|       0|      -5.108|       1.155
> Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
> user-space at 0xfda9638 (pid 3240)
> RTD|      -4.963|      -4.758|      16.020|       0|      -5.108|      16.020
> RTD|      -6.313|      -4.861|      10.980|       0|      -6.313|      16.020
> Xenomai: Switching display-3238 to secondary mode after exception #1025 from 
> user-space at 0xfe7c1c4 (pid 3240)
> ---|------------|------------|------------|--------|-------------------------
> RTS|      -6.313|      -4.811|      16.020|       0|    00:00:05/00:00:05
> Xenomai: stopping RTDM services.
> 
> Best regards