I 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 EndSection Section "Monitor" Identifier "S24B420B" VendorName "Samsung" ModelName "Samsung S24B420B" HorizSync 30 - 81 VertRefresh 56 - 63 DisplaySize 518 324 Option "DPMS" "true" EndSection 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" EndSection Section "Screen" Identifier "Screen0" Device "PGX64" Monitor "S24B420B" DefaultDepth 24 SubSection "Display" Depth 8 Modes "1920x1200" "1920x1080" "1600x900" "1600x1200" "1440x900" "1280x1024" EndSubSection SubSection "Display" Depth 24 Modes "1440x900" "1280x1024" EndSubSection EndSection Section "Module" Load "type1" Load "freetype" EndSection Section "DRI" Mode 0666 EndSection
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, whic￼h used the mach64 accelerated driver, is poor.
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.
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.
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.