forked from Imagelibrary/rtems
814eccb4cf
The VME support is only used by powerpc BSPs. This patch is a part of the BSP source reorganization. Update #3285.
66 lines
2.9 KiB
Plaintext
66 lines
2.9 KiB
Plaintext
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);
|
|
|