Subject: Re: bootstrapping a sun4m
To: Aleksi Suhonen <ams@lenkkari.cs.tut.fi>
From: Aaron Brown <abrown@eecs.harvard.edu>
List: port-sparc
Date: 09/06/1995 14:14:18
On Wed, 6 Sep 1995, Aleksi Suhonen wrote:

>  
> }-But the sun4m port is actively being worked on and there has been some
> }-substantial progress over the past few months.
> 
> Out of interest ... What exactly have been proven to be the problems with
> porting NetBSD (or mach or any other os) to sun4m?

There have been several large hurdles, mostly due to inadequate 
documentation and variation between models.

One problem is trying to create a kernel that will run on both the Sun4/4c
and Sun4m. Since the 4m has an entirely different MMU model than the 4/4c
(it uses three-level page tables kept in software but with hardware
lookup; no pmegs) and uses different pte's (the bits don't match for
protections, caching, etc) much of the pmap code had to be rewritten, and
lots of functions were virtualized to avoid constant "if (cputyp ==
CPU_SUN4M)" checks. Similar problems cropped up with interrupts--the 4m has
a different interrupt control structure since it supports multiple CPUs
(no, the port is *not* multiprocessor capable as of yet, but you still
have to deal with the different registers). And there are a bunch of
places in locore where there aren't enough registers to go around... 

The other problems come from the new I/O architecture. The le has been
replaced with a ledma, and there's now an entirely separate I/O MMU used
for DVMA. And the existing esp driver breaks on a SS20. Unfortunately,
documentation for these things (and similar devices such as the iocache,
the cgfourteen framebuffer, etc) have been hard to come by. This is where
most active development is now. 

Finally, there are way too many variants on the 4m architecture. The 
kernel has to detect and act appropriately for microsparcs, 
microsparc-IIs, supersparcs, and hypersparcs. Each processor type has 
different MMU control registers and different memory-fault handling 
procedures. Also, the supersparc/hypersparc machines (SS10, SS20) use a 
36-bit physical address space for accessing I/O, which makes device and 
sbus support a bit grungy.

But its coming pretty well; the pmap/dvma stuff is done, and on a Classic
it can mount root from a SCSI disk...on the SS20 I'm using the SCSI is
still broken and the e-net is partially there, but not enough to network
boot quite yet. 

--Aaron