[Xenomai-core] insmod xeno_rtcan_mscan gets stuck on MPC5121
Dear all,
I'm currently evaluating xeno_rtcan_mscan driver on a phyCORE-MPC5121e.
I'm using linux-2.6.33.5 with Xenomai 2.5.6
(adeos-ipipe-2.6.33.5-powerpc-2.10-03.patch).
Kernel has been configured with CONFIG_XENO_DRIVERS_CAN_MSCAN
Everything is ok until module is been loaded: insmod xeno_can_mscan hangs.
$insmod xeno_can.ko
RT-Socket-CAN 0.90.2 - (C) 2006 RT-Socket-CAN Development Team
$insmod xeno_can_mscan.ko
= get stuck then
I went through module source code. Module loading is stuck in an endless
loop in rtcan_mscan_mode_stop routine in
ksrc/drivers/can/mscan/rtcan_mscan.c. The driver expects can controller
to acknowledge a sleep and init command.
Having a look at native linux source code shows a different way to
initialize CAN controller. A strategy is being implemented to avoid
being stuck here.
I've come to the attached patch to replicate native linux kernel module
behaviour regarding this init routine. Insterting patched module shows:
rtcan_mscan: device failed to enter sleep mode. We proceed anyhow.
rtcan: registered rtcan0
rtcan_mscan 80001300.mscan: MSCAN at 0xd314c300, irq 23, clock Hz
rtcan_mscan: device failed to enter sleep mode. We proceed anyhow.
rtcan: registered rtcan1
rtcan_mscan 80001380.mscan: MSCAN at 0xd3154380, irq 24, clock Hz
I've tested it successfully: i'm now able to load driver and to use it
(using canfestival for instance).
I'm not sure about the cause of this behaviour (e.g. chip revision, or
something else ?) but i'm quite confident it solves this issue.
Could someone advise on the modifications brought here?
Thanks in advance
Fabrice
Index: xenomai-2.5.6/ksrc/drivers/can/mscan/rtcan_mscan.c
===
--- xenomai-2.5.6.orig/ksrc/drivers/can/mscan/rtcan_mscan.c 2011-09-06 11:19:29.0 +0200
+++ xenomai-2.5.6/ksrc/drivers/can/mscan/rtcan_mscan.c 2011-09-06 14:20:03.0 +0200
@@ -40,6 +40,8 @@
#include rtcan_mscan_regs.h
#include rtcan_mscan.h
+#define MSCAN_SET_MODE_RETRIES 255
+
/**
* Reception Interrupt handler
*
@@ -294,31 +296,54 @@
rtdm_lockctx_t *lock_ctx)
{
int ret = 0;
- int rinit = 0;
+ int i=0;
can_state_t state;
struct mscan_regs *regs = (struct mscan_regs *)dev-base_addr;
- u8 reg;
+ u8 canctl1;
state = dev-state;
/* If controller is not operating anyway, go out */
if (!CAN_STATE_OPERATING(state))
goto out;
- /* Switch to sleep mode */
- setbits8(regs-canctl0, MSCAN_SLPRQ);
- setbits8(regs-canctl0, MSCAN_INITRQ);
-
- reg = in_8(regs-canctl1);
- while (!(reg MSCAN_SLPAK) ||
- !(reg MSCAN_INITAK)) {
- if (likely(lock_ctx != NULL))
- rtdm_lock_put_irqrestore(dev-device_lock, *lock_ctx);
- /* Busy sleep 1 microsecond */
- rtdm_task_busy_sleep(1000);
- if (likely(lock_ctx != NULL))
- rtdm_lock_get_irqsave(dev-device_lock, *lock_ctx);
- rinit++;
- reg = in_8(regs-canctl1);
+ canctl1 = in_8(regs-canctl1);
+ if (!(canctl1 MSCAN_SLPAK)) {
+ setbits8(regs-canctl0, MSCAN_SLPRQ);
+ for (i = 0; i MSCAN_SET_MODE_RETRIES; i++) {
+ if (in_8(regs-canctl1) MSCAN_SLPAK)
+break;
+ if (likely(lock_ctx != NULL))
+rtdm_lock_put_irqrestore(dev-device_lock, *lock_ctx);
+ /* Busy sleep 1 microsecond */
+ rtdm_task_busy_sleep(1000);
+ if (likely(lock_ctx != NULL))
+rtdm_lock_get_irqsave(dev-device_lock, *lock_ctx);
+ }
+ /*
+ * The mscan controller will fail to enter sleep mode,
+ * while there are irregular activities on bus, like
+ * somebody keeps retransmitting. This behavior is
+ * undocumented and seems to differ between mscan built
+ * in mpc5200b and mpc5200. We proceed in that case,
+ * since otherwise the slprq will be kept set and the
+ * controller will get stuck. NOTE: INITRQ or CSWAI
+ * will abort all active transmit actions, if still
+ * any, at once.
+ */
+ if (i = MSCAN_SET_MODE_RETRIES)
+ rtdm_printk(rtcan_mscan: device failed to enter sleep mode.
+We proceed anyhow.\n);
+ else
+ dev-state = CAN_STATE_SLEEPING;
+ }
+ if (!(canctl1 MSCAN_INITAK)) {
+ setbits8(regs-canctl0, MSCAN_INITRQ);
+ for (i = 0; i MSCAN_SET_MODE_RETRIES; i++) {
+ if (in_8(regs-canctl1) MSCAN_INITAK)
+break;
+ }
+ if (i = MSCAN_SET_MODE_RETRIES)
+ ret = -ENODEV;
}
/* Volatile state could have changed while we slept busy. */
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Xenomai 2.6.0-rc1
On 09/06/2011 11:15 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 20:19 +0200, Gilles Chanteperdrix wrote: On 09/06/2011 05:10 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote: On Tue, 2011-09-06 at 16:53 +0200, Philippe Gerum wrote: On Tue, 2011-09-06 at 16:19 +0200, Gilles Chanteperdrix wrote: On 09/06/2011 03:27 PM, Philippe Gerum wrote: On Tue, 2011-09-06 at 13:31 +0200, Gilles Chanteperdrix wrote: On 09/04/2011 10:52 PM, Gilles Chanteperdrix wrote: Hi, The first release candidate for the 2.6.0 version may be downloaded here: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc1.tar.bz2 Hi, currently 2.6.0-rc1 fails to build on 2.4 kernel, with errors related to vfile support. Do we really want to still support 2.4 kernels? That would not be a massive loss, but removing linux 2.4 support is more than a few hunks here and there, so this may not be the right thing to do ATM. Besides, it would be better not to leave the few linux 2.4 users out there without upgrade path to xenomai 2.6, since this will be the last maintained version from the Xenomai 2.x architecture. That stuff does not compile likely because the Config.in bits are not up to date, blame it on me. I'll make this build over linux 2.4 and commit the result today. No problem, I was not looking for someone to blame... Since you are at it, I have problems compiling the nios2 kernel too, but I am not sure I got the proper configuration file. HEAD builds fine based on the attached .config. Btw we now only support the MMU version (2.6.35.2) of this kernel over Xenomai 2.6. Reference tree is available there: url = git://sopc.et.ntust.edu.tw/git/linux-2.6.git branch = nios2mmu nommu support is discontinued for nios2 - people who depend on it should stick with Xenomai 2.5.x. Ok, still not building, maybe the commit number mentioned in the README is not up-to-date? The commit # is correct, but I suspect that your kernel tree does not have the files normally created by the SOPC builder anymore, these can't (may not actually) be included in the pipeline patch. In short, your tree might be missing the bits corresponding to the fpga design your build for, so basic symbols like HRCLOCK* and HRTIMER* are undefined. I'm building for a cyclone 3c25 from the NEEK kit, with SOPC files available from arch/nios2/boards/neek. Any valuable files in there on your side? (typically, include/asm/custom_fpga.h should contain definitions for our real-time clocks and timers) I create a file arch/nios2/hardware.mk, which contains: SYSPTF = /path/to/std_1s10.ptf CPU = cpu EXEMEM = sdram Then run the kernel compilation as for any other platform. Is it not sufficient? Perhaps my .ptf file is outdated? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
