Subject: RE: Sun3/50 memory map
To: Adam Glass <adamg@microsoft.com>
From: Harry Schreurs <HLS@oce.nl>
List: port-sun3
Date: 06/09/1994 15:44:39
> From: Adam Glass <adamg@microsoft.com>
> To: gwr@mc.com, hls
> Date sent: Thu, 2 Jun 94 14:34:05 TZ
> Subject: RE: Sun3/50 memory map
> Copies to: port-sun3@sun-lamp.cs.berkeley.edu
>
> | 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!!!
Yesterday, I discovered that I was using an IP number, that was already
in use by someone else. So that was the reason that the bootp-request failed
At this moment I am using /dev/ttya as the console port.
For now it's impossible to use the to use the large black and white
screen of my SUN 3/50 as the console.
It's funny to literally see the programs running on the screen!
The memory where the frame buffer lives is also used by NETBSD to
load programs into.
--
> |
> | 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.
>
Adam,
Can you explain this in more detail. Do you already have some code
lying around to implement this? I would like to write the necessary
code myself, but first I need some detailed information how to proceed.
Keep up the good work,
Harry Schreurs
------------------------------------------------------------------------------
H.L Schreurs Email: hls@oce.nl
Business Unit Printing Systems Phone: +31 77 593775
Oce Nederland B.V. Fax: +31 77 595434
The Netherlands
------------------------------------------------------------------------------
###########################################################
# This note does not necessarily represent the position #
# of Oce-Nederland B.V. Therefore no liability or #
# responsibility for whatever will be accepted. #
###########################################################
------------------------------------------------------------------------------