Tuesday, 18. December 2007, 17:47:54
PGX32, graphics, Raptor, SPARC64
...
Yeah, we support it now.
Turned out genfb would have worked out fo the box if the firmware wasn't buggy - the OpenFirmware calls to change palette registers don't work and in 32bit colour the 'linebytes' property incorrectly contains the same value as 'width'. So I added a workaround, if 'linebytes' is smaller than bytes_per_pixel*width then we know 'linebytes' is bogus and use that instead. Yeah, it's slow but it works.
The PGX32 isn't much more than an off-the-shelf Permedia2 with Sun firmware and a few jumpers to turn off things like fixed VGA PCI resources. XFree86's glint driver supports the chip and would have worked out of the box if it had ever been tested on a big endian machine with an operating system that enforces PCI mapping restrictions - NetBSD doesn't allow you to mmap PCI space that doesn't belong to any device. The driver on the other hand was written a little bit sloppy - there's a register block, 128kB, which contains the same set of registers twice, once big endian and once little endian. The little endian block comes first. Now the problem is that the driver always tries to mmap 128kB even when it wants the 2nd part which results in attempting to map 64kB of unoccupied PCI space. Trivial to fix but still annoying.
Other than that it Just Works(tm).
Sunday, 21. May 2006, 04:17:59
NetBSD, SPARC64, sparc, Sun
Since Core decided to switch to X.org I've been gradually importing sources into NetBSD's cvs repository, namely modular X.org 7.0, freetype2 and Mesa. The latter two were part of the monolothic releases.
As a first step to get something usable I added the missing bits and pieces to make it work on NetBSD/sparc64, binaries can be found
here. This is by no means final and doesn't include most of our additions, like all the sunffb bugfixes ( only some ) or CG6 acceleration. I tested it on an ffb2+ and the onboard Rage Pro found in my Ultra 10 - works just fine, seems reasonably stable after the last round of bugfixes.
Sunday, 2. April 2006, 20:13:30
NetBSD, sparc, SPARCbook, Sun
...
Yesterday I went insane or something and tried to run Opera 7.54 under NetBSD's COMPAT_SVR4 on my 3GX ( I used 7.54 because I had it around and was just too lazy to download something newer at that point ). As expected it barfed over a bad system call. Since this particular error didn't happen on sparc64 I had a look - turns out the 32bit emulation maps this particular call to an empty function returning 0 so I changed COMPAT_SVR4 accordingly and the error went away. And Opera just started. No garbled GUI like on sparc64, everything looked fine.
Poking around a bit more I found that DNS lookups don't work in opera. Poking around even more I found that DNS lookups don't work with any Solaris binary ( like, telnet <some_IP> works, but telnet some.host.name doesn't if it required a DNS lookup ).
I'm using libraries snatched from a machine running Solaris 9 and apparently Sun added a shedload of new sockio()s and the DNS resolver barfs if sockio(SIOCGLIFNUM) fails. Christos added it over night and now Opera works fine with 'Synchronous DNS' enabled.
The reason why I find this noteworthy is - by todays standards this machine is slow ( just a 110MHz MicroSPARC II ) and has not much RAM ( 64MB ). Opera is fast enough to be useful. It's certainly faster than the HTML renderer in KDE1 and running something gecko-based with only 64MB RAM is a joke. In fact only Dillo is faster but it doesn't support any CSS and of course lacks just about everything Opera supports.
Just for kicks ( and to get rid of the ad banner which is really annoying on a small 800x600 screen ) I installed Opera 8.52 - works just fine. Not a bit slower than 7.54, quite the opposite actually.
So big thumbs up to Opera Software for making the only modern browser that's usable on this kind of hardware.
Saturday, 3. December 2005, 19:27:52
NetBSD, sparc, SPARC64, Sun
So 3.0 is about to be released Really Soon Now(tm) - why should anyone care? Here's why:
First, the infamous sleep forever bug that made various UltraSPARC boxes lock up randomly has been fixed. Finally.
Second, NetBSD/sparc64 switched to the wscons console driver which allows nice things like virtual consoles, different terminal emulations, fonts and so on. We have accelerated drivers for most Sun-labeled graphics devices you're likely to find an any supported Ultra, namely the CG6 family ( GX, GX+, TGX, TGX+ ), ffb ( Creator, Creator3D ), afb ( Elite3D ) and mach64 ( PGX24, graphics chips found on Ultra 5 and Ultra 10 mainboards, probably others )
With 3.0 can also run XFree86 on all of these, with full acceleration. The acceleration part for the cg6-driver had to be written from scratch and there were a few bugs to squish in the ffb/afb driver and the Xserver itself but now things work nicely.
To sum it up - we're almost on par with i386 feature-wise now. For 4.0 I'll hopfully omit 'almost'

The cg6 isn't exclusively found in sparc64 machines, there are probably more 32bit Suns equipped with this kind of graphics board and of course both the console and the XFree driver work there too. However, since we still don't have wscons-compliant console drivers for all framebuffers commonly found in 32bit Suns these won't be included with 3.0
What's to come after 3.0:
- A new ffb driver that uses XAA and supports hardware-accelerated alpha-blending ( this greatly speeds up drawing of anti-aliased text ) - works in -current, too new for 3.0.
- support for switching virtual consoles with X running. Still needs some bugs fixed.
- wscons and XFree on NetBSD/sparc. Right now we have drivers for Weitek P9100 and CG6 ( both X and console ), cg14 and ZX/leo are being worked on.
- greatly improved support for Tadpole SPARCbook 3GX and similar laptops. We have drivers for the audio chip ( still somewhat experimental but good enough to play MP3s ), PCMCIA ( stable ), console (stable, but not active since NetBSD/sparc didn't switch to wscons yet ), XFree86 ( currently 8bit only but with some acceleration ), CPU power saving, more feedback on the built-in status-LCD and so on.
- XFree86 now works on the JavaStation Krups. Unaccelerated and 8bit only but at least it uses a hardware cursor, it's definitely usable for light work ( and you won't run anything heavy on a 100MHz MicroSPARC IIep anyway )