After publishing the last post on networking and the security series, I felt it was necessary to go ahead and publish a piece on building a custom router.  I have been a fan of pfSense for the past four years and swear by it. It has the ease of use of a commercial GUI-driven router and unrivaled flexibility limited only by the hardware it is installed on.  In this howto article, we will cover installing pfSense on an embedded platform and initial configuration for getting your router up and running.

First, an introduction to pfSense

PfSense is a lightweight FreeBSD based distribution geared towards router and firewall installations. It has been around since 2004 when it was forked from the m0n0wall project and has since turned into an excellent stand-alone distribution for routing and firewalling.  Although pfSense is generally intended towards full-PC installations, they offer an embedded image for use without skimping on the features.  pfSense is well known in the Linux/Unix/BSD community and is very highly regarded for both it’s feature set and it’s flexibility.

A question I get asked a lot is “Why pfSense? Why not just buy a Linksys?”  The answer is about hardware and software.  While I do own a couple of Linksys routers and do admire Linksys for bringing NAT devices to the common user, their hardware is restrictive and is only usable in the standard configuration (1 WAN and 4 LAN/WIFI) Even though it has been proven several times that the hardware they use for the LAN portion can support advanced features like VLAN support, bridging, multiple interfaces/IP’s, they will never release this functionality to those that want it and will instead force the advanced user to look elsewhere. In Linksys’s view, the router dictates the network.  With pfSense, I can build a custom configuration however I deem fit, with multiple NICs for WAN and LAN, with custom configurations and with VLAN support.  Not to mention that “stock” pfSense even supports DHCP, Captive Portal (like “free wifi”) , DNS, VPN support, Fail Over mode and many other options that Linksys wouldn’t ever make available.  Even if I never use VPN support or use the Failover mode, it’s nice to know those features are there should I ever need them.

Hardware Requirements:

In order to use pfSense Embedded, you will need a computer that adheres to the below spec.  Of course more is better, but these are the minimum specs as posted on the pfSense website.

• CPU: 100MHZ x86 Pentium or equivalent.
• RAM: 128 MB RAM
• Serial Port
• 512MB Flash storage or 1GB hard drive
• Two Network Adapters (NICs)

Please note that some of the advanced features like VPN support, Captive Portal and some high-bandwidth connections may require faster processors than what is outlined below.  If you want to make sure your embedded platform matches spec, take a look at pfSense’s hardware sizing guide which covers some of the items more in depth.

A note on storage:

The pfSense distribution comes in two flavors.  You have the “desktop PC” version for full-size computers with a CD ROM and a hard drive, and you have an “embedded” version which is for devices without a CDROM or hard drive and use some method of flash storage.  While you may be able to install the desktop PC version on the embedded device, it is not recommended as the distribution will be tailored for running on a hard drive, not a solid state memory device.  If you intend to use a hard drive, install the PC version.

You can use any IDE device for storage as long as it is recognized by your computer’s BIOS and is supported by FreeBSD.  I have not had a problem with either of these two stipulations, so you should not have any problems with it. One thing to consider is the use of an IDE to CF adapter like this one on Newegg.  This particular device fits right into the IDE header on the motherboard and allows you to use a Compact Flash cartridge as an IDE hard drive which is perfect for installing and running pfSense.  The router in my home is a slightly different model, but is running on a Sandisk 4GB CF cartridge and has been doing so for the last two years without fail.

My hardware:

In this howto, I will be using a Transcend 1GB IDE solid-state device that I got on Ebay. This device plugs into the 40 pin IDE header and mimics a standard hard drive.  It is fast and will definitely get the job done.  The hardware I will be using is a set top box device I scavenged from a computer show a long time ago.  It has a 233MHz Cyrix processor , 512MB RAM, an onboard serial port, an IDE port, an onboard NIC and a single PCI riser slot where I will be installing a dual 10/100 Intel NIC.

Getting Started:

If you are using the CF to IDE adapter mentioned earlier, you can use a USB-CF reader and an application to burn the image to the CF cartridge.

In order to proceed, you will need the following items

• A Linux based computer with one free IDE port
• An IDE-CF adapter with an appropriately sized CF card minimum 512MB, recommended 1GB, referred hereafter as flash cartridge.
• The “target system” that will ultimately run pfSense with at least two NICs.
• A third NIC (optional, for guest network, discussed in the “Advanced” section below).
• A serial cable (Female to Female) and a Null Modem Adapter.
• A pocket switch with a small patch cord.

Identify your Flash device

First, attach your flash cartridge to your Linux PC and boot it.  Make sure that it boots your Linux distribution first and does not attempt to boot from the flash cartridge.  Once booted, login as root and run dmesg. Look for the /dev entry for your flash module.  You may be able to look for the manufacturer name as is the case in my output below:

My dmesg output.

In the output above, my Transcend module was recognized as hda (primary master HD), so my /dev entry is /dev/hda.  We will need this later on to burn the image.

Download, validate, burn:

Now that we know what device we need to burn to, it’s time to get the image.  Head on over to the pfSense Mirror selection page and pick a server that’s closest to you.

You should then be presented with a list of images named pfSense-1.2.3-RELEASE-XXXX-nanobsd.img.gz where XXXX is a choice of 512mb, 1g, 2g and 4g images.  In my particular case, I will be using pfSense-1.2.3-RELEASE-1g-nanobsd.img.gz as it is pre-built to a 1gig flash cartridge.

Use wget to download the image along with the accompanying .md5 file as shown in the sample output below. Note: URLs in the below image may differ depending on the mirror you are using, but the filenames will be the same.

wget download of files

Once both files have downloaded, use md5sum -c to check the file for consistency against the provided md5 checksum as shown in the sample output below.

md5sum validation

If the MD5 check returns OK then you are clear to proceed. If not, go back and re-download the file again. Make sure you downloaded the same file and md5 checksum.  In order to burn it, we will use zcat to cat the zipped image out to the /dev entry mentioned earlier.  My syntax will be zcat pfSense-1.2.3-RELEASE-1g-nanobsd.img.gz | dd of=/dev/hda bs=16khowever, if your flash cartridge shows up at another location other than /dev/hda, be sure that you change the command above to point to the proper device.  Once the command completes, it should look like this:

Image Burn Completed

Now that the image burn is done, shutdown the Linux box and pull your flash cartridge out and install it in the device that is going to run pfSense.  Go ahead and connect it up but do not attach any network cables to the interfaces just yet.  You will also need to connect the serial cable with a null modem adapter to the device to continue initial setup.

Initial Configuration and Setup

Now that we’ve burned the image, we are ready to do the initial setup.  This entails doing some NIC probing to find the network adapters in the system and to assign them to their respective duties (WAN, LAN, Optional Interface 1, etc).  You should only ever need to do this once as once the NICs are set up and the router is running, you can do everything including re-assign the interfaces from the web-based GUI.

Open up PuTTY, Hypertrm or your favorite terminal application and set the serial port parameters to 9600 baud, no parity 8 data bits, 1 stop bit.  Turn on the embedded device and after a moment, you should see some BSD boot stuff flash past.  Wait until it prompts you to set up VLAN information as shown below:

Vlan Setup Prompt

If you are lucky, you should see two interfaces, one for each NIC.  If you have three network cards in your system, you will see three different interfaces.  In the above screenshot, I have em0, em1 and fxp0.  Since we will not use VLANs for our basic or our advanced configurations, we will answer “N” here.

Now, we will do some network probing to figure out exactly which NIC  goes to which interface using the pocket switch and the patch cord.  Don’t plug anything in yet.

Probe for LAN interface

With nothing plugged into the network interfaces, hit a and hit enter.  This will start the autodetection process. When prompted, attach the pocket switch to the interface you will use as the LAN interface and make sure that the LINK light on the switch and the NIC come on.  Hit Enter and you should see a message where it detected the LAN interface link come up.  It will then prompt you for the WAN interface.  Hit a then enter again and move the patch cord to the WAN interface and hit enter.  Repeat this process for the Optional interface (OPT1) or if your router only has two NICs, just hit enter.  Refer to the below output.

Assigned NICs

Be sure that you only change the patch cord when it tells you to.  If you disconnect the cable at the “hit A for autodetect” prompt, it may not detect link when it should.  If you run into this issue, disconnect the patch cord and restart your router.  Allow it to boot up and start over.  Once you get done assigning interfaces, simply hit Enter to exit assignment.  It will print the current assignments of the interfaces and ask you to validate.  Answer Y if the displayed assignments are correct and hit Enter, otherwise hit N and start over or restart the device.

Assuming all went well, you will see it do a bunch of additional configuration.  Once you get to the menu as shown below, you can then disconnect the serial cable and proceed with the configuration of the pfSense router.

Configuration Completed

Continuing the Configuration

Connect the pocket switch up to the LAN port of the router and connect your router’s WAN port to your Internet connection.  Connect a computer to an unused port on the pocket switch and start it up. Once booted, you should have an IP address in the 192.168.1.x subnet and depending on whether or not your Internet connection is DHCP, you may already be able to surf.

Open a browser and go to http://192.168.1.1 and when prompted login with the username of admin and the password of pfsense.  If all goes well, you should see a screen that looks like the one below.

pfSense Wizard

Click “Next”

On this screen, you will set some basic network configuration parameters like the pfSense’s hostname, local domain and the two DNS servers.  Use the ISP provided DNS servers here and click Next.

pfSense Wizard, page 2

On this screen, we will set up the timeserver and the timezone of the firewall.  Set the timezone where appropriate and then either use the provided time server or set your own.  I left it default and have not noticed any issues with time reporting.

pfSense Wizard, page 3

The next screen is where we will set up the WAN parameters.  Start off with selecting which type of WAN link you have.  Choices are DHCP (default),  Static IP, PPPoE and PPTP.  For each selection, there is a relevant section that must be completed.  Since I use DHCP, I left it as default.

pfSense Wizard, page 4

Pay special attention to the bottom two options.  The first option “Block RFC1918 networks” prevents LAN IP addresses from the “private” networks from entering from the WAN interface. Private networks are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.  Unless you are using this router inside another NAT environment, this option is best left turned on.

The other option “Block Bogon Networks” should be left enabled. This prevents non-routed and not-assigned networks from being routed against from your WAN interface. Since these addresses are not routed and not assigned, they should never contact your router anyways.

pfSense Wizard, page4, Bogon networks and RFC1918 options

Now we are at the LAN configuration.  This is where we can change the router’s internal IP address and subnet mask.  Please note that most of pfSense uses CIDR notation, so you may want to get familiar with it or have a CIDR calculator at the ready. Tip: a /24 is the same as 255.255.255.0

pfSense Wizard, page 5

This screen allows us to change the default password of pfsense.  I highly recommend changing it to something memorable.  If you forget it, you can always reset it via a serial connection without resetting the router back to factory settings.

pfSense Wizard, page 6

Finally we have reached the end of the wizard.  Click “Reload” and wait a few minutes.  During this time, the router will reboot itself to get adjusted into the new environment.  Let the web page reload the router’s admin page and it should take you to a configuration page like the one below.

pfSense main status page

Once you are at this screen, you should be able to browse the Internet.

Some basic tips:

• Portforwarding can be set up under Firewall -> NAT and works pretty much like you would expect a Linksys box to work.  Be sure to leave the “Auto Add a firewall rule to permit traffic through this NAT rule” at the bottom checked.  This will create a matching rule on the WAN side to allow traffic along with the rule to bring the traffic from the WAN to your destination computer.
• You can see each interface’s status by going to Status -> Interfaces.  If you are on a PPPoE or PPTP connection, you can disconnect and reconnect from this page.  If you are using DHCP, you can also release and renew your IP here.
• If you run into trouble performing port forwarding, you can access the system firewall logs via Status -> System Logs.  Be sure to turn on Logging on your rules so you can see new connections as they are being performed.
• If you’re having problems with a specific host, you can access a packet capture utility via Diagnostics -> Packet Capture
• If you want to diagnose upstream Internet connectivity issues, you can access Traceroute via Diagnostics -> Traceroute. and a ping utility via Diagnostics -> Ping
• Like numbers and graphs? Check out the system traffic graph (Status-> Traffic Graph) and the system RRD graph (Status -> RRD Graphs).  You may need to install the Adobe SVG viewer to view these graphs.
• Unlike a Linksys box, it is recommended to halt the router before powering down and use the reboot function if a restart is needed.  Both options appear under Diagnostics with the labels “Halt system” and “Reboot system” respectively.

