Technical Bulletins

Sometimes I happen to go through a lengthy process of configuring something (usually related to one of my computers or parts of my home network). Sometimes it looks like others may face similar challenges, so I decided to launch a dedicated blog, where from time to time I will publish some (hopefully) useful information.

Subscribe: [RSS Feed]

Friday, May 14, 2010

Nokia Booklet 3G FDE SSD Upgrade


A week ago, blinded by its beauty (and long battery life), I purchased the Nokia Booklet 3G netbook. Actually the purchase was not 100% impulsive, as I had done some research beforehand.



For almost a year I have been using the Lenovo X200s laptop, equipped with a solid state drive (SSD). The Lenovo SSD I chose still seems to be the only one on the market, supporting FDE functionality. FDE means the drive strong encrypts everything it stores and securely manages encryption keys. FDE technology does not require any supporting software, which is nice. The only thing it needs is a hard disk password enabled in BIOS. In standard disks, the hard disk password just enables the drive. In FDE disks the password is used to release an encryption key from a TPM chip on the drive. Actually the Lenovo 256GB FDE SSD drive is manufactured by Toshiba, and the part number is THNS256GG8BAAA. I had it in my X200s Thinkpad, in a 2.5 inch bay. While the drive itself is 1.8 inch.




Analyzing the Nokia Booklet 3G I found it was built around another 1.8 inch Toshiba drive, the MK1235GSL 120GB unit. There are two major differences between the two (setting capacity aside). The original 120GB one is mechanical, with 4200rpm speed, which makes the computer very slow. And I mean very. Almost unbearable. The only way to make it usable (but still far from demonic speed) is to swap the spindle drive with a SSD one. I was lucky to have a 1.8 inch SSD in my Lenovo. So decided to make a try.

It is a little challenging to disassemble the Booklet 3G. The chassis is an aluminum monocoque, a single block of metal forming both the upper and lower side of the case, plus sides. Zero screws and bolts. Actually to get to the motherboard you have to take the keyboard off. I did this by inserting a credit card between the keyboard and the display hinge. And then popping the keyboard up from its latches. Once the keyboard is taken away, there is a steel shield you have to unscrew using a Torx driver. The drive is in the middle, not fastened by any additional screws. Just pull it up gently and disconnect the micro-SATA ribbon. The original drive is wrapped in a rubber jacket, I took this jacket off and put it on the new drive. Then plugged the new one to the micro-SATA connector and everything started to work as intended.




After I reassembled the machine back to the factory state (with the new drive in), it showed the SSD drive on the boot screen. After this it was only the matter to install Windows 7 from an external DVD drive. It all went smoothly.




There have been two immediate effects noticeable after the upgrade. The first, obviously, has been the overall speed of the system. I do not have precise benchmarks, but the hard disk score now is 5.9, a remarkable number for such low end Atom - based system. It is a night - and - day difference when compared to the original setup. The computer boots fast, applications launch fast. The memory consumption is lighter, as many spindle - drive associated mechanisms available in Windows 7 arsenal (superfetch, readyboost, application prefetch) are no longer needed.

The second effect of the SSD upgrade is shorter battery life. This may be a surprise for some, but contrary to the general belief, today's SSD drives consume more power than the mechanical ones. In the Nokia Booklet 3G case, the original drive is rated 700mA at 3.3V, while the SSD I have used is 1600mA at 3.3V. So the difference is 3 Watts, what over ten hours means 30 Watt-Hours, or half the available battery capacity. Of course this power rating is peak, not continuous, and SSD drive completes the high power operations in shorter time. All in all in my case I have experienced battery life drop from 12.5 hours down to about 8.5 hours, which still is a significant 30%, but I can bear with that, having a system that does not crawl like a snail. Later I plan to test a different SSD drive (sans FDE encryption), so I hope to report the results here.

In my opinion the SSD upgrade is a must for anyone seriously thinking of making the Nokia Booklet 3G their main / primary machines. I am very happy with the upgrade. I have a really tiny laptop, with big and fast 256GB storage. I also equipped my desk with the iiyama ProLite E2210HDS 22-inch FullHD display I connect to the Nokia via a nice and small HDMI cable that carries both digital video signal and sound. Such screen coupled with a comfortable Lenovo DiNovo Bluetooth keyboard and the original Microsoft Bluetooth mouse makes my home station setup very comfortable. Of course the Nokia is the heart of it and I do love having exactly the very same setup (albeit with a smaller screen and keyboard) on the road.



