> On Tue, 08 Feb 2000, Eduardo E. Horvath wrote:
> >>   ...and whoa...am I reading things wrong, or is the last sparc64 snapshot
> >> really a year old?  What am I missing here?
> >
> >Yup, it's about a year old.  I keep starting on a new one and then get
> >sidetracked.  I was working on one a few weeks ago, but things weren't
> >going all that smoothly, and then I got access to a U10 to play
> >with, which needs a whole new set of drivers....
> 
>   Hmm...with that, and if the le driver is still as flaky as the web pages
> suggest, it sounds like the Ultra stuff isn't...well, umm, useful. 8-/

I can't comment on the le driver.  I haven't had an opportunity to
test it attached to an ethernet yet.  I am seeing some similar
behavior over ppp, so it may be a callout issue rather than a driver
issue.  Or I may have a miserable ISP.

> 
> >I still recommend just using the NetBSD/sparc userland and compiling a
> >new 32-bit kernel from -current.  It's much less painful than dealing
> >with the still broken gcc compiler.  And 32-bit NetBSD emulation is still
> >rather sucky.
> 
>   I don't mind running it in 32bit mode...I just want it *running*.  A friend
> is over here hacking, trying to get the sparc64 kernel built from -current
> sources as of a couple of days ago.  He's cussing a lot and banging his fists on
> the desk; I'm afraid to ask him how it's going. :)  Any pointers on the
> specifics?  I live and breathe Sun hardware all day and all night, but I've
> never touched an Ultra because I don't want to soil my soul with Slowlaris.

I'm surprised he's having so much trouble.  I recently cross-compiled
a kernel on an x86 box and it worked quite well.  I'll attach a copy
of my /etc/mk.conf.  The only important thing is to make sure that the
assembler groks V9 instructions and spits out v8plusa format binaries.
I believe that the in-tree toolchain is capable of doing that.

Also, DO NOT enable COMPAT_NETBSD32 on a 32-bit kernel.  It's for
64-bit kernels only and simply won't work.

Let's see, what else?  Oh, yeah.  The kernel needs to be 4MB aligned
to run since it's mapped in by a single 4MB page.  The kernel is
intelligent enough to determine that it's not 4MB aligned and relocate
itself if needed, but it seems that some versions of the OBP do not
support changing an existing mapping and the kernel does not boot.  I
just placed a new ofwboot in:

ftp.netbsd.org:/pub/NetBSD/arch/sparc64/other/ofwboot

which should fix this problem.


>   I'll hack on it for a while tonight...if we can't get it running before I fall
> asleep, I guess I'll have an Ultra1/170 for sale. 8)

I hope it doesn't need to come to that 8^).  But make sure that it's a
170 with esp/le/cgsix and not a 17E with fas/hme/ffb since there are
no drivers for fas and ffb, and I don't know how well the hme driver
works.

=========================================================================
Eduardo Horvath				eeh@netbsd.org
	"I need to find a pithy new quote." -- me