What’s next?

Even in its basic configuration you already have a very powerful router on your hands.  The sky’s the limit. The pfSense installation can support a great many different configurations and options so don’t think that you’re locked into a single configuration.  Out of the box, pfSense has the software support for DHCP, DNS server, and other basic functionality as well as more things like CARP Failover, Open NTPD (Time server), OpenVPN, Remote Syslog, Traffic aggregation, and many other features that warrant exploration.

In a follow up article, I will explore setting up an advanced configuration, establishing a VLAN to isolate a wireless network from the wired network while still providing Internet access.  This is a useful configuration for you that like to share your Internet access but don’t want to make your home network vulnerable.

Happy Hacking!

FIRESTORM_v1

A few months ago, I posted a hardware teardown of the CVS Sylvania Netbook pictured above. After working with it and performing a lot of research on it, I promised a follow up article, and here it is.  To sum it all up, with a bit of modification to the software, a spare SD card and a lot of patience, you can actually turn this thing into a somewhat useful Linux device.  There’s also some improvements and suggestions to be had for improving the Windows CE side of things should you decide to continue using it in its default state.

When I posted the original teardown, I was somewhat distressed at how little information there was for this device. There was a ton of “marketing” material online however very few real-world posts.  This appears to have changed and although most of the reviews lamblasted the device as a horrible design and underpowered, I have found that for the price I paid for it, it’s not bad at all.  In this article, we will be focusing on software because as much as I’d like to say I’ve done a lot of hardware mods to this thing, the truth of the matter is that I haven’t.  Time has continued to get away from me and I’ve had to put a lot of projects on hold.  But let’s not start this article off on a downbeat.

In the three months that I’ve been doing research on the Sylvania Netbook, I have uncovered a lot of information that can help turn this machine into a pretty useful piece of equipment.  The fact that it has a pretty decent battery in of itself should be of merit to justify the time invested in fine-tuning it.

1: Windows CE

In my research, there have been two key complaints against the Sylvania netbook in regards to a “stock” configuration.  The first complaint has been that it is running Windows CE (affectionately called “WinCE”) and the second being that the WinCE installation is really badly implemented.

• The key thing to remember with working with Windows CE is that Windows CE is NOT Windows like on your desktop or “normal” laptop! Windows CE was designed for small form factor devices and although it shares the same name as it’s bigger brother desktop OS, Windows CE can not run Native Windows applications. This appears to be the biggest hurdle in locating user software for the device as people will attempt to download software then when they get the software into the netbook, they are thrown off by an error message stating it’s not a “valid” application.  Consider it like taking a MacOS program designed for MacOS and attempting to get it running in Windows XP.  It ain’t gonna happen.  That being said, there is Windows CE applications out there, however the pickings are slim.

• The other issue with working with the stock Windows CE installation is that the OS software is so badly implemented on the netbook that most things that should work, don’t.  Thankfully for us there is a patch available that will make things easier.  From research, the patch addresses several performance issues with the core OS, several updates to the builtin applications as well as an update to Internet Explorer.  Unfortunately, IE will still render mobile sites by default, but the rendering won’t take as long.  The patch also fixes the issue with the wireless card not being able to properly associate with WPA/WPA2 secured networks and DHCP release/DHCP renew works as expected.  I have uploaded the patch to here.  In order to install the patch, follow the below instructions. You will need a spare SD card at least 128MB in size.

Here’s how to download and perform the OS update:

1. Download the patch from here:  sylvania_laptop_OS_update.zip
2. Extract the executable to an SD card.
3. Insert the SD card into the Sylvania netbook.
4. Browse to the SD card slot (Computer -> SD Card)
5. Launch the patch and follow the on screen prompts.

2:On the Linux side of things…

When I did my original research, I was fortunate to have come by a site dedicated to a Linux distribution made solely for the WM8505 series devices like the Sylvania Netbook. The site and the distribution were called Bento Linux and much like the Japanese namesake, the distribution was very small and was designed to be able to run within the computer’s limited spec.  Unfortunately, the site www.bento-linux.org no longer exists but thankfully I still have the documentation and files needed to pull it off.  If you are the owner of bento-linux.org and are willing to give me the site files, I would be more than happy to host it here. Please contact me in the comments.

One of the added benefits of Bento-Linux is that unlike some replacement OS installations, this is a sidecar installation meaning that all work is done on the SD card.  If you want to boot to Windows CE, halt the Linux OS, pop out the SD card and power the Netbook back on and you’re up and running like nothing happened.  Although the Bento Linux site did have instructions for performing an installation to the device’s flash ram, it is not recommended as if you accidentally mess up the Linux distribution, there may be no recovery. In a sidecar installation, you can pop the SD card into another device, make your changes, and then put the SD card into the netbook and you’re up and running again.

Although the site claimed that the distro could run on a 512MB SD card, I will up the recommendation to at least a 2GB card.  Prices are low and SD cards are very commonplace so it’s worth it to get a larger chip.  I started out on a 2GB SD card, but later upgraded to a 4GB Microdrive and noticed a significant performance increase going from solid-state memory to a USB Microdrive. Your mileage will vary, but it is recommended to stick with an SD card first, then perform upgrades and additional installations as needed later on.  As far as USB devices are concerned, you can use any USB storage device/keydrive that is recognized by the usb mass-storage driver in Linux.

Please note that the version of Bento I was running is usable however it did not appear that the sound card was operational. Since I am intending to use this as an external serial console, this was not a deal breaker for me.

Installation (SD Card Only)

Bento-linux comes in two parts. One part is for a FAT16 partition placed at the beginning of the SD card and it contains the boot commands needed to tell u-boot (the Netbook’s bootloader) how to boot the linux kernel and the root filesystem.  The other part contains the linux kernel and the filesystem in an EXT3 filesystem and will contain all the files needed to run Linux.

1. You will need to start with an SD card at least 1GB in size.  I used a 2GB which gave me some room to play around on and of course the bigger, the better.
2. Partition the SD card with a 20MB FAT16 partition at the beginning of the card and the rest of the disk space can be allocated for an EXT3 partition.  Do not create a swap partition.
3. Download the file fatpart.tgz and extract it into the root of the FAT partition on the SD card.
4. Download the file extpart.tgz and extract it into the root of the EXT3 partition of the SD card.
5. Unmount the card and insert into the Sylvania’s SD cardslot and power on the machine. It should boot the Bento Linux distribution

Installation (SD Card + USB stick)

This setup does not require special partitioning, however it does require that the SD card be formatted FAT16.   You will also need a USB storage device formatted EXT3.

1. Download the file fatpartusb.tgz and extract it to the root of the FAT formatted SD card.
2. Download the file extpart.tgz and extract it to the root of the EXT3 formatted USB stick (or hard drive).
3. Insert the SD card into the Sylvania’s SD slot and insert the USB stick into a free USB port on the Sylvania.

In either instance, when you first boot the distro, it will simply bring you to a console prompt and you are good to go.  There are a couple of things you may want to do:

• (Pretty much required)  Set a root password.
• Install fluxbox (light weight graphical interface) and wicd for wireless control.
• Install aurora (lightweight firefox lookalike)
• Install other applications though apt-get as desired.

Although the bento-linux site is no longer in existence, it appears that all the repositories that come with the distribution point to the arm ports of the official Debian repositories.  Prior to them going offline, I saw a note about Bento-Linux had the sources for the WM8505 however it appears that VIA has recently released the sources for the WM8585/VT8505 chips that drive the netbook so if you have any custom drivers, it appears that now there is an easier method for getting the drivers compiled in.  I am not a kernel compiler expert so I can’t advise on this process, however some brief research does seem to indicate that there is some element of truth to this.

Linux Impressions and final words

After getting the Bento Linux distribution working comfortably in the netbook, I played around with it and made some tweaks here and there that did give some notable boost in performance.   If you are using a spinning platter form of storage, creation of a  swap file or swap partition is recommended as it will give you a performance boost.  Attempting to make a swap file on the SD card or on a solid-state USB drive are not recommended because of the performance hit when writing to these devices and also due to the issue of “burn-in” when a storage cell is written to frequently.  I found that the device works decently enough for quick tasks and light webpages however it will not handle flash at all, nor will it be able to render sites with large amounts of images.  In my testing, I was able to use this device to configure Cisco switches and other devices through a USB-Serial adapter and Linux’s “minicom” terminal emulator.

While I believe it was a valiant effort by Sylvania to enter into the netbook market, I do believe that they should have done more research.  The Sylvania netbook, even running Linux and with all the performance tweaks mentioned, still is easily beat by Asus’ first offerings into the Netbook market. The two biggest things that seem to harm this device are the lack of RAM in the system (mine only has 128MB RAM) and the sub-par processor less than 1GHz.  If you have one, then you may be able to make it work for you, however if you are considering one, I’d stay clear.  It’s not worth the price they are asking for it at CVS.

A couple of comments left by Syed and Dave to the original CVS netbook post indicates that there are people out there that are able to get Android running on this device.  If you have information or an article written on how you did it, let me know in the comments.  I’m interested in trying it out and finding out what works on this machine.

Well, the annual gift-giving season has drawn to a close and now we are left with retailers trying to get rid of all that extra stuff that thy have left over in their inventories.  Of course as a hardware geek, I’m always on the look out for another great hack. While at my CVS I came across a Sylvania netbook device for under $100. Even better, I got mine as an open box for only $30 making it an awesome find.  Read further to discover what this little beastie’s hiding under its hood.

The device touts itself as a “Wireless mobile internet device” and from the box, the stats are a little on the slim side. It runs Windows CE, has several USB ports, an SD card slot and a mic and headphone jack. The manager warned me to not expect a fast performing machine and that since it was an open box, CVS would not be able to take a return especially at the price I was being given. I told him that I plan on modding the device and would not need to return it.  He told me that although these devices were popular, many people were downright irate when they brought them back because of the device’s supposed horrible operability. I was still on the fence and told him that there’s a good chance I could do something with it and he sold it to me for $30 just to get rid of it and avoid having to ship it back to corporate.

Front of box

Back of Box

The box is small and light and shows the device as well as some specs on the back. I could see where the uninformed may be led to believe that this was a full blown laptop or netbook PC and purchase this instead thinking they got a bargain.  But, since I was out for hardware and not necessarily for a netbook, I knew immediately what I was getting into.  Let’s take a deeper look.

Closed Netbook

This image really doesn’t do much justice. This thing is SMALL.

Size against standard laptop

Here’s another pic of it sitting on my work computer. It’s roughly 1/3rd the weight, 1/3rd the height and 1/3rd the length of my lenovo T500.  Aside from the smallness of the device, I was impressed at how sturdy the device was. It’s plastic but the consruction itself was solid.

Netbook by itself

The keyboard is very small on this device however after typing on it for a while (this article was written on the netbook, minus image adds and minor editing) it quickly became comfortable, although don’t make any plans on speedtyping any time soon.

Netbook left side

On the left side of the device, you will find the mic and speaker jacks as well as the SD card slot for expansion storage.  The audio is powered by a VIA VT1613 audio codec.

Rear of the netbook

The back of the device has a wired Ethernet jack, a USB port and the 9VDC power port. Nothing too special here although I would have preferred an Ethernet jack with status LEDs. (first mod, maybe?)

Right side of netbook

The right side has two more USB ports designated by icons as for a mouse and keyboard however my keydrive worked in all three ports without a hitch.

Stock desktop

Keeping in mind that the device runs Windows CE, I fired up the stock software. It booted quickly in under 5sec to this screen.  I was able to configure it to my network and it ran quickly however I did notice that it had a problem with getting a DHCP address. I statically set it up and everything worked out of the box via corded connectivity.  There is an update (will post an update soon) that fixes this and many other issues.  Since this article is primarily intended to focus on the hardware, I won’t go into the OS details here.

Now let’s crack the case open and take a look at what’s inside.