Update: as an exercise I decided to try another brand of SSD. I was able to borrow the Samsung MMDPE56GTDXP-MVBD1 micro-SATA (uSATA) MLC Thin 256GB drive. Actually calling it a drive is a bit of an exaggeration , as you can see on the photo above, the Samsung SSD drive resembles more a memory module than a drive.

To speed things up, I decided to use the Acronis Clone Drive, plugging the Samsung to the USB port. I used a standard USB-to-SATA adapter (taken from a USB drive enclosure) and a SATA-to-micro-SATA (SATA-to-uSATA) converter.

On the first run the cloning operation failed. The reason behind the failure is quite interesting. Windows 7 introduced a special command, called TRIM, that helps in handling SSD drives (there is a good, detailed explanation here). Some newer SSD drives support TRIM, some older do not. Windows queries drive capabilities and adjusts its command set accordingly. Unfortunately the US15W SATA interface chipset in the Nokia does not support TRIM. So what happens, Windows queries the drive, the drive reports it is TRIM capable, Windows tries to execute the TRIM command, the chipset blocks it and the process hangs. The only workaround is to disable TRIM in Windows before cloning. You do this by opening a command prompt as an administrator and executing [fsutil behavior set disabledeletenotify 1]. This disables the use of TRIM at the system level, and you can then use any SSD (with some performance consequences on write operations).

On the second attempt, after dealing with the TRIM issue, Acronis handled the cloning operation without a glitch and when completed, I was able to swap the drives. To my surprise the battery life did not improve at all, comparing to the Toshiba - based system, even that the Toshiba drive was rated at 1.7A and the Samsung at 0.8A. It looks like those ratings do not reflect the real power consumption. After a couple of days it even seemed to me the Samsung drive was drawing more power, as I was never able to exceed 8 hours on a charge. Not seeing any benefits from the Samsung drive, I cloned the system back to the Toshiba FDE.

Tuesday, December 22, 2009

Setting Up The Sheeva Plug


The previous post on the initial Sheeva setup assumed readers had spent some time playing with the installer and with the Sheeva Plugcomputer itself. I received a number of requests to clarify things a bit more for beginners. So here is the more detailed description.

First, the plugcomputer itself. It is an integrated platform, based on SoC (System-on-Chip) offered by Marvell and named Kirkwood. Kirkwood contains so called ARM core, so all applications executing on this platform have to be compiled for ARM. The Sheeva has 512MB system RAM and 512MB system flash memory (so - called NAND memory). It also has four ports:
  • 1GB RJ-45 Ethernet port - to attach to a network
  • USB host port - can be used to plug a variety of USB devices - USB hubs, pen flash drives, protocol converters (like a 1-wire converter or a USB-to-RS-232 converter), USB cameras, keyboards, and even graphic monitors (using DisplayLink technology - more on this in later posts)
  • MMC/SD card port - to plug a SD card. This is important, as I recommend playing with the Sheeva equipped with SD storage. Due to process of wearing, flash memory has limited number of write cycles. If an SD card wears out, you can just plug a new one. If your internal NAND flash wears out, the entire unit will have to be replaced.
  • USB client port - this is used to initially setup the computer, before it can execute anything on its own.
