22 June 2010

GuruPlug - Part 2

Once your GuruPlug is up and running, you might notice that it seems to run really hot. You're not alone - there are quite a few reports of heat issues with the GuruPlug. For me, enabling the wireless module in client mode while doing anything constructive with the plug is enough to trigger a thermal overload and lockup; connecting the plug to a gigabit switch ends the same way. Based on several forum posts, it's possible that the gigabit NIC issue is not (only) heat related, but time will tell.

I don't have all of the components on hand yet, but I plan to transfer the innards of the GuruPlug to a slightly larger plastic project box, add two or three heat sinks to the metal plate on the bottom of the board, and add a couple of 30mm fans to the project box. Since I don't intend to use either the wireless or bluetooth capabilities, the included power supply (which doesn't appear to have had much love in its creation) should be able to handle the two 30mm fans (each should draw approximately 0.1 amps). If not, I know where to find a 25W (5V/5A) power supply for it :-)

I'll post pics and such when I'm done - stay tuned...


GuruPlug - Part 1

Well, after a successful trial of the SheevaPlug, which is now in use as a firewall (sharing a 3G connection via the onboard ethernet), I purchased a GuruPlug Server Plus back in April. I've just now had time to do much with it, but I'm not terribly impressed overall. Granted, the SheevaPlug was a "developer preview" and thus is expected to be more easily "tweakable" and such, while the GuruPlug seems to be aimed more at end users who just plug it in and use it, but I hadn't expected the GuruPlug to be quite as crippled as it is. That's probably not a fair use of the term "crippled" since it's not intentionally limited by the manufacturer and/or vendor, but it's the only term that comes to mind - basically, it's not easily (if at all) possible to load the kernel from usb or mmc devices, and the uboot (bootloader) shipped on the plug is unable to read ext* partitions at all. I tested some other uboot builds (including one by Philippe Kehl of Debian) and even compiled one myself, but it still wouldn't replicate what I was able to accomplish with the SheevaPlug (load the kernel and initrd from /boot partition on mmc and use / on mmc). Perhaps there was a hefty dose of PEBKAC involved, but eventually, I found it easier and less time-consuming to just put the kernel and initrd on the embedded NAND.

For those who stumble across this blog post, here's the process (but note that this WILL wipe the root filesystem off of /dev/mtd2, so you will no longer be able to boot the OS shipped on the plug). Make the kernel and initrd images and such available via tftp and configure the uboot environment as detailed in INSTALL_KIRKWOOD.TXT and then do something like this:

>> tftp 0x6400000 uImage-kirkwood
>> nand erase 0x100000 0x400000
>> nand write.e 0x6400000 0x100000 0x400000
>> tftp 0x6400000 uinitrd-kirkwood
>> nand erase 0x500000 0x1fb00000
>> nand write.e 0x6400000 0x500000 0x800000

Now, verify that it did what you think it did: :-)

>> nand start
>> nand read.e 0x00800000 0x100000 0x400000
>> nand read.e 0x01100000 0x500000 0x800000
>> iminfo 0x00800000
>> iminfo 0x01100000

Both of those 'iminfo' lines should end with "Verifying Checksum ... OK"

Now you'll want a uboot environment something like this:

>> printenv
bootargs_root=root=/dev/sdb2 waitforroot=10 rootfs=ext4
bootcmd_slack=bootm 0x00800000 0x01100000
bootcmd_usb=usb start;
bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); \
run bootcmd_usb; run bootcmd_nand; run bootcmd_slack;
bootcmd_nand=nand start; nand read.e 0x00800000 0x100000 0x400000; \
nand read.e 0x01100000 0x500000 0x800000

Environment size: 629/131068 bytes

Labels: , ,

10 June 2010

NetworkManager on Slackware

Yes, you read that right. :-)

Since I've got a 10 day old infant (as of 10 June 2010) at home, I've been pulling a lot of sleepless nights lately. I've never been one to waste time, so I found a nice project to work on between feedings and diaper changes, and that was NetworkManager. I'm not quite ready to throw any packages out for public consumption, but I'm close - I think I've got all of the major kinks worked out of it, and the only thing left to do now is some final touchups and resolve some issues in Slackware itself that affect the result.

Stay tuned! :-)

Update (20100622): All of it available on http://slackbuilds.org :-)

Labels: ,