Saturday, 14. November 2009, 13:27:09
Shark IGS Sun Raptor PGX32 TCX S24
Since I got an S24 for the promise of writing drivers I had to follow through - tcx as sbus now uses the 'blitter' for scrolling and the stipple 'engine' for filling rectangles and drawing characters. This card is seriously weird.
First the non weird characteristics - it's got 4MB video memory, each pixel is 26bit with 2 bits control and either 8 bit palette or 24bit colour with or without gamma correction. It plugs into the SPARCStation 5's AFX slot which is basically the MicroSPARC's graphics bus which is 64bit wide and apparently works at more or less the same speed as the memory interface. To that add a DAC which understands the control bits, supports a hardware sprite etc, and different viesw on the graphics memory, either as 24bit without control, 24bit with control bits or 8 bit. So far so standard. The weird thing is how this card does graphics acceleration. It doesn't have a graphics processor, instead it has a 'blit space' and a 'stipple space'. Both respond to 64bit writes where the address you write to defines a target pixel in video memory and what you write into it defines a command which can be 'copy up to 32 pixels from one location to another' or 'write this 32 pixel pattern in this colour'. Stipple space supports only transparent patterns and they have to be aligned to 32 pixel boundaries. Blit space can copy 1 to 32 pixels without any alignment requirements. Both exist in two versions, either with access to the control bits or without ( although copies without control bits are kind of useless ).
I also added acceleration support to Xorg's suntcx driver, it uses EXA and supports block copies and rectangle fills.
After that I finally got around to write a console driver for the Sun PGX32 / TechSource Raptor GFX 8P. It's nothing special, just a Permedia 2 with 8MB SGRAM. For now pm2fb at pci uses the blitter for scrolling and rectangle fills. For some reason I couldn't get the drawing engine to actually draw anything, therefore characters are drawn by software and rectangle fills use SGRAM-specific fast fill operations. I must be missing something here since Xorg's glint driver clearly manages to get it to draw stuff. The whole thing is a mess - a dozen subunits, each with enable bits in a dozen different registers. I probably forgot to enable one crucial subunit which keeps drawing operations from doing anything else than zeroing rectangles out. Ah well, at least copy operations work right.
Finally, last week hell froze over and I had another look at my rev. 5 Shark's graphics chip. Finally cleaned up the igsfb hacks that have been sitting in my source tree for years, committed the mode setting code, made sure it doesn't behave any different than before on Krups, added support for Sun-like video mode specifiers in OpenFirmware's output-device variable.
So, on a rev. 5 Shark you can now
setenv output-device screen:r1280x1024x60
And igsfb will switch to 1280x1024 in 60Hz. Any mode defined in src/sys/dev/videomodes/ should work as long as the graphics chip can support it. There is no support for TV output yet.
The firmware doesn't support modesetting but it will happily ignore the mode specifier so we can use it and users can now treat the shark more or less like a weird Sun
That said, I also finally got around to write an Xorg driver. The xf86-video-igs driver so far only supports the VLB CyberPro 2010 but adding support for PCI variants and the CyberPro 2000 should be trivial - I don't have the hardware though. The driver is still quite immature, it uses wscons ioctl()s for the hardware cursor, doesn't contain any modesetting support ( it uses whatever it finds, that's why I added the code described above
), it only accelerates rectangle fills and block copies and there is no support to switch colour depth either. This will be added to the kernel driver though, make it switch to whatever is the highest colour depth possible in the given mode when switching to graphics mode.
Wednesday, 1. April 2009, 15:34:12
Xorg, sgimips, NetBSD, O2
My CRIME driver for Xorg is now more or less complete. Hardware acceleration for xrender supports everything KDE and friends need, missing features have been added ( clipping, framebuffer image downloads, pattern fills etc. ) and the latest version should give some nice speedup as well thanks to increased parallelism between CPU and rendering engine.
With this KDE runs quite well for a machine this old, konqueror is working just fine and nowhere near as sluggish as you'd expect after running things like firefox on IRIX.
Right now the only known case where the driver produces visible artifacts is libXaw and the funny way it draws greyed-out menu items ( prominent example: xterm's menu ), something that XAA doesn't even try to accelerate. Guess I'll have to add my own font renderer too.
Thursday, 19. February 2009, 22:35:31
CRIME, Newport, NetBSD, Indy
...
I got a new toy - an R5k Indy with 24bit Newport graphics. That of course meant I had to get X going. Porting the NetBSD-specific code from the XFree86-driver to Xorg was trivial, the one remaining issue is that colours look right only when X is started right after a cold boot. Restarting X or rebooting the machine ( wether or not X was running ) results in messed up colours. Must be missing something in the DAC setup.
The kernel driver needed ( and still needs ) some work as well - I added support for virtual consoles and all the related goodies, got rid of the hardware sprite cursor ( which doesn't support background inversion anyway so you can't see what's under the cursor ) mostly because it needs an ugly workaround for a hardware bug in some Newport boards - different board revisions need different offsets added to the cursor's X coordinate. So all it did was cause trouble with no benefit. There's still some work to do, like redrawing the screen when X exits, picking the right screen geometry for additional consoles and so on. Nothing complicated.
Now Newport and CRIME ( and probably other SGI graphis hardware as well ) have one thing in common - you can't really access the framebuffer directly. On CRIME you can, in a way, but it's organized in 128x128 tiles, not linear as X would like it, and they can be scattered all over main memory. Also, CRIME uses a rather unusual pixel format - it puts the alpha channel into the lowest byte instead of the highest as pretty much all mainstream graphics hardware does. These things make it mostly useless for XFree86 or Xorg.
Using the newport driver as a reference I was finally able to find out what caused the glitches I got on CRIME. A bug in XAA ( it wouldn't use scanline image uploads even if they are available, only block uploads ) and some bugs in my fix. Now Xorg on CRIME looks right, the Xserver thinks it's running an ARGB framebuffer and we have some off-screen memory.
With this we have accelerated X support on O2 and on most Indys - time to switch sgimips to native Xorg.
Thursday, 19. February 2009, 22:19:01
Xorg, NetBSD
NetBSD 5.0 will ship with Xorg on x86, sparc64, macppc and shark - most other ports will still ship with XFree86 for one or more of the following reasons:
- special hardware-specific Xservers couldn't be ported to Xorg yet ( some DEC specific ones, probably others )
- not all drivers have been ported from XFree86 ( that's the case on sparc and sgimips )
- platform-specific code wasn't ready at branch time ( alpha )
Actually, getting Xorg to work on prep, bebox, ofppc, ibmnws and netwinder should be pretty much trivial, it's just a matter of the right combination of skill, time and hardware in the right hands.
Alpha and sgimips may still ship with Xorg - the platform support code for alpha is working on at least some models and I have both newport and crime drivers working on my machines. Both beat their XFree86 equivalents soundly - the old newport driver is unaccelerated and the old crime driver is highly experimental, required unreleased hacks to work and still produces visual glitches. Both Xorg drivers support the usual acceleration features, including alpha-blending.
Friday, 11. April 2008, 18:33:50
sgimips, NetBSD, O2, SGI
A while ago some kind soul sent me a nice little SGI O2, specifically to write a driver for the onboard graphics chip and to make X work. On NetBSD of course.
Now getting the thing to me took a little longer than expected and Jared McNeill beat me to the graphical console driver ( he also ported OpenBSD's audio driver ) but this driver is just a dumb framebuffer console, it plays the same trick as Linux in order to get something resembling a linear framebuffer. The problem with that is it's slow and we can't use the rendering engine since it only operates on a 16x16 array of 64KB tiles, depending on colour depth they're 128, 256 or 512 pixels wide, and 128 lines high. Now the problem with that is that there's no documentation available from SGI itself but I found a rudimentary register description and after a long period of poking around I got the blitter to work. With this crmfb is now a fully hardware accelerated graphical console with all the usual goodies and pretty good speed even in high resolutions.
Getting X itself to work wasn't difficult - it's already built on NetBSD/sgimips and adapting wsfb to the O2's graphics hardware wasn't hard either. There's a big problem though - its native pixel format is RGBA, pretty much all halfway common graphics boards use either ARGB ( the vast majority ) or ABGR ( mostly Suns, a very distant second ). This isn't much of a problem for X itself - the machine independent drawing routines can easily deal with this but xrender doesn't really and there's a lot of software out there which simply doesn't work with the alpha channel in the lowest byte. All Cairo applications for instance just crash. Older applications which use motif or gtk1 usually work though. Others that otherwise work produce slightly off colours ( WindowMaker for instance, text in the menus has a greenish tint when it's supposed to be grey )
Using wsfb obviously depends on the linear fb trick and is completely unaccelerated. So to improve things I started to write a native driver for the graphics hardware. This has the additional benefit that the blitter can convert pixel formats when copying data from a linear buffer to the tiled framebuffer so we can pretend to run in ARGB and get around those xrender issues. This causes another problem though - rendering into the framebuffer isn't going to work because it's tiled and everything expects a linear framebuffer. Fortunately the rendering engine supports quite a few drawing operations and pretty much every compositing operation known to mankind. So I wrote a driver which supports:
- rectangles
- screen to screen copies
- solid and dashed lines
- colour expansion
- image uploads
- compositing
It turned out that XAA doesn't use image uploads even if they're available in some cases, it always defers some drawing operations to the fb module ( like drawing arcs ) and it's only capable to accelerate a handful xrender operations. To get around that I added some missing functionality to XAA ( use image uploads when available ), don't do and arc drawing at all for now, draw single pixels via hardware and implement my own composite handler so all screen-to-screen or cpu-to-screen xrender operations are done by hardware.
With all this in place xfce4 works just fine, there are a few glitches left ( window backgrounds which are pixmaps aren't always drawn right, this can be seen in galeon for instance ) but things work and especially xrender operations are pretty fast.
The driver can be found
here, the hacked libxaa is
here.
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.
Saturday, 16. December 2006, 07:29:11
NetBSD, shark, DNARD, ARM
...
Also known as D.N.A.R.D. - DIGITAL Network Appliance Reference Design. Cute little StrongARM-based computer that's intended to run over the network but it's possible to add an internal disk ( on a horribly slow IDE interface that doesn't support DMA ). The machine looks more like a PayTV decoder than anything else with that infrated transceiver and SmartCard slot.
I got mine for the promise to make X work, so far I did:
- added some glue to make the igsfb driver work so we get a high resolution graphical console
- added some missing config bits to XFree86 so we can use the wsfb driver for now
- a native, accelerated driver existed in XFree86 3.x - I'm converting it into an XFree86 4.x module. Not there yet though
Saturday, 16. December 2006, 07:21:09
NetBSD, Apple, macppc, PowerMac
...
Just some updates. I had a chance to play with a PowerBook 3400c so I had to do some work on NetBSD support:
- the built-in Ethernet interface didn't work because OpenFirmware lied about the IRQ line it used - fixed that.
- turns out that said IRQ line is connected to a 2nd interrupt controller that the old interrupt handling code was blissfully unaware of - rewrote half of it to support multiple PICs. Now I need a PowerBook G3 to add support for the 2nd Heathrow found in some of those...
- wrote a console driver for the built-in graphics controller - thumbs up to Intel for still offering docs for the C&T 65550 for download
- fixed a few weirdnesses in XFree86's 'chips' driver - apparently nobody ran it on big endian hardware so far
- added some experimental code to properly set up the CardBus bridges - OpenFirmware can't pe arsed to do so for some reason
Then I got a beige G3, 1st generation, worst Apple OF ever. Without firmware patches it can't load anything from an IDE disk or CDROM so I had to netboot it to get anything installed. Ran into the following issues:
- the onboard audio chip doesn't produce any sound. Turns out there is an additional mixer chip controlled via i2c which also supports bass and treble controls. Wrote a 'driver' for it.
- said i2c bus is controlled by Cuda, which also controls the ADB bus, real time clock, power etc. - turns out the existing ADB code is an unholy mess, no sane way to add i2c support there so I would up to write my own.
- the new ADB code ( not committed yet but will soon ) supports the same kind of ADB hardware, is much smaller than the old code and should be a lot cleaner. Got rid of a lot of weirdnesses like phantom scancodes following caps-lock, fixed LED control on full-size external keyboards, sane support for mouse button emulation ( since ADB mice tend to have only one button )
- clear separation between Cuda / PMU and ADB since newer Macs don't have ADB anymore and at least the PMU is extremely bitchy regarding commands it doesn't understand - instead of spitting an error like Cuda does it just powers down the machine. Very annoying.
- the PMU driver is unfinished - no support for brightness/volume control, battery and power management so far but that's easy to add.
General changes in NetBSD/macppc:
- now we can use other console drivers than ofb. Namely machfb ( for most mach64-based graphics controllers ), radeonfb ( most radeons ), chipsfb ( C&T 65550 ) and voodoofb ( 3Dfx Voodoo3 ) - all use the blitter whenever possible.
- added 24bit audio support to the snapper driver
- bugfixes, bugfixes, bugfixes
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 )
Wednesday, 16. February 2005, 05:37:59
I have an odd faible for old and unusual computers and recently a nice little Sun Ultra 10 found its way into my greedy paws, merely for the promise to work on improving NetBSD's support for it, especially to get XFree86 working. So I went ahead and had a look at the code. There was a half-done driver for the onboard graphics chip, an ATi Rage 3D Pro, it didn't do much more than initialize the chip and provide a basic unaccelerated console, so the logical next step was to dig up documentation and add the missing bits.
This is where trouble began - there is no such thing as freely accessible documentation. The docs you can get from ATi are about their drivers for Windows or Linux but not the hardware, and then only about their newer chips, not the old Mach64-based beasts like mine. The only thing getting anywhere close is the source code of the XFree86 driver, so I used that, finally figured out how the blitter works and ended up with a fast console which supports all the bits&whistles like virtual screens, does all drawing completely in hardware and so on, X works fine and the driver even works on NetBSD/macppc without needing any special support. But for some inexplicable reason it doesn't work with the Rage LT found in various PowerBook G3 models, the blitter either won't start or do something funky on its own. No chance to figure out what's wrong without any real documentation.
So - what the hell is wrong with ATi? They never answered my mails. They don't provide documentation about their chips - I tried to register as developer and got - nothing. How stupid is that? Don't they want people to use their chips or what? Why do they ignore operating systems that aren't Windows, Linux or MacOS X? It wouldn't cost them anything to release some docs. I don't care about fancy 3D stuff or the 12479th OpenGL or Direct3D tutorial, all I want is a bloody register reference and a list of differences between the various Mach64/Rage/Radeon chips so I can fix this friggin driver.
And in case some ATi employee reads this ( yeah, fat chance
) - if I ever need to buy some graphics board it certainly won't be one with an ATi chip as long as I can't get any real docs about it.
WIDGETIZE