The initial setup process is organized as follows:
  • The so-called installer is a set of binaries and scripts. You have to download it from the plugcomputer.org site and unpack to either Windows or Linux host machine. As I never succeded setting up the Sheeva from a Windows host, I will focus on the Linux variant here.
  • The installer has two parts. The first one is a set of binaries you have to copy to a pen flash drive. Then the populated pen drive has to be plugged to the USB port on the Sheeva. The second part are scripts, that are copied over USB link (a USB cable connected between Sheeva's client USB port and the host machine). The scripts are then executed on the Sheeva - their job is to move and unpack the binaries from the USB pen drive and place them either on the internal NAND flash memory or on the plugged SD card.
  • The Linux installer is basically a PHP script, so it requires a PHP client to run, as I wrote previously. The entire install procedure is well described in the installer's readme file. In short - there are two basic variants - one installs the system on the internal NAND (executed by [sudo php runme.php nand]), the other installs them on the SD (executed by [sudo php runme.php mmc]).
Before setting up the target operating system (in case of the current version it is the Ubuntu 9.04), the installer sets up the so - called boot environment. The boot environment is executed first when the Sheeva is powered up. It initializes the basic hardware components and then loads the OS. As there are some cases when you need to access the boot environment, the only way to do this is via serial terminal console. The serial link runs over a USB cable between Sheeva's client USB port and the host machine. My host runs Gnome, so my natural pick has been the GTKTERM application. If you run Windows, you may use PUTTY set up for a serial link (a COM port, 115200 baud, no parity, one stop bit).

As mentioned before - on my development Sheeva system I happen to refresh the OS quite frequently. With access to the boot environment it is a snap. Just plug in the previously populated flash pen drive with OS binaries, boot the Sheeva with serial console attached, and at the boot environment prompt just type [run recover1]. This partitions and formats the destination filesystem (NAND or SD card) and installs a fresh instance of the Ubuntu from the pen drive.

After the Ubuntu is set up, the serial console is no longer necessary, the USB cable can be unplugged. When Ubuntu loads, it may be accessed remotely from a host machine using SSH connection (terminal window in Linux or Putty in Windows). The default user is root and the default password is nosoup4u. Of course it is a good practice to change it after the first logon - by executing [passwd] command.

The other steps I run after the new clean install are:
  • update the distribution sources:
    apt-get update
  • upgrade the system components to the current versions:
    apt-get upgrade
  • install the NANO - an easy and simple character based text editor to work on various configuration files:
    apt-get install nano
  • clean the updater cache and remove potential orphaned modules:
    apt-get clean
    apt-get autoremove
  • synchronize the system clock:
    ntpdate pool.ntp.org
  • burn it to the hardware clock:
    hwclock --systohc
  • and configure the time zone data:
    dpkg-reconfigure tzdata

After these steps the Ubuntu on Sheeva is ready for experiments.

Sunday, December 20, 2009

Sheeva Plug Dev Station


I mentioned the Sheeva Plug computer several times on the headworx blog. Today I start a series of posts that will continue here on the tech.slupik.com, devoted to Sheeva development, and to plug computers and other embedded systems in general. But let me post the inaugural story in both places.

At the moment I run two Sheeva servers in my little data center. I have the third one set up as a development / staging environment. There are many ideas continuously coming to my mind. Most of them require testing various scenarios and it would simply be inconvenient to mess with the production machines. That is why I purchased the third one. hey, at $99 it is not a life changing decision.

When the third Plug arrived, I thought to myself it would be nice to have a permanent environment in place to play with it. Environment here means a host machine, needed to prepare the Sheeva to run and then a simple I/O for screen and keyboard and a web browser. The hardware requirements for such a machine are pretty minimal. As usual I wanted to have a decent screen resolution (1280 by 1024) and a good mouse / keyboard. I had a Samsung Syncmaster LCD display collecting dust underneath my desk. There was also a Logitech DiNovo keyboard and a Microsoft Mouse. The Samsung had simple VGA input and both keyboard and mouse were "Bluetooth". So all I needed was a kind of a low - end CPU with OS, storage and network interface. A Linux netbook seemed like a good idea. I called a friend of mine who purchased a number of HP-2133 mini-note netbooks some time ago. He had one for sale at a reasonable price. It arrived with Suse Linux on board. I played with it for a day, but did not like the Suse and tried a number of alternatives, finally selecting the Mandriva 2010 edition. The Mandriva was selected only because it installed almost flawlessly, detecting all the peripherals on board the netbook. I had some issues forcing it to support the native 1280 times 1024 resolution of the external monitor, but ultimately after upgrading the BIOS, I was clear to declare the victory. The system was fully up and running. Good screen, excellent keyboard and mouse, wired and wireless network and USB to connect serial console to the Sheeva.

Apart from the host Linux machine, I also needed an Ethernet switch. The Netgear GS105 is really nice. It is relatively heavy, so does not get pulled by the Ethernet cables. It is very small too, not taking too much space on the desk. I also found a very nice USB hub by Asmax (this is a Polish brand, but the product itself is probably available worldwide, just with a different name. It is white (matching the Sheeva) and has very thin and short cable with angled plug - perfect companion for the Sheeva - see the attached photos.

Now a few hints I put down.

To set up the Sheeva, I successfully use the SheevaPlug Installer. I never made it run on Windows, so won't help you here. But if you use the Linux version, here are a couple of things to consider (with respect to the Linux host machine):
  • Install the PHP client (sudo apt-get install php5-cli)
  • Install the missing LIBFTDI1 (sudo apt-get install libftdi1)
  • Set a proper MAC address to be burned to Sheeva by the Installer. The procedure is detailed in the installer's readme.
  • I strongly recommend setting up the Sheeva with a SD card. Personally I use 4GB Sandisk Extreme III 30 MB/s edition. It probably is faster than the internal NAND and most importantly - can be replaced once it wears out. On the other hand when you wear out the internal NAND, you will have to replace the entire Sheeva. To setup the system on a SD card, you invoke the installer as follows: [sudo php runme.php mmc].
Before you start installing system on the Sheeva, it is good to prepare a serial console on the host machine. This way you can watch the installer doing its job. To setup the console I had to do the following steps on the host machine:
  • Ensure proper serial interface is connected:
    rmmod ftdi_sio
    modprobe ftdi_sio vendor=0x9e88 product=0x9e8f
    chown uucp /dev/ttyUSB0 (or .../ttyUSB1 - depending on your setup)
  • Start serial terminal application
    gtkterm
After setting things up as described above and launching the installer the entire setup process takes about 10 minutes. It ends up with the Sheeva loaded with Ubuntu 9.04 (the rootfs is on the SD card) and its IP assigned by a DHCP server. You can ssh to root@. The initial password is [nosoup4u]. Before we start setting it up further, there is one issue, that has to be fixed in the boot loader. To get there keep the serial terminal open and reboot the Sheeva (do not disconnect from the mains, just use a paper clip to press the reset switch via the small hole by the SD card). Once it starts booting, hit Enter to stop the boot process. You will find yourself in the boot environment, that works on a set of string variables.

Display the environment by typing [printenv]. There are two variables we need to fix. Both are identical, one is called bootcmd, the other one is realbootcmd.

Type
setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); mmcinit; mmcinit; ext2load mmc 0:1 0x800000 /uImage; bootm 0x00800000'
and then
setenv real_bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); mmcinit; mmcinit; ext2load mmc 0:1 0x800000 /uImage; bootm 0x00800000'
and finally
saveenv
to make changes permanent.

