echo '^Rk1a!U}`cX' | tr '!-op-~' '0-~!-/'
This page provides some information about this board and how to configure
recent versions of Linux (>= 188.8.131.52) to run on it.
Some time ago, Demik gave me a
TE2 1U chassis, each with two of those boards inside.
Just like every other machine I put my hands on, my first goal was to try a recent version of Linux on them. A few things went wrong, this is why I created this page.
Quick summary of features that make these boards somewhat attractive.
Still unconvinced? You can overclock the CPU up to 750MHz (and it doesn't
Just imagine you're reading this page 10 years ago, when these boards were also probably quite expensive.
You don't need to read everything, but having them here will save you the trouble of finding them in case of need.
A quick introduction to its features.
This is simply the most useful document. It describes the various components, jumpers locations and OBP configuration. You definitely need to read this.
Some information about the two
sungem Ethernet controllers you can find
on this board. Unfortunately, they're not gigabit.
OBP 4.x manual. Worth reading.
You should have one of those on your Netra AX1105.
A list of hardware issues I encountered and solutions or workarounds where applicable. Most are more related to TE2 chassis.
Symptoms were random reboots and pages of numbers displayed instead of OBP. I
had to test my four DIMMs individually with
to discover that two of them were bad.
When a single PSU is connected to two boards such as in the TE2 chassis, and
you leave one of the boards in a hard reset state (with a jumper, or by
reset button), if you reboot the other board from the OS,
OBP or even manually with a hard reset, it will display the same random
numbers pattern as when a memory error occurs.
While it's not supposed to occur spontaneously, it's still a bug. Working around this requires you to release the hard reset on the first board (it should start to boot) and do a hard reset on the second board.
Don't bend them too much! I tried to straighten one which was already in a bad shape and it broke near the board surface.
This hardware issue seems to appear when you leave your machines in a humid garage for too long.
Although a single board consumes less, it is recommended to use at least a 200W PSU. The TE2 chassis comes with a 300W 1U PSU for two boards and two hard disk drives. Considering the reduced airflow such a chassis provides, the PSU may be stressed a bit too much. A few of my machines came with dead PSUs.
Integrated controllers seem to be picky with what you're connecting them
to. They weren't able to negotiate a link with the first
Connectland Ethernet switch I tried (the last time I had this
problem was with 3com ISA boards). Fixed by using another noname Ethernet
I assume that you know what OBP is. If not, read this. Below is a list of things you may find useful.
ttya (on this board, the first serial port is located
at the bottom) is the default system console, configured for 9600 baud by
default, which is slow. 38400 is the maximum speed you can configure in
You surely want to do this.
ok printenv ttya-mode ttya-mode = 9600,8,n,1,- ok setenv ttya-mode 38400,8,n,1,- ttya-mode = 38400,8,n,1,- ok reset Resetting ...
Now, configure your terminal for a speed of 38400. Remember that boot
diag-switch? will still require you to configure
it for 9600 baud in order to see them.
Here are my settings:
watchdog-timeout 10 63 watchdog-enable? true false watchdog-reboot? true false
Meaning that every 10 minutes in OBP or in the OS (if it hasn't reconfigured
the watchdog), it will spontaneously reboot. While you aren't forced to enable
it in OBP, it is still useful to clear a stuck
ok prompt on a
remote system console.
In other words, do not enable the watchdog before you're done
installing your OS and configuring the watchdog in it (and you should do so
The time base for
default. There doesn't seem to be an environment variable to change this in
OBP, however you apparently can from your OS. Read this
for possible values.
Don't forget that you can
netboot using DHCP. No more RARP and annoying
setups. All you need are DHCP and TFTP servers.
ok boot net:dhcp,10.1.1.20,vmlinux.aout root=/dev/sda2 ^^^ ^^^^^^^^^ ^^^^^^^^^^^^ ^^^^^^^^^^^^^^ | | | | | | | optional arguments | | file to load, relative to TFTP root | TFTP server address device alias for the first network interface (next to USB ports)Current device aliases can be listed by typing
\\paths separators instead of
/which doesn't work.
ok boot net:dhcp,172.16.3.1,linux-184.108.40.206\\vmlinux.aoutMaximum image size is 10MiB. While it is enough for a single compressed kernel, you need to be careful if you put an
It also appears that OBP prefers
a.out images. Maybe because they
are smaller. ELF images also work, but not as well. I use
elftoaout utility you can find
You can't, unless you write your own software package for OBP. Good luck.
I didn't try it, but there's no reason why it wouldn't work. Probably easier than network booting if you have a parallel ATA CDROM drive around.
The following patches were made for Linux 220.127.116.11 but may work with newer versions.
initis never run
In this kernel version, a regression affects this board making it unable to
complete the boot process. Using
git bisect, I found the
and made a
that reverts the entire commit.
Note: this is fixed since at least 2.6.37.
sungemEthernet driver causes a kernel Oops
It happens when trying to
ifconfig your interfaces, which is
unfortunately quite common. Caused by what appears to be an int overflow and
not checking for a possibly NULL pointer.
Other issues that need addressing:
eth0: RX MAC fifo overflow smac.
Is the hardware to blame? When sending data to only one interface at full speed, the other answers pings with a 60ms delay. Using both interfaces at full speed yields extremely poor performance. Same problem when accessing hard disk drives. Saturated bus?
As a bonus, this patch also allows setting MTU up to 1840 (works for me anyway) and increases TX and RX ring buffers sizes from 128 to 4096 bytes. Seems to mitigate the above issues a little.
Actually, there is one. Even two of them match the
ALi M1535 found on
these boards. However, one was only visible when configuring a kernel for x86,
the other was shown as working on SPARC hardware (especially Netras) but
didn't (actually a driver for the
Ali M7101 PMU, working on x86-based
Cobalt boards). This patch fixes
i2c-ali1535 was created without SPARC platforms in mind. Some
code was missing to use the correct memory address. While this
patch fixes the problem, I have
no idea whether it's how it should be done.
I don't have a patch for this. I don't know whether it's a hardware or a
software issue. UltraSPARC IIe can change their frequency on the fly to
consume less energy and Linux has a driver for it. If you
will be able to modify the CPU speed. However it immediately triggers a
watchdog reset and you'll see your machine booting at half the frequency
(250MHz) and crashing soon after. Do not enable this in your configuration.
Now that your kernel is all patched up, you can configure it.
Here's a sample
file for it, with all the options described below enabled. Note that this
configuration doesn't support loadable kernel modules.
Support for PCI and PS/2 keyboard/mousewhich may lead you to think that you'll only disable unused PS/2 devices. Fools.