Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
On Thu, Apr 07, 2011 at 10:26:02PM +0200, Gilles Chanteperdrix wrote: On my side, I meant to say, the issue is in the implementation of the I-pipe one-shot timer, the function ipipe_mach_set_dec... I couldn't find anything wrong there, but I did find this... In ipipe_tsc_asm.S you have #ifndef CONFIG_CPU_ENDIAN_BE8 /* Little endian */ ldr r0, [r0] cmp r2, r0 adc r1, r3, #0 #else /* Big endian */ ldr r1, [r0] cmp r3, r1 adc r0, r2, #0 #endif /* Big endian */ but my .config has CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y CONFIG_CPU_BIG_ENDIAN=y # CONFIG_CPU_ENDIAN_BE8 is not set CONFIG_CPU_ENDIAN_BE32=y and the machine really is big endian, so that might make a difference. Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
In ipipe_tsc_asm.S you have at the end of the file... /* User-space entry-point: r0 is the hardware counter virtual address */ #ifndef CONFIG_CPU_BIG_ENDIAN /* Little endian */ ... #else /* Big endian */ /* Little endian */ 1: ldrr1, .LCdec16_last_tsc + 4 ldrip, [r0] ldrr2, .Ldec16_Clast_cnt ---^ Did you mean .LCdec16_last_tsc here? Thanks, Richard subs ip, r2, ip addcs ip, ip, #0x1 myldrd r2, r3, r3, .LCdec16_last_tsc cmpr1, r3 bne1b adds r1, ip, r3 adcr0, r2, #0 #endif /* Big endian */ usr_ret lr ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
Richard Cochran wrote: On Thu, Apr 07, 2011 at 10:26:02PM +0200, Gilles Chanteperdrix wrote: On my side, I meant to say, the issue is in the implementation of the I-pipe one-shot timer, the function ipipe_mach_set_dec... I couldn't find anything wrong there, but I did find this... In ipipe_tsc_asm.S you have #ifndef CONFIG_CPU_ENDIAN_BE8 /* Little endian */ ldr r0, [r0] cmp r2, r0 adc r1, r3, #0 #else /* Big endian */ ldr r1, [r0] cmp r3, r1 adc r0, r2, #0 #endif /* Big endian */ but my .config has CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y CONFIG_CPU_BIG_ENDIAN=y # CONFIG_CPU_ENDIAN_BE8 is not set CONFIG_CPU_ENDIAN_BE32=y and the machine really is big endian, so that might make a difference. Yes, you can try changing the #ifdef. But note also that the big endian code was never actually tested. So, you probably would be better compiling a little user-space application to test this tsc code. the Linksys WRT54GS is an ixp 425, right?. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
Richard Cochran wrote: In ipipe_tsc_asm.S you have at the end of the file... /* User-space entry-point: r0 is the hardware counter virtual address */ #ifndef CONFIG_CPU_BIG_ENDIAN /* Little endian */ ... #else /* Big endian */ /* Little endian */ 1: ldr r1, .LCdec16_last_tsc + 4 ldr ip, [r0] ldr r2, .Ldec16_Clast_cnt ---^ Did you mean .LCdec16_last_tsc here? You do not really care about this code, since it is for 16 bit decrementers (currently only the integrator or the S3C has this, and they are not big endian machines). But yes. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] ipipe arm: fix big endian tsc emulation code
This commit replaces the CONFIG_CPU_ENDIAN_BE8 macro with the more general CONFIG_CPU_BIG_ENDIAN one. Also we fix a typo. Signed-off-by: Richard Cochran richard.coch...@omicron.at --- arch/arm/kernel/ipipe_tsc_asm.S | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/kernel/ipipe_tsc_asm.S b/arch/arm/kernel/ipipe_tsc_asm.S index 7dfec60..ca2 100644 --- a/arch/arm/kernel/ipipe_tsc_asm.S +++ b/arch/arm/kernel/ipipe_tsc_asm.S @@ -43,7 +43,7 @@ __ipipe_freerunning_32: ldr r0, .LCfr32_cntr_addr /* User-space entry-point: r0 is the hardware counter virtual address */ myldrd r2, r3, r1, .LCfr32_last_tsc -#ifndef CONFIG_CPU_ENDIAN_BE8 +#ifndef CONFIG_CPU_BIG_ENDIAN /* Little endian */ ldr r0, [r0] cmp r2, r0 @@ -69,7 +69,7 @@ __ipipe_freerunning_countdown: ldr r0, .LCfrcd32_cntr_addr /* User-space entry-point: r0 is the hardware counter virtual address */ myldrd r2, r3, r1, .LCfrcd32_last_tsc -#ifndef CONFIG_CPU_ENDIAN_BE8 +#ifndef CONFIG_CPU_BIG_ENDIAN /* Little endian */ ldr r0, [r0] mvn r0, r0 @@ -98,7 +98,7 @@ __ipipe_freerunning_16: /* User-space entry-point: r0 is the hardware counter virtual address */ 1: myldrd r2, r3, r1, .LCfr16_last_tsc ldr ip, [r0] -#ifndef CONFIG_CPU_ENDIAN_BE8 +#ifndef CONFIG_CPU_BIG_ENDIAN /* Little endian */ ldr r1, .LCfr16_last_tsc cmp r1, r2 @@ -137,7 +137,7 @@ __ipipe_freerunning_16: __ipipe_decrementer_16: ldr r0, .LCdec16_cntr_addr /* User-space entry-point: r0 is the hardware counter virtual address */ -#ifndef CONFIG_CPU_ENDIAN_BE8 +#ifndef CONFIG_CPU_BIG_ENDIAN /* Little endian */ 1: ldr r1, .LCdec16_last_tsc ldr ip, [r0] @@ -153,7 +153,7 @@ __ipipe_decrementer_16: /* Little endian */ 1: ldr r1, .LCdec16_last_tsc + 4 ldr ip, [r0] - ldr r2, .Ldec16_Clast_cnt + ldr r2, .LCdec16_last_cnt subsip, r2, ip addcs ip, ip, #0x1 myldrd r2, r3, r3, .LCdec16_last_tsc -- 1.7.0.4 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
On Fri, Apr 08, 2011 at 08:16:17AM +0200, Gilles Chanteperdrix wrote: Yes, you can try changing the #ifdef. But note also that the big endian code was never actually tested. So, you probably would be better compiling a little user-space application to test this tsc code. Yes, it worked. I sent a patch for 2.6.33. the Linksys WRT54GS is an ixp 425, right?. I don't know about that one. The NSLU is ixp42x, but many people run it in little endian. Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
Gilles Chanteperdrix wrote: Richard Cochran wrote: I have been trying to bring my IXP425 based system up to date, and I have found an apparent regression. Everything worked fine with ipipe 2.6.30 and Xenomai 2.4. With 2.6.31 an ipipe kernel still boots, but starting with 2.6.33 the trouble begins (see below). I see that Gilles refactored the TSC emulation starting with 2.6.33. I wonder whether this could be the cause? What this modification does is that: - there is only one clocksource, which is now xenomai tsc, with a very high rating; - the tsc read code is written in assembly, and copied in the vectors page, the one at 0x. I think the ixp is a 32 bits free-running counter with match register, wich is a configuration I tested. So, I would tend to think that the issue is rather in the clock_events implementation. Just to explain a little further about this modification. The reasons for this refactoring are: - the TSC emulation code is factored, so that when porting to a new port, we avoid copy-pasting the TSC emulation; - it is written in assembly, because even for such a simple thing, I was unable to get gcc to generate optimal code without useless register moves; - it is ready for multi-SOCs kernels (all the TSC emulations are compiled-in, the one chosen is copied to the vectors page when the ipipe_tsc_register function is called). This is the direction ARM linux is going, if you followed the ARM wrestling on the linux-arm-kernel mailing list. - the Linux clocksource code also uses this TSC, this keeps it in cache, and gets us ready for hostrt (actually, hostrt is already there on ARM, what is missing is just the equivalent of the code that was sent to the ARM mailing list for x86_32). - and most of all, this implementation is in the vector page, so is available to user-space applications. This means that Xenomai user-space support can be compiled without any knowledge of the actual TSC involved. IOW, it means that Xenomai user-space support compiled with --enable-arm-mach=generic (which is going to be the default) can use TSC emulation.. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
Richard Cochran wrote: On Fri, Apr 08, 2011 at 08:16:17AM +0200, Gilles Chanteperdrix wrote: Yes, you can try changing the #ifdef. But note also that the big endian code was never actually tested. So, you probably would be better compiling a little user-space application to test this tsc code. Yes, it worked. I sent a patch for 2.6.33. the Linksys WRT54GS is an ixp 425, right?. I don't know about that one. The NSLU is ixp42x, but many people run it in little endian. Ok. Thanks queued. I will also add the hostrt stuff. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
On Fri, Apr 08, 2011 at 08:35:37AM +0200, Gilles Chanteperdrix wrote: Ok. Thanks queued. I will also add the hostrt stuff. BTW, patch works for both 2.6.33 and 2.6.35. Both are booting fine, now. Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
On Fri, Apr 08, 2011 at 08:35:03AM +0200, Gilles Chanteperdrix wrote: - the TSC emulation code is factored, so that when porting to a new port, we avoid copy-pasting the TSC emulation; The ARM porting page on the wiki is out of date with regards to this. - it is ready for multi-SOCs kernels (all the TSC emulations are compiled-in, the one chosen is copied to the vectors page when the ipipe_tsc_register function is called). This is the direction ARM linux is going, if you followed the ARM wrestling on the linux-arm-kernel mailing list. Yes, that thread was really entertaining ;) Thanks for all your good work, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] kernel threads crash
Hi
I'm trying to implement some gateway functionality in the kernel on a
emerson CPCI6200 board, but have run into some strange errors. The
kernel module is made up of two threads that run every 1 ms. I have also
made use of the rtpc dispatcher in rtnet to dispatch control messages
from a netlink socket to the RT part of my kernel module.
The problem is that when loaded the threads get suspended due to exceptions:
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0xb929cbc0
after exception #1792
or
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0x0 after
exception #1025
or
Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at 0xb911f940
after exception #1792
I have ported the gianfar driver from linux to rtnet.
The versions and hardware are listed below. The errors are most likely
due to faulty software on my part, but i would like to ask if there are
any known issues with the versions or hardware i'm using. I would also
like to ask if there are any ways of further debugging the errors as i
am not getting very far with the above messages.
System info:
Linux kernel: 2.6.29.6
i-pipe version: 2.7-04
processor: powerpc mpc8572
xenomai version: 2.5.3
rtnet version: 0.9.12
--
/Jesper
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] kernel threads crash
On Fri, 2011-04-08 at 14:58 +0200, Jesper Christensen wrote:
Hi
I'm trying to implement some gateway functionality in the kernel on a
emerson CPCI6200 board, but have run into some strange errors. The
kernel module is made up of two threads that run every 1 ms. I have also
made use of the rtpc dispatcher in rtnet to dispatch control messages
from a netlink socket to the RT part of my kernel module.
The problem is that when loaded the threads get suspended due to exceptions:
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0xb929cbc0
after exception #1792
or
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0x0 after
exception #1025
or
Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at 0xb911f940
after exception #1792
I have ported the gianfar driver from linux to rtnet.
The versions and hardware are listed below. The errors are most likely
due to faulty software on my part, but i would like to ask if there are
any known issues with the versions or hardware i'm using. I would also
like to ask if there are any ways of further debugging the errors as i
am not getting very far with the above messages.
A severe bug at kthread init was fixed in the 2.5.5.2 - 2.5.6 timeframe,
which would cause exactly the kind of weird behavior you are seeing
right now. The bug triggered random code execution due to stack memory
pollution at init on powerpc for Xenomai kthreads:
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=90699565cbce41f2cec193d57857bb5817efc19a
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=da20c20d4b4d892d40c657ad1d32ddb6d0ceb47c
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=a5886b354dc18f054b187b58cfbacfb60bccaf47
You need at the very least those three patches (from the top of my
head), but it would be much better to upgrade to 2.5.6.
System info:
Linux kernel: 2.6.29.6
i-pipe version: 2.7-04
processor: powerpc mpc8572
xenomai version: 2.5.3
rtnet version: 0.9.12
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] kernel threads crash
Thanks i'll give 2.5.6 a shot.
Also it has come to my attention that there is some source files
(arch/powerpc/platforms/85xx/cpci6200.c,
arch/powerpc/platforms/85xx/cpci6200.h,
arch/powerpc/platforms/85xx/cpci6200_timer.c) that are probably not
covered by the adeos patch. Am i correct in assuming these need some
work to support i-pipe?
/Jesper
On 2011-04-08 15:12, Philippe Gerum wrote:
On Fri, 2011-04-08 at 14:58 +0200, Jesper Christensen wrote:
Hi
I'm trying to implement some gateway functionality in the kernel on a
emerson CPCI6200 board, but have run into some strange errors. The
kernel module is made up of two threads that run every 1 ms. I have also
made use of the rtpc dispatcher in rtnet to dispatch control messages
from a netlink socket to the RT part of my kernel module.
The problem is that when loaded the threads get suspended due to exceptions:
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0xb929cbc0
after exception #1792
or
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0x0 after
exception #1025
or
Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at 0xb911f940
after exception #1792
I have ported the gianfar driver from linux to rtnet.
The versions and hardware are listed below. The errors are most likely
due to faulty software on my part, but i would like to ask if there are
any known issues with the versions or hardware i'm using. I would also
like to ask if there are any ways of further debugging the errors as i
am not getting very far with the above messages.
A severe bug at kthread init was fixed in the 2.5.5.2 - 2.5.6 timeframe,
which would cause exactly the kind of weird behavior you are seeing
right now. The bug triggered random code execution due to stack memory
pollution at init on powerpc for Xenomai kthreads:
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=90699565cbce41f2cec193d57857bb5817efc19a
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=da20c20d4b4d892d40c657ad1d32ddb6d0ceb47c
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=a5886b354dc18f054b187b58cfbacfb60bccaf47
You need at the very least those three patches (from the top of my
head), but it would be much better to upgrade to 2.5.6.
System info:
Linux kernel: 2.6.29.6
i-pipe version: 2.7-04
processor: powerpc mpc8572
xenomai version: 2.5.3
rtnet version: 0.9.12
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] kernel threads crash
On Fri, 2011-04-08 at 15:20 +0200, Jesper Christensen wrote:
Thanks i'll give 2.5.6 a shot.
Also it has come to my attention that there is some source files
(arch/powerpc/platforms/85xx/cpci6200.c,
arch/powerpc/platforms/85xx/cpci6200.h,
arch/powerpc/platforms/85xx/cpci6200_timer.c) that are probably not
covered by the adeos patch. Am i correct in assuming these need some
work to support i-pipe?
I can't tell since I have no access to them, this is probably not a
mainline port.
In any case, if any of those files implements the support for the
programmable interrupt controller, hw timer, gpios and/or any form of
cascaded interrupt handling, this is correct: they should be made I-pipe
aware.
/Jesper
On 2011-04-08 15:12, Philippe Gerum wrote:
On Fri, 2011-04-08 at 14:58 +0200, Jesper Christensen wrote:
Hi
I'm trying to implement some gateway functionality in the kernel on a
emerson CPCI6200 board, but have run into some strange errors. The
kernel module is made up of two threads that run every 1 ms. I have also
made use of the rtpc dispatcher in rtnet to dispatch control messages
from a netlink socket to the RT part of my kernel module.
The problem is that when loaded the threads get suspended due to
exceptions:
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0xb929cbc0
after exception #1792
or
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0x0 after
exception #1025
or
Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at 0xb911f940
after exception #1792
I have ported the gianfar driver from linux to rtnet.
The versions and hardware are listed below. The errors are most likely
due to faulty software on my part, but i would like to ask if there are
any known issues with the versions or hardware i'm using. I would also
like to ask if there are any ways of further debugging the errors as i
am not getting very far with the above messages.
A severe bug at kthread init was fixed in the 2.5.5.2 - 2.5.6 timeframe,
which would cause exactly the kind of weird behavior you are seeing
right now. The bug triggered random code execution due to stack memory
pollution at init on powerpc for Xenomai kthreads:
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=90699565cbce41f2cec193d57857bb5817efc19a
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=da20c20d4b4d892d40c657ad1d32ddb6d0ceb47c
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=a5886b354dc18f054b187b58cfbacfb60bccaf47
You need at the very least those three patches (from the top of my
head), but it would be much better to upgrade to 2.5.6.
System info:
Linux kernel: 2.6.29.6
i-pipe version: 2.7-04
processor: powerpc mpc8572
xenomai version: 2.5.3
rtnet version: 0.9.12
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] kernel threads crash
With the risk of jinx'ing it the 2.5.6 version seems to have done the
trick. Huge thanks to you Philippe, you have saved my head from
decapitation :)
/Jesper
On 2011-04-08 15:39, Philippe Gerum wrote:
On Fri, 2011-04-08 at 15:20 +0200, Jesper Christensen wrote:
Thanks i'll give 2.5.6 a shot.
Also it has come to my attention that there is some source files
(arch/powerpc/platforms/85xx/cpci6200.c,
arch/powerpc/platforms/85xx/cpci6200.h,
arch/powerpc/platforms/85xx/cpci6200_timer.c) that are probably not
covered by the adeos patch. Am i correct in assuming these need some
work to support i-pipe?
I can't tell since I have no access to them, this is probably not a
mainline port.
In any case, if any of those files implements the support for the
programmable interrupt controller, hw timer, gpios and/or any form of
cascaded interrupt handling, this is correct: they should be made I-pipe
aware.
/Jesper
On 2011-04-08 15:12, Philippe Gerum wrote:
On Fri, 2011-04-08 at 14:58 +0200, Jesper Christensen wrote:
Hi
I'm trying to implement some gateway functionality in the kernel on a
emerson CPCI6200 board, but have run into some strange errors. The
kernel module is made up of two threads that run every 1 ms. I have also
made use of the rtpc dispatcher in rtnet to dispatch control messages
from a netlink socket to the RT part of my kernel module.
The problem is that when loaded the threads get suspended due to
exceptions:
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0xb929cbc0
after exception #1792
or
Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0x0 after
exception #1025
or
Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at 0xb911f940
after exception #1792
I have ported the gianfar driver from linux to rtnet.
The versions and hardware are listed below. The errors are most likely
due to faulty software on my part, but i would like to ask if there are
any known issues with the versions or hardware i'm using. I would also
like to ask if there are any ways of further debugging the errors as i
am not getting very far with the above messages.
A severe bug at kthread init was fixed in the 2.5.5.2 - 2.5.6 timeframe,
which would cause exactly the kind of weird behavior you are seeing
right now. The bug triggered random code execution due to stack memory
pollution at init on powerpc for Xenomai kthreads:
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=90699565cbce41f2cec193d57857bb5817efc19a
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=da20c20d4b4d892d40c657ad1d32ddb6d0ceb47c
http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=a5886b354dc18f054b187b58cfbacfb60bccaf47
You need at the very least those three patches (from the top of my
head), but it would be much better to upgrade to 2.5.6.
System info:
Linux kernel: 2.6.29.6
i-pipe version: 2.7-04
processor: powerpc mpc8572
xenomai version: 2.5.3
rtnet version: 0.9.12
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] ARM IXP: ipipe regression from 2.6.31 to .33 and .35
Richard Cochran wrote: On Fri, Apr 08, 2011 at 08:35:03AM +0200, Gilles Chanteperdrix wrote: - the TSC emulation code is factored, so that when porting to a new port, we avoid copy-pasting the TSC emulation; The ARM porting page on the wiki is out of date with regards to this. Yes, and about the GPIO demuxing too. I will update it when I am done with the Panda port, which will allow me to document the SMP bits... - it is ready for multi-SOCs kernels (all the TSC emulations are compiled-in, the one chosen is copied to the vectors page when the ipipe_tsc_register function is called). This is the direction ARM linux is going, if you followed the ARM wrestling on the linux-arm-kernel mailing list. Yes, that thread was really entertaining ;) Thanks for all your good work, You are welcome, it is a pleasure to work with people who do not expect us to do all the fixing on our own. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] kernel threads crash
On Fri, Apr 08, 2011 at 02:58:33PM +0200, Jesper Christensen wrote: I have ported the gianfar driver from linux to rtnet. Can you publish this driver? I have been wanting to make a rtnet gianfar myself. Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
