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);