Old Sunshine – migrating Ultra5 to Sparc64

SunLogoI pulled a Sun Microsystems Ultra5 machine out of the e-waste some time ago, and have been running various versions of debian sparc or Ubuntu on it for the last few years. The final version was debian Wheezy, the current old old stable.

However, since there is no further work on the debian old old stable, and as there was no working https support in any browser, it was time to upgrade to a more modern release. But, for sparc processors I couldn’t find anything suitable. Solaris 10 was last upgraded in 2013. A path was illuminated when I read this email from John Paul from June 2016, asking the 82 remaining users of debian sparc distribution to migrate to the Sparc64 port. I guess I was one of those last 82 hold outs. And that was 2 years ago. So, Sparc64 became the target port.


The Ultra5 I pulled from the e-waste has been improved over the years, and it is now no longer a machine that could have be purchased from Sun. I’ve added 1GB of 50ns RAM, by cutting (hacking in the literal sense) the 2nd hard drive carrier to make space, and have upgraded the CPU to 440MHz, which was only supported in the Ultra10.



I disconnected the jet engine cooling fan, and replaced it with a quiet slow fan sitting on top of the CPU heat sink, and replaced the hard drive by a 64GB PATA SSD.


I’ve also added a PGX64 video card and a USB card to enable modern devices to be supported.

My final hack was to convert the NVRAM to use a VERY LARGE battery. The NVRAM is used to store the MAC address, and other important system configurations. The standard chip has about a 2 year lifetime, if the machine is mainly turned off. The new Lithium Ion CR123A battery should last about 150 years.



Following a number of false starts, the upgrade to Sparc64 went very easily. The April 4th netinstall ISO is good, and can be used as a reference. Of course newer ISOs will be regularly provided, but at least I’m sure that a working machine can be built from the Internet Archive April 4th snapshot. From the OpenBoot command line.

> boot cdrom expert libata.dma=0


The instructions for the upgrade are very standard debian, using the netinstall ISO. The only special instruction is to enter the archive mirror details.

  * when prompted to enter mirror data, use the following:
    - mirror: http://ftp.ports.debian.org
    - directory: /debian-ports/



The installer automatically realises that the hard disk controller is incapable of DMA and configures it to PIO4 mode. Later, the radeon modesetting can be prevented by adding an options line to the local.conf file.


At this point you should have a working Sparc64 installation.

Using the PGX64

The PGX64 has some additional memory, which allows higher screen resolutions than the inbuilt PGX24 graphics. But, unfortunately, it is no faster than standard.

In order to get it to work without conflict, it is necessary to disable to inbuilt PGX24 device, located on PCI Bus B location 2, by configuring the pcib-probe-list.


Building a Desktop

Getting the Ultra5 to be a desktop machine again requires a working X11 graphics adapter. The PGX64 (and the inbuilt PGX24) graphics use the ATI Rage chip, supported by the mach64 driver.

> sudo apt-get install xserver-xorg-video-mach64


Unfortunately, sometime around 2013, the mach64 driver support disappeared. Around the time that the security aspects of Linux kernel were tightened.

Loading the mach64 driver, which is still supported on Sparc64, produces an error when loading.

From /var/log/Xorg.0.log, the driver is unable to map its mmio aperture.

[ 84.251] (II) MACH64(0): Creating default Display subsection in Screen section
 "Default Screen Section" for depth/fbbpp 24/32
