On 2011-06-01 00:07, Andrew Tannenbaum wrote: > 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
Good to hear. > 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. If you send a request to a web server that is not started yet, nothing will be buffered and processed later on when the service is finally up. The CAN stack does not behave differently here. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