Bottom of netbook

On the bottom of the device, there are 11 visible screw holes. The 12th is hidden under the white “Windows CE” tag and will also need to be removed.

battery pack

Once you remove the two screws in front of the bulge (foreground of last photo), you can remove the battery cover exposing the small battery pack.  I have no idea if this is an LiIon pack or NiMH or just plain NiCD. Disconnect the two leads and remove the battery.  Remove all remaining screws.

At the top of the keyboard, there are four tabs that hold the keyboard down. Push them in gently and then gently disconnect the keyboard ribbon cable from the mainboard.

Keyboard removed

Once the keyboard is removed, you will see two smaller openings with ribbons. Disconnect the left one as it goes to the trackpad. Tilt the screen all the way back and you will feel it lock into position. (No, you didn’t break it.) At this point, you can carefully remove the silver bezel from the black base. Now that the bezel’s gone, disconnect the right ribbon cable from the front of the mainboard. This is the LEDs for power and keyboard indicators as well as the left and right buttons for the trackpad. Also next to the right ribbon cable, there is a single screw. Remove it as well as the four screws holding down the hinges to the monitor and this will free up the mainboard. Do not attept to disconnect the two ribbons going into the display housing. The right ribbon is the USB WiFi module which is hand soldered and the other is the ribbon which carries the video signal and is glued to the mainboard.

netbook mainboard

Now that the beastie’s guts are on display, let’s take a look.

Netbook SOC

The entire device is powered by a VIA WM8505 SOC with a 2GB flash chip and 128MB RAM. Those extra pins have got to be used for something fun…

VIA Audio

As mentioned earlier, a VT1613 Audio codec provides sound.

Netbook Network IC

An IC IP101A chip provides us the 10/100 networking.

Keyboard Controller

The feared epoxy blob, in this case appears to be the keyboard controller.

Unpopulated header

What do we have here? An unpopulated header with two wires that run straight from the SOC to the header. Perhaps this is a 3.3v serial port?

Trackpad

This is the touchpad from the bottom. It is a Cypress CY8C214 and ironically enough is also the controller Apple uses in their Ipods. Now that we’ve disassembled the base unit, it’s time to take a look at what’s under the display bezel.  You can get at the screws holding the display bezel together by removing the four black rubber stops at the corners and the screws that lie beneath them.  Once removed, the bezel is easily separated by the use of a spudger or small common screwdriver.   Once revealed, you can see the display, the display controller board and power switch, the two tiny speakers and the wifi card in the top right hand corner.

Display Module

Now, I’ve seen all kinds of weirdness when it comes to the internals of laptops however this one had me floored.  The wifi card was not a “card” but more like a USB dongle that had the connector ripped off and replaced by a long cable to the mainboard.  The downside is that this is a very cheap move on the part of the manufacturer but the upside is that you can pretty much replace this USB dongle with one of your liking later on.  It appears that the stock card is a Ralink RT2070L chip and should be well supported in Linux.

USB Wifi

In Summary…

So after spending a couple of days working on it, I was able to locate a firmware update for the Windows CE device.  This update fixes the DHCP issue that previously required me to set a static IP for wifi and for ethernet connectivity.  There were some noticeable speed improvements to the device.  I have been able to get Debian Linux to boot off an SD card on the device and also have managed to get the onboard Ethernet to work.  I have also been able to get the device to start a blackbox X session and installed Iceweasel however the speed for page loads and views is very slow so performance will need to be tuned. Once I have it tuned properly and performance is decent, I’ll post the updated image to the site so you can download and enjoy.

All in all, I think this is an excellent find at the $30 I paid for it. It is  comprable to the Dockstars I have but even at $100 retail it’s got a lot of potential to make it worth the cash. Just be sure to download and install the Windows CE update as soon as you get it. This will help you avoid a lot of headache later on trying to get the thing to talk to your LAN. As soon as I have more resources, I’ll post a followup article with links for downloading the updates as well as the linux images.

Just in case you missed it, let’s go over the details:

• Display: HL 070 TN92 – Unknown Manufacturer -  800×480 May be TFT?
• Battery: Unknown Metal, 1800mAh 8.4v
• Charger: 9VDC, 1500mA positive tip.
• System Processor: WonderMedia WM8505+ (linux identifies as an ARM936EJ-S rev 5), unknown speed.  Research points anywhere from 200MHz to 600MHz.
• System RAM:  128MB SDRAM, unknown manufacturer. Chip number: NY64X161043
• System Flash: 2GB cumulative (WinCE partitions 500MB for system and 1.5G for storage) – Samsung K9GAG08U0
• SD expansion port
• Audio: VIA1613 codec
• Ethernet: 10/100 provided by ICIP101A
• Stock OS: Windows CE 6.0

If you’ve done any mods to your netbook, post a comment! There’s a lot of “reviews” but no real modifications yet to speak of. Hopefully this cheap starter will open up some good ideas.

Happy Hacking!

FIRESTORM_v1

The Parallax VGA GUI Demo is great for adding a pre-built GUI for your projects. The bonus is that the drivers for using a PS/2 keyboard and mouse and a VGA display are pre-built and ready to run.  With a little bit of configuration, you can add a well built UI to your application and make it easier to display output and receive input from the user.

In this article, I will demonstrate some of the basic options that are needed in order to get the GUI up and running.  While our application is going to be turning on a few LEDs, once you have these basics down you should be able to use this article and build whatever user elements are required for your application.

Prerequisites:

If you haven’t already, I would recommend the Parallax PS/2 and VGA Adapter board. This board provides two PS/2 ports (mouse and keyboard) and a 15 pin VGA port in an easy to use modular design that is breadboard compatible.  Here is a link to the VGA board on Parallax’s site and here is the link to my earlier article.

In addition to the Adapter Board, you will need
- A PS/2 mouse (Not a USB mouse with a PS/2 adapter)
- A PS/2 keyboard (Not a USB keyboard with a PS/2 adapter)
- A 15 pin VGA monitor
- six LEDs, any color
- six 100 ohm resistors (Brown-Black-Brown)
- Jumper Wires for the Adapter board
- A PC with USB port for the PropPlug USB programmer.
- 9V Battery or other 9VDC power source

Understanding the concept of a UI

Before we get started, let’s discuss the basic differences between a Prompt and a UI.

A Prompt:

• – asks for something direct like “Your Name”
• – Reads the response, Input halts until requirement satisfied, e.g. (Press any key to continue)
• – Treats the response as programmed, e.g. $YourName
• – is programmed in a linear fashion. e.g. You prompt for your name, then you prompt for your address, then you prompt for your date of birth, etc…

A GUI:

• Shows multiple items to interact with
• Reads a response when triggered with an event and does not wait.
• Performs actions based on event triggers.
• Can perform actions in a non-linear fashion. e.g. Clicking Button 1, Button 3, Button 2, Button 6, Button 1 again.

Remember, although a GUI can contain prompts (“Click OK to Continue”), it’s not often that a prompt becomes a GUI. Also remember that a GUI is Event driven, not prompted.

Events

It’s important to understand that performing any action with the mouse and keyboard triggers an event. It’s when the event (in most cases, a mouse click) occurs on a GUI element (a checkbox for example), we get something to happen.  By programming the Parallax GUI Demo, you will build GUI Elements (things to click on or type into) using Mouse and Keyboard Events in order to generate some kind of output (Lighting LEDs).

Keep this in mind, as generating events and how to deal with them are the cornerstone of any GUI programming (not just Parallax!).

Elements

Mouse events are nothing without something to interact with, so that brings us to the point where we have to talk about the GUI. Each object in a GUI, checkboxes, menu items, windows, submit buttons, etc. are all considered elements of the GUI. We build the GUI using elements to satisfy our program’s needs.  For the “What is your name?” prompt, we would need a window element (with a Window Title element), a text element saying “What is your name?”, a text field element (so we can get the name back to the program) and a submit button element.  That’s Five elements! Thankfully, only two of them are interactive.  The text field needs to be clicked on (to tell the GUI that keyboard input goes here), and the Submit button needs to be clicked on to tell the program to continue.

Even though we started out with five elements, thankfully we only have to code for two events.

Below is a screenshot of various elements that the Parallax UI is able to generate.

Parallax VGA Demo Screenshot

In this screenshot, we can see the following interactive elements:
- Spin Boxes – A single element with up and down arrows that allow you to select from a list of predefined options. (like a Page Count field on a Print window)
- Checkboxes – A listed series of predefined options that allow for multiple options to be selected.
- Radio Buttons – A listed series of predefined options that allow only a single option be selected.
- Pushbuttons – A single element that is clickable (like a submit button).
- Menu Bar – A horizontal element containing multiple pushbuttons.
- A Text Input field – Another horizontal element that takes input from the keyboard.

We also see the following non-interactive but still needed elements:
- Windows – We need windows to keep these elements organized, otherwise it doesn’t work too well.
- Status Lamps – Think of these as the GUI equivalent to an LED and resistor. They can be toggled on or off.

Now that we know what all the elements are, let’s do something.

Getting the hardware ready

Connect the 15 pin VGA/PS2 breakout kit to the lower right hand corner of the breadboard as shown in the image below. The breadboard should be oriented as shown with the PropPlug mounted on the top, usb cable pointing right. You can then connect the 12 pins straight across (watch out for the crystal) to the 12 pins on the right hand side of the Propeller (P16-P27).  Attach the Vss lead to any of the Vss busses (black lines) on your breadboard.

VGA adapter hooked up

In order to get the required +5V for the PS/2 mouse and keyboard, look closely at the two voltage regulators at the top of the board. There is an LM2940 (back regulator on the picture below) that provides the 5V and a LM2937 (front regulator) which provides a 3.3V source for the Propeller. Be sure to attach to the OUTPUT of the LM2940 as shown in the picture below.  As a hint, my wire is in the third horizontal row from the top of the LM2940 which is its output lead.

+5V location

DO NOT CONNECT YOUR +5V LEAD TO THE +9V BATTERY OTHERWISE DAMAGE TO THE PROPELLER, MOUSE AND KEYBOARD MAY RESULT.

After you have the VGA adapter connected, hook up the LEDs so that the cathodes go to ground and the anodes run through the 100ohm resistors to P0-6 as shown below.

LED connection

Get the software

If you haven’t already done so, download the VGA Text GUI Demo from here:  http://obex.parallax.com/objects/413/

Unzip the archive, load it up in your Propeller Tool application and load it into RAM to save write cycles on your EEPROM.  If everything works properly, you should be able to move the mouse, click on things and be able to type text in to the “COMMAND” field at the bottom. Play around with it for a bit and get used to how the elements interact with each other.  If you want to ensure that your wiring is correct, read the GUIDEMO and GUIBASE section below.

Before proceeding, it’s recommended to make a backup of the unzipped Propeller VGA demo so that you will have something to refer to in case you accidentally delete part of the demo application. Load the copy of the code for the next step and leave the original copy untouched.

Hacking up the Code

Now that you’re up and running with the test code, let’s take a look at the existing code and start modifying it.  We’ll cover important aspects of the existing code along the way. In our application, we will be using the UI to draw a simple window containing six checkboxes that correspond to the six LEDs we have installed.  Once finished, when we check a box, it will light the corresponding LED. If we clear that checkbox, it will extinguish the LED.

So let’s get started.

GUIDEMO.spin

The GUIDemo.spin file is considered the “Top Level” or “root” (if you’re a Linux admin like I am) of the entire  application. This file references sub-codebases through  an OBJ (Object) declaration. Although Parallax called it Top Level, I have always referred to it as the “root” as in the root of the project much like the root of a filesystem.

Without getting into the syntax of Spin (the Propeller coding language, a topic that Parallax is much better suited for than I am) just know that this is the trunk of the tree as far as all other pieces of code in the VGA Demo are concerned.

Code Heirachy

Starting at the top of the GUIDemo.spin file, you see a secion labeled CON. This is for the constants that GUIBase uses to initialize the PS/2 mouse and keyboard and the 15pin VGA port.

The vga_base should point to the I/O pin that is connected to the “V” pin of the PS/2 VGA adapter. The GUIBase will assume that the rest are mapped accordingly.  If you are using something other than the Parallax adapter, you will want to ensure that your adapter is wired up as shown below:

I/O Pin        Function
P16        V – Vertical Scan
P17        H – Horizontal Scan
P18        B0 – Blue Positive?
P19        B1 – Blue Neutral?
P20        G0 – Green Positive?
P21        G1 – Green Neutral?
P22        R0 – Red Positive?
P23        R1 – Red Neutral?

* Please note, the ?’s mean I’m not certain on polarity, but I am sure on the grouping. The reason is that I only have the Parallax VGA adapter so I haven’t tried to fabricate my own adapter.

The mouse and keyboard each require two pins, “dat” and “clk”.  The Parallax Adapter has each pin’s function silkscreened onto the adapter’s PCB for easy connection and are mapped as shown below:

I/O Pin        Function
P24        Mouse Data
P25        Mouse Clock
P26        Keyboard Data
P27        Keyboard Clock

If you’re using Parallax’s VGA adapter, then make sure that your values match what is shown above.  If you are using another adapter, make sure that the values match your respective device’s pins.

The OBJ section is where we declare any additional code that needs to be included. In the original code, you can see there are three objects declared (GUI, TMRS and NUMS) however for our program, we only need the first one (GUI).  Delete the two lines starting with TMRS and NUMS highlighted in the green square in the image below.

External Objects

When it comes time for you to add your own routines, you can include them here by defining them as objects. For now, just scroll down to the next section.

The VAR section is important because the code shows that all of the interactive elements in the GUI require a byte be assigned to them. This is important as this is how the GUI keeps track of what element is called when an event is triggered. It is critical to remember when you are designing your own GUI, that each interactive element has it’s own unique ID. This will be important later when we tie the elements into events. For now, remove all the declared bytes and add the below in it’s place:

Variable Bytes

In the above image, we are declaring six CHKB elements numbers 1 through 6.  The naming convention is important as there is code later on where these get defined.