The reason we do this is the double mmcinit command. There is a bug in the boot environment. After power up, it does not initialize the SD card properly. So without the above modifications, your Sheeva would not boot after power loss. Calling the mmcinit twice is a good enough workaround.

And we do this twice for a reason. Usually the bootcmd is used. But there will be time when you will have a need to reinstall the system from scratch. Having access to the boot environment, all that has to be done is to
run recover1
at boot time. The system will be refreshed. And so will be the bootcmd (it is copied from the real_bootcmd). Applying the fix in both places (bootcmd and real_bootcmd) lets you run the fresh installation process anytime without any need for additional fixes.

So the system is up and running now. The story will continue here :)

Friday, September 18, 2009

Ubuntu and Canon IP5200R WiFi Printer


I have been experimenting with Ubuntu recently. Must say the 9.04 package is far beyond expectations, especially when it comes to support for various hardware components. I installed the entire system in fully automatic mode and it discovered all connected hardware. It did not discover my Canon IP5200R printer, as it is not connected directly to any physical machine - being available on my home network over Ethernet instead.

Canon does not provide any Linux drivers for the IP5200R, so I was rather skeptical about being able to run it... But the other day I tried.

First I connected the printer using the USB interface. Surprisingly Ubuntu discovered it and offered a list of potential drivers. The IP5200R was on that list, so I picked it. Then it offered to print a test page and it proved everything was working fine.

