Posts tagged with "sparc"
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, 30. September 2007, 21:09:38
graphics, sparc, Fujitsu
Some kind soul sent me a SparcStation 20 and others sent a VSIMM module, various CPUs and a Fujitsu AG-10E graphics board. Adapting the cgfourteen driver to wscons wasn't particularly difficult - it's a dumb framebuffer after all, at least until we get documentation about the SX rendering engine found on the SS20 mainboard. So all 'acceleration' available is a shadow framebuffer in host memory and some trickery to run the console in 8bit for speed and X in 24bit. We also support a hardware cursor using the usual /dev/fb* ioctl()s and X canuse it.
The AG-10E was a little more difficult. Basically it's Frankenstein's Monster among graphics boards - a workalike to high-end graphics machinery made using off the shelf parts. It has independent framebuffers for 24bit and 8bit colour depth and a 3rd one for Window IDs. All controlled by completely different graphics chips, hooked together using an IBM RGB561 DAC. The DAC is pretty high end - it supports WIDs, 10bit gamma tables, 30bit colour and a whole bunch of other bells & whistles.
Apparently there's also a SBus-PCI bridge somewhere on the board since at least two of the graphics chips in question ( an Imagine 128 and a GLint 300SX ) only exist in PCI or AGP variants. The 3rd one, a Weitek P9100 does exist as SBus device, it's used that way in the SPARCbook 3GX and similar laptops, but it's not clear which variant has been used here, might as well be PCI since the board desing needs PCI for the other chips already.
So, why three graphics chips with their own video memory? Well, the GLint is used for 24bit colour, it has 12MB video memory according to SBus resources while the chip itself reports 16MB, plus 16MB 'local buffer' - since I don't have real documentation about this chip I don't know what exactly this additional memory is used for. SBus resources report two independent framebuffers with 6MB each. The I128 has 4MB and is used for 8bit graphics while the P9100 has 2MB which are used as WIDs - basically per-pixel information telling the DAC how to interpret the corresponding data from the other graphics chips. So you can - for each individual pixel - control wether it's drawn using data grom the GLint, from the I128, which of the GLint's framebuffers and how to convert the pixel data to actual RGB output. Options are 8bit palette, greyscale, 24bit colour, 30bit colour and so on.
This arrangement alows the kernel driver to completely ignore the GLint while the X11 driver can completely ignore the I128 and the P9100. We just switch WIDs around to make the I128's framebuffer visible when we're using the console and the GLint's when we're running X11. That way nobody's stepping on anyone else's feet.
There are two new drivers in NetBSD -current which deal with the AG-10E - agten at sbus for the kernel part and ag10e for XFree86. The kernel driver uses the I128 as console, the blitter is used for scrolling and rectangle fills, it will be used for character drawing as soon as I can figure out how that's supposed to work, unfortunately XFree86's i128 driver doesn't use colour expansion and neither does Xorg's. Besides that the driver provides access to the DAC, so far limited to a hardware cursor and a simple 8bit palette. I'll probably add support for the gamma tables at some point.
THe XFree86 driver uses the kernel driver for hardware cursor support ( using the standard /dev/fb* interface ) and otherwise provides enough glue for the 300SX part of XFree86's glint driver to run mostly unmodified. Thus we have hardware acceleration here as well, currently for screen-to-screen copies, rectangle fills with or without pattern and line drawing. The chip is actually an OpenGL accelerator which was rather popular in the mid to late 1990s, it was used in a number of more mainstream CAD boards like the ELSA GLoria series. Without actual documentation about the AG-10E itself it will be difficult to support any real 3D acceleration since most of it relies on DMAing commands, textures etc. from host memory and I don't have the faintest idea how the GLint's PCI DMA engine maps to SBus DVMA - or rather, I have no idea what kind of view the GLint has on host memory, if at all. I couldn't find documentation for any SBus-to-PCI bridge at all, let alone the one used on the AG-10E. Same about interrupts, the board's SBus resources report a single IRQ, might be the GLint's although all the graphics chips are capable of generating interrupts.
Finally there's an Analog Devices DSP ( also with dedicated memory ) present on the card - no idea what it's used for or how to talk to it either. So far my drivers ignore it and things are fine - we have a pretty decent console and accelerated X in 24bit which is more than we can do on most other graphics boards you could plug into a 32bit SPARC.
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.
Friday, 10. March 2006, 20:48:44
NetBSD, SPARCbook, tadpole, sparc
- I finally figured out why external mice didn't work - turns out the Tadpole microcontroller sets an additional bit in each frame header which caused our driver to discard these frames. Doh. Fixed that.
- report more events to powerd, like lid and AC power status
- power up the audio/ISDN chip only when we really use it
Monday, 27. February 2006, 19:08:33
NetBSD, sparc, SPARCbook, tadpole
I finally found out how to switch the SPARCbook's graphics chip to 16 and 24bit colour, also added hardware acceleration for line drawing and colour expansion ( for text drawing ). Performance is pretty good, certainly feels a lot faster than Solaris' Xsun - not that I ran any real benchmarks though.
One more item to scratch from the Things That Solaris Can Do But Not Us list
Saturday, 3. December 2005, 20:40:59
sparc, NetBSD, tadpole, SPARCbook
Yes, they're outdated and old but when did that ever stop anyone?
So, the first questions will probably be:
- What hardware is supported?
- What am I going to lose compared to Solaris?
- What will I gain over Solaris?
The answers for question one:
- NetBSD/sparc runs on the SPARCbook 3GX, 3TX and probably 3GS.
- the graphics chip is supported, including acceleration, for both the console and XFree86. X is currently limited to 8 bit but that's going to change.
- audio is supported, currently output only but that's going to change
- PCMCIA works. You can use any PCMCIA device supported by NetBSD which is quite a lot more than what you could do with Solaris. I'm using a wlan card for instance.
- CPU power management. No more overheating.
- hardware sensors are exposed via envsys. Currently that's internal temperature, battery- and DC-in voltage.
- pressing the power button will initiate a shutdown
- the usual Sun-hardware, like esp SCSI, lance ethernet and so on is supported.
... question two ...
- Support for more than 8 bit in X. I'm working on that one though.
- SunISDN. I have documentation for the ISDN part but no ISDN line so someone else will have to write the driver.
- Audio input. Coming soon.
- Suspend to disk. NetBSD has no generic suspend-to-disk support like Solaris does.
- the external monitor port doesn't work yet
- external mice don't work yet. The microcontroller detects them but doesn't forward any data for some reason
And question three:
- You can only run old versions of Solaris, usually 2.6 and sometimes 7. They won't get security fixes forever. NetBSD will support the SPARCbooks as long as it supports SPARCs.
- NetBSD boots much faster
- Solaris supports only a handful PCMCIA devices, NetBSD is MUCH better here.
- NetBSD gives you more control over the hardware ( think envsys )
- Our console is better. We use the blitter for everything while Solaris uses the PROM to draw everything in software. We have virtual consoles.
- binary packages for NetBSD/sparc just work.
- no need to update all the broken or outdated system tools with superior free versions or to install many of those that don't come with Solaris ( think tar, gzip, bzip2, gcc and so on )
What you need to run it:
- NetBSD/sparc -current. Grab a build from releng.netbsd.org
- kernel source. Get it via CVS or from releng.
First, install -current. The TADPOLE3GX kernel should just work.
Second, build a wscons kernel.
To do that add these things to the TADPOLE3GX config file in src/sys/arch/sparc/conf/:
options WSEMUL_VT100
options WSDISPLAY_COMPAT_RAWKBD # can get raw scancodes
options WSDISPLAY_CUSTOM_OUTPUT # wsconsctl(8)
options WS_DEFAULT_FG=WSCOL_BLACK
options WS_DEFAULT_BG=WSCOL_LIGHT_WHITE
options WS_KERNEL_FG=WSCOL_GREEN
options WS_KERNEL_BG=WSCOL_LIGHT_WHITE
options WSDISPLAY_COMPAT_PCVT # emulate some ioctls
options WSDISPLAY_COMPAT_SYSCONS # emulate some ioctls
options WSDISPLAY_DEFAULTSCREENS=1
options SPARCBOOK_CMD # enable screen switching with lAlt-Fn
options FONT_BOLD8x16 # a somewhat smaller font
Remove the old console stuff since it will collide with wscons:
## Use a faster console than the PROM's slow drawing routines. Not needed
## for headless (no framebuffer) machines.
options RASTERCONSOLE # fast rasterop console
#options FONT_GALLANT12x22 # the console font
options FONT_BOLD8x16 # a somewhat smaller font
options RASTERCONSOLE_FGCOL=WSCOL_BLACK
options RASTERCONSOLE_BGCOL=WSCOL_WHITE
And this has to go too:
zs1 at obio0 # sun4m
kbd0 at zs1 channel 0 # keyboard
ms0 at zs1 channel 1 # mouse
Add the actual drivers:
zs1 at obio0 # sun4m
zstty* at zs1 channel ? # mouse/keyboard
kbd0 at zstty?
ms0 at zstty?
wskbd* at kbd? console ?
wsmouse* at ms?
wsdisplay* at pnozz? console ?
pseudo-device wsmux # mouse and keyboard multiplexor
pseudo-device wsfont
Probably add or remove PCMCIA drivers.
Now build the kernel, put it into / but make sure you don't overwrite the old kernel in case something goes wrong. Before trying to boot it make sure that:
Boot the new kernel and cross fingers.
When things work you can set up X. First make sure /usr/X11R6/bin/X points to /usr/X11R6/bin/XFree86 ( it defaults to Xsun ), then run 'X -configure' as root, that will write an almost working config file into /root/XF86Config.new. Add 'DefaultDepth 8' to the "Screen" section and put the config file to /etc/X11/XF86Config. That's it.
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 )
WIDGETIZE