Getting Solaris x86 Graphics, NIC and Audio working on the ECS GeForce 6100SM-M

There was a recent sale at Fry's on CPU+ mobo combo. This was for an Athlon 64 x2 3800+ 65W AA processor retail kit with an ECS GeForce6100SM-M motherboard - all for $139 before tax. The motherboard is based on the nVidia MCP61 (nForce 405) chipset with socket 939, PCI-express x16 and x1 slots, DDR2 800 memory slots, the standard I/O for disks and floppy and USB, onboard nVidia GeForce 6100 graphics, built-in nVidia 10/100 Fast Ethernet and High-Def Audio with a ALC 660 Codec.

Getting Solaris to run well on this system wasn't the easiest thing. While GeForce 6100 is a supported graphics chip, the version on this board wasn't recognized by the bundled 'nv' driver which we collaborate closely with nVidia to get done with the most recently drop dated January 2007, just weeks ago. The on-board NIC was a strange device with what looked like a 10/100/1000 capable PHY part but a chip (pci10de,3ef) only capable of 10/100 Fast Ethernet speeds. And the audio was another hybrid of sorts that used the MCP61 HD Audio controller coupled with a Realtek ALC660 codec. The controller seems to function to the Intel HD Audio spec and therefore similar to all the other nVidia Azalia (codename for HD Audio) controller. But the codec was a cheaper version of 5.1 audio, as opposed to the standard 7.1 Surround Audio for most HD Audio Codecs (such as the ALC880, 882, 885, etc.). And as expected, the back audio I/O ports included only a single column of 3 jacks for Line In, Mic, and Line Out.

Using the VESA graphics driver with 16 bits.

The GeForce 6100 graphics wasn't suffering the usual errors and exit issues that'd I'd expect from a unsupported card. Instead, it was starting and the system thought it was starting, but my 20 inch flat panel was complaining that the signal was at a mode unsupported by the monitor and the monitor would blank at that point. To get the Graphics working, I examined the /var/log/Xorg.0.log file and found that the actual startup of graphics fell through the 'nv' driver due to errors caused by missing modules for GLX and, instead, loaded the VESA module. Even though the BIOS was set to share 64MB of memory with Graphics, I couldn't get the VESA driver to display the native 1600x1200 resolution of my 20 inch flat panel. The command line options are in the Xorg.0.log file but I had assumed everything was kosher.

I managed to keep the system in command-line mode and manually fired up Xorg by typing: /usr/X11/bin/Xorg, and suddenly, X came up in a standard grey, houndstooth style screen. But if I executed /usr/X11/bin/X (which is a script that sets up the Xserver that then calls Xorg) then it fails. I put a "set -x" line into the /usr/X11/bin/X script and observed how it started and discovered quite a bit of initial checking to discover the default bit-depth of the screen. Without any environment settings, the system defaults to 24-bits per pixel and formats a command-line with a number of options that includes the bit depth. This is then passed to Xorg. so the difference between calling Xorg with no args and X was the set of options. Using the process of elimination, I then determined that without -depth 24, the X script also can start the Xorg server and does so using a default 16 bpp for 1600x1200 resolution. I could actually get the VESA driver to do 24 bpp with 1280x1024, but that was far more blurry and not the native resolution. So I decided to correct the /usr/X11/bin/X script and add a line prior to the initialization of the Xserver setting the DefaultDepth to 16bpp. This allowed the GUI to come up in native resolution with 32k colours. This is good enough for most uses, but application popup menus are colored incorrectly when overlapping another window under 16 bpp. It's tolerable and still works, but I'd prefer 24 bpp and 1600x1200 resolution support.

HD Audio modifications