I knew the printer was assigned an IP address of 192.168.0.10 so now the task was to try to connect it without the USB cable. And the solution proved to be much simpler that expected... In the printer settings dialog in Ubuntu there is a Device URI field. It was pointing to one of the USB ports. I changed it to [socket://192.168.0.10] and... it worked. Printed a test page with USB cable unplugged and kept on printing everything else over the network...

Unix has this great charm of simplicity... Thinking of this later I realized this printer must have a simple LAN to serial converter, meaning the actual protocol of commands and data transmitted to it never changes... regardless of the physical interface (LAN / Wireless / USB). So it is logical, to enable printing via LAN, it should be enough to change just the port settings.

Tuesday, November 18, 2008

Squeezebox Bose Duet


The Bose Acoustic Wave System (AWS) has been one of my favorite outdoor music systems for a long time. Mostly used for summertime garden parties it has remained a top sound engine, while lacking some of the latest music source capabilities. Actually the original Bose AWS has just two options: a CD player (no MP3...) and an FM-tuner. Ah and there is - as with all Bose systems - an AUX port, so I used to connect my iPod to it. iPod is fine, but it has one drawback - the music is static, you will never hear or discover new music, as iPod can play only what you store on it.

Pandora (my favorite music discovery service) is different. It keeps on playing exactly the music you like, but most of it you do not know, hearing it for the first time. The primary device to play Pandora on is a computer, but that is not as easy as turning on radio. And to be honest I hate computers (in their usual form, with screens and keyboards). That is why I have a house full of various products from SlimDevices, especially loving the Duets, as they decouple the music receiver (essentially a black box) from the control remote, with its rich experience and easiness.

Since the first Duet arrived at my home, I have been thinking of embedding one inside the Bose AWS, as they seemed to be the perfect match. I just have not been sure the Duet receiver would fit inside the AWE, but willing to try I've been prepared to sacrifice the built-in CD Player.

What was my surprise, after opening the AWS, there seemed to be a special place reserved just for the Duet receiver - see the photos.





























As the project ended with full success, here is the small step - by step how-to, should you have the desire to repeat what I did :).
  • Opening the AWE. There are two steps to it. First is removing the top part with the twitters, CD drive and touch buttons. The second is to play with the power supply accessible from the bottom, but let us leave that for later.
  • So start unscrewing the five screws on the left / right / back side of the AWS. The fifth holds the antenna, take it out and remove the antenna. Then detach the top part from the AWS.
  • Remove the board with five micro switches on it. Then using wire cutters or similar tool, cut the plastic frame below it to allow comfortable placement of the Duet board.
  • The Duet board needs one of the corners to be trimmed. See the attached pictures. Do it carefully, and after the cut clean the edge with a file. Otherwise you may short circuit the board with the remains of copper on both sides.
  • I placed a small piece of rubber between the Duet board and the micro switch Bose board, so they keep nicely together. Ah and you may use one of the micro switches to double as the Duet micro switch - solder two pieces of wire between the two, I decided to sacrifice the "CD Mode" switch.
  • Connect the Duet audio output terminals to the aux in terminals of the AWS. Make sure the shield is connected only on one side (I soldered it to the AWS terminal). Otherwise you will get some extra unwanted hissing sound effects.
  • Now the power supply. The AWS power supply delivers somewhere between 12 and 15 volts. The Duet board requires 9 volts. I used an L7809 regulator to take care of that. First I was not sure if I wanted the Duet part to be permanently ON, but it proved to be the right decision. You can always turn it off using the remote. The wiring and the placement of the L7809 are shown on the pictures. The left terminal (input) is connected by the red wire to the (+) terminal of the AWS power supply. The middle terminal is the ground, and so is the radiator, so I did not bother there, connecting the middle and the right terminals to the angled power plug, plugged into the Duet board.
The end result is something I think Bose should look into. They have phenomenal audio, but they really lack the latest digital connectivity options. Sure there is the new Logitech Boom, but it is more suited towards indoor, small room operation. The Bose AWS excels on the sound scale, has perfect outdoor accessories (integrated carry bag and battery compartment) plus it can do karaoke too. I am very happy with the modification and I think some of my fellow readers will try to follow :). Recommended!

Thursday, November 06, 2008

Making Powerline Ethernet HomePlugAV interoperable


