The following article contains the answers to some Frequently Asked Questions often seen in the freebsd-sparc mailing list. Please don't ask these questions again, they've been answered plenty of times already - and please don't flame someone just because they may not have read this particular posting. Thank you.
All information here has been contributed with good intentions, but none of it is guaranteed either by the contributors or myself to be accurate. The users of this information take all responsibility for any damage that may occur.
Initially the answers to questions contributed will be verbatim from the mail archives, and credit will be given to author(s). With subsequent updates to the FAQ, these answers will be re-structured to give an informative "third-party" view.
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.
Well, right now the answer is, without a doubt, no. In the longer term though, you will probably have better luck running the port on UltraSPARCs, unless I get lots of help for the other processors.
There are multiple answers to this:
1) SME specifically wants a FreeBSD port because that's what potential customers have been clamoring for.
2) I'm particularly attached to FreeBSD, but don't like supporting Intel (both because of their business practices and because of the quality of their products).
Well, I (Jason Evans, jasone@canonware.com) initiated the port. This doesn't exactly make me in charge, but you can bet that I'll constantly have my hands dirty working on it.
SME is particularly interested in having the port work on the UltraSPARC. That leaves out the 4m, 4c, etc. (I haven't been around for a terribly long time, so I don't even have it straight in my mind what all there is).
My work is going to concentrate on the UltraSPARC, which is a 64 bit processor. A number of people have expressed interest in support for older platforms, but no one is very interested in actually writing the code to make it happen, so don't hold your breath.
I'm using the Cygnus-supported version of the GNU toolchain, which was officially released sometime in February 1998. The entire toolchain is released under the GPL, but Cygnus engages in some funny business to try to keep free software from being free. That means you won't get the toolchain from them unless you first pay for a support contract. Of course, once you've done that, you can re-release the code to your heart's content. And that's what I'm doing. I'll have a machine colocated on a T1 by the first week of April 1998, and will make the toolchain source available there at that time.
I've written a program that keeps my cvs tree current. That is, it tracks FreeBSD-current. Source file version numbers get lost as a side effect of the method I'm using, but that isn't really important. What is important is that every so often I can merge -current into my local development tree, so that once everything is working well enough to merge it into -current, doing so won't be such a daunting task.
Although there may be small changes committed to -current to facilitate the port, chances are that we won't merge until after 3.0 has been released. In preparation for the 3.0 release sometime next summer or fall, we need to be careful not to introduce code that could cause instability in the release version. Hopefully by that time there will be a lot of work done that can be merged.
Absolutely, yes, and on an ongoing basis. Have no fear of my work being yanked, even if I am.
Briefly, the first challenge is to get the kernel to build using a cross-platform development environment. Next we need a secondary loader. After that we need a working console driver and a completely stripped down kernel to get the kernel to initialize itself. There are a number of areas that are going to take a lot of work to make even this much happen.
There is talk of a source tree restructuring, but my feeling is that we should put this off as long as possible, so that when we do it, we have a good idea of what we're trying to achieve.
The memory subsystem will need to be ripped to shreds and put back together.
There is discussion of how to make bus interfaces abstracted in the kernel.
Assumptions about the size of int will need fixed, since we'll be using LP-64 (int is 32 bits, long and pointer are 64 bits).
There are many, many things to do. Exactly what order they need to be done in isn't completely clear yet, but we'll manage somehow.
Pretty much anything can be of use, depending on your goals. For my purposes, the following works well.
I'm using a machine based on the UltraAX motherboard. It has a 167 MHz processor, PCI bus, EIDE controller, Ethernet adapter, and serial ports on board. It has 8 DIMM slots, and memory is 4-way interleaved, so DIMMs are added in sets of 4 (I have 4 8MB DIMMs). It is a bit spendy, but there is a newer version of the motherboard based on the (266 or 300 MHz) UltraSPARC IIi processor currently in beta. This processor has a number of things built in (MMU?, PCI chipset?), which makes the cost quite a bit lower. This board also has SCSI instead of EIDE built in, so it will probably be a better choice if any of you are thinking of buying a board.
See http://www.bellmicro.com. I successfully ordered machines from here (for Sun). They operate a bit differently than PC component vendors, in that you establish a contact, and then they quote you a price, etc., etc..
When is a software project ever "done"? Seriously though, this is a huge project. I hope to have a minimal booting kernel in early summer 1998. Past that I don't know what kind of projections to make, though I'm hoping to have something relatively useful by the end of 1998. It will really depend on how much help I get, and what kind of road blocks are encountered.
Because I'm interested in it, and am a major proponent of free software. I can't imagine a job more fulfilling than doing my part to make FreeBSD a technologically superior OS (even more so than now). And as an employee of SME, I can justify this as a project to sell more processors. =)
Subscribe to the freebsd-sparc@freebsd.org mailing list. To do so, send a message to majordomo@freebsd.org with only the text
subscribe freebsd-sparc
in the message body. You will receive an email message asking for confirmation. Send the "auth" line by itself in the message body to majordomo@freebsd.org (not freebsd-sparc!).
The FAQ has only seen a couple of revisions so far, mainly because not much has happened yet to warrant more in depth questions.
Feel free to ask for further information, or clarification of anything in the FAQ. The freebsd-sparc mailing list (see Q.15.) is the best place to ask questions.
Last modified: March 8, 1998 21:20 PST