Hands on dreamplug

A DreamPlug device

Update: Óscar García gently published a similar spanish version of this article.

Couple of weeks ago I received my dreamplug, from NewIT. Though I knew some software troubles in device, I remains hopeful. However when I unpacked and powered on the plug I got a number of problems. This is the history about these problems and their solutions. I hope that my experience can be useful for anyone who take the same model and have the same problems. Afterall, the NewIT forum has a number of posts about these and other problems, so reading it is recommended.

The first problem that I found was a bad partition table, which is also a well-known bug in NewIT forums; and the second one is the Ubuntu installation which is not very tiny by default 🙂 Fortunately, both problems are easy to solve.

These are the steps that I followed to “upgrade” my dreamplug software to a cooler one. Please note that the Globalscale guys do not support other system images and installations AFAIK, so perform this changes under your own responsibility. You are warned!.

Anyway, that is the recipe:

STEP ONE: Creating a bootable USB

The first step in our process is to create a pseudo-bootable USB. The “pseudo” prefix is here because we don’t need really a bootable USB, but a USB storage with the contents of the image inside. We will use the same uImage provided in the original dreamplug or, of course, you can change the kernel image whenever you want.

For this USB image you can use a factory one, debian image provided by Globalscale guys, or my own debian image (which is my favourite one, of course). You also need to format your USB with ext2, ext3 or ext4 filesystem (the current Dreamplug kernel do not support much filesystems), and then unpack the image into it. It’s very simple step, for example, if you have plowshare installed, you can follow these steps:

$ plowdown http://www.megaupload.com/?d=R59E1DU3
$ mkfs.ext4 /dev/sdñ # or your USB unit
$ mount -t ext4 /dev/sdñ /mnt
$ tar -xvpzf dantzig-dreamplug-image.tar.gz -C /mnt
$ cp dantzig-dreamplug-image.tar.gz /mnt/root # only required for step 4.

In this example I suppose that device /dev/sdñ exists and it’s the USB device.

STEP TWO: Boot from USB

The next step is to boot from the USB that we make in the last step. To perform well this step we also need to have attached a JTAG unit. Without the JTAG we cannot control the boot process and we cannot force to u-boot to use the USB. The idea is to boot from the factory kernel image, but setting the root filesystem to the USB.

In other plug models, like Guruplug, you can change the boot environment from the OS, so you do not require the JTAG (if everything works fine), but AFAIK, Dreamplug has u-boot code in a different flash memory which cannot be modified from the OS. If anyone knows a way to do this, please don’t keep it in secret 🙂

When system starts in JTAG console you can see the following lines:

88E1121 Initialized on egiga1
Hit any key to stop autoboot: 3

Then you can press any key to enter in the u-boot prompt:


Then change the environment to point the root filesystem to the USB:

Marvell>> setenv x_bootargs_root root=/dev/sdc1 rootdelay=15
Marvell>> boot

The rootdelay paramenter is required to wait while the USB bus is initializing after kernel loading. While kernel bus scan is asynchronous, you need to wait until the USB one starts successfully. You cannot control this time and it’s depends on many factor, but usually a 15 sec value is time enough.

Please note that we never commit the changes into the environment, we boot the kernel with the new one, but not save this environment because we do not need to start from the USB anymore.

STEP THREE: Rebuilding partitions.

Once the system start (will take ~30s), you can login with the root password. The password depends on the image that you use in first step, but the password nosoup4u is default one for my image and for factory ones too.

Once you get a prompt, is time to take a look into partition table:

# fdisk -l /dev/sda
Disk /dev/sda: 1967 MB, 1967128576 bytes
61 heads, 62 sectors/track, 1015 cylinders
Units = cylinders of 3782 * 512 = 1936384 bytes
Disk identifier: 0xabcdef

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        1016     1920993+   6  FAT16
Partition 1 has different physical/logical endings:
     phys=(54, 61, 61) logical=(1015, 54, 24)
/dev/sdb2              56        1021     1826706   83  Linux

As you can see we’ve a problem with partitions. The first one is a FAT16 partition, which store the kernel in uImage format, which is loaded by u-boot when booting, but as you see in the previously output, the size is not correct. The partition (as documentation said) might have a size of 16M, that is 55 cylinders, so we need to remove the partition and create a new one:

