After looking athe SPARCle laptop, I thought that I would look at the Naturetech Mesostation 999, and see if there was anything that could be done to suport power management there too. The first step was to get a working serial port, so that I could use serial console for testing, as this is much more convenient for testing and debugging. I already have a network boot server (NetBSD sandpoint) so the code/build/test cycle is much easier with NFS and network boot.

The Mesostation has the same 8-pin mini-din serial port connector as some of the SPARCstations and I already had a 530-1662 cable, so it should be simple. However, using this gave no input nor output. Ebay and a B&B RS-232 BreakOut Box to the rescue! With this, I discovered that the Mesostation uses pin 5 for receive and pin 4 for transmit, and probably pin 1 for signal ground. The other pins are harder to check and not needed for the console to work, so I've just wired these 3 into a DB25 to RJ45 converter which I use with the 530-1662 cable.

Unfortunately, I wasn't able to find any device that might be the power management controller. However, I did look at the console instead. The firmware sets up 1024x1068, but online documentation notes that the resolution of the screen should be 1440x900. Our radeon driver sets the resolution based on EDID, so creating an EDID entry seemed the way to go. We already have some fixup code in autoconf.c to handle adding properties, so adding the EDID data would be easy.

With the aid of the EDID Specification and an online EDID reader plus a lot of testing, I was able to create a mode giving 1440x900 resolution. I added this as a separate file in the same way that the macppc ones are done. A slight change was to call the property EDID:1 because port 1 is used for the internal screen.

I'd done almost all the testing using the serial console, as that was faster. When I switched back to the framebuffer console, the laptop appeared to lock up with the screen blanked. After a day of adding printf() to almost every block of code in the attach routine, I saw that it was crashing during the time when the screen was blank, and also wasn't responding to the keyboard. A hack in db_trap.c and in machdep.c to call reboot when entering DDB made it easier to track down the bug, fit it and commit the changes.

The result of this is:

[   1.0000000] radeonfb0 at pci1 dev 2 function 0: ATI Technologies Radeon 7000/VE QY (rev. 0x00)
[   1.0000000] radeonfb0: refclk = 27.000 MHz, refdiv = 12 minpll = 125000, maxpll = 400000
[   1.0000000] radeonfb0: 32 MB aperture at 0x04000000, 64 KB registers at 0x00100000
[   1.0000000] radeonfb0: display 0: initial virtual resolution 1440x900 at 8 bpp
[   1.0000000] radeonfb0: using 16 MB per display
[   1.0000000] radeonfb0: port 0: physical 1024x768 60Hz
[   1.0000000] radeonfb0: port 1: physical 1440x900 60Hz

and output appears on the external monitor as well. Our driver doesn't find any EDID information for the external monitor (or the pins are not connected) so it defaults to 1024 x 768.

-^- More notes -^-