There are many parts that need to be consistent, and many of our failed boots were from inconsistency in kernel version, 32 vs. 64 bit, software in /afs/slac/g/lcls/epics/R3-14-12-4_1-0 vs /afs/slac/g/lcls/epics/ etc.
kernel vers 3.2.13-121108
set extra-args ROOTPATH=afsnfs2:/afs/slac:/afs/slac
/afs/slac/g/lcls/epics/iocCommon/All/Dev/linuxRT_nfs.cmd
/afs/slac/g/lcls/epics/iocCommon/ioc-b34-cd43/kernel-modules.cmd
echo -n 1 > /sys/module/spurious/parameters/noirqdebug
su laci -c /afs/slac/g/lcls/epics/iocCommon/ioc-b34-cd43/startup-laci-rt.cmd
KERNEL_DRIVER_HOME=/afs/slac/g/lcls/package/linuxKernel_Modules
SIS8300_DRIVER=$KERNEL_DRIVER_HOME/sis8300drv/Branch_Straumann
PCI_EVR_DRIVER=$KERNEL_DRIVER_HOME/pci_mrfevr_linuxRT/buildroot-uclibc-x86
insmod $PCI_EVR_DRIVER/pci_mrfevr.ko
$PCI_EVR_DRIVER/module_load
modprobe uio
insmod $SIS8300_DRIVER/sis8300drv.ko
chmod ugo+wr /dev/sis*
ln -s /afs/slac/g/lcls/epics/iocCommon/ioc-b34-cd43 /home/root/bpm \[NOTE: should be /root, not /home/root, produced error message\]
standard ulimit/umask lines
nfs and kernel-module lines, redundant with startup.cmd
cd /afs/slac/g/lcls/epics/iocCommon/ioc-b34-cd43/vioc-in10-bp02
bin/bpmApp iocStartup.cmd
Standard pre/post
chdir("/afs/slac/g/lcls/epics/iocTop/Bpm/sonya/Bpm-R9-5-6/iocBoot/vioc-in10-bp02")
../../bin/linuxRT-x86/bpmApp
iocsh("st.cmd")
eltc(0)
kernel vers 3.14.12-rt9_x86_64
set extra-args ramdisk_size=524288 ROOTPATH=lcls-dev3:/afs/slac:/afs/slac BOOTFILE=/afs/slac/g/lcls/epics/R3-14-12-4_1-0/iocCommon/ioc-b34-cd43/startup.cmd
Soft link to $IOC/All/Dev/linuxRT_startup_cpu.cmd
Changed path to caRepeater:
su laci -c /afs/slac/g/lcls/epics/R3-14-12-4_1-0/base/base-R3-14-12-4_1-0/bin/linuxRT-x86_64/caRepeater&
Should we move caRepeater to kernel-modules.cmd? Is there a way to use the same script for 32 and 64 bit systems, and systems with different Base versions?
KERNEL_DRIVER_HOME=/afs/slac/g/lcls/package/linuxKernel_Modules
SIS8300_DRIVER=$KERNEL_DRIVER_HOME/sis8300drv/Branch_Straumann
PCI_EVR_DRIVER=$KERNEL_DRIVER_HOME/pci_mrfevr_linuxRT/buildroot-uclibc-x86_64
^ NOTE: Changed to _64 version ^
insmod $PCI_EVR_DRIVER/pci_mrfevr.ko
$PCI_EVR_DRIVER/module_load
modprobe uio
insmod $SIS8300_DRIVER/sis8300drv.ko
chmod ugo+wr /dev/sis*
ln -s /afs/slac/g/lcls/epics/iocCommon/ioc-b34-cd43 /home/root/bpm \[NOTE: should be /root, not /home/root, produced error message\]
standard ulimit/umask lines
cd /afs/slac/g/lcls/epics/iocCommon/vioc-b34-ev43
iocSpecificRelease/bin/linuxRT-x86_64/evrLab iocStartup.cmd
epicsEnvSet("IOC_APP","/afs/slac/g/lcls/epics/R3-14-12-4_1-0/iocTop/evrLab/MAIN_TRUNK")
epicsEnvSet("IOC_BOOT","${IOC_APP}/iocBoot/vioc-b34-ev43")
cd ${IOC_BOOT}
< st.cmd
All PMC EVRs had firmware 1107.
Tested with pci_mrfevr_linuxRT/buildroot-uclibc-x86\[_64\] driver, 32/64 bit driver with 32/64 bit kernel.
Initial testing with Bpm software use event-R4-1-0
Testing with Kukhee where we didn't have the button to make output 4 work (wrong screen used) was 32 bit version of evrLab app, event R4-1-5
Using this test setup with Vadatech carrier and breakout box, outputs 0-9 work. Trying to use outputs 10 and up produces error messages about pulse generators.
More notes from Garth & Kukhee testing:
1. HYTEC AMC carrier has an issue with interrupt. The EVR could not generate interrupt with the carrier. Garth and Kukhee did double check the EVR generates interrupts with other carrier: Vadatech. So, we isolated an issue on the HYTEC carrier.
2. The rear transition module works with the HYTEC carrier. But, the 4th channel is missing somehow. Other 6 channels work well.
3. The messages related pulse generator. There are limited number of pulse generated in the PMC module. So, we could not activate more than 10 triggers at the same times. If we tried to enable more than 10 triggers, we can see the message Sonya saw.
Later testing where we got channel 4 working, found no problems with channel mapping, was with 64 bit version of evrLab app, event-R4-1-5
The Fail LED flashes occasionally when using the HYTEC carrier card.
Check if interrupts are happening with this command: cat /proc/interrupts | grep mrf
You should see the numbers increasing at 720+ Hz.
The MRF EVR uses PLX9030 bridge chipset, the kernel driver set up the interrupt polarity active high.