Scroll down to the PUB statement below. This section is the actual code of the program and where we will be doing most of the editing.  First off, make sure that you can see between the CreateUI statement and the PUB statement (top of the blue section of code as pictured below. We will be removing the code there as it was used with the timers code object (that we removed) was initialized at start.  Just like before, delete all the code within the green box. It’s not needed and will generate errors if you attempt to compile it.

PUBlic function to delete

We will replace the deleted code with our own code. This  is the initialization code for our application and occurs prior to the GUI being set up. All our code does is ensure that the first six I/O pins (P0-P5) are set as outputs and are set low so that the LEDs are off.

When you are developing your own program, be sure that the initialization code occurs before the CreateUI statement for best results.

PUBlic INIT code to add

At this point, we have removed excess objects from our code and declared six variables for our checkbox elements and we have initialized the LEDs. Now we will tell the application what to do when an event has been triggered in order to get the LEDs to light up.

If you look at the code, you will notice that it is a very large repeat loop that contains a case loop inside it. The way it works is that the Propeller will constantly evaluate GUI.ProcessUI. When evaluated, it will check gx against the list of elements and if gx matches a defined element ID, it will then perform the appropriate action.

For now, start at the line that reads “case gx” and highlight the text down until you get to the “START OF UI HELPER FUNCTIONS”. Since we are not using the demo code in our application, we can safely remove it.

Once removed, add the code in the below image to tie in the events with our custom function. (We’ll write it next).

Public Events to add

In the above code, we are calling LEDFunction with a different parameter corresponding to each of the six LEDs. Now we need to write the function LEDFunction so it actually does something.

In your application, you may end up writing all of your code in another .spin file and then using an OBJ to declare it.  If you do that, then you can reference your OBJ functions instead of using a basic function here.

Start off by copying that CON statement and inserting it into the empty space. This will create a line we can use when reading the code to make it easier.  Change it from “UI HELPER FUNCTIONS” to “UI APPLICATION FUNCTIONS” and add the below code as shown.

PRIvate Function to add

In this section of code, we will write our function for the events.  All we are doing is taking the function’s parameter and inverting it’s existing value. If it’s 1 (on) it is then set 0 (off) and vice versa.  Although we return the value of the I/O pin, it is not used elsewhere and will get overwritten elsewhere.

Scroll further down and we finally get to the CreateUI function.  This is where the UI gets built and the bytes for the elements earlier get defined.

We can see that there are a lot of commands listed here. Don’t let that intimidate you as we are going to remove most of them. Find the line that starts off with “vga_cols” and highlight all the way down to the MIT License.  Remove the code and add the code in the picture.

GUI Code to add

This code draws out the Text box for our project and gives it a text label. Don’t worry about the syntax, we’ll cover that in the GUI CODE section later.

Basically what happens here is that a Simple Box (SBOX) gets drawn with the title of “LEDs”.  Inside that box, six checkboxes are drawn, each with their own text description. Pretty straightforward on the UI, right?

We’re almost done and ready to test our new GUI.

GUIBASE

Now, there’s one more thing we need to do before we go loading this project into RAM and seeing if it works. We need to make an edit to GUIBase.
At the very top of GUIBase, in the CON section, you can see that there is a note describing the GUI Element Inventory that must be present.  We need to edit the code and tell GUIBase that we’re only using six checkboxes.  However, as the note describes, we can’t just go set GZ_CHKB to 6 and all others to 0, as this would throw a compiler error.

Go ahead and set all of the GZ_ variables to 1 except for GZ_CHKB which will get a value of 6 since we have six LEDs as shown below.

GUIBase changes

Once modified, be sure to save your work and then go to “Run”, Compile Top, Load RAM.  You should get something like the below image on your display.

Our GUI LED demo

If all went well and you didn’t get a compiler error, you should get this GUI.  The little green square is the mouse cursor.  Go ahead and try it out. Make sure that checking each checkbox lights up an LED and that clearing the checkbox turns it off.

Now that we’ve got a working GUI up and running, let’s review what all we did aside from removing a lot of extra stuff.

• We declared a byte for each GUI element.
• We added initialization code.
• We added a declaration in the main loop to handle events from the UI to point to our function
• We wrote a function that did something based on the events we had given it.
• We updated GUIBase with the element count so that the GUI code knew how much it had to work with.

These are the fundamental steps for creating a UI with the propeller using the GUIBase code. Now that you understand the basics as far as what is required, let’s take a look at some other stuff you can do too.

Looking further into the GUI Code

In the GUIBase.spin file, you can find the code required to draw the various elements of your GUI.  Reading through the code,  most of the options required are in terms of position.  For example, the code for the simple box (window) shown earlier, required an X and Y coordinates (in rows/cols) to place the upper left hand corner of the UI, then the width and length of the box and a title.  The Checkboxes each required an X and Y coordinate, then a text length and finally a label.

If we were to use a Radio Button group, we would need to provide an X and Y coordinates, a text length, a text label and a Group ID.  The Group ID is used to associate the radio buttons together.  Below is a screenshot of my implementation along with an Apply button:

Radio Buttons and Pushbutton code

In the above code, you can see that I have established five radio buttons (RADIO1 to RADIO5) in addition to PUSHBTN1 pushbutton. These are set up in the main loop below:

Push Button UI Code and Functions

In the above code, you can see that the SetLEDStorage passes a number which gets stored in LEDState. When the Apply button is pressed, CommitLEDs takes LEDState and sets the six LEDs to the binary value of whatever was in it.  Below is what the UI looks like:

Radio Button GUI

Just like adding the checkboxes, I followed those same steps here:

• – I declared my additional UI elements’ GUID bytes (RADIO1 to RADIO5), my Radio Button group (RBGID1), my  pushbutton (PUSHBTN1) and my LEDState variable.
• – I added my init code (setting LEDState to 0, not pictured)
• – I added routines for my elements to call user functions. (SetLEDStorage and CommitLEDs)
• – I declared the routines so that they did something (stored the LED value, applied the value to the first six I/O pins)
• – I updated GUIBase.spin with the new list of items ( added five radiobuttons and one pushbutton.)

Give the code a try and you will see that while the checkboxes set the LED state instantly, the radio buttons do nothing until they are applied with clicking on the Apply button. This is important because as you design your GUI, you will need to decide if something must happen when the mouse is clicked right then (immediate action) or if the action will get applied later on via an “Apply” button. This is entirely up to you and there is no need to do things only one way.  Either method works but whether or not it works properly for your application will be your choosing.

Tips and Tricks, and things to watch out for

While developing this article, there were a couple of things I came across that you may want to watch out for. Don’t worry, you won’t blow up your Prop if you make a mistake in coding, however there are a few things you may want to keep an eye on:

• - Load to RAM, load to RAM, load to RAM and check your battery.
  In my writing this article, I found out real quick that driving a display, mouse and full size keyboard will drain a 9V transistor battery very quick.  A symptom of this drain is the Green LED that is present on the Propeller Education Kit. If it starts to pulse and your monitor loses sync, it’s time for a new 9V or consider a 5V USB power cord. Also, to save write cycles on the EEPROM, load to RAM whenever possible. Your computer’s hard  drive is more suited to incremental saves, EEPROMs are not.  Only save to EEPROM when you are ready to test your application in real life.
• - There is no boundary checking.  If you overlap your windows, then there is no going back. When in doubt, you can use the Mouse code to print the mouse coordinates on your project to help you identify and troubleshoot positioning.  Remember that all GUI elements start by defining the upper left hand corner of the element. You will need to include the NUMS object (SimpleNumbers.spin) and the code from the original GUIDEMO.spin (lines 314 to 316) in order to have it show up.  You can see an example of the boundary overlap in the below image.

Button overlaps window

• - There is no off-edge boundary checking either.  If you are setting a text field too far right of the video display or too far down, it will get cut off and your entire GUI will not work right.  In this case, I set the Predefines window to X40,Y75 and 25 columns wide which was out of the limits of the current VGA resolution.  The below image was the result and my UI only partially worked.  Resetting and reloading RAM fixed it.

Window moved out of range

• - Also as demonstrated in the image above, UI elements are not bound to the window you create them under. Assuming that both windows were same size and I mis-typed the coordinates, the Apply button could very easily show up under the checkboxes instead of the radio buttons leading to a confusing display.  You will want to make sure that your UI elements do not overlap at all as this could affect how the UI interprets your mouse actions.

Last Thoughts

There is so much you can do with the Propeller UI to make your applications more interactive.  With little work, you could build something like a serial terminal and embed your project in an LCD monitor or you could make a basic home automation system with a touchscreen LCD and a wireless transceiver. The possibilities are endless and with the Propeller, you can now use full GUI capability with keyboard and mouse support.

As always, Happy Hacking!

FIRESTORM_v1

The reason I haven’t written any more about my fun with the Dockstar was that due to an unfortunate set of circumstances I was left with a bricked dockstar. (read: I did something stupid.)  After performing a lot of research and thanks to a bunch of people over at the PlugApps.com Forum site who helped me, I was able to get it running.  Read more for a complete list of what you will need including how to build an adapter and where to get the needed JTAG kit.

Before we begin

This document demonstrates how to recover your Dockstar and upload a custom bootloader to it using a JTAG cable.  JTAG is used for low-level in-circuit debugging of embedded applications and is very hardware specific. If you are familiar with working with Linksys routers and uploading custom firmware to them, you have heard of the term bricking and you have more than likely heard of something called JTAG that is used to recover it.

Because of the nature of JTAG and the fact that manufacturers don’t typically like us having access to the JTAG port, these ports are often hidden in many different locations, usually unmarked or unpopulated headers, or other odd locations and is the way that the manufacturer loads the firmware for the very first time on to a new device.

By using JTAG, we can place the hardware into a “debug” mode where we can manipulate the microprocessor’s core functionality.  We can also send instructions to it, monitor responses from it, or even pause the chip, leaving it in a state of suspended animation until we issue the command to start it up again or reset the device.

In this particular howto, we will cover how to use the debug mode of the Marvell chip in the Dockstar to upload a new boot loader in order to rewrite the bootloader to the onboard Flash which will result in a working, new Dockstar.  Please note that if you have NOT bricked your dockstar, there is no need to perform the steps in this howto.  This is only for bricked dockstars that have been verified with a serial adapter to be dead. (A dead dockstar will produce NO serial output and the front panel LED will not light up when power is applied.)

Legal Disclaimer

By performing the steps outlined in this document, you agree not to hold firestorm_v1, YourWarrantyIsVoid.com or any other linked sites, forums, companies, liable if you really screw something up.  You can also not hold any of these entities responsible for data loss, physical damage, emotional trauma, spousal abuse or any other act of whatever god(s) that you may have happen to you.  In short, Read twice, type once, hit enter and don’t screw up.  If you’re at this point, then you’ve already come to terms that your dockstar may be unrecoverable already so deal with it.

Parts List

In order to perform this recovery, you will need the following items:

1. The dead seagate dockstar and power supply.
2. A handful of 2.0mm female connectors or one 2.0mm female connector with at least 10 pins (5 pins in 2 rows)
3. A 10 pin header that matches your PCB 2.5mm spacing  (again, 5 pin, 2 row)
4. A bit of holed PCB board 2.5mm pin spacing. (Radio Shack is good for this kind of stuff)
5. A CA-42 cable with the appropriate pins as outlined in my previous Dockstar post.
6. A handful of extra breadboard jumpers.
7. Superglue
8. A Windows PC (2k or XP, untested on vista/7 although plugapps forums says it should work.) with a Parallel Port
9. Whatever provisions needed for the CA-42 cable to work properly.  (I have to use a linux box to SSH to, you can do the same or if your Windows computer works with the CA42 cable, you can use that as well.  You don’t need two PCs for this operation.)
10. A TAIO Buffered/Unbuffered “Universal” Parallel Port JTAG module kit (Here’s the eBay seller where I got mine, ~$21.00 out the door) and a Parallel cable extension (Male to Female) so that you can reach it without having to get behind your PC. For my setup, I used an old iomega Parallel/SCSI Zip drive cable. I also recommend the ebay link as this is the seller that I purchased mine from and it comes with a lot of extra jumpers that are very useful for this project.
11. A USB A to USB mini B cable (for powering up the JTAG adapter).
12. Glue gun with extra gluesticks
13. Heatshrink tubing and lighter/heat source
14. In lieu of building/reinforcing your JTAG cable, you can use a laptop hard drive adapter (3.5 IDE to 2.5IDE) if you’re in a pinch and just need to get it running.

In addition to the above items, you will need the following software applications:

1. Kragorn’s copy of dockstar.cfg – Mirrored Here
2. A copy of OpenOCD – Mirrored Here
3. A copy of the Jeff Doozan’s custom USB-boot capable u-boot (Recommended!) (Mirrored Here) or a copy of another factory or custom uBoot.  If you want to compile your own, there’s a great write-up here: http://jeff.doozan.com/debian/uboot/
4. A copy of PuTTY for Serial/Telnet communication.  You can download it here.

Getting Started

This howto will be divided up into several sections:

Section I:Building an adapter cable – This section will cover how to build the required cable from spare 2MM connectors or if you already have the proper cable, this will describe how to reinforce it for repeated use using heatshrink tubing. I call it a smokestack cable because it resembles a small smokestack sticking out of the Dockstar’s mainboard.

Section II: Wiring it all up – This will cover the Dockstar’s pinout, the TAIO parallel port pinout, the serial port pinout and how to wire it up together.

Section III: Performing the JTAG recovery – This is where the actual recovery process takes place now that we have everything wired up.

Section IV: Notes and credits – As much as I’d like to say this was all my doing, truth is it’s not.  I couldn’t have done it without some great people from the PlugApps forums.

Each section will have lots of pictures that you can use as a guide to make sure you’re making the right connections.

BIG FAT OBNOXIOUS WARNING!!!

Although there are as many JTAG adapters on the market as there fish in the sea, I can not cover each and every device’s unique configuration options. Generally the JTAG port is a universal standard but many vendors implement their own standard, have other standards that they choose to leave out and their pin configurations may not match what is given here.  This article is based on my experience performing the JTAG restoration of a dockstar I broke using the equipment and the software outlined above.  If you are new to JTAG, I recommend using the versions and adapter board listed as other devices/software may not work in the same way.  When in doubt, go with what you know!

Section I: Building out the JTAG adapter cable.

The dockstar’s JTAG port uses a 2.0 mm spacing and while it’s good for tight spaces, isn’t exactly ideal when dealing with breadboard jumpers as most breadboards have a 2.5mm spacing and the jumpers have connectors to match.  In this instance I felt that since I was going to be working on actually developing code for the Dockstar, the inevitable would happen and I would end up bricking it through a random error (namely user failure) and would need a quick and reliable connector that I could use to quickly connect and disconnect the JTAG port as needed during restore and development.

I checked out EPO and managed to find several 2.0mm spaced connectors however these were in groups of three and while they would work, would require significant effort to harden the connectors to something that could stand the test of repeated connections and disconnections. So let’s get started.

Checking the connectors to make sure they would work

This is a shot of the connectors standing out of the Dockstar.  Since I had four connectors with 3 pins each, this means that I had two pins that hung over the connector block on the Dockstar.  Since these two wires were not needed, I cut them and removed the metal connector from inside the plastic, leaving 10 wires for 10 pins of the dockstar’s JTAG port.  We’ll deal with the two vacant holes later.

Little known fact: The pin spacing on the Dockstar’s JTAG port is identical to that of a laptop hard drive (which is why this part of the process is optional.)  In a pinch, you can use a laptop IDE adapter similar to this one (in fact I own several exactly like this).  If you decide to use a laptop IDE adapter, use the part of the adapter opposite the power connector.

Since the goal is to harden the four little connectors to one single connector, I used a dead laptop hard drive and superglued the four connectors together. USE THE SUPERGLUE SPARINGLY!! You do not want to superglue your connectors to a hard drive so only put a tiny amount. It also helps to put a dab of glue on one connector, then put the connectors together as you’re pushing them onto the laptop HD pins.  Make sure they are completely seated so they will be even as possible.  If you see the pins of the laptop HD, you’re not down far enough.

Glued 2.0MM connectors curing on a laptop HD.

Once you get all four connectors onto the laptop HD and properly aligned, let it cure for at least an hour.  This will ensure that the superglue bonds correctly and the connector doesn’t fall apart later.

Glued connectors after the superglue set.

Now that the superglue has set, check that it still fits in the Dockstar. On the connectors used here, my wires were quite long. To alleviate yet another mass of cable snakes on my desk, I cut them down to about three inches, which should be big enough to handle, but small enough to not get in the way. You can cut your wires to any length desired.

In order to solder to the 10 pin header and ensure that the wires would not seperate from use, I chose to use a small piece of PCB as shown below.

Header and Breadboard

Keep in mind that if you cut your own, you’re soldering 10 wires into a 10 pin header, so you will need a 20 hole piece of PCB (5 holes by 4 holes).  The idea here is that the wires will come in on the component side of the PCB and wrap around it then go further down to the 2.0mm connector we just glued together.   Go ahead and solder the header into the center two rows of the PCB as shown below(Leave one row of 5 on each side of the header).

Header and PCB soldered together

Strip off a 1/8 inch off of each wire on one side of the glued connector and solder to the PCB. Keep your pinout the same and do not cross the wires.   Below, you can see that the first half of the PCB and the wires has been soldered.

Header with one side soldered.

Now comes the fun part.  Trying to solder the other side of the PCB without burning yourself or the other wires and without creating unnecessary solder bridges to other pins.  Below is a shot of my connector, partially soldered.

Second set of wires to solder

Protip: If you don’t already have a pair, I highly recommend you get a pair of Helping Hands for soldering like this. Available at Radio Shack and many other electronics outlets.  Below is a picture of the completely soldered PCB.

Completed PCB soldering

Now that the PCB is soldered, go ahead and check your wiring!  Don’t do any pin swaps, make sure that pin 1 on the 2.0mm connector is pin 1 on the header, pin2 on the 2.0mm connector is pin 2 on the header and so on. Also make sure that you didn’t bridge between pins on the PCB. Before you slip on the shrinkwrap, we’re going to reinforce the body of the adapter.  Get your hot glue gun ready and shoot a large bead of glue down the length of the wire. Once that is done, shoot some more hotglue around the connector to reinforce the wires coming out of the connector. Below is a picture of the hotglue process.

Wires hotglued together and header is wrapped in hotglue.

The hotglue on the wire-side of the plug will make sure that the wires don’t wiggle around inside the heatshrink tube and fail later on.  After you’ve properly applied the hot glue, put the tip of the hotglue gun over the two holes that we vacated earlier.  Keep consistent pressure on the hotglue gun and press the trigger.  This will inject hot glue into the holes left behind when the excess pins were extracted and ensure that the connector is “keyed” and will prevent a one-off connection (and prevent further headache).  This is what the hotglue injected connector looks like.

Key-glued header.

Take one moment and check your cable one last time.  Make sure that the pins are wired one to one.  Once you’re ready, get the heatshrink tube and cut it to a little bit less than the length of your adapter.  Below, you can see the heatshrink and adapter lengths I used. (This image was taken before the hot glue was applied.)

Header adapter and shrinkwrap.

Slip over the heatshrink wrap over the connector (it may not fit over the PCB) and leave just a little bit so that it overlaps the 2MM connector end.  Apply even heat to the 2MM connector end first so that it will shrink and hold the heatshrink wrap in place as you apply even heat to the rest of the connector. When completed, you should have a connector resembling the below image.

Heatshrink wrapped adapter.

Now take the hotglue gun and fill in the gap between the heatshrink wrap and the bottom of the PCB. If your gluegun has a fine tip, also shoot some hot glue into the open end of the shrinkwrap.  This will further harden the connector and ensure that it doesn’t flex and damage the connections.  You may have something looking like the below image.

Header Top with glue bead.

For a final touch, wrap and distribute hot glue around the wiring from a little bit over the heatshrink wrap all the way to the black part of the header wiring.  It’s ok to use a large amount of glue as this will make sure that the connector is properly protected.  As a last step, connect it to the Dockstar and make sure it fits.  Once finished, you should have something resembling the below image.

Completed Smokestack adapter on Dockstar.

Now, you have a completed Smokestack adapter.  You can use this for any device that has 2.0MM connector pitch and for any purpose.  Since the header on top is a 1 to 1 representation of the connector on bottom, you can use this anywhere where you need to use breadboard connectors for a temporary connection to these headers.

Section 2: Wiring it all up.

With a completed smokestack adapter, now you can wire it all up together  but before we begin, it is highly recommended to solder in a ground pin.  This ground pin will be used to ensure that the ground used by the JTAG adapter’s reference ground will be the same as the ground used by the Dockstar.  While it may not be required, it is recommended as a difference in ground may end up corrupting data being sent and received as part of the update.  To do that, we can use any of the ground planes, shields or open spots on the PCB.  I preferred to use one of the three USB shields as the shield’s purpose is the same as the GND connection that we are trying to establish.  For this, we’ll use a jumper pin with no plastic on it.  Start off by applying a small bead of solder to the USB shield as shown below.

Dockstar USB shield pin prepped for header pin.

Apply the heat from the soldering iron to the bead again and drop in the jumper pin.  Remove heat and do not touch the jumper pin until the connector has cooled.  Do not apply heat for a long period of time otherwise you may damage the USB port itself.  Below is the completed ground pin installation:

Dockstar Ground pin installed.

Now, we have a properly installed Ground pin that is easy to connect and remove and we also have our smokestack JTAG adapter.  At this point, we can start wiring up the JTAG connector up and prepare for recovery of our dead dockstar.  If you went with my suggestion and ordered the TIAO Parallel JTAG adapter, you should have received the following items.  JTAG board (blue with DB25 connector), Short jumpers (left of  JTAG board) and Long Jumpers (above board) as shown in the picture below.

TIAO Parallel JTAG kit.

The below image is the entire wiring diagram for the Dockstar JTAG adapter.  As long as you keep pin 1 on the dockstar as pin 1 on the smokestack adapter, you should have no problems with the connection.  As mrbill and Klingon and several others pointed out in the PlugApps forums, the nSRST line (orange) and the DINT(purple) leads are both not connected.  Pin 1 on the Dockstar/Smokestack are also left unconnected as we will use the Dockstar’s power supply to power the board while it is connected to the JTAG adapter.  Additionally, it is crucial to plug the USB cable into the JTAG adapter and into a PC to power the onboard buffer chip.  Without the USB cable connected, the adapter will not function.  There is also an LED on the JTAG adapter that will light when the device has sufficient power. Click on the below image to get a much larger image.

Dockstar/TAIO JTAG connection table.

The Dockstar layout diagram on the right hand side of the image is bundled together to provide a reference.  Pin 1 of the JTAG port is on the LED side of the jumper and is towards the center of the board and is designated by a black dot in the image and a white triangle on the dockstar board itself as shown below.  The picture of the Dockstar is rotated 90 degrees clockwise to the layout diagram in the image above.

Dockstar JTAG port showing pin 1

You can use the following images as a reference that your dockstar is connected properly.  The below image is a picture of my CA-42 adapter’s serial header as discussed in the serial port post. Also, since the serial port post discussed soldering to the header, if you haven’t done so already, remove the existing serial port wires so that your smokestack adapter will fit.  In the image below, the three jumpers coming off of the pins are colored as they would be if you had just cut and stripped back the CA-42′s cable. Remember that your CA-42 cable may be different!

Serial Port jumpers from CA42 USB cable.

The below image shows the top of the smokestack adapter and the respective colors.  You can see that the black wire for GND is attached to the USB shield pin we installed earlier. Remember, pin 1 and pin 7 on the smokestack are left not connected!

Top of smokestack adapter with jumpers.

The below image shows the JTAG adapter, properly wired and ready to go.  You can see the device is powered by the USB connector and that the orange and purple wires have been spared off.   Although the flash from my camera drowned out the red power LED, you will need to make sure that your LED is lit.  Please note, the JTAG adapter does require power however it will not show up as anything in Windows as we are using the USB port strictly for the power lines for the JTAG buffer.

TIAO JTAG wired up and ready.

An aerial view of the whole mess.     Yes, I know my desk is still messy.

C:\Program Files\OpenOCD\0.4.0

Wow, what a rats nest.

Now that all of the required connections have been made, it’s time to get busy with the software. Plug in the power cable to your dockstar and proceed to the next section.

Step III: Software

If you haven’t already, go back up to the Parts list and download Kragorn’s dockstar.cfg, OpenOCD and the uBoot image.

Install the OpenOCD software and accept the defaults.  Once completed, unzip the dockstar.zip and copy dockstar.cfg to C:\Program Files\OpenOCD\0.4.0\board and then copy your uboot image to C:\Program Files\OpenOCD\0.4.0  It would be recommended to rename it to just “uboot.bin” so that way you won’t have to retype that complicated line later on.

Now that we have all the proper software in place let’s discuss what all is going to happen.  When you start OpenOCD in a DOS window, it will in turn start a telnet server on localhost, port 4444.  You will use PuTTY to connect to the telnet server process and issue commands to OpenOCD.   In conjunction with that, you will need a second PuTTY session established to COM1 (if your windows machine has the CA-42 cable plugged into it) or to SSH to the machine you have the cable connected to. The reason is that once you enter specific commands on the telnet window, you need visibility to the other window (serial or SSH) to see if your dockstar is booting. Timing is critical! From here on out, commands and things to look for in output are in bold with other important text in bold, italics and underline.

In my configuration, my windows computer is what will run OpenOCD and the telnet session, and a nearby Linux box will have the SSH session with an application called minicom.

Start off by opening a DOS window (Start -> Run -> “cmd” )

Type the following command in exactly as shown: 

openocd -f board/dockstar.cfg

You should get output similar to the below image.  If you get what I have, then you can proceed to the next step.  If you get any errors, check your wiring. Make sure only those pins shown in the above images are what you have hooked up. Also, you may get a  Windows Firewall exception error.  If you do, just hit “Allow” otherwise you won’t be able to talk to OpenOCD.

OpenOCD successful startup

If OpenOCD is running without errors, minimize the DOS box and start PuTTY. Use the below configuration to establish a connection to the telnet process that OpenOCD started.

PuTTY Telnet settings

When you connect, you should get a window that says “Open On-Chip Debugger” with a caret “>” prompt.  Before we continue, if you haven’t already pulled up your serial session to the dockstar, you will need to do that now.  The issue is that from here on out, we will either be communicating with OpenOCD via Telnet, or communicating with the Dockstar via serial.

Now that you’ve established your connection to OpenOCD, perform the next two steps.

• Type the command “init” into the telnet session and hit enter.
• Type the command “sheevaplug_init” into the telnet session and hit enter.

Now, here is the hard part. The routine sheevaplug_init from above will attempt to halt the processor.  The Marvell chip has two types of halt, one of which labelled “ARM” and one labelled “Thumb”.  If your output resembles the below output (processor halted in Thumb state), you will need to perform the next steps otherwise skip down to the next section. When in doubt,  continue with the instructions below.

Thumb State Halt is no good!

If you got “Target halted in Thumb State”: There is some additional trickery that must be performed.   The issue is that the processor must be halted in ARM state as this allows OpenOCD to communicate with the processor properly.

• Hit Ctrl-C in your OpenOCD session. Your PuTTY session will break and generate an error. Dismiss the error and restart OpenOCD.
• Hold down the reset button and keep it held down with one hand and with the other, type “sheevaplug_init” and hit enter.  Ignore the error messages.
• Type in the command “halt” . DO NOT HIT ENTER YET!
• Release the RESET switch and simultaneously hit Enter.
• You should see that the processor was halted in ARM state.
• Type in “sheevaplug_init” and hit enter. No output should be generated from this command.

Check your telnet session output with my output in the screenshot below.  Make sure your output matches the screenshot before proceeding.

Properly halted dockstar

Now for the ultimate test.  We need to probe the NAND flash to make sure that the processor can communicate with it. Type in “nand probe 0” (zero) and hit enter.  If everything is correct, you should get text returned similar to “NAND flash device ‘NAND 256MiB 3,3V 8-bit’ found“.  If you get any other message ESPECIALLY anything about Unknown Manufacturer, restart OpenOCD and try again.  Here is my output so far:

Nand Probe Successful!

Now that the processor has been correctly identified by OpenOCD and the processor has properly identified the flash memory, we can now load the image into the Dockstar’s RAM and tell the processor to execute it. Type in load_image uboot.bin 0×800000 (zero, letter x, 8 and five zeros). If you renamed your uboot file something other than “uboot.bin” then substitute as needed.  This will take a couple of minutes as the image is transferred. Here is the output of what I have after the image loaded into RAM:

Load_Image successful!

When you get the caret prompt back “>”, type in the command “resume 0×800200” and check your serial connection for activity.  At this point, you can minimize the telnet session.  Now we will be dealing expressly with the serial connection.  Depending on your connection method, you may have a different window, but the text is the same.  As soon as you hit enter on the resume command, you should notice that the LED on your once dead dockstar is now blinking. Immediately switch over to the serial connection and hit a key to disrupt the boot process. If you did it right, you should see that the command prompt now shows Marvell>> as shown in the screenshot below:

Interrupted boot sequence

DO NOT DISCONNECT POWER FROM THE DOCKSTAR YET! WE ARE NOT DONE. The Dockstar has successfully loaded and ran the uboot commands in RAM however if we hit the reset switch or powercycle the dockstar, the device will return to it’s zombie state, and we will have to do it all over again. The only thing left to do is to prepare and write the image to flash.

If you were like me and you accidentally typed in ‘nand erase” and bricked your dockstar, you will need to re-erase the flash to reload it.  If you bricked your dockstar by another method, skip this step and go on to the next paragraph. To do this, type in “nand erase“.  This will erase the entire flash chip.  Now to write the working uboot to flash, use the command “nand write.e 0×800000 0×0 0×80000“  (zero x eight then 5 zeroes, zero x zero, then zero x eight then four zeros). You should get a message that the nand write was successful similar to the below screenshot.

Successful flash write.

If you did not brick your dockstar by an errant nand erase command, you will want to use “nand erase 0 0×0 0xa0000” (zero, zero x zero, zero x a then four zeros).  The reason for this difference is that if you didn’t erase your flash, this command will preserve the u-boot environment variables, otherwise you would have to recreate them later on.

Now, it’s time for the moment of truth.  Don’t start disconnecting wires just yet, simply tap the reset switch to load the uboot from the flash and test your recovery.   You will notice two key things:  Your uboot will be stuck in a permanent loop (assuming you didn’t interrupt autoboot) and the LED on the dockstar will alternate between flashing green and flashing orange as uboot cycles through.  This is because the dockstar can’t find a valid kernel or filesystem to boot from.  If you used the same version of the uBoot I listed above then you will notice that this uboot will attempt to boot off of USB key drives unlike the original factory image which opens up a LOT of opportunity.

To clean up, simply exit the various windows you have open, and exit OpenOCD by hitting Ctrl-C.  Remove power from the Dockstar, then remove the smokestack adapter and the ground wire on the USB shield.  If you want to make sure (because you’re as paranoid as I am, reapply power after all the jumpers have been removed and make sure that the Dockstar’s LED continues to blink orange then blinks green and repeats.  This means that your dockstar is confirmed as running off it’s own flash.

Now get to hacking!

Section IV: Notes and Credits

This article was assembled using information and help from various sources.  I want to thank everyone listed below for your assistance in helping me with getting the Dockstar JTAG figured out.  It was definitely not easy for someone new to JTAG however it was an enjoyable learning experience once I got the bugs worked out,  even if I did scratch my head a lot.

From the PlugApps forums, I’d like to thank Admin, Kragorn, bzboi, klingon, ygator, mrbill, and jtagfun.

A special thanks to bzboi for the initial howto that most of the OpenOCD instructions were used from and to Admin for the starting post with the Dockstar’s JTAG diagram.

I’d also like to thank mrbill for getting me involved with these things. It’s all his fault that I even have a dockstar to break.

Thanks goes to Kragorn for finding out the proper settings in his dockstar.cfg so that all of us could unbrick after the inevitable “Oops…” moment.

Last, but not least, thanks goes out to Jeff Doozan for his work with uBoot and compiling in needed features into the bootloader so that we can use USB sticks as boot devices.

Where do we go from here?

The answer is “Where do you want to go?”  In my relatively short time with the Dockstar, I was working on getting OpenWRT compiled and installed on it.  OpenWRT is the same OS that they use for the Linksys and other branded routers and is pretty much it’s own distribution.  There are also processes on how to install Debian onto the dockstar, using a laptop drive and USB sled to run the OS.  There is a lot of people doing research and finding out other warranty voiding things to do with their dockstars so take a look around.

As far as me personally?  I have three of them and while one of them is going to be a small NAS fileserver, one of the more esoteric things I was planning on doing with mine is making it into a roving USB camera with wifi.  The idea is that the Dockstar’s mainboard would be the brains of the rover and could send commands to a Parallax BOE-BOT via a usb to serial converter.  Since the entire thing would be wireless off of a USB dongle, I could use the IP based connection to deliver video and commands via a custom written application.

I sincerely hope that you are able to recover your dockstar using the above process.  It’s no fun when you accidentally destroy something you have put so much work into however now you should be able to work on the Dockstar without fear that you’re going to damage it and prevent it from booting.  Also, if you decide to try custom boot loaders, you can do so worry free.

Happy Hacking!

FIRESTORM_v1

As long as there has been electronics, there has been the problem of how to keep them cool.  Unfortunately, the problem gets more complex the smaller that computers get and what works for one PC might not work for others.  This is clearly the obstacle to overcome when trying to cool down a settop box.  Read more to find out how I was able to pull it off very well for a little over $10 in parts and still maintain all my hair.

It’s pretty synonymous that computers == heat and with any mainstream processor, you have a pretty significantly sized heatsink and fan to keep the processor cool.  While processor fans and heatsinks are pretty easy to come by for standard desktop computers and servers, embedded devices are pretty much left to their own devices (no pun intended).  I was faced with the very same problem when I decided to start using two embedded computers to replace a NAT router and mini home server.   These machines are sold as a “set-top-box” and were initially intended for some kind of Video On Demand service that used broadband service to deliver content.  The computer hardware was figured out and working however left to the “stock” heatsink and heatspreader (there was no fan when I started) the box was very hot to the touch.  I decided to initially tack a case fan to the heatsink to help with the cooling, but that only served to band-aid the problem.

The settop box. Those holes on top are supposed to keep this cool?

A view of the internals left very little room to work with.  There was no way I was going to be able to use a standard computer case fan without some massive case modding. Since I wasn’t really looking for a reason to spend the entire day with the dremel cutting sheet steel, I decided to take a look at what I had to work with.

Settop internals. It's quite cramped in there.

Since this thing was designed to be a set top box, there were all kinds of connections on the back, including a big SCART connector.  According to wikipedia, SCART is primarily a European standard and is very commonplace for connecting AV equipment to TVs and etc.  Since this settop was sold in the US, the SCART connector was unpopulated and instead left a knockout.  This gave me a sizeable aperture for the hot exhaust, now to find some way to get the air moving.

Exhaust Port Location

In the above shot, the SCART port is the large dull steel colored rectangular hole in the silver backing.  The hole is high enough that it does not interfere with the SDRAM sticks and far enough away from the power supply not to be a shock hazard.  Now knowing what I had and how big of a fan I needed, I went to Microcenter and took a look around. They had a lot of normal desktop fans and a few oddball fans and the one that would work best ended up being an old-style squirrelcage fan.  A squirrelcage fan is like the standard case fan that you’re used to however instead of normal blades, the squirrel cage fan uses an impeller that sucks in air from the front and exhausts it out of the side of the fan. The fan exhaust is perpendicular to the intake unlike a standard fan.  The advantage is that a squirrel cage fan offers the airflow of a standard fan in a smaller form factor due to the perpendicular exhaust.  The general idea is that the squirrel cage fan will suck in the warm air from inside the case and exhaust out of the now ex-SCART port.

Squirrel cage blower

This is the squirrelcage fan that I selected. Although I couldn’t find a link on Microcenter’s website, here is a link of a comparable fan. It is a12V fan that is designed to screw into a removed expansion slot blank on a computer case.  The fan connects via a 12VDC Molex connector and is designed to connect between the power cable and a hard drive or CDROM.  Since there are no Molex connectors, I had to also get a three pin cable to connect to the motherboard. Thankfully Microcenter had a clearance on Intel OEM Processor fans and were selling just the connector for 25 cents.

Intel cable and Power header

The Intel cable snaps perfectly into a convenient header that I found on the motherboard.  This will be perfect as if I ever need to replace the squirrelcage fan, I can do so without having to cut up wires and desolder splices.

Now that I had the idea of generally where everything was to go, I had to make some modifications to the steel bracket on the blower. The blower was originally designed to fit in an empty expansion slot and the tab used for securing the blower to the chassis needed to be flattened.

Squirrelcage bracket

The bracket in question is so eloquently highlighted by none other than Duke Nukem.  In order to modify the bracket without destroying the fan in the process, I decided to remove the bracket.  In the above picture, you can see a notch that holds the fan in the bracket.  There are four notches in total, two on each side. I used a couple of flat bladed screwdrivers and gently pried the bracket off.

Bracket removed from fan

After a little bit of  the creative application of force, I finally had the bracket flat enough so that it would not interfere with mounting. (Translation:  I beat the crap out of it with a hammer.)

Flattened Bracket modification

Now that the bracket is flattened enough, it’s time to see about how to go about lining it up with the SCART exhaust port.

SCART holes line up with the grill.

I lucked out on this one.  The two holes that were intended for the SCART interface hardware line up perfectly with two lines on the grill.  This made mounting the bracket as easy as a couple of small nuts and bolts.  Once mounted, it was time to start working on the power cable.  I decided to use the yellow and black wires for the fan’s power because black is considered “ground” and yellow is considered the “+12V” lead in computer power supplies.

Three wire connector

I cut off the green lead, and cut the cable about two inches long.  I then wired the wires from the fan to the Intel cable.  The red wire on the blower goes to the Yellow wire on the Intel cable and the two blacks go together. Not shown in this image is the small length of shrinkwrap used to secure and isolate the connection.

Solder Preperation

After soldering the first wire, I sealed it with the heatshrink and then soldered the other wire.

Soldered and Shrinked

Another piece of heatshrink later and I have a ready to install cable.

Completed cable

With the cable now complete, all that remained was to plug the power cable into the power header and snap the blower back into the bracket.

Blower Mounted

Here is a shot of the back of the case with the now operational blower.

SCART Exhaust port.

And finally, here’s a side-by-side (or top and bottom) with an unmodified settop box.

Modded and Unmodded settops

Final Results

I’ve been running the settop now for the past couple of days and I can say that the blower is 100% effective.  The case is cool to the touch and my fears of cooking the processor have been abated.  The machine will do very nicely as a pfSense firewall as soon as I get around to finishing it up but for now, this is one less thing stopping me from using it.

If you ever find yourself in a similar situation where you have to get airflow but don’t have much space, I highly recommend these squirrelcage blowers.  They’re cheap, they’re effective and well worth the time to install.  Although I had to go a bit out of my way to install the blower, not having to worry about cooking the machine is well worth the effort.

I hope you enjoyed this article, it was definitely an interesting approach to cooling in a small form factor.  Do you have any insight or other experience with odd cooling in a similar situation?  Please leave a comment, I’m always interested in other people’s stories.

Ok, so not long after I published the article on  the hardware teardown of the Seagate Dockstar, I couldn’t help myself  so I started working on things to do with this device.  I did a lot of research in regards to the capabilities of the Dockstar, including being able to push a customized Linux OS on the device.  Once I saw the article at Hackaday that covers exactly how to replace the OS, I knew I had to do it for myself.  There are two ways to perform this upgrade however in order to capture syslog output and to be able to get to the bootloader, a serial port is required.  Just about all of the sites will describe the pins needed to make the connection, however none of them detail how to do it very clearly and none of them address the issue of aesthetics.  Read on for my method of adding a serial port to the Dockstar without affecting the look of the device.

Before We Begin….

The Seagate Dockstar has a serial port available via three of the pins on the header at the front of the PCB.  The issue is that they’re not very easy to get to without having to disassemble the device each and every time you need to do a recovery on it.  This is hardly an ideal solution, and who knows what I’ll be doing with the device in the future.  If I decide to embed the  device and something goes wrong, I’ll have to have access to the serial port in order to debug it.

But, simply having access to the serial port is not enough.  The Dockstar’s aesthetic elegance is in the fact that it’s so simple.  No  massive amount of connectors aside from Power and Ethernet, and with little room to begin with, I don’t want to have a cable hanging out of the box just to have access to the serial port.  After much deliberation, I decided that a pin-row setup would be ideal instead of some other outward-facing connector.  The advantages to a pin-row set up is that there are only as many holes as are needed to establish connection and the connector size is significantly smaller than would be a standard DB-9 connector.  An additional advantage to the pin-row setup is that the connection would be temporary and can be easily removed. The resulting connection port would still be cleanly presented and would not stick out like a sore thumb.

Parts List:

In order to pull this off, you will need the following items:

- a CA-42 USB cable. – This is most commonly sold as a Nokia cable through Amazon and can usually be had for a few bucks. This is required as the dockstar’s serial port voltages are at a 3.3V TTL.  interfacing it to a standard +12V/-12V serial port will damage your Dockstar. The CA-42 cable has a PL-2303 USB to 3.3v TTL serial adapter in it which provides the required 3.3v TTL and gives an easy to use connector for plugging it into your host PC.

- a 4-pin header with long pins. – The pins have to be long enough that they will go through the Dockstar case and into the matched connector securely.

- a matched connector for the 4 pin header. – This will be mounted inside the Dockstar.

- Heat shrink tubing of various sizes. (Use the images as a guide)

- A couple of spares of the 4 pin header and the connector.  (We’ll use one spare for making the holes in the case, but it’s always good to have extras just in case.

Tools List:

- Soldering Iron

- Lighter (for heatshrink)

- small diameter drillbits

- Spudger (or Radio Shack soldering toolkit)

- A Linux machine with an available USB port. Note: It may be possible to use a windows computer for testing however my USB adapter only works in Linux.

Now that you have all the components, it’s important to stop here for a sec and cover the legal mess. It is critically important that you know what you’re doing.  You can not blame me or hold this site responsible (or the maintainers of this site) if you do something and blow up your Dockstar.  Be careful, do your research, check twice, solder once.

Please note that if you have never worked with shrinkwrap, the important thing is to watch the fire and keep it moving.  If you leave the lighter in the same place for too long, the shrinkwrap will stop shrinking and will catch fire.  When in doubt, apply the hat quickly and watch the shrinkwrap closely.   If it does something wrong, move the lighter away and start blowing on it to cool it down.

Part 1:  The Cable

It’s easier to do the modification on the cable first rather than do the Dockstar portion due to the fact that part of performing the Dockstar side of things will require testing to make sure it’s all working properly. So, let’s get started.

CA-42 cable, header and connector

This is the cable that we will be hacking together. The pin-row connector shown above is a 4 pin wirewrap terminal and a push-on style PCB mount connector.

cable header and connector

In the above photo,you can see the long header pins and the matching connector and how they fit together.  Before we get started with modifying the cable, we first need to figure out how it’s wired up.  Because there is a very good chance that you have a generic cable, and generic cables are wired differently, we will start off with spudging the USB connector apart.

Spudger to cable case

Follow the plastic seam of the USB connector with the sharp blade of the spudger.  Gently work the two halves of the plastic apart until you are able to seperate them.  You should see a connector that looks like the one below.

Opened cable

A closer of the PCB will reveal that the  wires (white, blue and green) are labeled for our easy hacking convenience . The three wires in my cable are Blue(GND), Green (RxD), and White (TxD). Now that we know which wire does what, reassemble the USB cable as we will not need to do any work on this end of the cable.  Starting with the 4 pin connector, pick one of the two internal pins and remove it.

Removed pin from connection block

The reason for removing the offset pin is for two reasons.  1) There are only three wires required for connection and 2) The missing pin will allow us to key the connector so that it can’t be reversed.  Going back to the USB cable, cut off the fat Nokia phone end and strip the cable back about an inch.  To help with soldering, insert the long end of the header pins into a block of breadboard.  This will help hold the connection stable while you solder the cable.   You will also need to cut the small diameter shrinkwrap in three sizes as shown below.

Cable preparation

The reason for the three lengths of heatshrink tubing is that we will build up the edge of the cable to a large size so that we can use the larger heatshrink tube  (in the back of the picture) to bind the header pins into the wrap and the wrap to the end of the cable to strengthen the cable.  If you have never worked with heatshrink tubing, it’s very easy to work with.  Start with the longest piece of tubing, and slide it over the cable. Make sure that the cut end matches the end of the insulation and heat with the lighter.  KEEP THE FLAME MOVING ACROSS THE HEATSHRINK!! Once the heatshrink has stopped shrinking, allow it to cool and repeat for each piece.

Shrinkrwrapped cable

This is the end result of the shrinkwrapping.  Now that the end is built up, slide a piece of the large shrink over the end of the cable but do not apply heat just yet. Strip back the individual wires so that you can attach them to the header pins.

Cable prepped for soldering

Now that we’re ready to solder the connector, it’s important to decide how to create the pinout.  In my setup, I elected to have the GND connection by itself, then the TX and RX pins.  For each wire, wrap the wire around the soldering post on the header pins and solder.  Be sure to use only enough solder as is required for the connection and do not  bridge the pins.

Soldered cable to header pins

Now with the cable soldered and the connections solid, it’s time to apply the heat to the large heatshrink.  Very carefully pull the end of the heatshrink over the black plastic header and gently apply heat.  Adjust if needed and let the tubing shrink without it pulling itself off of the header plastic.

Heatshrink applied to header

When you have it this far, go ahead and apply heat to the rest of the heatshrink tubing, making sure not to singe it.  When you are done, you should have a cable looking like the one below.

Completed cable with socket

This was the easy part, Now it’s time for the dockstar.

Part 2: The Dockstar

We’ve got the cable, but without something to connect it to, it’s pretty useless (unless you want to use it on a breadboard).  Let’s take a look at what’s going on.

Dockstar connection planning

Since I’ve already determined that I want the connector for the serial to come out of the back of the device and I’ve already found a suitably small connector, it’s time to find a location where I can attach it without getting too involved or without interfering with the existing ports on the back of the dockstar.  I’ve elected to put the serial port just above the center USB connector.  In the photo above, you can see how much space we’re dealing with in comparison with the USB ports and the header socket.

Dockstar shielding

Some of the RF shielding will need to be removed, but thankfully the metal is pretty flimsy and easily cut.   Be sure that when you remove the little fins pictured that you do not distort the top of the metal shielding.  We need a surface as smooth as possible for the superglue to properly bind with the connector for the serial port.

Unneeded shielding removed

Here is the picture of the unneeded shielding removed.  Please only remove the shielding that you need.  Next, you will need to prep another three pin header just like you did for the cable.  Rather than trusting faulty measurements and guessing, we’re going to use the header’s pins themselves to point out where we need to place our holes.

Burned through holes

Using a pair of needlenose pliers and your soldering iron, heat the pins evenly and apply moderate pressure.  The pins may wiggle slightly but don’t let them move too far off otherwise your holes won’t be lined up. When all three pins have punched through, remove the pins with the needlenose pliers.  Use the small diameter drill bit to widen the holes and to furr out any residual plastic scraps.  Your finished holes should look something like below.

Completed holes

Just to make absolutely sure, go ahead and test with the connector and the cable to make sure everything fits properly.

Hole Alignment Test

If you’ve made it this far, you’re doing good.  Now it’s time to prep the connector for supergluing into the Dockstar’s case.  Since it’s a four pin connector and we’re only using three pins, make sure that the connector is properly oriented so that it fits properly and so that the serial cable can move freely in and out of the connector.  Back the cable off a bit so you can see which pin is missing and cut off the connector’s matching pin to eliminate a possible mis-wiring later on. Go ahead and attach and solder a wire to each of the three remaining pins.

Socket connection with wires

In order to glue the connector socket in, take the excess wire and coil it up for now. Apply a thin coat of superglue inside the Dockstar and when aligned, push the three pin header you used for burning the connector in through your drilled holes and into the connector.  This will hold the socket steady while the superglue cures.  Give it about 15 minutes to cure properly, then gently remove the pins from the socket.  At this point, you should have a fully mounted socket like in the picture below.

Glued in header socket

Now that the socket is taken care of, we need to attach it to the serial port on the Dockstar’s board.  Before we do anything permanent, we will test the serial port and then once we are satisfied that it’s all working, we’ll solder them in and close it up.   Start off with wrapping the ground wire to the lower right hand pin on the connection block.  This is the common GND connection and must be established first. If you are using my wiring plan, the GND wire is the single pin by itself on the three pin header we made earlier.

wirewrapped GND wire

The two pins to the left of the GND pin are the RX and TX pins respectively.  Attach the centermost pin to RX and the remaining pin to TX on the superglued connector.

Connected wires

Remember, we have NOT soldered the three wires yet.  Also, make sure that none of the wires are touching prior to connection.  In order to test the serial port and make sure we have it hooked up right, connect the three pin header on the serial cable to your socket on the back of the Dockstar and connect the USB connector to your computer. Do not apply power to the Dockstar yet.  Open up minicom and set the serial device to /dev/ttyUSB0, 115200, no parity, 8 bits, 1 stop bit.  When properly configured, apply power to the Dockstar and watch your console window.  If you got it right, you should get similar output like below.   If not, pull the power plug on the Dockstar and disconenct the serial cable out of the back of the dockstar.  Swap the left two pins (RX and TX) and try again.  You should get output like below.

Serial terminal output

Now that you’ve tested the wiring, disconnect the power and the serial cable from the Dockstar.  Solder the wires in place and reassemble the Dockstar. Be careful closing the cover as you want to make sure that the wires coming off the superglued socket do not touch the metal shielding. (Editor’s Note: I really need a hot glue gun)

Closeup of Dockstar prior to reassembly

Close it all up and test it one more time.  If everything works as should, you’re good to go.  Now you can access the serial port without having to take your Dockstar apart over and over again.

Completed mod with serial cable attached

Here is a picture of the completed serial cable mod. The serial cable is plugged in right above the keydrive in this photo.

View of Serial Port

Same view as above, but with the serial cable removed.  Nothing but three holes.

Dockstar box

This is the box that the Dockstar came in.  Having not bought a non-OEM seagate drive in ages, I was pleasantly surprised that they used normal cardboard instead of some plastic case for this device.  Seagate is really pushing their “Go Green” incentive by changing the entire box (even the box inside) with easy to recycle cardboard instead of that translucent plastic “tray” that normally accompanies electronics.  While not necessarily an indication of product performance, it does show that they care about the environment.

Dockstar contents

Inside the box, aside from the little “Getting Started Manual” is the following items:  A Universal power brick pre-fitted with the US style prongs, a shielded ethernet cable and of course, the dockstar itself.

universal plug sticker

Here’s a closeup of the universal plug and all it’s various warnings and certifications.  I have seen a shift towards these universal plugs and away from the more proprietary plugs that manufacturers would normally use as a cost saving process. Since there is no one world-wide standard on power for every country that Seagate does business with, why spend that money building 20+ different power adapters when all you need is one with different prongs to fit whatever country’s plugs you’re going to be selling to.

Universal Plug details

And, just because I’m a sucker for details (and I keep losing the power bricks), here’s the voltage and amperage rating of the power brick.  Output is 12vDC 2Amps with a positive tip.

Dockstar front

Finally, we get to the dockstar to find what secrets it holds.  The front panel has one LED for device status and the USB mini-B port for the Freeagent drive to sit in.  Unlike most older-style USB devices, the Seagate Freeagent is powered entirely through the USB port, eliminating the need for two cables to power one device.  Overall it’s a simple presentation of what looks to be a fairly complex device.

Dockstar Back

The back of the dockstar has two USB ports, the Gigabit Ethernet port and the power port on it.  I would like for there to have been a link and an activity LED for the Ethernet port, but unfortunately this was not implemented.  I guess I’m a sucker for LEDs.

Right side of dockstar

The right side of the dockstar features another USB port and the reset switch for the device.  The left side of the dockstar (not pictured) only has cooling vents on the side.

Dockstar Bottom

This is the bottom of the dockstar which has a large sticker that shows the serial numbers and MAC address of the device.  Of note, there was one number on this sticker which is formatted like some kind of product activation key and is formatted as follows:  six alphanumeric characters,  hyphen, six alphanumeric characters, hyphen, two alphanumeric characters, hyphen, six alphanumeric characters, hyphen, six alphanumeric characters.   At first glance, I thought these were hexadecimal numbers however the letters used were not between A-F and so it’s currently unclear what this number is for.  There is no mention of what this number is for in the documentation.

Gaining access to the insides

Typically on a device like this and most small consumer devices, there are four screws on the bottom (usually under the black slip-resistant dots) however the Dockstar doesn’t have any.  In order to gain access, I used a metal spudger to work the bottom away from the top half of the body.  There are two notches on each side of the square base, so you may need to use something flat like a spudger, small flathead screwdriver or a expansion slot blank to pry it open.

Cracked the case

Once you cracked the case open (hopefully without breaking it), you should see the small cable that connects the top USB port to the dockstar’s mainboard.  Carefully disconnect this cable and the two halves should now be seperated.

Mainboard top view

This is the dockstar in all it’s nude glory. The front of the device is to the right in this photograph. The small black square is Nanya 1Gb (comes out to ~128 megabytes)  DDR-2 RAM in a BGA package. Datasheet available here and the large square is the device’s main processor.  From research I have performed, this appears to be a Marvell 1.2GHZ processor (just like the sheevaplug devices that Marvell is also selling. I tried to pull some more datasheets from plugcomputer.org, but their datasheet listing is quite lacking.  For now, just know that it’s an arm compliant processor and when I post an update article, I will have more juicy details on the capabilities of the processor.  Also of note, just below and to the right of the processor is a small ten pin header.  Presumably this can be used for a serial port however I do not have the cable for that.  Once I get it in and test it, I will update this article with a pinout diagram for you. Since this device is so low-level I would not recommend trying to connect a regular serial port to it directly as it more than likely requires a level shifter like a MAX232 to bring the -12/+12VDC down into something that won’t blast the components.

Mainboard bottom

This is the bottom of the dockstar’s mainboard.  Unfortunately, the board is now oriented that the front of the dockstar is now at the bottom of the picture. (Bad cameraman, no cookie.)  There’s not really much to note here as the board layout is jam packed with passive components.  The large black square on the lower right is the NAND storage for the device and while I couldn’t pull up the datasheet for it, the guys over at PlugPBX already had a forum post that showed the Dockstar’s hardware specs for us.  According to their chart, the dockstar’s storage is 256MB. which should be more than adequate for general Linux fun.  The small chip just under the black tape in the upper right hand corner of the board is presumably the ethernet NIC however googling the chip numbers came up with nothing.

Just looking at the hardware overall, it would appear that the Seagate Dockstar is a very capable device that just needs to be altered to run whatever we choose to run with it.  While the software on the device (stock) comes with a filesharing service called Pogoplug, I do not intend on using that software and will be looking to get this device as far away from stock as possible.  Here is a list of some things I’ve been thinking of doing with it so far:

• Home NAS (without Internet file sharing)
• multihomed router (I have a stack of pegasus USB modules)
• semiportable network notification device (USB to parallel port, HD44780 LCD display)
• realtime data acquisition device (USB logger and serial ports?)
• Apple MT-DAAPd server for streaming music to iTunes installations on your local network

Some sites I’ve seen while doing research have mentioned things from a in-home webserver with databases, to even a PBX server (take a look at www.plugpbx.org)

The big question is:  What would you do with it? Feel free to leave a comment as to what you’d do with this device, suggestions, information, etc.

FIRESTORM_v1

BIG FAT OBNOXIOUS WARNING!:

Because of the Dockstar’s affinity to want to “phone home” thanks to the Pogoplug software,  I would not recommend plugging this into your live network just yet.  In all of the research I have done for this device, just about every site I have seen has posted some kind of warning about this.  The dockstar was originally designed to run with pogoplug which is an internet filesharing service that allows you to access your files from anywhere with Internet connectivity.  I don’t exactly trust an outside third party to have access to my files on a device that is only going to be used on a local network so I have not connected mine up to even test it.  If you are going to do any work with this device, I recommend that you use a dedicated mini-hub or switch and that it not be allowed to connect to the Internet until you have a complete understanding of what all it wants to do.

Image courtesy of Parallax.com

Hello Everyone!   If you’ve been in a Radio Shack sometime in the last year or so, you’ll know that Radio Shack and Parallax have teamed up to bring some variety to the parts drawers.  This once $50 serial RFID reader kit is now $10 at Radio shack although it only comes with two tags.  Read more for additional details about the Serial RFID reader now on sale!

The Parallax Serial RFID reader is 5 volt TTL compatible signalling and requires two I/O pins.  One is output for the “enable” pin which when brought low, turns on the RFID reader.  The tag data comes in on another pin to be read by your 5V TTL compatible microcontroller.   If you are using the 5V Basic Stamp or the 3.3V (5V tolerant) Propeller, then this is just a snap-in add on, no additional hardware is required.  Other controllers may require additional voltage converters to drop the TTL signal down to a voltage compatible for your controller.

Also take note that this is a 125kHz tag reader, so reading your company’s HID RFID tag will more than likely not work unless you have a 125kHz tag.

You can find the full datasheet, sample code and schematics from Parallax’s product web page here.

If two tags just aren’t going to cut it, you can take a look at all of Parallax’s tags here.

You can download the update from Sprint at http://shop.sprint.com/en/software_downloads/pda_smartphone/samsung_moment.shtml

Please note: According to the instructions available at the link above, you will need to use a Windows PC to apply the update to your phone.  I will be posting a mirror shortly and it will show up in the “Download Files” page at the top of this page.