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
------------------------------------------------------------------------------