[9fans] sparc64 -- unstable
Tim Newsham
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.
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
Tim Newsham
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.