1*c64267c6Sandvar $NetBSD: VMEbus-RAM,v 1.5 2023/09/30 20:15:54 andvar Exp $ 27fed4934Sscw 37fed4934SscwNetBSD/mvme68k: VMEbus RAM card configuration 47fed4934Sscw~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 57fed4934Sscw 67fed4934SscwNetBSD-mvme68k can be configured to support additional RAM boards 77fed4934Sscwaccessed over the VMEbus. 87fed4934Sscw 97fed4934SscwThis file describes where to configure your VMEbus RAM and how to 107fed4934Sscwpoint the kernel in the direction of it. 117fed4934Sscw 127fed4934SscwThe MVME147 board has a fairly primitive VMEbus controller chip. The 13d20841bbSwizmapping of CPU address to VMEbus address is hardwired and so dictates 14d20841bbSwizwhat can be seen where by the 68030. From the CPU's perspective, A24 157fed4934Sscwspace spans 0x00000000 to 0x00ffffff. However, onboard RAM also spans 167fed4934Sscwthis space. With 8Mb of onboard RAM, only the top 8Mb of VMEbus A24 177fed4934Sscwspace can be seen. With 16Mb onboard, there is no easy way to get at 187fed4934SscwA24 space at all! 197fed4934Sscw 207fed4934SscwThe other MVME boards have a more sophisticated VMEbus controller 217fed4934Sscwwhich can remap segments of VMEbus address space anywhere in the CPU's 227fed4934Sscwaddress space. This document will assume the remap is `transparent', 237fed4934Sscwie. no translation is taking place. The same restriction as MVME147 247fed4934Sscwapplies to these boards in that, without translation, a region of 257fed4934SscwVMEbus address space is masked by onboard RAM. The size of this region 267fed4934Sscwdepends entirely on the size of onboard RAM. 277fed4934Sscw 287fed4934SscwThe best place for VMEbus RAM cards is somewhere in A32D32 VMEbus address 297fed4934Sscwspace. Obviously, if your VMEbus RAM card doesn't respond to that space 307fed4934Sscwthen you'll have to locate it elsewhere. Typically, you may find it 317fed4934Sscwresponds to A24D16 only, in which case the CPU-relative address you need 327fed4934Sscwto specify below will be in the 16MB region starting at 0xZZZZZZZZ. 337fed4934Sscw 34*c64267c6SandvarFor A32D32, choose an address which is reasonably close to the end of the 357fed4934SscwMVME board's RAM. That is, if you have 32MB of onboard RAM, set the 367fed4934SscwVMEbus RAM board to appear at A32:02000000. 377fed4934Sscw 387fed4934SscwThis starting address needs to be written to the MVME board's NVRAM at 397fed4934Sscwaddress 0xfffe0764 for MVME147, and 0xff, as follows: 407fed4934Sscw 417fed4934Sscw 147Bug> mm fffe0764 ;L 427fed4934Sscw FFFE0764 00000000? 01000000 <cr> <--- you type 01000000 437fed4934Sscw FFFE0768 00000000? . <cr> 447fed4934Sscw 147Bug> 457fed4934Sscw 467fed4934SscwNext, you need to configure the end address of VMEbus RAM. Assuming 477fed4934Sscwyour RAM card is 8Mb in size, this would be 0x017fffff. You need to 487fed4934Sscwwrite this value to NVRAM address 0xfffe0768, as follows: 497fed4934Sscw 507fed4934Sscw 147Bug> mm fffe0768 ;L 517fed4934Sscw FFFE0768 00000000? 017fffff <cr> <--- you type 017fffff 527fed4934Sscw FFFE076c 00000000? . <cr> 537fed4934Sscw 147Bug> 547fed4934Sscw 557fed4934SscwYou could obviously combine the above two steps. 567fed4934Sscw 577fed4934SscwIf you have more than one VMEbus RAM card, you must configure them so 587fed4934Sscwthat they appear physically contiguous in A32 address space. So, to add 597fed4934Sscwanother 8Mb card in addition to the card above, it should be jumpered 607fed4934Sscwto start at 0x01800000. In this case, you would change NVRAM location 617fed4934Sscw0xfffe0768 to be 0x01ffffff. 627fed4934Sscw 637fed4934SscwIf NVRAM location 0xfffe0764 is zero, the kernel assumes you only have 647fed4934Sscwonboard RAM and will not attempt to use any VMEbus RAM. 657fed4934Sscw 667fed4934Sscw 677fed4934SscwSome extra notes on VMEbus RAM cards 687fed4934Sscw~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 697fed4934Sscw 707fed4934SscwSo... You've got your nice shiny VMEbus RAM card up and running with 717fed4934SscwNetBSD, and you're wondering why your system runs slower than it did 727fed4934Sscwwith less RAM! 737fed4934Sscw 747fed4934SscwThe simple answer is "Motorola got it wrong". (Or at least that's my 757fed4934Sscwopinion. If anyone can cure the following, let me know!) 767fed4934Sscw 777fed4934SscwIn their infinite wisdom, the designers of the MVME147 decided that 787fed4934Sscwthey would disable the 68030's cache on *any* access to the VMEbus. 797fed4934SscwThe upshot is that the cache only works for onboard RAM, not VMEbus 807fed4934SscwRAM, hence your system runs slower. As far as I can see, the only 817fed4934Sscwway to cure this is to physically cut a trace on the circuit board 827fed4934Sscwand use the MMU to control caching on a page-by-page basis... 837fed4934Sscw 847fed4934SscwAnyhow, hopefully the above instructions have finally put to rest 857fed4934Sscwthe most asked question about the mvme68k port. 867fed4934Sscw 877fed4934SscwCheers, 8829c72c57SkeihanSteve Woodford: scw@NetBSD.org 89