The @code{svec.ko} is the only kernel module produced during compilation. It depends on @code{fmc.ko}, that must
be loaded first (unless you rely on automatic dependencies), and the Linux
VME bus infrastructure. It won't detect any SVECs unless a VME bus master/bridge driver is loaded
(such as the Tundra TSI148 @code{vmebridge.ko} driver used at CERN).
During load time, the driver must be supplied with the list of the slots occupied by SVEC cards and the LUNs that will
identify them in the system. Despite the SVEC being a VME64x card, there is no autodetection mechanism provided as it may be unsafe for certain older VME devices. The VME bus configuration can be supplied either when loading the driver, through module parameters or at any later time
through a sysfs interface (see @ref{SVEC Module Parameters} and @ref{User-Space Tools}) .
The @code{svec.ko} driver depends on @code{fmc.ko}, that must
be loaded first (unless you rely on automatic dependencies).
The example below shows how to load the driver on a system with two SVECs installed in slots 4 and 12:
@smallexample
modprobe fmc
modprobe svec slot=4,12 lun=0,1
@end smallexample
@code{svec.ko} registers as a VME driver and maps two VME windows, one as
CR/CSR space and another one A32/D32 for register access.
@b{Note:} The driver verifies the presence of the SVEC cards at a given slot by accesing their CSR registers which are geographically addressed. However,
providing an incorrect slot number pointing to a non-VME64x card may have unpredictable results.
For each new SVEC device found on the system, the driver performs the
following steps:
For each new SVEC device found on the system, the driver performs the following steps:
@itemize @bullet
@item It maps a VME CR/CSR window.
@item It loads the @code{fmc/svec_golden.bin} ``golden'' gateware file.
@item It maps a VME A32/D32 window.
@item It allocates two @i{fmc_device} structures and registers as
a new devices in the @i{fmc} bus.
@item Map a VME CR/CSR window for the particular slot.
@item Check if the card is present through the AFPGA bootloader interface.
@item Check if the driver has been supplied with VME window configuration via the module parameters.
@item If true, load the @code{fmc/svec-golden.bin} ``golden'' bitstream file (or any other bitstream configured through module parameters) and check what FMCs are connected.
@item Map the register access VME window (A24/A32).
@item Create two @i{fmc_device} structures and register as
new devices in the @i{fmc} bus.
@item If there is no VME configuration supplied, wait until the user sets up the VME window via sysfs and enumerate/startup the FMCs afterwards.
@end itemize
Failure of any of the above steps is fatal.
Failure of any of the above steps is considered fatal.
The suggested @code{svec_golden.bin} gateware binary is always available
The suggested @code{svec-golden.bin} gateware binary is always available
from the @i{files} area of the @i{svec-sw} project on @code{ohwr.org}.
The current binary version to be used with this software version is
In shared interrupt mode, the SVEC driver calls all registered FMC IRQ handlers until one of them has handled the interrupt by returing @code{IRQ_HANDLED}.
Requesting an IRQ in shared mode can be done by passing IRQF_SHARED flag to @code{fmc->op->irq_request()}.
If the interrupts are further multiplexed inside the FMC gateware, the driver must dispatch them accordingly.
This mode provides a simple abstraction for the Vectored Interrupt Controller (VIC), the standard BE-CO-HT HDL module for multiplexing
interrupts inside an FPGA. The advantage is plug and play enumeration of the interrupts and no sharing overhead. Requesting an IRQ in VIC mode is done by:
@itemize
@item passing the SDB base address of the core whose interrupt we want to via the @code{irq} field in @code{struct fmc_device}.
The first time the @code{irq_request} is called, the SVEC driver will detect the VIC and configure it accordingly. It therefore requires an SDB-enabled gateware with
correctly initialized VIC vector table. For more details, refer to [1].
@node sysfs interface
@chapter @code{sysfs} interface
The driver allows userspace programs to (re)configure each SVEC's VME interface through @code{sysfs} files. Such configuration
method is useful for systems containing multiple SVEC cards mixed with other VME devices (such as many of CERN VME frontends, where the configuration is stored in an external database).
The @code{sysfs} controls for a SVEC card (identified by a @code{LUN}) reside in @code{/sys/bus/vme/devices/svec.LUN/} directory:
@smallexample
# ls -l /sys/bus/vme/devices/svec.0/
-rw-r--r-- 1 root root 4096 Aug 30 16:26 bootloader_active
-rw-r--r-- 1 root root 4096 Aug 30 11:53 configured
-rw-r--r-- 1 root root 4096 Aug 30 16:26 firmware_name
-rw-r--r-- 1 root root 4096 Aug 30 11:53 interrupt_level
-rw-r--r-- 1 root root 4096 Aug 30 11:53 interrupt_vector
-r--r--r-- 1 root root 4096 Aug 30 11:53 slot
-rw-r--r-- 1 root root 4096 Aug 30 11:53 use_fmc
-rw-r--r-- 1 root root 4096 Aug 30 11:57 vme_addr
-rw-r--r-- 1 root root 4096 Aug 30 11:53 vme_am
-rw-r--r-- 1 root root 4096 Aug 30 11:53 vme_base
-rw-r--r-- 1 root root 4096 Aug 30 11:57 vme_data
-rw-r--r-- 1 root root 4096 Aug 30 11:53 vme_size
@end smallexample
@subsection Configuring the VME interface
VME configuration is done by writing the VME window parameters to appropriate files and afterwards, committing the changes by writing 1 to @code{configured} file:
@smallexample
# cd /sys/bus/vme/devices/svec.0
# echo 0x39 > vme_am
# echo 0xa00000 > vme_base
# echo 0x100000 > vme_size
# echo 0x80 > interupt_vector
# echo 1 > configured
@end smallexample
The example above will configure a 1 MiB A24 window at @code{0xa00000}, and a VME interrupt at vector @code{0x80}. Alternatively, you can use the @code{svec-config} tool, documented in the next section.
Reading the @code{configured} file lets you check if the card has been already configured by someone else.
@b{Note 1:} VME reconfiguration causes the card's firmware and FMC drivers to be reloaded.
@b{Note 2:} Readback values of the VME parameters are updated when the configuration is committed.
@b{Warning 1:} The driver performs some trivial checks on the VME window/interrupt parameters, but it is still possible to crash the system by assigning a configuration that conflicts with other VME cards.
@b{Warning 2:} If the driver is to be configured via @code{sysfs}, it will almost always load without errors (unless there is no SVEC in the specified slot). If there's something wrong (with the SVEC config or the attached FMC drivers), the errors will be triggered during userspace reconfiguration.
@subsection Raw access to the VME registers
This is handled via the @code{vme_addr} and @code{vme_data} attributes.
In order to read something from a given address, put the address in @code{vme_addr} file and then read the @code{vme_data} file. Writes are done in the same way.
@b{Note:} Raw VME access through @code{sysfs} works only if the VME register window is correctly configured.
To-Do. Not supported for the current driver version.
