blob: 1059d8c80633796c6209916df63770168be22589 (
plain) (
tree)
|
|
The tundra drivers are in a separate subdir
because they are maintained at SSRL outside of the
rtems CVS tree. The directory is called 'vmeUniverse'
for historic reasons. 'tundra' would be better
since we now support the tundra tsi148 as well...
Till Straumann <strauman@slac.stanford.edu> 1/2002, 2005, 2007
A BSP that wants to use these drivers
must implement the following headers / functionality:
- <bsp/pci.h> offering an API like 'libbsp/powerpc/shared/pci'
- <bsp/irq.h> offering the 'new style' RTEMS irq API
(like 'libbsp/powerpc/shared/irq').
- <libcpu/io.h> for the I/O operations (out_le32,in_le32, ..., out_be32,...)
- <libcpu/byteorder.h> for byte-swapping (st_le32, ld_le32, ..., st_be32,...)
- glue code that implements the 'VME.h' and 'VMEDMA.h' APIs
using the vmeUniverse and/or vmeTsi148 driver code.
The 'glue' code initializes appropriate VME/PCI windows when booting
and installs the VME interrupt manager.
The 'glue' may also use the 'bspVmeDmaList' code to implement generic
parts of linked-list DMA.
Boards with a 'universe' chip may use a pretty generic version of
the glue code that is defined in libbsp/powerpc/shared/vmeconfig.c,
libbsp/powerpc/shared/vme_universe.c, and
libbsp/powerpc/shared/vme_universe_dma.c. The board-specific parameters
are defined in a single BSP-specific file 'VMEConfig.h'. That's where
the actual addresses of VME/PCI windows are configured and where
interrupt wires can be assigned etc.
Read libbsp/powerpc/shared/VMEConfig.h for more information and use
it as a template. Note that BSP implementors should try *not* to
clone 'vmeconfig.c' but use the constants in VMEConfig.h
- The BSP should export 'VME.h' and 'VMEDMA.h' to applications
and encourage them to only use the API defined there in order
to make application code driver-independent. This will ensure
seamless portability of applications between the universe and Tsi148
drivers.
TESTING: A valuable tool for testing are the (substitute XXX for
'Universe' or 'Tsi148') routines:
vmeXXXMapCRG()
maps the controller registers to VME space so you
can test if you successfully can read/write from VME.
You can read or DMA the PCI configuration registers
and compare to what you expect (beware of endianness).
vmeXXXIntLoopbackTest()
this installs an ISR and then asserts an IRQ on the VME
backplane so you can verify that your interrupt routing
and handling really works.
NOTES: The universe may always issue MBLTs if a data width of 64-bit
is enabled (default for non-BLT addressing modes -- the
VME_AM_STD_xx_BLT / VME_AM_EXT_xx_BLT enforce 32-bit transfers).
Therefore, if you want to setup a outbound window that always
uses single cycles then you must explicitely request a data
width < 64, e.g.,
vmeUniverseMasterPortCfg(port, VME_AM_EXT_SUP_DATA | VME_MODE_DBW32, vme_addr, pci_addr, size);
|