A few weeks ago I posted an overview on the ZyXEL NBG-318S Powerline Ethernet switch / router with WiFi. After several weeks using the ZyXEL as my main entertainment room hub (both the PlayStation 3 and my set-top satellite box are connected to it, and it also serves as an access point), I can say the only thing I can give it a thumb down is the name. NBG-318S... who invents things like that? Nevermind... I can live with the name as long as the product shines.

So... the NBG-318S is a HomePlug AV device. That means, at least in theory it should work in tandem with any other HomePlug AV device. That includes for instance the PLE200 from Linksys. But that is the theory. In practice when I did a simple test plugging both the ZyXEL and the Linksys to the wall, they did not see each other. Digging here and there I found the PLE200 with factory installed firmware was not fully HomePlug AV compliant. Upgrading it to the latest firmware ultimately did the trick. The upgrade process was not as straightforward as it should be. First, there are different versions of PLE200 firmware on different Linksys.COM servers. I succeeded using the one from the US site. Here is the link. Version 3.3, with release date May 23rd, 2008. The upgrade process is done via the PLE200 client utility, but it has problems with Windows Vista, so I had to find a Windows XP machine, and disable the firewall on it (the Windows firewall prevented the upgrade too). And that is all the PLE200 utility can be used for, as I did not succeed linking to the ZyXEL using it.

On the other hand the ZyXEL web-based management interface allowed me to add the upgraded PLE200 to the Powerline Ethernet network. You do that simply by entering a MAC address and a device password, both printed on the back of the PLE200. Once the Linksys adapters were upgraded to the 3.3 firmware, the HomePlug AV network runs without any glitch. The average link speed exceeds 100mbps (see the side picture) and I have already watched a ton of movies streamed from my NAS server to the DLNA - enabled Sony PlayStation via the power line.

Sunday, November 18, 2007

Digital Home


I blogged here and there before describing various components of my digital home. The WiFi network, the IP Camera, the Squeezeboxes, the Slimserver... Now after several years of putting together several ad-hoc components the time has come to redesign the entire systems from scratch, based on the experinence with various products, vendors and technologies.

I will be updating this post, so come down here in a few weeks to see what has changed. Today just a short list of bullet points of what I intend to cover.

First of all I have two homes (one small wooden cottage I love to spend summer and weekends in) and a second one in the city, with a hot tub for harsh winter :). The ultimate goal is to connect both homes together and have a unified user experience in as many aspects as possible - starting from music playlists that should be up to date and synchronized among my iPod and both places, to the IP subnets addressing to be able to connect to any device from anywhere.

So here is the entire idea in a nutshell:
  • There will be a VPN tunnel set up between both homes. The one in the country has a fixed IP DSL line (1Mb only, unfortunately...). The one in the city has a 2Mb line with dynamic IP. I intend to use a Dlink DFL-800 VPN Router / Firewall there. The DFL-800 will server as a remote VPN server (I want to be able to connect to the home network whenever I am on the road) and also as a VPN endpoint of a tunnel between the homes. On the other side of the tunnel I plan to use a Dlink DFL-200 (have to check if it can "redial" the other end when DSL IP address is recycled by the service provider or whenever the link is just dropped. If the DFL-200 does not handle the tunnel good enough, I will probably opt for a second DFL-800.
  • Behind the firewalls I plan to use the Infrant ReadyNAS NV+ storage servers. They will serve as a generic storage on a local area network. I plan to set up replication jobs between them, so that each unit is a backup of the other. This way, for example, when I buy new music and save it on one of them, the content will be replicated to the other home, ready to be played there when I move.
  • The Infrant units will host Slimservers to power a local array of Squeezeboxes to handle multi - room audio around each home. This is easy to do now, as the latest Infrant boxes come with Slimserver preloaded.
  • Looking forward the Infrant units will serve as multi-purpose DLNA - compliant home servers, to be able to stream videos to various devices like the PS3 console or a Loewe Connected TV, or pictures to connected photo frames around each home.
  • Infrants will also store live picture snapshots from IP cameras, so the WiFi photo frames will be able to show near-real-time pictures from the other end. Living in the city it will always be nice to have a look at the wonderful virgin winter in the country :)
  • There will be other addons, like UPS units, WiFi access points, I will be describing them if they deserve some attention.
That is all from the distant perspective... will see how it goes... as the devil is in the details (as always!).