[9fans] sparc64 -- unstable

[9fans] sparc64 -- unstable

[Tim Newsham]

Hi, I put up a copy of my sources for the ultrasparc for anyone
adventurous enough to try it out.  The sources are at /n/sources/newsham
along with a short note on how to run it.

  - The code base is still unstable, but working.
    Dont expect to get much real work done on it yet.
  - My system is an ultra2, but the code should (fingers
    crossed) work on other ultrasparc based machines with
    SBUS.
  - You will need a working plan9 system to build the
    sources and netboot your machine.

I'm interested in feedback.  In particular, flaws with the instructions,
which platforms it worked on and which platforms it didn't work on that it
should have worked on.  I'm also interested in feedback on the code --
where I've done things suboptimally, where I've deviated from plan9 norms,
suggestions, etc.  Feel free to be very critical.  Also any contributions
to the code are welcome.

Tim N.

Re: [9fans] sparc64 -- unstable

[Ronald G. Minnich]

On Wed, 12 Jan 2005, Tim Newsham wrote:

> Hi, I put up a copy of my sources for the ultrasparc for anyone
> adventurous enough to try it out.  The sources are at /n/sources/newsham
> along with a short note on how to run it.

well, that's pretty impressive. I wonder if we could get a rought estimate 
of the amount of work it took to do this port. You did the compiler, 
right? Compiler, drivers, mach code, etc. -- it would be fascinating to 
see the relative effort of this vs. something like BSD. My experience is, 
given a new architecture, that Unix systems take just a bit longer than I 
think you took ...

ron

Re: [9fans] sparc64 -- unstable

[Tim Newsham]

> well, that's pretty impressive.

Well, its not finished yet.  Still a lot of work left to be done.

> I wonder if we could get a rought estimate
> of the amount of work it took to do this port. You did the compiler,
> right? Compiler, drivers, mach code, etc. -- it would be fascinating to
> see the relative effort of this vs. something like BSD. My experience is,
> given a new architecture, that Unix systems take just a bit longer than I
> think you took ...

My timeline is something like:

   - mid oct - mid nov:  I got sparc v8 code working in an emulator
     to the point where I could boot the kernel with a ramdisk and
     run commands.  Some time was spent learning plan9, and learning
     the emulator's debug facilities and code.  I occasionally had
     to fix emulator bugs as well.  Also involved some sparc v8
     investigation.  Unfortunately good docs were hard to come by.
   - mid nov - mid dec: Starting with the v8 code, I rewrote portions
     to work on sparc v9 and got the code booting on a ram disk.
     This involved lots of reading of v9 docs as well as docs on
     the ultrasparc subsystems (luckily much better docs were available
     than in the last phase).
   - 2 weeks in mid dec: crafted new v9 emulator out of old v8 emulator
     to aid in hunting down a nasty bug.  Then some more reading and
     debugging later found the bug the old fashioned way.  Emulator
     didnt help, but was a fun diversion.
   - Late dec and early jan: holidays.  Ethernet driver and debugging
     getting the machine to mount a remote filesystem and run some
     commands.
   - Last weeks: Testing, some cleanup, forked off the k[cal] and
     sparc stuff in anticipation of future work.  Made a release tree
     and directions and tested them.

I've been fortunate to have the time to invest, so most of the work
was done at 40+ hrs a week.  I've also been fortunate to borrow
heavily on previous efforts and draw upon the knowledge of some of
the people who did the work, as well as find a knowledgable freebsd
developer to answer a few of my questions.

   - I had an older plan9 sparc kernel to use as a reference and
     to borrow code from.
   - I was able to reuse most of the code for an earlier uart
     driver.  This means the only major driver I've had to write
     so far was the ethernet driver.
   - I did not have to write any compiler code yet.  Aside from one
     minor bug (which I received some help on) I am using the pre
     existing sparc compiler as-is.  The sparc64 port is still just
     using generated 32-bit code (the only change was to change the
     page size).
   - Getting userland to build was fairly simple due to the
     similarities in the targetted risc platforms and in some
     cases the assembler formats.

So that's about 3 months of work, but perhaps not the most direct
approach, and with a bit of a learning curve.

And of course, there's a lot of unfinished work:

   - Right now the only hardware supported is the serial console
     and the ethernet device.  Drivers are needed for SCSI and
     frame buffer, and testing needed to ensure that keyboard and
     mouse work.
   - The assembler needs to be augmented for new instructions.
   - The compiler needs to be updated to support 64-bit registers.
   - The kernel needs to be updated to take advantage of new
     compiler support (this step should be simple).
   - Some of the userland libraries were rushed, and need to be
     revisited.
   - support for pci would be nice to support newer ultrasparcs.
     As additional platforms are brought up, there would be some
     work to integrate the code cleanly together in a shared tree.
   - getting the v8 code running on real hardware would be nice,
     although these platforms are aging.
   - And of course lots of testing needs to be done.

> ron

Tim N.