We have some minimalist HD audio support currently shipping with Solaris 10 update 3 and Open Solaris. The driver actually supports a growing list of Codecs from Realtek, Analog Devices and Sigmatel. The architecture of HD audio is different from the old AC'97. Both specs are from Intel, but the newer HD Audio spec isn't designed as a superset of AC'97 features. It is a new device architecture that separates controller from codec. So the MCP61 controller appeared to be much like all the previous nVidia Azalia controllers. In fact, by adding the line: "audiohd "pci10de,3f0" to the /etc/driver_aliases file, and the running "update_drv audiohd" and "devfsadm" then rebooting, the audiohd module in Solaris does load and almost attaches. It errors out however because inside the driver module, there is a codec initialization routine that fails because the codec isn't recognized.

The funny thing about this ALC660 codec is that it has 5.1 channels, as opposed to 7.1 for most HD Audio codecs. It's a short cut that removes some of the audio output pins. I thought perhaps that this was probably very similar to ALC880 and ACL882 codecs and I could probably tickle the same pins using the same code. Only, there'd be one fewer pair of pins. While the risk of frying the part can exist if you configure it incorrectly in a driver, the chance of that really happening was slim and something I guessed was worth it, if I could even get the system to play just a noise.

Within the codec initialization in the Solaris audiohd.c code are a number of switch/case blocks that do the work. I started by modifying the audiohd_impl.h header file and added a new AUDIOHD_VID_ALC660 entry which corresponds to a pci10ec,0660 device ID. This actually is attached to the PCI-express bus. Next, I opened the audiohd.c file and added entries in a few dozen places wherever I saw ALC880/882. Rebuilding the 32- and 64-bit drivers, and adding them to the /kernel/drv and /kernel/drv/amd64 directories, I rebooted then enabled the audio to play.

Open source nVidia Ethernet driver

The later Nevada builds and Solaris 10 update 3 all support the nVidia onboard GigE device (nge), but the MCP61 networking chip has an unrecognized device ID (pci10de,3ef). I tried to add this also to the /etc/driver_aliases, and run my update commands and reboot, but while the module loaded, it did not attach to the device and I couldn't get it to plumb. Seaching on the web, I encountered Murayama's Free Solaris NIC drivers and an alpha version of the nfo-2.4.1 driver. It does support a number of nVidia on-board fast ethernet chips, but none with the same ID. I attempted to try and attach it anyway, and the message logs told me that the driver attempted to attach but it failed to find it in the nfo NIC table. I looked at the nfo_gem.c file and found an array declaration for the nfo_nictbl[] that had a list of 15 devices supported so far, then cloned the last entry and added a 16th with the new device ID supporting 64-bit and JUMBO frames. I wasn't sure if that was the case, but I recompiled and copied these back into their respective /kernel/drv and /kernel/drv/amd64 and magically the interface came up when I rebooted and manually did an "ifconfig nfo0 plumb".

The next step was to access the network and bringover about 15 GB of files and sample audio which came over quickly and without any issues. This was to do further testing on the audio driver as well, which continued to play just fine.

All in all, not the most straight forward of installs, and not hands free, but it was relatively painless and largely made easy because of the community and open source.


Will you be merging these changes back into (Open)Solaris? If so, what is the time frame?

Posted by UX-admin on February 06, 2007 at 06:41 PM PST #

There's work underway to get many of the OpenSolaris community drivers into the nightly build. That will take some time as there is quite a bit of testing. I'm starting with some of the testing by installing S10u3 first and building the drivers with mods and testing them under the Solaris HCTS (Hardware Compatibility Test Suite). Alan DuBoff, who heads the Silicon Valley Open Solaris User Group, works in the same group. One of his goals is to get a lot of the community NIC drivers into the regular install media. I've also notified both Murayama-san of the changes, and Minskey Guo - Sun Beijing Audiohd engineer about the changes, so the ball starts rolling now. It can take many months to pass testing, even if the driver seems fine under normal conditions.

Posted by PotstickerGuru on February 07, 2007 at 01:51 AM PST #

Still, this is great news, since it means even wider hardware support and therefore more penetration clout for Solaris. In the long run, this (testing) startegy will pay off.

Posted by UX-admin on February 07, 2007 at 05:03 PM PST #

Post a Comment:
Comments are closed for this entry.



« July 2016