FreeBSD/SPARC Port History


FreeBSD/SPARC was initiated by Jason Evans in 1997. Originally, the port was backed by Sun Microelectronics, but they have since backed out. This is quite interesting, given this press release from Sun, which announces that RedHat Linux 6.1 can now be purchased and shipped with a new UltraSPARC server or workstation. Sun joined Linux International in May 1998, shortly after Jason announced that he would no longer be working on the port in an official capacity. Jordan Hubbard, the release engineer for FreeBSD, responded to Jason's post suggesting that somebody needed to take the reins. Although I was not yet involved with the port, this was a strong motivation for me to take a more active role.

FreeBSD/SPARC didn't die, however disheartening the news of Sun's retreat was. The mailing list did go on haitus, for a while, while several people worked on coding. Late in October 1998, a source code tarball was made available. This is a fuzzy area for me, as it was right before I came aboard and there are apparently several missing mailing list posts during this period.

Paolo Di Francesco was the next "father" of the port. Paolo attempted, for the first time in the history of the port, to organize information, developers, and tasks into a structure that can only be known as project management. If not for the 98-99 holiday season and a few overspoken individuals on the mailing list, Paolo would have continued on. During his tenure, a number of people stepped up to work on the older Sun SPARC architectures. This did cause a slight chasm in the project, and many of the more qualified individuals were on the side of the UltraSPARC family of machines. Luckily, this didn't end up a period of quiet on the mailing list, as Telecom Italia provided us with a list keep-alive - a glitch in their system caused one of Paolo's posts to keep coming back and back and back... This repeat post continued well into 1999, when the list did once again become (mostly) silent.

That brings us up to date. I have been itching for a long time to start work on the port, but I have been waiting for some sort of direction. As the months dragged on into 2000, I decided that nobody was going to accept the challenge if I didn't. As to the port status, nothing much has changed since the early boot code release of October 1998. The rest of the port history is best expressed by Jason Evans. You can read his last update of the port status below.

<:)  Lyndon Griffin, Jan 2000


FreeBSD/SPARC port status

from the original FAQ, by Jason Evans

The SPARC port is in its infancy. We've done a good bit of research into what needs done in order to make FreeBSD/SPARC a reality, but the vast majority of the work has yet to be done.

Here's a short history of what led up to this porting effort. Sun Microelectronics (SME) is the part of Sun that makes microprocessors. Up to now, SMCC (the part of Sun that makes workstations) has been the overwhelmingly primary customer of SME. SME naturally wants to expand its sales, and to do that, they need to sell CPUs to people outside of Sun. FreeBSD is perceived as being a way of accomplishing this.

To understand why Sun could fund a FreeBSD port, which would seem to conflict with Sun's Solaris offerings, you need to realize that Sun is broken up into separate business units that often _compete_ with each other. The Solaris people at Sun may not like having a FreeBSD port to compete with, but their power to prevent it is somewhat diminished due to the business model. Of course, if the FreeBSD port were a major threat, SMI (the main Sun umbrella company) would put a stop to it. However, this is unlikely, since FreeBSD mostly meets the needs of a different market sector than Solaris. Solaris does wonderful things on big MP servers. FreeBSD is fast and lean for small servers. It is also useful for certain types of embedded applications, which is actually the main reason SME is interested in seeing a port of FreeBSD to SPARC.

A while back, SME approached FreeBSD core and offered monetary compensation of some nature (I don't know the details) in exchange for an official UltraSPARC port. FreeBSD core turned down this offer. Once again, I don't know details, but one of the main statements made (actually somewhat inferred) by Jordan Hubbard was that SME's offer was not of major interest since to be of long term use to FreeBSD, such a proposal would need to include support for a number of years from someone internal to Sun.

Jordan's statement makes a great deal of sense. I've traced down documentation in preparation for this port that people external to Sun would have had a difficult, perhaps impossible time procuring. Without such access, it is very difficult to make continual progress on such a project.

Now it's time to mingle some of my background into this narrative. I started working at SME in September 1997. During my first week I caught wind of the negotiations SME was making with FreeBSD core. I expressed extreme interest in working on the project. Through a bit of persistence (and the failure of the proposal made by SME) I was given permission to begin work on the port.

My other duties at SME include finding information for software vendors who are porting their OSes/RTOSes to the UltraSPARC. This puts me in a good position to gather hardware information pertinent to the FreeBSD port.

So here's the catch. I have access to documentation, a machine to develop on, but very little low level OS or hardware experience. I learn quickly, but I've got a lot to learn. Already several people have been able to help me grasp concepts that are key to porting FreeBSD, but there is much, much more to learn.

So, I can use the following types of help (not exclusively, of course):

1) Answer my questions about kernel and hardware details. For example, I have documentation on the MMU, but have never actually dealt with one, so John Dyson has volunteered to get me through the rough spots having to do with memory management, as well as discussing design issues due to the difference in nature between PCs and Suns.

2) Actually write code.

3) Various administrative things, such as a web page, bug tracking, FAQ, etc.

4) Whatever you can do to help.


Last modified: Jan 21, 2000 04:07 EST