# fdisk /dev/sda
Command (m for help): d
Partition number (1-4): 1
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
Partition number (1-4): 1
First cylinder (1-1015, default 1): 1
Last cylinder, +cylinders or +size{K,M,G} (1-55, default 55): 55

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 6
Changed system type of partition 1 to 6 (FAT16)

Command (m for help): w
The partition table has been altered!

Syncing disks.

Now the first partition has the correct size, but unfortunately, the second partition is incorrect too. It starts at cylinder 56, which is correct, but ends beyond the end of disk. We need to correct the size of this partition too, in the same way as we do in the last step:

# fdisk /dev/sda
Command (m for help): d
Partition number (1-4): 2
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
Partition number (1-4): 2
First cylinder (56-1015, default 56): [enter]
Using default value 56
Last cylinder, +cylinders or +size{K,M,G} (56-1015, default 1015): [enter]
Using default value 1015

Command (m for help): w
The partition table has been altered!

Syncing disks.

And that’s all. At this point we have the correct partition size in both partitions, and the system might work fine. We only need to reboot the system, sacrify a goat and pray. But maybe you want to delete Ubuntu and install other distribution, let’s say Debian or even better Gentoo. As my boot image is Debian based, it’s easy to delete Ubuntu and install Debian Squeeze (which is the image base)…

STEP FOUR: Debianize

If you remember the step one, we also copied the dantzig-dreamplug-image.tar.gz image into /root. Now we will use this targz to unpack it into sdb disk.

Let’s suppose that you are booting from USB image and login the system and get a root console (steps 1,2),then:

# umount /dev/sda2 # Puesto que ha sido montado automáticamente por usbmount
# mkfs.ext4 /dev/sda2 # Formateamos con ext4
# e2label /dev/sda2 root # Etiquetamos la partición como root (opcional)
# mount -t ext4 /dev/sda2 /mnt
# tar xvzpf /dreamplug_debian_v0.2.tar.gz -C /mnt
# sync && sync && sync
# umount /mnt

At that point we must have a Debian distro installed in sdb2, and in next reboot the new system will be booted.

Maybe you need to know a bit more about dantzig-dreamplug-image.tar.gz. This is the image which I created to my plugs (dreamplug and guruplug) and it works in production for connectical.com site for months. This image uses runit as init process and a lot of features and geek services 🙂


6 thoughts on “Hands on dreamplug

  1. Hi,
    I’m a newbie with this system, until now I’ve did some microcontroller board (PIC, AVR and so on) then I’m sitting in front the shell of Dreamplug (I’m using Fedora 16 into VirtualBox environment on a WinXP machine) and now I’m asking if there is some tutorial able to show a noob how I can start in coding (C, C++ langiage) on a such system. My goal will be build a microcontroller USB based external device able to communicate with the Dreamplug but I need some hint how to start. With Dreamplug I don’t have a GUI to write and compile my code just a terminal console. Could you suggest me a way to start? Thanks for your time. Best regards. Fabio

  2. Thank you for explaining the fdisk magic.

    Got my dreamplug yesterday, fully up and running with everything I wished in about one hour.
    I see many entries in dmesg regarding the end-of-file. I find it strange to see that neither Globalscale nor Newit fix this and put up a fresh 2Gb image for it. This has been known for months now.

    Maybe it is advised to do an fsck and a resize2fs after fixing the partition size.

    1. Hi Merijn,

      Sure, after resize partitions a fs resizing is required (or almost highly recommended), I dunno say anything about it because of I want to reinstall debian (and reformat partitions), but of course if you want to keep the original ubuntu image you might resize the fs.


    1. Hi mike,

      Unfortunately, AFAIK, it’s not possible right now, I do not know any new way to do this. Older models, like GuruPlug, maps the MTD device into the OS, so you could access to the NAND memory using fw_setenv and fw_printenv tools. However, in DreamPlug the MTD is behind an FTL and it not possible to access directly, so you will need a JTAG 😦

      If anyone discover a new way here are two guys very interesting in knowing that 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s