Subject: RE: Sun3/50 memory map
To: None <gwr@mc.com, hls@oce.nl>
From: Adam Glass <adamg@microsoft.com>
List: port-sun3
Date: 06/02/1994 14:34:00
| The changes look OK to me (makes buffer_map and phys_map pageaable).
| It didn't make a difference for me.  Did this fix something for you?
|

they are required for the new vm.

| > With these changes I was able to boot a kernel, based on the latest
| > kernel sources, up to the point where it consults BOOTP.
| > >From this point on, something is going very terribly wrong!!
| > I think this is caused by the fact, that the memory being used to
| > prepare this bootp-request, is part of the black and white memory
| > frame buffer of my SUN 3/50. At some point, the packets that are being
| > put on the network have the wrong ethernet source adresses!!!
|
| Yikes!  I don't have a 3/50 but that sounds interesting.  Adam has
| previously written that we need to turn on MACHINE_NONCONTIG for the
| ugly 3/50 memory map.  I wonder if we can just "allocate" the memory
| where the frame buffer lives to keep it from being mis-used. (Adam?)
|
| Gordon Ross
|
|

Was wondering when this would pop up.

The vm system is fed a range of physical addresses that represent the 
available physical address space.On a 3/50 this includes a hole at 1mb 
for some goofy frame buffer.

As far as I know there is no mechanism for pre-allocating that hole, 
particularly since its a physical address space hole. MACHINE__NONCONTIG
is the answer and a relatively easy one though it needs some 
synchronization with the vm bootstrap
code.

later,
Adam Glass

------------------------------------------------------------------------------