By PotstickerGuru on Sep 19, 2008
Ever since Intel introduced their Little Valley and Little Valley 2 systems into the low-power, mini-ITX consumer space, they've been a hit. Both from the power savings standpoint, and from the price-performance view. During this summer, they introduced a new board, the Little Falls, or the D945GCLF, which has a new 1.6GHz hyperthreaded 64-bit processor, and Intel ICH7 chipset with GMA 950 integrated graphics. The cost of this board on popular retail web sites have ranged from $65 - $79 for this board - an awesome price. Solaris Community Edition does run on this board, and fairly well, although there were some quirks that need to be to overcome.
Booting into 64-bit
The Intel Atom processor is supposed to be a recent 64-bit hyperthreaded core, and this is true of this system. But up through Solaris Community Edition build 98 and OpenSolaris, we find that Solaris will default boot into 32-bit. A bug in the way the Solaris version of grub boots, mistakens the CPU ID for one that cannot support 64-bit, so it switches and boots into 32-bit by default. With the help of several Atom enthusiasts inside Sun and in the community reporting, a fix for this hopefully should arrive in the next few weeks as we roll out build 99 of Solaris Community Edition and it should show up on the next OpenSolaris 2008 later next quarter. For those who can't wait, a little digging into the kernel shows no potential issues running the 64-bit kernel and so we can force grub to boot the 64-bit kernel simply by editing the /boot/grub/menu.lst file and adding an entry at the top of the list like the following:
#---------- ADDED BY BOOTADM - DO NOT EDIT ---------- title Solaris Express Community Edition snv_96 X86 64-bit explicit findroot (rootfs0,0,a) kernel /platform/i86pc/kernel/amd64/unix module /platform/i86pc/amd64/boot_archive #---------------------END BOOTADM--------------------
If this is the first entry on the grub menu.lst then the default grub boot priority should boot 64-bit going forward. If you added this as the last entry, you may need to also modify the default near the top of the menu.lst to look like:
# default menu entry to boot default 3
Change the number '3' to the placement of your explicit 64-bit boot entry.
NIC Interface - Realtek RTL8101E/RTL8102EL
A lot of Linux mail-lists and discussion groups have all had issues with the new version of Realtek NIC that Intel decided to use for this board. And a lot of folks have asked, if Intel makes it's own NICs, like the Intel Pro/1000, why they don't simply put one of their only NICs? Or include a default MAC on the southbridge and just hook up a compatible PHY. The short answer is cost. It's cheaper for makers, even like Intel, to buy a whole MAC/PHY chipset than to bring out a chipset MAC and pay separately for a compatible PHY. That was the case here.
The main problem a lot of folks in BSD, Linux and the Solaris communities ran into however, was that this wasn't your run of the mill Realtek rtls NIC that was rtl-8100/8139 compatible. Starting with the 8101E line, the chips started to use a PCI-express lane off the south bridge and they had MAC interfaces and registers that looked a lot more like the RGE or RTL-8169 (gigabit) series of NICs, only with a fast 10/100 PHY. And while the hardware PCI registers (either lspci or prtconf or /usr/X11/bin/scanpci) all indicate that this version of NIC was RTL8101E, the smbios Intel provides with this board shows that the NIC is actually an 8102EL - a slightly modified version of the 8101E. For all intents and purposes, the chips are the same, except for Hardware Checksum support. The old initialization support for hwcksum isn't the same register, and was either removed (because it's a slow NIC) or changed. I've made contact with Realtek and after explaining the issues, their engineer knew exactly what the problem was and forwarded me a couple of pages torn out of their datasheet. Some minor changes are going to be required and until we get the go-ahead that this is okay to open source, which should be soon, we can't quite export them to the community. However, a quick workaround for HW Checksum is easily done and gets the NIC working just fine, and that is to disable the Hardware checksum for the NIC. The easiest way to do that permanently is to edit the /etc/system file and put:
then save and exit, and reboot the system. For most Solaris community edition post build 82 or later, I think, we should have the PCI ID already listed in /etc/driver_aliases. If you run prtconf -pv and or /usr/X11/bin/scanpci and the device ID for the NIC doesn't match anything in /etc/driver_aliases, then in the section for rge devices, add an entry for the vendor/device ID following the same format and then either run reboot -- -r or run update_drv rge then devfsadm. A reboot is still required if you haven't done so after editing /etc/system to turn off hardware IP checksum.
Getting the HD Audio Working
The ICH7 chipset supports Intel HD-Audio. However, the Solaris audiohd driver may try to attach but fail to initialize the codec, which looks like a Realtek ALC662. Fortunately, there's been a project underway lead by Garrett D'Amore and the Sun China Audio team to put a parser into an OpenSolaris audiohd driver that can discover and plumb the codec capabilities automatically. It's not perfect by any means, but for the vendors that hook in the codec correctly and publish the correct node-IDs and capabilities to the controller will mostly work, which is about 70+% of most motherboards today. Try downloading the latest August 25th version and try that. I've had good success without the need to go in and hack a hard coded codec into the controller like before. Thanks much Minskey, Garrett and China Audio team!
The rest just works as normal
What's kind of cool is that the rest just seems to work, like the Intel integrated graphics, the SATA and IDE ports, and the performance isn't bad. The old Little Valley boards were SiS Mirage graphics based and the chips had a quirk that really got "snowy" under the Xorg SiS driver. The solution was to use the VESA driver instead, but that limited usage of 4:3 monitors to a maximum, I think of 1600x1200 pixels. With lots of widescreen LCDs available today, that wasn't really preferrable. The new Intel GMA950 is sharp and bright with all the screen resolutions.
I could end this with a sharp criticism on the power consumption for the Little Falls. The 1.6 Ghz Atom has a TDP of only 4Watts. But the overall board with a cheap ICH7 desktop chipset (not mobile) makes to total system power draw at the wall closer to 26 Watts idle, 41Watts peak depending on the type and efficiency of the power supply used. My box has a DC-DC converter Pico PSU 120 with brick and I use a 2.5 inch SATA hard disk, 2GB DDR2 800 and slim DVD burner. With a 3.5 inch SATA drive and a full sized DVD optical drive (spinning) the peak power draw can hit 59Watts! Admittedly, Intel have said that this board was targeting cost more than power. Other vendors produce palm tops and embedded systems with far lower total power using more expensive mobile chipsets.
Still, the board is very economical and a decent power miser. The system is also fairly quiet, although the irony of this board is the northbridge/gma graphics has a fairly noticeable heatsink and fan, while the Atom cpu has just a half-height block heat sink. At first glance, folks may think the Atom has the h/s fan. I haven't run perf comparisons, but based on boot-up times and running some multimedia apps, this feels like a faster board and CPU. Whether that's because of the faster 1.6GHz clock compared to the previous Conroe-L 1.2 GHz Celeron 220 core or it's the hyperthreading allowing fewer hiccups while multi-tasking needs verification. At just $65 though, I couldn't help myself and bought 3 of them for tinkering around.
What will Intel come up with next? Looking forward to it.