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

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