Home | History | Annotate | Line # | Download | only in docs 
      1     	$NetBSD: VMEbus-RAM,v 1.5 2023/09/30 20:15:54 andvar Exp $
      2     
      3     NetBSD/mvme68k: VMEbus RAM card configuration
      4     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      5     
      6     NetBSD-mvme68k can be configured to support additional RAM boards
      7     accessed over the VMEbus.
      8     
      9     This file describes where to configure your VMEbus RAM and how to
     10     point the kernel in the direction of it.
     11     
     12     The MVME147 board has a fairly primitive VMEbus controller chip. The
     13     mapping of CPU address to VMEbus address is hardwired and so dictates
     14     what can be seen where by the 68030. From the CPU's perspective, A24
     15     space spans 0x00000000 to 0x00ffffff. However, onboard RAM also spans
     16     this space. With 8Mb of onboard RAM, only the top 8Mb of VMEbus A24
     17     space can be seen. With 16Mb onboard, there is no easy way to get at
     18     A24 space at all!
     19     
     20     The other MVME boards have a more sophisticated VMEbus controller
     21     which can remap segments of VMEbus address space anywhere in the CPU's
     22     address space. This document will assume the remap is `transparent',
     23     ie. no translation is taking place. The same restriction as MVME147
     24     applies to these boards in that, without translation, a region of
     25     VMEbus address space is masked by onboard RAM. The size of this region
     26     depends entirely on the size of onboard RAM.
     27     
     28     The best place for VMEbus RAM cards is somewhere in A32D32 VMEbus address
     29     space. Obviously, if your VMEbus RAM card doesn't respond to that space
     30     then you'll have to locate it elsewhere. Typically, you may find it
     31     responds to A24D16 only, in which case the CPU-relative address you need
     32     to specify below will be in the 16MB region starting at 0xZZZZZZZZ.
     33     
     34     For A32D32, choose an address which is reasonably close to the end of the
     35     MVME board's RAM. That is, if you have 32MB of onboard RAM, set the
     36     VMEbus RAM board to appear at A32:02000000.
     37     
     38     This starting address needs to be written to the MVME board's NVRAM at
     39     address 0xfffe0764 for MVME147, and 0xff, as follows:
     40     
     41     	147Bug> mm fffe0764 ;L
     42     	FFFE0764 00000000? 01000000   <cr>	<--- you type 01000000
     43     	FFFE0768 00000000? .          <cr>
     44     	147Bug>
     45     
     46     Next, you need to configure the end address of VMEbus RAM. Assuming
     47     your RAM card is 8Mb in size, this would be 0x017fffff. You need to
     48     write this value to NVRAM address 0xfffe0768, as follows:
     49     
     50     	147Bug> mm fffe0768 ;L
     51     	FFFE0768 00000000? 017fffff   <cr>	<--- you type 017fffff
     52     	FFFE076c 00000000? .          <cr>
     53     	147Bug>
     54     
     55     You could obviously combine the above two steps.
     56     
     57     If you have more than one VMEbus RAM card, you must configure them so
     58     that they appear physically contiguous in A32 address space. So, to add
     59     another 8Mb card in addition to the card above, it should be jumpered
     60     to start at 0x01800000. In this case, you would change NVRAM location
     61     0xfffe0768 to be 0x01ffffff.
     62     
     63     If NVRAM location 0xfffe0764 is zero, the kernel assumes you only have
     64     onboard RAM and will not attempt to use any VMEbus RAM.
     65     
     66     
     67     Some extra notes on VMEbus RAM cards
     68     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     69     
     70     So... You've got your nice shiny VMEbus RAM card up and running with
     71     NetBSD, and you're wondering why your system runs slower than it did
     72     with less RAM!
     73     
     74     The simple answer is "Motorola got it wrong". (Or at least that's my
     75     opinion. If anyone can cure the following, let me know!)
     76     
     77     In their infinite wisdom, the designers of the MVME147 decided that
     78     they would disable the 68030's cache on *any* access to the VMEbus.
     79     The upshot is that the cache only works for onboard RAM, not VMEbus
     80     RAM, hence your system runs slower. As far as I can see, the only
     81     way to cure this is to physically cut a trace on the circuit board
     82     and use the MMU to control caching on a page-by-page basis...
     83     
     84     Anyhow, hopefully the above instructions have finally put to rest
     85     the most asked question about the mvme68k port.
     86     
     87     Cheers,
     88     Steve Woodford: scw (a] NetBSD.org
     89