Subject: Re: How can one get a hold of hardware specifications for
To: Draco Paladine <rombios@acedsl.com>
From: Erik E. Fair <fair@clock.org>
List: port-sparc
Date: 01/05/2003 13:44:52
The Sun firmware is an early version of what became IEEE 1275 
(OpenBoot Firmware) which based on the Forth programming language. 
The idea is really quite clever: put a Forth interpreter on the 
motherboard, and add-in boards only need to have a driver written in 
Forth in their little PROMs, regarless of the system's processor - 
the same board with the same driver should work fine in a SPARC, an 
UltraSPARC, and, because Apple adopted IEEE 1275 for its PCI based 
PowerPC systems, in those too. It's a real shame that Intel/AMD/PC 
clone vendors didn't adopt it too.

See
	http://playground.sun.com/1275/

for some useful online docs.

The best documentation for Sun's Frame Buffers is in the Sun Frame Buffer FAQ:

	http://www.sunhelp.org/faq/FrameBuffer.html

Alas, this does not cover programming as such.

The workstations generally used AMD Local Area Network Controller - 
Ethernet (the famous LANCE) 7990, and docs for that are available 
from AMD's web site. See the le(4) man page for the last URL we had 
for that.

The serial ports are common Zilog 8530 DUARTs. This covers the mouse 
& keyboard too.

The SCSI is NCR (now Symbios) 5380.

Sun had a business in licensing the SPARC, so they published 
programming documents for the instruction sets and the chips, 
probably still available at Sun's web site.

Sbus was made into another IEEE standard at some point, but I don't 
recall the number.

NetBSD uses a structure such that we have one driver for each chip, 
regardless of what kind of bus the chip is accessed through, so that 
we write the driver once, and can use the same driver on every 
platform that the chip shows up in (Alphas, Macs, PCs, Suns, SGIs, 
etc). This is one reason why we can port to a new platform so quickly 
- there is an industry inclination to use standard chips, so once GCC 
can produce code for the CPU, and we figure out how to get the system 
firmware to load and start our kernel, we figure out which chips they 
used and off we go!

	Erik <fair@clock.org>