[ 84.251] (==) MACH64(0): Depth 24, (--) framebuffer bpp 32
[ 84.252] (==) MACH64(0): Using XAA acceleration architecture
[ 84.252] (EE) Unable to map mmio aperture. Invalid argument (22)
[ 84.252] (WW) MACH64: Mach64 in slot 2:1:0 could not be detected!
[ 84.252] (II) UnloadModule: "mach64"
[ 84.253] (EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
[ 84.253] (EE) no screens found(EE)

The only options are to rebuild a kernel with the security disabled, or to find another method of getting a working display driver.

Fortunately, it is possible to use the old framebuffer method for driving the ATI Rage graphics chip. A xorg.conf needs to built, to direct the xserver to load the fbdev driver.

Section "ServerLayout"
    Identifier "Xorg Ultra5"
    Screen 0 "Screen0" 0 0

Section "Monitor"
    Identifier "S24B420B"
    VendorName "Samsung"
    ModelName "Samsung S24B420B"
    HorizSync 30 - 81
    VertRefresh 56 - 63
    DisplaySize 518 324
    Option "DPMS" "true"

Section "Device"
    Identifier "PGX64"
    Driver "fbdev"
#   Driver "mach64"
    Card "ATI Rage Pro - Sun PGX64"
#   Option "DMAMode" "sync"
#   Option "ForcePCIMode" "true"
#   Option "BufferSize" "8"
#   Option "ExaNoComposite" "true"

Section "Screen"
    Identifier "Screen0"
    Device "PGX64"
    Monitor "S24B420B"
    DefaultDepth 24
    SubSection "Display"
        Depth 8
        Modes "1920x1200" "1920x1080" "1600x900" "1600x1200" "1440x900" "1280x1024"
    SubSection "Display"
        Depth 24
        Modes "1440x900" "1280x1024"

Section "Module"
    Load "type1"
    Load "freetype"

Section "DRI"
    Mode 0666

This above xorg.conf gets the required outcome. A listing from Xorg.0.log below.

[ 704.327] (II) LoadModule: "fbdev"
[ 704.328] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 704.329] (II) Module fbdev: vendor="X.Org Foundation"
[ 704.329] compiled for 1.19.0, module version = 0.4.4
[ 704.329] Module class: X.Org Video Driver
[ 704.329] ABI class: X.Org Video Driver, version 23.0
[ 704.329] (II) FBDEV: driver for framebuffer: fbdev
[ 704.330] (II) Loading sub module "fbdevhw"
[ 704.330] (II) LoadModule: "fbdevhw"
[ 704.332] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 704.333] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 704.333] compiled for 1.19.6, module version = 0.0.2
[ 704.333] ABI class: X.Org Video Driver, version 23.0
[ 704.335] (**) FBDEV(0): claimed PCI slot 2@0:1:0
[ 704.335] (II) FBDEV(0): using default device
[ 704.336] (**) FBDEV(0): Depth 24, (--) framebuffer bpp 32
[ 704.336] (==) FBDEV(0): RGB weight 888
[ 704.336] (==) FBDEV(0): Default visual is TrueColor
[ 704.336] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
[ 704.337] (II) FBDEV(0): hardware: ATY Mach64 (video memory: 8176kB)
[ 704.337] (II) FBDEV(0): checking modes against framebuffer device...
[ 704.337] (II) FBDEV(0): mode "1440x900" ok
[ 704.337] (II) FBDEV(0): mode "1280x1024" ok
[ 704.337] (II) FBDEV(0): checking modes against monitor...
[ 704.338] (--) FBDEV(0): Virtual size is 1440x1024 (pitch 1440)
[ 704.338] (**) FBDEV(0): Default mode "1440x900": 106.5 MHz (scaled from 0.0 MHz), 55.9 kHz, 59.9 Hz
[ 704.338] (II) FBDEV(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz d)
[ 704.338] (**) FBDEV(0): Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0 kHz, 60.0 Hz
[ 704.338] (II) FBDEV(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz d)
[ 704.338] (**) FBDEV(0): Display dimensions: (518, 324) mm
[ 704.339] (**) FBDEV(0): DPI set to (70, 80)
[ 704.339] (II) Loading sub module "fb"
[ 704.339] (II) LoadModule: "fb"
[ 704.340] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 704.341] (II) Module fb: vendor="X.Org Foundation"
[ 704.341] compiled for 1.19.6, module version = 1.0.0
[ 704.342] ABI class: X.Org ANSI C Emulation, version 0.4
[ 704.342] (**) FBDEV(0): using shadow framebuffer
[ 704.342] (II) Loading sub module "shadow"
[ 704.342] (II) LoadModule: "shadow"
[ 704.343] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 704.344] (II) Module shadow: vendor="X.Org Foundation"
[ 704.345] compiled for 1.19.6, module version = 1.1.0
[ 704.345] ABI class: X.Org ANSI C Emulation, version 0.4
[ 704.345] (==) Depth 24 pixmap format is 32 bpp
[ 704.392] (==) FBDEV(0): Backing store enabled
[ 704.396] (**) FBDEV(0): DPMS enabled

That is all that is required to get the desktop working.

Experimenting with both xfce and lxde, the lxde desktop is clearly faster. But, unfortunately neither desktop is particularly workable as the framebuffer display driver is quite slow. Responsiveness compared to debian Wheezy, which used the mach64 accelerated driver, is poor.

Next Steps

Just purchased an old Sun XVR-100 PCI adapter to give it a go. The Sun XVR-100 is an ATI Radeon 7000 64 MByte board that contains a SUN ROM to allow it to be recognised by OpenBoot, and to work in the Sun environment.


OpenBoot show-devs

After configuring the OpenBoot to boot with the XVR-100 as the default screen and, to avoid conflicts, disabling the internal PGX graphics PCI interface, we are welcomed by the following boot screen.


Ultra5 – OpenBoot with XVR-100

So it is looking good! But unfortunately, the radeon driver and radeonfb drivers are not working properly. The first sign of trouble is early in dmesg when BAR locations can’t be allocated.


And then again later in the boot sequence the radeonfb driver complains that it can’t map the XVR-100 ROM and being unable to claim BAR 6 to assign a bridge window.


And this leads to the xorg xserver loading the radeon driver but then being unable to properly address the XVR-100, so it bails out leaving us with no X screen. Luckily, the console is still working.

To be continued.

One thought on “Old Sunshine – migrating Ultra5 to Sparc64

  1. consider in the future an IDE DOM of some manner instead, in the amount of 128MB or so for boot. the onboard IDE controller in the 5/10 is very slow with no DMA, and that will have a negative impact on performance. the way I got around this in my 10 was the addition of that IDE DOM for /boot and putting the rest of / on a SATA hard drive with a Silicon Image 3112 card with a Mac BIOS flashed to it. (Adaptec 1208SA I think it is? any Mac BIOS’d silicon image card made of a 3112 should work.) SATA SSDs won’t work with these though, something with the command set between the card and the drive that doesn’t make it work properly… same goes with optical drives on that card. Likewise a proper IDE card should also work as well, you just can’t boot from it. so again, the IDE DOM for booting and put the PATA SSD on an IDE card someplace that the machine likes and will use in Linux. thus the overhead the onboard controller makes is absolutely minimal.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s