NetBSD/sys/arch/mvme68k
jdolecek 921705c3eb cleanup Makefiles, put common stuff to Makefile.booters, ditch unnecessary
stuff
make this all compile with -Wall -Wno-main -Wmissing-prototypes
	-Wstrict-prototypes -Werror , also compilable on 1.4.1
label itself as NetBSD/mvme68k instead of "BSD" in bootblock message
move bugcrt.c to libbug, remove bugcrt directory (bugcrt is still built
	and used separately to rest of libbug)
convert sboot to use ordinary mvme68 libsa, instead of copying needed
	stuff in libc_sa.c
convert to use version info generated by sys/conf/newvers_stand.sh
	instead of previous version.c files, add necessary 'version' files
put chiptotime() to separate libsa file (used also by sboot/clock.c)

Thanks to Steve Woodford for help with this. Note that -current build
might be hosed by this change, will be addressed by Steve shortly.
2000-07-24 18:39:01 +00:00
..
compile mvme68k port -- for the motorola vme147 m68030 card 1995-07-25 23:11:53 +00:00
conf Implement generic soft interrupts for mvme68k. 2000-07-20 20:40:34 +00:00
dev G/C cf_unit. It wasn't really being used in a meaningfull way. 2000-07-23 20:50:21 +00:00
include G/C the IIO* #defines. They're no longer needed. 2000-07-24 11:20:47 +00:00
mvme68k G/C a debugging printf left over from the last commit. 2000-07-21 08:08:38 +00:00
stand cleanup Makefiles, put common stuff to Makefile.booters, ditch unnecessary 2000-07-24 18:39:01 +00:00
Makefile Rework the way kernel include files are installed. In the new method, 1998-06-12 23:22:30 +00:00
README.VMEbus-RAM Remove paragraph describing problem with initialising VMEbus RAM cards' 1997-11-01 19:18:39 +00:00

	$NetBSD: README.VMEbus-RAM,v 1.2 1997/11/01 19:18:39 scw Exp $

NetBSD/mvme68k port: VMEbus RAM card configuration

As of version 1.3, NetBSD-mvme68k (for VME147) officially supports
additional RAM in A32 space over the VMEbus.

This file describes where to configure your VMEbus RAM and how to
point the kernel in the direction of it.

The MVME147 board has a fairly primitive VMEbus controller chip. The
mapping of cpu address to VMEbus address is hardwired and so dictates
what can be seen where by the 68030.

From the cpu's perspective, A24 space spans 0x00000000 to 0x00ffffff.
However, onboard RAM also spans this space. With 8Mb of onboard RAM,
only the top 8Mb of VMEbus A24 space can be seen. With 16Mb onboard,
there is no easy way to get at A24 space at all!

The cpu sees VMEbus A32 space starting from 0x01000000. The lowest
16Mb of A32 space is not accessable (it's covered either by onboard
RAM or A24 space). With 32Mb of onboard RAM, the cpu can address A32
space from 0x02000000 upwards. This still leaves a considerable chunk
of A32 space visible, so in practice isn't really a problem.

The best place for VMEbus RAM cards is in A32 space, at the address
given by:

	max(0x01000000, onboard_ram_size)

In my case, this would locate my 8Mb VMEbus RAM card at 0x01000000.

This starting address needs to be written to the MVME147's NVRAM at
address 0xfffe0764, as follows:

	147Bug> mm fffe0764 ;L
	FFFE0764 00000000? 01000000   <cr>	<--- you type 01000000
	FFFE0768 00000000? .          <cr>
	147Bug>

Next, you need to configure the end address of VMEbus RAM. Assuming
your RAM card is 8Mb in size, this would be 0x017fffff. You need to
write this value to NVRAM address 0xfffe0768, as follows:

	147Bug> mm fffe0768 ;L
	FFFE0768 00000000? 017fffff   <cr>	<--- you type 017fffff
	FFFE076c 00000000? .          <cr>
	147Bug>

You could obviously combine the above two steps.

If you have more than one VMEbus RAM card, you must configure them so
that they appear physically contiguous in A32 address space. So, to add
another 8Mb card in addition to the card above, it should be jumpered
to start at 0x01800000. In this case, you would change NVRAM location
0xfffe0768 to be 0x01ffffff.

If NVRAM location 0xfffe0764 is zero, the kernel assumes you only have
onboard RAM and will not attempt to use any VMEbus RAM.


Some extra notes on VMEbus RAM cards
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So... You've got your nice shiny VMEbus RAM card up and running with
NetBSD, and you're wondering why your system runs slower than it did
with less RAM!

The simple answer is "Motorola got it wrong". (Or at least that's my
opinion. If anyone can cure the following, let me know!)

In their infinite wisdom, the designers of the MVME147 decided that
they would disable the 68030's cache on *any* access to the VMEbus.
The upshot is that the cache only works for onboard RAM, not VMEbus
RAM, hence your system runs slower. As far as I can see, the only
way to cure this is to physically cut a trace on the circuit board
and use the MMU to control caching on a page-by-page basis...

Anyhow, hopefully the above instructions have finally put to rest
the most asked question about the mvme68k port.

Cheers,
Steve Woodford: scw@netbsd.org