[Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

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

Hi,

 

I was trying to upgrade my application running on Viper (2.6.16.28 kernel
with xenomai 2.3.1)  to 

kernel 2.6.30.10 with xenomai 2.4.10 and ran into couple of problems.

 

1. My application uses real-time hook to CPLD interrupt, which is chained
interrupt.

   Xenomai 2.4.10 for some reason assigns general purpose interrupt handler
to I-pipe  acknowledgment handler :

 

in kernel/irq/chip.c:

 

               

 


[-- Attachment #2: Type: text/html, Size: 2561 bytes --]

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
> Hi,
> 
>  
> 
> I was trying to upgrade my application running on Viper (2.6.16.28 kernel
> with xenomai 2.3.1)  to 
> 
> kernel 2.6.30.10 with xenomai 2.4.10 and ran into couple of problems.
> 
>  
> 
> 1. My application uses real-time hook to CPLD interrupt, which is chained
> interrupt.
> 
>    Xenomai 2.4.10 for some reason assigns general purpose interrupt handler
> to I-pipe  acknowledgment handler :
> 
>  
> 
> in kernel/irq/chip.c:

Looks like you hit the send button without finishing your message ?

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

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

Hi,

 

I was trying to upgrade my application running on Viper (2.6.16.28 kernel
with xenomai 2.3.1)  to 

kernel 2.6.30.10 with xenomai 2.4.10 and ran into couple of problems.

 

1. My application uses real-time hook to CPLD interrupt, which is chained
interrupt.

   In Xenomai 2.4.10 for some reason general purpose interrupt handler for
chained interrupt is assigned  to I-pipe  acknowledgment handler during
board initialization:

 

in kernel/irq/chip.c:  

 

_set_irq_hanler(...

 

#ifdef CONFIG_IPIPE

               else if (is_chained) {

               desc->ipipe_ack = handle;

               desc->ipipe_end = &__ipipe_noend_irq;

               handle = &__ipipe_noack_irq;

#endif    

 

As a result, when CPLD interrupt happened, general purpose interrupt from
Linux domain is executed as part of ipipe interrupt acknowledgment. After
that my real-time interrupt handler gets executed. This is not normal, as my
handler supposed to replace general purpose handler, which should not be
executed at all, unless I want it to be executed.  I  fixed this problem by
reassigning ipipe acknowledgment to __ipipe_ack_edge_irq, and not changing
handler at all, and it worked in my case. But this probably can break some
other code.

 

2. USB on Viepr is not working with I-pipe.  

 

I found the cause of this problem. Again for some reason, I-pipe patch
changes type of the USB and all other multiplexed interrupts from edge to
level interrupt, which they are in original Linux kernel. Of course, this
breaks everything. I fixed USB by changing back interrupts type from level
to edge in arch/arm/plat-pxa/gpio.c:

 

void __intit pxa_init_gpio(

               instead of 

#ifndef CONFIG_IPIPE

               set_irq_handler(irq,handle_edge_irq);

#else

               set_irq_handler(irq,handle_level_irq);

#endif

 

I'm using just 

               set_irq_handler(irq,handle_edge_irq);

, as it was in original Linux code and everything works fine.

 

Shouldn't changes to interrupt code in Xenomai depend on particular board
and not be part of the common code? 

 

I would appreciate any response regarding these issues.

 

Regards,

 

Ivan

 


[-- Attachment #2: Type: text/html, Size: 6113 bytes --]

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
> Hi,
> 
>  
> 
> I was trying to upgrade my application running on Viper (2.6.16.28 kernel
> with xenomai 2.3.1)  to 
> 
> kernel 2.6.30.10 with xenomai 2.4.10 and ran into couple of problems.

Yes good idea, old patches contain a deadly bug which has been fixed
only recently. Going one step further, I think you should try Xenomai
2.5.0. It really has interesting features for ARM, such as unlocked
context switch, which really decreases interrupt latency.

> 
>  
> 
> 1. My application uses real-time hook to CPLD interrupt, which is chained
> interrupt.
> 
>    In Xenomai 2.4.10 for some reason general purpose interrupt handler for
> chained interrupt is assigned  to I-pipe  acknowledgment handler during
> board initialization:
> 
>  
> 
> in kernel/irq/chip.c:  
> 
>  
> 
> _set_irq_hanler(...
> 
>  
> 
> #ifdef CONFIG_IPIPE
> 
>                else if (is_chained) {
> 
>                desc->ipipe_ack = handle;
> 
>                desc->ipipe_end = &__ipipe_noend_irq;
> 
>                handle = &__ipipe_noack_irq;
> 
> #endif    
> 
>  
> 
> As a result, when CPLD interrupt happened, general purpose interrupt from
> Linux domain is executed as part of ipipe interrupt acknowledgment. After
> that my real-time interrupt handler gets executed. This is not normal, as my
> handler supposed to replace general purpose handler, which should not be
> executed at all, unless I want it to be executed.  I  fixed this problem by
> reassigning ipipe acknowledgment to __ipipe_ack_edge_irq, and not changing
> handler at all, and it worked in my case. But this probably can break some
> other code.

It looks like the I-pipe generic code is trying to get a generic demux
code, whereas on arm, the demux code is done another way. So, the two
solutions collide.

However, the new solution is more attractive, since it avoids
duplicating the irq demux code in ipipe mode. Will fix.

Actually, the fix is simple, remove completely ipipe_mach_demux_irq and
get the linux demux code to call __ipipe_handle_irq instead of
handle_irq, with an #ifdef CONFIG_IPIPE. Like:

#ifndef CONFIG_IPIPE
	handle_irq(whatever);
#else
	__ipipe_handle_irq(whatever else);
#endif

> 2. USB on Viepr is not working with I-pipe.  
> 
>  
> 
> I found the cause of this problem. Again for some reason, I-pipe patch
> changes type of the USB and all other multiplexed interrupts from edge to
> level interrupt, which they are in original Linux kernel. Of course, this
> breaks everything. I fixed USB by changing back interrupts type from level
> to edge in arch/arm/plat-pxa/gpio.c:
> 
>  
> 
> void __intit pxa_init_gpio(
> 
>                instead of 
> 
> #ifndef CONFIG_IPIPE
> 
>                set_irq_handler(irq,handle_edge_irq);
> 
> #else
> 
>                set_irq_handler(irq,handle_level_irq);
> 
> #endif
> 
>  
> 
> I'm using just 
> 
>                set_irq_handler(irq,handle_edge_irq);
> 
> , as it was in original Linux code and everything works fine.
> 
>  
> 
> Shouldn't changes to interrupt code in Xenomai depend on particular board
> and not be part of the common code? 

handle_edge_irq is a misnomer, it should be called
"handle_edge_irq_by_bogus_interrupt_controller"
handle_level_irq is perfectly fine for edge irqs if the interrupt
controller does not loose edge irqs when they are masked.

The point is that handle_edge_irq is incompatible with Xenomai. So, we
replace handle_edge_irq with handle_level_irq in the hope that your edge
controller is not buggy. I did not invent this, I read it on the linux
arm kernel mailing list, and for the sake of preempt_rt, people are
doing the same thing (only without a #ifdef) in the mainline kernel,
they maybe even did it in 2.6.33, or it is pending for 2.6.34.

The point is: you think that everything works fine, but I really doubt
it. Normally, with handle_edge_irq, the I-pipes receives the irq, acks
it, does not mask it, and then go to some other business with irqs on,
the problem is that since the interrupt handler was not run, the
peripheral from which originates the interrupt may trigger it again, and
then you get a lock-up. This is what the code you disabled fixes. And
this is the only fix we have at hand for now.

The interrupt controller depends on the SOC you are using, so normally,
if the PXA controller is not buggy, it should not be buggy on any PXA.
Now, if it does not work for your board, it may be for several reasons,
I would appreciate if you could trace the reason why handle_level_irq
does not work, because it should.

I would also be curious to know why handle_edge_irq works with USB
driver. Maybe the USB driver has some quirks for this case?

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Ivan Kalatchev wrote:
>> and not be part of the common code? 
> 
> handle_edge_irq is a misnomer, it should be called
> "handle_edge_irq_by_bogus_interrupt_controller"
> handle_level_irq is perfectly fine for edge irqs if the interrupt
> controller does not loose edge irqs when they are masked.
> 
> The point is that handle_edge_irq is incompatible with Xenomai. So, we
> replace handle_edge_irq with handle_level_irq in the hope that your edge
> controller is not buggy. I did not invent this, I read it on the linux
> arm kernel mailing list, and for the sake of preempt_rt, people are
> doing the same thing (only without a #ifdef) in the mainline kernel,
> they maybe even did it in 2.6.33, or it is pending for 2.6.34.
> 
> The point is: you think that everything works fine, but I really doubt
> it. Normally, with handle_edge_irq, the I-pipes receives the irq, acks
> it, does not mask it, and then go to some other business with irqs on,
> the problem is that since the interrupt handler was not run, the
> peripheral from which originates the interrupt may trigger it again, and
> then you get a lock-up. This is what the code you disabled fixes. And
> this is the only fix we have at hand for now.

Ok, I have dug the linux arm kernel mailing list archives. It turns out
that PXA, SA1100 and AT91 have buggy PICs which need absolutely
handle_edge_irq.

That said, I think that the lockup issue does not happen with any
peripheral when the interrupt controller is configured in edge mode. I
think the problem happens when a peripheral with a "level" behaviour is
plugged on a pin configured as edge.

In short, you are right, we will ask people who have the lockup issue to
call set_irq_handler(handle_level_irq) for the drivers who have the
problem. Only, the way you presented your mail made me think that your
modification was a hacker's random change rather than a fully thought
out/documented one.

-- 
					    Gilles.

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
> Hi Gilles,
> 
>> Yes good idea, old patches contain a deadly bug which has been
>> fixed only recently. Going one step further, I think you should try
>> Xenomai 2.5.0. It really has interesting features for ARM, such as
>> unlocked context switch, which really decreases interrupt latency.
>> 
> 
> I actually did try 2.5.0, but problem was I couldn't compile it. My
> compiler fails when it reaches src/skins/native/timer.c:
> 
> --------- Making all in src make[1]: Entering directory
> `/mnt/drive-1/build/xenomai-2.5.0/src' Making all in include make[2]:
> Entering directory `/mnt/drive-1/build/xenomai-2.5.0/src/include' 
> make  all-am make[3]: Entering directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/include' make[3]: Nothing to be
> done for `all-am'. make[3]: Leaving directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/include' make[2]: Leaving
> directory `/mnt/drive-1/build/xenomai-2.5.0/src/include' Making all
> in rtdk make[2]: Entering directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/rtdk' make[2]: Nothing to be
> done for `all'. make[2]: Leaving directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/rtdk' Making all in skins 
> make[2]: Entering directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/skins' Making all in common 
> make[3]: Entering directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/skins/common' make[3]: Nothing
> to be done for `all'. make[3]: Leaving directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/skins/common' Making all in
> native make[3]: Entering directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/skins/native' /bin/sh
> ../../../libtool  --tag=CC   --mode=compile arm-linux-gcc
> -DHAVE_CONFIG_ H -I. -I../../../src/include  -O2 -D_GNU_SOURCE
> -D_REENTRANT -Wall -pipe -march= armv5 -D__XENO__ -D__IN_XENO__
> -Wstrict-prototypes -I../../../include    -MT lib native_la-timer.lo
> -MD -MP -MF .deps/libnative_la-timer.Tpo -c -o libnative_la-t imer.lo
> `test -f 'timer.c' || echo './'`timer.c libtool: compile:
> arm-linux-gcc -DHAVE_CONFIG_H -I. -I../../../src/include -O2
> -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv5 -D__XENO__
> -D__IN_XENO__ -Ws trict-prototypes -I../../../include -MT
> libnative_la-timer.lo -MD -MP -MF .deps/ libnative_la-timer.Tpo -c
> timer.c  -fPIC -DPIC -o .libs/libnative_la-timer.o {standard input}:
> Assembler messages: {standard input}:115: Error: register or shift
> expression expected -- `adds r5,r 8,lsr#31' {standard input}:116:
> Error: register expected, not '#0' -- `adcs r0,#0' {standard
> input}:117: Error: register expected, not '#0' -- `adc r1,#0' 
> {standard input}:119: Error: bad arguments to instruction -- `adds
> r5,r8' {standard input}:120: Error: bad arguments to instruction --
> `adcs r0,r9' {standard input}:121: Error: register expected, not '#0'
> -- `adc r1,#0' {standard input}:123: Error: bad arguments to
> instruction -- `adds r5,r8' {standard input}:124: Error: bad
> arguments to instruction -- `adcs r0,r9' {standard input}:125: Error:
> register expected, not '#0' -- `adc r1,#0' {standard input}:177:
> Error: register or shift expression expected -- `adds r5,r 8,lsr#31' 
> {standard input}:178: Error: register expected, not '#0' -- `adcs
> r0,#0' {standard input}:179: Error: register expected, not '#0' --
> `adc r1,#0' {standard input}:181: Error: bad arguments to instruction
> -- `adds r5,r8' {standard input}:182: Error: bad arguments to
> instruction -- `adcs r0,r9' {standard input}:183: Error: register
> expected, not '#0' -- `adc r1,#0' {standard input}:185: Error: bad
> arguments to instruction -- `adds r5,r8' {standard input}:186: Error:
> bad arguments to instruction -- `adcs r0,r9' {standard input}:187:
> Error: register expected, not '#0' -- `adc r1,#0' make[3]: ***
> [libnative_la-timer.lo] Error 1 make[3]: Leaving directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/skins/native' make[2]: ***
> [all-recursive] Error 1 make[2]: Leaving directory
> `/mnt/drive-1/build/xenomai-2.5.0/src/skins' make[1]: ***
> [all-recursive] Error 1 make[1]: Leaving directory
> `/mnt/drive-1/build/xenomai-2.5.0/src' make: *** [all-recursive]
> Error 1
> 
> I looked at time.c but couldn't figure out what's causing this.

It comes from a macro written in assembly in include/asm-arm/arith.h.
However, this code compiles fine here for armv5. You are probably using
a toolchain that is incompatible with this assembly code. What version
of binutils are you using? If that is not hard to you, please upgrade to
a more recent toolchain. Otherwise, we will try to get your assembly to
accept this code (but looking at the error messages, it looks hopeless).

> 
> 
>> The interrupt controller depends on the SOC you are using, so
>> normally, if the PXA controller is not buggy, it should not be
>> buggy on any PXA. Now, if it does not work for your board, it may
>> be for several reasons, I would appreciate if you could trace the
>> reason why handle_level_irq does not work, because it should.
>> 
>> I would also be curious to know why handle_edge_irq works with USB 
>> driver. Maybe the USB driver has some quirks for this case?
> 
> I did trace the reason. (took me long time, as the only tool I have -
> printk). The regular linux kernel when doing chained interrupts

I also use only printk.

> doesn't call mask/unmask for MUX interrupts during 'demultiplexing'
> of chained interrupt. So mask of the MUX interrupt stays as it was
> set during enabling of MUX interrupt - enabled. But when Xenomai
> changed interrupt handler to be level_irq, it calls mask_ack_irq
> during acknowledgment - see __ipipe_ack_level_irq. As a result, MAX
> mask is assigned to 0 and MAX interrupt became disabled for some
> time. Looks like just because it happens during walking of pipe line
> when interrupts are enabled, it runs into conflict with hardware that
> supposed to produce trigger at this moment.

Yes, the PXA interrupt controller is bogus, and needs the interrupts to
remain enabled to work, as explained in another mail.

Please do not forget to CC the list.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

 Gilles,

> It comes from a macro written in assembly in include/asm-arm/arith.h.
> However, this code compiles fine here for armv5. You are probably using
> a toolchain that is incompatible with this assembly code. What version
> of binutils are you using? If that is not hard to you, please upgrade
> to
> a more recent toolchain. Otherwise, we will try to get your assembly to
> accept this code (but looking at the error messages, it looks
> hopeless).

I'm using original toolchain that came with development for Viper board from Arcom. That probably was time of 2.4 kernels...
Trouble with upgrading of toolchain I'm afraid of - is that all packages, libraries etc., that I used thus far with our embedded application will become obsolete and will need to be recompiled with this new compiler.

As to my first problem with assigning of general interrupt handler to chained irq acknowledgment, I'll try to change my code to go with it, as my real-time handler for chained interrupt does actually call some 'acknowledgment' that is based on general interrupt handler. It's just it took quite a time to figure out weird behaviour of my application when 
I switched to new Xenomai and couldn't find any info about how Xenomai changes chained interrupts handling. That caused some frustration. May be there should be some sort of Howto about it on Xenomai site?

Thanks a lot for you help.

Best regards,

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
> Gilles,
> 
>> It comes from a macro written in assembly in
>> include/asm-arm/arith.h. However, this code compiles fine here for
>> armv5. You are probably using a toolchain that is incompatible with
>> this assembly code. What version of binutils are you using? If that
>> is not hard to you, please upgrade to a more recent toolchain.
>> Otherwise, we will try to get your assembly to accept this code
>> (but looking at the error messages, it looks hopeless).
> 
> I'm using original toolchain that came with development for Viper
> board from Arcom. That probably was time of 2.4 kernels... Trouble
> with upgrading of toolchain I'm afraid of - is that all packages,
> libraries etc., that I used thus far with our embedded application
> will become obsolete and will need to be recompiled with this new
> compiler.

Ok, what version of gcc/binutils ? You can workaround this build issue,
by using the generic implementation of xnarch_nodiv_llimd. In
incldude/asm-arm/arith.h, replace

#if __LINUX_ARM_ARCH >= 4
with
#if __LINUX_ARM_ARCH >= 4 && __GNUC__ >= 4

Assuming that your gcc version is 3.something.

> 
> As to my first problem with assigning of general interrupt handler to
> chained irq acknowledgment, I'll try to change my code to go with it,

Please try what I told you: replacing handle_irq with __ipipe_handle_irq
in Linux' original irq handler.

> as my real-time handler for chained interrupt does actually call some
> 'acknowledgment' that is based on general interrupt handler. It's
> just it took quite a time to figure out weird behaviour of my
> application when I switched to new Xenomai and couldn't find any info
> about how Xenomai changes chained interrupts handling. That caused
> some frustration. May be there should be some sort of Howto about it
> on Xenomai site?

Actually this is described in the howto porting the I-pipe for arm to a
new board:
http://www.xenomai.org/index.php/I-pipe:ArmPorting#New_variables_and_functions
see ipipe_irq_mux_p and ipipe_demux_irq

But the problem is that the generic code changed and I missed that
change, so the old way is documented, not the new one.

> 
> Thanks a lot for you help.
> 
> Best regards,
> 
> Ivan
> 
> 
> 
> _______________________________________________ Xenomai-help mailing
> list Xenomai-help@domain.hid https://mail.gna.org/listinfo/xenomai-help


-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> Ok, what version of gcc/binutils ? You can workaround this build issue,
> by using the generic implementation of xnarch_nodiv_llimd. In
> incldude/asm-arm/arith.h, replace
> 
> #if __LINUX_ARM_ARCH >= 4
> with
> #if __LINUX_ARM_ARCH >= 4 && __GNUC__ >= 4
> 


my gcc is 3.3.4

I changed arith.h as you suggested, and it compiled, but then linker couldn't find rthal_arm_nodiv_ullimd definition, as
there is no  code for it for __GNUC__ < 4.


> Please try what I told you: replacing handle_irq with
> __ipipe_handle_irq

I need CPLD MUX interrupts (which are ISA interrupts in my case) to be real-time. How that should be done then - request real-time CPLD interrupt with empty handler and request each ISA interrupt as real-time handler as well?

Regard,

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>> Ok, what version of gcc/binutils ? You can workaround this build
>> issue, by using the generic implementation of xnarch_nodiv_llimd.
>> In incldude/asm-arm/arith.h, replace
>> 
>> #if __LINUX_ARM_ARCH >= 4 with #if __LINUX_ARM_ARCH >= 4 &&
>> __GNUC__ >= 4
>> 
> 
> 
> my gcc is 3.3.4
> 
> I changed arith.h as you suggested, and it compiled, but then linker
> couldn't find rthal_arm_nodiv_ullimd definition, as there is no  code
> for it for __GNUC__ < 4.

Ok, you need to change the other #ifdef a bit further.

> 
> 
>> Please try what I told you: replacing handle_irq with 
>> __ipipe_handle_irq
> 
> I need CPLD MUX interrupts (which are ISA interrupts in my case) to
> be real-time. How that should be done then - request real-time CPLD
> interrupt with empty handler and request each ISA interrupt as
> real-time handler as well?

No, just requet the ISA interrupt you want to use. Do not touch the mux
interrupts parent. This should work transparently.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> > my gcc is 3.3.4
> >
> > I changed arith.h as you suggested, and it compiled, but then linker
> > couldn't find rthal_arm_nodiv_ullimd definition, as there is no  code
> > for it for __GNUC__ < 4.
> 
> Ok, you need to change the other #ifdef a bit further.

When I added __GNUC__ >= 4 to both #if __LINUX_ARM_ARCH__ in asm-arm/arith.h, 
I again received compiler error for some reason. 
Is there way to do what nodiv_ullimd is doing through Linux's do_div ? That's what I usually use.


> >
> >
> >> Please try what I told you: replacing handle_irq with
> >> __ipipe_handle_irq
> >

I tried and it worked perfectly well!!!
Now my code is straightforward, much simpler and nicer. Thanks a lot!

Regards,

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>>> my gcc is 3.3.4
>>>
>>> I changed arith.h as you suggested, and it compiled, but then linker
>>> couldn't find rthal_arm_nodiv_ullimd definition, as there is no  code
>>> for it for __GNUC__ < 4.
>> Ok, you need to change the other #ifdef a bit further.
> 
> When I added __GNUC__ >= 4 to both #if __LINUX_ARM_ARCH__ in asm-arm/arith.h, 
> I again received compiler error for some reason. 
> Is there way to do what nodiv_ullimd is doing through Linux's do_div ? That's what I usually use.

It works here, I replaced both #ifdef, and it compiles. do_div is slow,
nodiv_ullimd uses no division.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>>> my gcc is 3.3.4
>>> 
>>> I changed arith.h as you suggested, and it compiled, but then
>>> linker couldn't find rthal_arm_nodiv_ullimd definition, as there
>>> is no  code for it for __GNUC__ < 4.
>> Ok, you need to change the other #ifdef a bit further.
> 
> When I added __GNUC__ >= 4 to both #if __LINUX_ARM_ARCH__ in
> asm-arm/arith.h, I again received compiler error for some reason. Is
> there way to do what nodiv_ullimd is doing through Linux's do_div ?
> That's what I usually use.

If you are interested in nodiv_llimd vs do_div based llimd, see the test
case named "arith".

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

Thanks,

I'll do that

Best regards,

Ivan

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
> electrons.com]
> Sent: January-12-10 3:05 PM
> To: Ivan Kalatchev
> Cc: 'Xenomai help'
> Subject: Re: [Xenomai-help] Viper board (ARM XScale) problems with
> Xenomai-2.4.10
> 
> Ivan Kalatchev wrote:
> >>> my gcc is 3.3.4
> >>>
> >>> I changed arith.h as you suggested, and it compiled, but then
> >>> linker couldn't find rthal_arm_nodiv_ullimd definition, as there
> >>> is no  code for it for __GNUC__ < 4.
> >> Ok, you need to change the other #ifdef a bit further.
> >
> > When I added __GNUC__ >= 4 to both #if __LINUX_ARM_ARCH__ in
> > asm-arm/arith.h, I again received compiler error for some reason. Is
> > there way to do what nodiv_ullimd is doing through Linux's do_div ?
> > That's what I usually use.
> 
> If you are interested in nodiv_llimd vs do_div based llimd, see the
> test
> case named "arith".
> 
> --
> Gilles Chanteperdrix, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> >> Ok, you need to change the other #ifdef a bit further.
> >
> > When I added __GNUC__ >= 4 to both #if __LINUX_ARM_ARCH__ in
> > asm-arm/arith.h, I again received compiler error for some reason. 

Looks like my compiler stumbles at __rthal_add96and64 as well, that's why I can't compile it.

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>>>> Ok, you need to change the other #ifdef a bit further.
>>> When I added __GNUC__ >= 4 to both #if __LINUX_ARM_ARCH__ in 
>>> asm-arm/arith.h, I again received compiler error for some reason.
>>> 
> 
> Looks like my compiler stumbles at __rthal_add96and64 as well, that's
> why I can't compile it.

Could you show me the error messages? The assembly sequence is pretty
simple.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> 
> Could you show me the error messages? The assembly sequence is pretty
> simple.
> 

{standard input}:142: Error: bad arguments to instruction -- `adds r0,lr'
{standard input}:143: Error: bad arguments to instruction -- `adcs ip,r2'
{standard input}:144: Error: register expected, not '#0' -- `adc r3,#0'
{standard input}:148: Error: bad arguments to instruction -- `adds r0,r4'
{standard input}:149: Error: bad arguments to instruction -- `adcs ip,r1'
{standard input}:150: Error: register expected, not '#0' -- `adc r3,#0'
{standard input}:152: Error: bad arguments to instruction -- `adds r0,r5'
{standard input}:153: Error: bad arguments to instruction -- `adcs ip,r2'
{standard input}:154: Error: register expected, not '#0' -- `adc r3,#0'
{standard input}:224: Error: bad arguments to instruction -- `adds r4,r8'
{standard input}:225: Error: bad arguments to instruction -- `adcs r5,ip'
{standard input}:226: Error: register expected, not '#0' -- `adc r3,#0'
{standard input}:228: Error: bad arguments to instruction -- `adds r4,r9'
{standard input}:229: Error: bad arguments to instruction -- `adcs r5,lr'
{standard input}:230: Error: register expected, not '#0' -- `adc r3,#0'
{standard input}:237: Error: bad arguments to instruction -- `adds r4,fp'
{standard input}:238: Error: bad arguments to instruction -- `adcs r5,ip'

I just checked ARM instructions and adds for instance should be  
	adds r0,r1,r2  # where r0 = r1 + r2

but in arith.h there are only 2 arguments ??

Regards,

Ivan 

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>> Could you show me the error messages? The assembly sequence is pretty
>> simple.
>>
> 
> {standard input}:142: Error: bad arguments to instruction -- `adds r0,lr'
> {standard input}:143: Error: bad arguments to instruction -- `adcs ip,r2'
> {standard input}:144: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:148: Error: bad arguments to instruction -- `adds r0,r4'
> {standard input}:149: Error: bad arguments to instruction -- `adcs ip,r1'
> {standard input}:150: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:152: Error: bad arguments to instruction -- `adds r0,r5'
> {standard input}:153: Error: bad arguments to instruction -- `adcs ip,r2'
> {standard input}:154: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:224: Error: bad arguments to instruction -- `adds r4,r8'
> {standard input}:225: Error: bad arguments to instruction -- `adcs r5,ip'
> {standard input}:226: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:228: Error: bad arguments to instruction -- `adds r4,r9'
> {standard input}:229: Error: bad arguments to instruction -- `adcs r5,lr'
> {standard input}:230: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:237: Error: bad arguments to instruction -- `adds r4,fp'
> {standard input}:238: Error: bad arguments to instruction -- `adcs r5,ip'
> 
> I just checked ARM instructions and adds for instance should be  
> 	adds r0,r1,r2  # where r0 = r1 + r2
> 
> but in arith.h there are only 2 arguments ??

Well, we probably do not check the same ARM manual, because mine allows
adds with two arguments. Anyway, you can try to fix the assembly. I
guess you can repeat the first argument before each add. Otherwise, I
can send you a .o, which I will ask you to disassemble to know what your
version of binutils wants.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>> Could you show me the error messages? The assembly sequence is pretty
>> simple.
>>
> 
> {standard input}:142: Error: bad arguments to instruction -- `adds r0,lr'
> {standard input}:143: Error: bad arguments to instruction -- `adcs ip,r2'
> {standard input}:144: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:148: Error: bad arguments to instruction -- `adds r0,r4'
> {standard input}:149: Error: bad arguments to instruction -- `adcs ip,r1'
> {standard input}:150: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:152: Error: bad arguments to instruction -- `adds r0,r5'
> {standard input}:153: Error: bad arguments to instruction -- `adcs ip,r2'
> {standard input}:154: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:224: Error: bad arguments to instruction -- `adds r4,r8'
> {standard input}:225: Error: bad arguments to instruction -- `adcs r5,ip'
> {standard input}:226: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:228: Error: bad arguments to instruction -- `adds r4,r9'
> {standard input}:229: Error: bad arguments to instruction -- `adcs r5,lr'
> {standard input}:230: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:237: Error: bad arguments to instruction -- `adds r4,fp'
> {standard input}:238: Error: bad arguments to instruction -- `adcs r5,ip'
> 
> I just checked ARM instructions and adds for instance should be  
> 	adds r0,r1,r2  # where r0 = r1 + r2
> 
> but in arith.h there are only 2 arguments ??

Ok, forgot I had a gcc 3.3.4 here, I can do the tests myself. I will
send you a patch once done.

-- 
					    Gilles.

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>> Could you show me the error messages? The assembly sequence is pretty
>> simple.
>>
> 
> {standard input}:142: Error: bad arguments to instruction -- `adds r0,lr'
> {standard input}:143: Error: bad arguments to instruction -- `adcs ip,r2'
> {standard input}:144: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:148: Error: bad arguments to instruction -- `adds r0,r4'
> {standard input}:149: Error: bad arguments to instruction -- `adcs ip,r1'
> {standard input}:150: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:152: Error: bad arguments to instruction -- `adds r0,r5'
> {standard input}:153: Error: bad arguments to instruction -- `adcs ip,r2'
> {standard input}:154: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:224: Error: bad arguments to instruction -- `adds r4,r8'
> {standard input}:225: Error: bad arguments to instruction -- `adcs r5,ip'
> {standard input}:226: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:228: Error: bad arguments to instruction -- `adds r4,r9'
> {standard input}:229: Error: bad arguments to instruction -- `adcs r5,lr'
> {standard input}:230: Error: register expected, not '#0' -- `adc r3,#0'
> {standard input}:237: Error: bad arguments to instruction -- `adds r4,fp'
> {standard input}:238: Error: bad arguments to instruction -- `adcs r5,ip'
> 
> I just checked ARM instructions and adds for instance should be  
> 	adds r0,r1,r2  # where r0 = r1 + r2
> 
> but in arith.h there are only 2 arguments ??

Ok. The attached patch seems to fix it. Note however that I could not 
finish a linux 2.6.30 kernel compilation with my old toolchain because 
of s some assembly error in mm/page_alloc.c, looks like a toolchain bug 
detected by the kernel (.err is invoked directly).

I ran the arith unit test on arm926ejs. the do_div based llimd 
implementation gives:
out of line llimd: 0x79364d9364d9362f: 9880.462 ns, rejected 11/10000
that is almost 10us
the C version of nodiv_llimd (with 3 lines of inline assembly) gives:
out of line nodiv_llimd: 0x79364d9364d9362f: 551.893 ns, rejected 26/10000
the arm assembly version of nodiv_llimd gives:
out of line nodiv_llimd: 0x79364d9364d9362f: 379.022 ns, rejected 29/10000

Here comes the patch:
diff --git a/include/asm-arm/arith.h b/include/asm-arm/arith.h
index eca69ba..6908681 100644
--- a/include/asm-arm/arith.h
+++ b/include/asm-arm/arith.h
@@ -14,9 +14,9 @@ rthal_arm_nodiv_ullimd(const unsigned long long op,
 #else /* arm <= v3 */
 #define __rthal_add96and64(l0, l1, l2, s0, s1)         \
        do {                                            \
-               __asm__ ("adds %2, %4\n\t"              \
-                        "adcs %1, %3\n\t"              \
-                        "adc %0, #0\n\t"               \
+               __asm__ ("adds %2, %2, %4\n\t"          \
+                        "adcs %1, %1, %3\n\t"          \
+                        "adc %0, %0, #0\n\t"           \
                         : "+r"(l0), "+r"(l1), "+r"(l2) \
                         : "r"(s0), "r"(s1): "cc");     \
        } while (0)
@@ -46,17 +46,17 @@ rthal_arm_nodiv_ullimd(const unsigned long long op,

        __asm__ ("umull %[tl], %[rl], %[opl], %[fracl]\n\t"
                 "umull %[rm], %[rh], %[oph], %[frach]\n\t"
-                "adds %[rl], %[tl], lsr #31\n\t"
-                "adcs %[rm], #0\n\t"
-                "adc %[rh], #0\n\t"
+                "adds %[rl], %[rl], %[tl], lsr #31\n\t"
+                "adcs %[rm], %[rm], #0\n\t"
+                "adc %[rh], %[rh], #0\n\t"
                 "umull %[tl], %[th], %[oph], %[fracl]\n\t"
-                "adds %[rl], %[tl]\n\t"
-                "adcs %[rm], %[th]\n\t"
-                "adc %[rh], #0\n\t"
+                "adds %[rl], %[rl], %[tl]\n\t"
+                "adcs %[rm], %[rm], %[th]\n\t"
+                "adc %[rh], %[rh], #0\n\t"
                 "umull %[tl], %[th], %[opl], %[frach]\n\t"
-                "adds %[rl], %[tl]\n\t"
-                "adcs %[rm], %[th]\n\t"
-                "adc %[rh], #0\n\t"
+                "adds %[rl], %[rl], %[tl]\n\t"
+                "adcs %[rm], %[rm], %[th]\n\t"
+                "adc %[rh], %[rh], #0\n\t"
                 "umlal %[rm], %[rh], %[opl], %[integ]\n\t"
                 "mla %[rh], %[oph], %[integ], %[rh]\n\t"
                 : [rl]"=r"(rl), [rm]"=r"(rm), [rh]"=r"(rh),

Regards.

-- 
					    Gilles.

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> Here comes the patch:
> diff --git a/include/asm-arm/arith.h b/include/asm-arm/arith.h
> index eca69ba..6908681 100644
> --- a/include/asm-arm/arith.h
> +++ b/include/asm-arm/arith.h
> @@ -14,9 +14,9 @@ rthal_arm_nodiv_ullimd(const unsigned long long op,
>  #else /* arm <= v3 */
>  #define __rthal_add96and64(l0, l1, l2, s0, s1)         \
>         do {                                            \
> -               __asm__ ("adds %2, %4\n\t"              \
> -                        "adcs %1, %3\n\t"              \
> -                        "adc %0, #0\n\t"               \
> +               __asm__ ("adds %2, %2, %4\n\t"          \
> +                        "adcs %1, %1, %3\n\t"          \
> +                        "adc %0, %0, #0\n\t"           \
>                          : "+r"(l0), "+r"(l1), "+r"(l2) \
>                          : "r"(s0), "r"(s1): "cc");     \
>         } while (0)
> @@ -46,17 +46,17 @@ rthal_arm_nodiv_ullimd(const unsigned long long op,
> 
>         __asm__ ("umull %[tl], %[rl], %[opl], %[fracl]\n\t"
>                  "umull %[rm], %[rh], %[oph], %[frach]\n\t"
> -                "adds %[rl], %[tl], lsr #31\n\t"
> -                "adcs %[rm], #0\n\t"
> -                "adc %[rh], #0\n\t"
> +                "adds %[rl], %[rl], %[tl], lsr #31\n\t"
> +                "adcs %[rm], %[rm], #0\n\t"
> +                "adc %[rh], %[rh], #0\n\t"
>                  "umull %[tl], %[th], %[oph], %[fracl]\n\t"
> -                "adds %[rl], %[tl]\n\t"
> -                "adcs %[rm], %[th]\n\t"
> -                "adc %[rh], #0\n\t"
> +                "adds %[rl], %[rl], %[tl]\n\t"
> +                "adcs %[rm], %[rm], %[th]\n\t"
> +                "adc %[rh], %[rh], #0\n\t"
>                  "umull %[tl], %[th], %[opl], %[frach]\n\t"
> -                "adds %[rl], %[tl]\n\t"
> -                "adcs %[rm], %[th]\n\t"
> -                "adc %[rh], #0\n\t"
> +                "adds %[rl], %[rl], %[tl]\n\t"
> +                "adcs %[rm], %[rm], %[th]\n\t"
> +                "adc %[rh], %[rh], #0\n\t"
>                  "umlal %[rm], %[rh], %[opl], %[integ]\n\t"
>                  "mla %[rh], %[oph], %[integ], %[rh]\n\t"
>                  : [rl]"=r"(rl), [rm]"=r"(rm), [rh]"=r"(rh),
> 

Hi Gilles,

Repeating of the first argument did solved the problem! I've built 2.5.0 and will start to play with it.
By the way, for some reason patch itself didn't work - said something about malformed patch at line 16:

	@@ -46,17 +46,17 @@ rthal_arm_nodiv_ullimd(const unsigned long long op,

 I couldn't see what the problem was, so just updated everything manually.

Thanks a lot for your help.
Best regards,

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
> Hi Gilles,
> 
> Repeating of the first argument did solved the problem! I've built
> 2.5.0 and will start to play with it. By the way, for some reason
> patch itself didn't work - said something about malformed patch at
> line 16:
> 
> @@ -46,17 +46,17 @@ rthal_arm_nodiv_ullimd(const unsigned long long
> op,
> 
> I couldn't see what the problem was, so just updated everything
> manually.

Sorry, my fault, I pasted the patch from terminal emulator, but this
does not work, my terminal emulator converts tabs to spaces, patch wants
tabs.

-- 
					    Gilles.

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> > May be there should be some sort of Howto about it
> > on Xenomai site?
> 
> Actually this is described in the howto porting the I-pipe for arm to a
> new board:
> http://www.xenomai.org/index.php/I-
> pipe:ArmPorting#New_variables_and_functions
> see ipipe_irq_mux_p and ipipe_demux_irq
> 
> But the problem is that the generic code changed and I missed that
> change, so the old way is documented, not the new one.

I actually read that document, but thing is that CPLD interrupt on Viper is not MUX interrupt, although it is chained interrupt. That's why I missed it. So may be HOWTO should still mention chained interrupts specifically in addition to MUX interrupts. Just a thought.

Regards,

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>>> May be there should be some sort of Howto about it on Xenomai
>>> site?
>> Actually this is described in the howto porting the I-pipe for arm
>> to a new board: http://www.xenomai.org/index.php/I- 
>> pipe:ArmPorting#New_variables_and_functions see ipipe_irq_mux_p and
>> ipipe_demux_irq
>> 
>> But the problem is that the generic code changed and I missed that 
>> change, so the old way is documented, not the new one.
> 
> I actually read that document, but thing is that CPLD interrupt on
> Viper is not MUX interrupt, although it is chained interrupt. That's
> why I missed it. So may be HOWTO should still mention chained
> interrupts specifically in addition to MUX interrupts. Just a
> thought.

Chained interrupt and muxed interrupt are the same thing.

-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Ivan Kalatchev]

> 
> Chained interrupt and muxed interrupt are the same thing.
> 

Then may be for Viper __ipipe_mach_irq_mux_p should be
	__ipipe_mach_irq_mux_p(irq)(((irq)== IRQ_GPIO_2_x) || ((irq)==gpio_to_irq(VIPER_CPLD_GPIO)))
?

Then it would take care of viper handling CPLD IRQ automatically.

Regards,

Ivan

Re: [Xenomai-help] Viper board (ARM XScale) problems with Xenomai-2.4.10

[Gilles Chanteperdrix]

Ivan Kalatchev wrote:
>> Chained interrupt and muxed interrupt are the same thing.
>>
> 
> Then may be for Viper __ipipe_mach_irq_mux_p should be
> 	__ipipe_mach_irq_mux_p(irq)(((irq)== IRQ_GPIO_2_x) || ((irq)==gpio_to_irq(VIPER_CPLD_GPIO)))
> ?
> 
> Then it would take care of viper handling CPLD IRQ automatically.

Yes, that would be the old way. But as you pointed out, the code
changed, so the new way, is to avoid duplicating the demux code into an
__ipipe_mach_demux_irq function and simply conditionnaly replace
handle_irq with __ipipe_handle_irq in Linux demux code.


-- 
Gilles Chanteperdrix, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com