Re: [Xenomai-help] trouble running PEAK CAN board on Atom N270 with Xenomai 2.5.5.2

[Andrew Tannenbaum <trb@domain.hid>]

Jan Kiszka wrote:
> On 2011-05-31 18:52, Andrew Tannenbaum wrote:
>> I am having trouble getting my PEAK CAN board running under
>> Linux/Xenomai.  It crashes when it loads xeno_can_peak_pci.ko.
>>
>> I tried mailing to PEAK Linux support, but they said they had no one
>> providing Linux RT support at this time.
>>
>> I have an Advantech PCM-9361 PCI104 Atom N270 motherboard with a PEAK
>> PCI104 CAN 2-channel board.
>>
>> I plugged the CAN board into the Atom board, and I plugged a Copley
>> Accelnet servo into the first port of the CAN board.
>>
>> I installed a copy of Ubuntu 10.04.2 LTS on the Atom, that distro kernel
>> runs ok.
>>
>> I downloaded a copy of Linux 2.6.35.7 from kernel.org, and compiled it
>> (mostly with the Ubuntu distro config), that runs ok.
>>
>> I downloaded a copy of Xenomai 2.5.5.2 from xenomai.org, and patched the
>> 2.6.35.7 to provide basic Xenomai functionality, including POSIX and
>> RTDM interfaces, and I was able to run the Xenomai testsuite/latency
>> test with decent latency.
>>
>> Note that in my current kernel, I turned CONFIG_XENO_HW_SMI_WORKAROUND
>> off, because I had been getting the "SMI workaround failed" message:
>>
>> May 24 17:02:00 atom1 kernel: [    1.252782] I-pipe: Domain Xenomai
>> registered.
>> May 24 17:02:00 atom1 kernel: [    1.252900] Xenomai: hal/i386 started.
>> May 24 17:02:00 atom1 kernel: [    1.252960] Xenomai: scheduling class
>> idle registered.
>> May 24 17:02:00 atom1 kernel: [    1.252970] Xenomai: scheduling class
>> rt registered.
>> May 24 17:02:00 atom1 kernel: [    1.256862] Xenomai: real-time nucleus
>> v2.5.5.2 (Ghosts) loaded.
>> May 24 17:02:00 atom1 kernel: [    1.257212] Xenomai: SMI-enabled
>> chipset found
>> May 24 17:02:00 atom1 kernel: [    1.257238] Xenomai: SMI workaround
>> failed!
>> May 24 17:02:00 atom1 kernel: [    1.257328] Xenomai: starting native
>> API services.
>> May 24 17:02:00 atom1 kernel: [    1.257340] Xenomai: starting POSIX
>> services.
>> May 24 17:02:00 atom1 kernel: [    1.257430] Xenomai: starting RTDM
>> services.
>>
>> I understand that 2.5.6 is current Xenomai, but I started this a few
>> months ago, so I'm running 2.5.5.2.
>>
>> At this point, I was ready to try to talk with the PEAK CAN board, so I
>> turned on
>>
>> CONFIG_XENO_DRIVERS_CAN_SJA1000=m
>> CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_PCI=m
>>
>> Without driver support for the board, lspci sees the CAN board.  I want
>> to talk to the board using the Xenomai interface, but I am not sure of
>> the best way to make that work.
>>
>> I downloaded and compiled peak-linux-driver-7.2 (I'm not sure that is
>> necessary, so I won't discuss that yet.)
>>
>> Here is the PEAK board stanza from lspci -v:
>>
>> 01:04.0 Network controller: PEAK-System Technik GmbH PCAN-PCI CAN-Bus
>> controller (rev 02)
>>      Subsystem: PEAK-System Technik GmbH Device 0004
>>      Flags: medium devsel, IRQ 10
>>      Memory at fdcd0000 (32-bit, non-prefetchable) [size=64K]
>>      Memory at fdce0000 (32-bit, non-prefetchable) [size=64K]
>>      Kernel modules: xeno_can_peak_pci
>>
>> I have not been able to run a kernel that with the Xenomai/Linux CAN/PCI
>> driver.  It fails during the boot process when loading the PEAK driver.
>>
>> If I move the CAN/PEAK drivers out of the way, the kernel runs correctly
>> (as a Linux kernel - not talking with the CAN board).  I moved these
>> drivers aside, adding ".no" to the names:
>>
>> ./kernel/drivers/xenomai/can/sja1000/xeno_can_sja1000.ko.no
>> ./kernel/drivers/xenomai/can/sja1000/xeno_can_peak_pci.ko.no
>>
>> I can insmod these by hand, the SJA1000 driver loads ok, the PEAK driver
>> causes the system to freeze.  tail /var/log/syslog looks like this:
>>
>> May 31 12:14:25 atom1 kernel: [410578.847836] RTCAN SJA1000 driver
>> initialized
>> May 31 12:15:19 atom1 kernel: [410632.808061] PEAK-PCI-CAN: initializing
>> device 001c:0001
>> May 31 12:15:19 atom1 kernel: [410632.808106] PEAK-PCI-CAN 0000:01:04.0:
>> PCI INT A ->  GSI 16 (level, low) ->  IRQ 16
>
> Important are the IRQs reported while loading. The PCI config space data
> lspci is listing is more informational. If other devices share the same
> IRQ, you lose unless
>   - you can move those other devices elsewhere (change slot, disable
>     device)
>   - you can move the CAN adapter to a different slot, thus - maybe - to
>     a different IRQ
>
> Jan
>

Thanks, Jan.

I was able to get my board running.  For the benefit of others who might 
have the same problem I did:

The PEAK PCAN PC/104-Plus board has a hardware jumper (J9) for Interrupt 
Select.  The first position (INT A) was IRQ 16 on my system.  The second 
position (INT B) was IRQ 17, and that makes it work for me.  There are 3 
sets of jumpers: ID, Clock, and Interrupt.  The device manual says this:

"For communication with the host the PCAN-PC/104-Plus card uses
the PCI interface where specific relations between the lengths of the
signal lines must be met. Different line lengths result from different
positions of a PC/104-Plus card in a PC/104 stack. Therefore the
PCAN-PC/104-Plus card must be adjusted to a specific position in
the stack by setting the appropriate jumpers. The spatial distance to
the host results in the index for the assignment of the jumpers."

I didn't want to change Clock, since that might mess with the signal 
time settings for my board in the first position.  I did change the 
other two jumpers - ID and Interrupt.  When I only changed Interrupt, 
that didn't work (my kernel would crash when I loaded the PEAK driver).

Once I got it running, I was able to run the rtcan tools: rtcanconfig, 
rtcansend, and rtcanrecv.  The source and README for those are in 
xenomai-n.n.n/src/utils/can/ .  First I tried to run rtcansend followed 
by rtcanrecv (from the command line), but rtcanrecv would not find the 
answer messages.  When I ran rtcanrecv first (and it blocked) it would 
then get answers when I'd send messages with rtcansend (in another 
xterm).  Maybe I need to set a mode so that the answer messages will be 
held in a buffer, I'll have to check.

-Andy