1 files changed, 0 insertions, 65 deletions
diff --git a/c/src/lib/libbsp/shared/vmeUniverse/README.universe b/c/src/lib/libbsp/shared/vmeUniverse/README.universe
deleted file mode 100644
index 1059d8c806..0000000000
--- a/c/src/lib/libbsp/shared/vmeUniverse/README.universe
+++ /dev/null
@@ -1,65 +0,0 @@
-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);
-