Re: A24 access with 32MB onboard?

On Wednesday 26 November 2003 11:13 am, Henning Kiel wrote:

> Now the first question is more principle: can I access A24 cards with
> 32MB onboard mem? (as 32MB already fills the first 24bits address
> space)

Yes. mvme167's VME bridge is much more configurable compared to mvme147.

Apart from DRAM being in the same place, the mvme167's memory map is 
different to that of the mvme147. In particular, the mvme167 does not 
overlay DRAM on top of VME A24 space.

There is usually one default A24 window at 0xf0000000, but this is D16 
only. If you want a D32 window, you'll need to configure one manually 
from 167-Bug, as follows:

167-Bug> env
...
Master Enable #1 [Y/N] = Y?
Master Starting Address #1 = 02000000?
Master Ending Address #1   = EFFFFFFF? eeffffff		<--- change
Master Control #1 = 0D?
Master Enable #2 [Y/N] = N? y				<--- change
Master Starting Address #2 = 00000000? ef000000		<--- change
Master Ending Address #2   = 00000000? efffffff		<--- change
Master Control #2 = 00? 3d				<--- change
Master Enable #3 [Y/N] = N? .				<--- exit

Update Non-Volatile RAM (Y/N)? y

Reset Local System (CPU) (Y/N)? y

The above example will free up 16MB at the top of the existing A32/D32 
window (Master #1), and create a new A24/D32 window in that free space 
using Master #2. (Note: depending on how your mvme167 was configured 
previously, you might see different values for the Master windows. I 
suggest making sure Masters #3 and #4 are disabled, and that #1 and #2 
match the above example.)

So, you now need to mmap two regions in your program:

	0xf0000000 x 16MB	A24/D16
	0xef000000 x 16MB	A24/D32

Both regions map to A24 address space, but with different data sizes.

> I use the following code fragment, which worked on the 147.
> BTW I have the kernel "option INSECURE" compiled in. (is there a way
> to check this for the running kernel?)

Check the "kern.securelevel" sysctl variable. If it's >= 1, you cannot 
access /dev/mem.

> Does [the code] look ok?

The code looke more or less ok, other than needing to deal with two 
mmap'd regions instead of one.

Note: I recommend adding 'volatile' qualifiers to the type casts in your 
GetDxx() and PutDxx() macros...

Cheers, Steve