I have an embedded device with this SD card:

[root@(none) ~]# busybox fdisk -l
Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes
4 heads, 16 sectors/track, 121008 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1             305        8497      262144+ 83 Linux
/dev/mmcblk0p2            8497       16689      262144+ 83 Linux
/dev/mmcblk0p3           16689       60352     1397247   b Win95 FAT32

and these partitions:

[root@(none) ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               253871    140291    113580  55% /
none                     16384         4     16380   0% /tmp
none                    127016         4    127012   0% /dev
none                        16         4        12  25% /var/lib
none                        16         0        16   0% /var/log
none                       128        16       112  13% /var/run
/dev/mmcblk0p3         1394520    118036   1276484   8% /mnt/onboard

I have a u-boot kernel image file, uImage, of ~2 Mb. What happens exactly if I do the following?

dd if=uImage of=/dev/mmcblk0 bs=512 seek=2048

Why am I asking this? This command is strange for me because:

  1. the copied image is smalled than target partition
  2. it seems that the image is extracted on /dev/mmcblk0p1, that is the root partition. It starts at 305, while dd skips 2048 blocks EDIT: see Anthon's answer
  3. there's not a boot partition
  4. uImage is extracted; on the contrary I expected it will be used by u-boot as-is

Background: the device is a Kobo Glo, and the command is executed by update scripts to update the kernel.


1 Answer 1


I am guessing here, as I have no Kobo Glo (I wish my Bookeen HD was reprogrammable).
You seem to have a 2Gb SD memory internally ( 60352 cylinders of 32K each)

The dd does skip 2048 blocks of 512 (1048576), which is less than the 305 cylinder offset (9994240). In fact have to write more than 8Mb to reach the /dev/mmcblk0p1 partition that way.

How the device boots depends on its firmware, but it is likely that there is some basic bootstrapping done via the first 1Mb on the SD memory, that in turn then calls the image written with dd.

/dev/mmcblk0p1 is 256Mb ( (8497 - 305)*32768 ) and that seems to be mounted as / with maybe a backup of it on /dev/mmcblk0p2 or vv.

  • I see. So there's a sort of "hidden" boot partition, an unpartitioned space used directly with dd. This solution is strange, since the rest of the device is completely unlocked, you're root by default and if you ssh or telnet the device you can control it completely. PS: Sorry for the cylinder error. And yes, /dev/mmcblk0p2 is a partition for resetting the device. Don't know if an entire separate partition was really needed. Apr 22, 2014 at 16:33
  • 1
    @LucasMalor by not putting the image in a real filesystem, they can keep the equivalent of grub more simple as it doesn't need to know about filesystem structures. I think that is why it organised as it is.
    – Anthon
    Apr 22, 2014 at 17:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .