I have an embedded device with this SD card:[root@(none) ~]# busybox fdisk -lDisk /dev/mmcblk0: 3965 MB, 3965190144 bytes4 heads, 16 sectors/track, 121008 cylindersUnits = 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 FAT32and these partitions:[root@(none) ~]# dfFilesystem           1K-blocks      Used Available Use% Mounted on/dev/root               253871    140291    113580  55% /none                     16384         4     16380   0% /tmpnone                    127016         4    127012   0% /devnone                        16         4        12  25% /var/libnone                        16         0        16   0% /var/lognone                       128        16       112  13% /var/run/dev/mmcblk0p3         1394520    118036   1276484   8% /mnt/onboardI 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=2048Why am I asking this?This command is strange for me because:the copied image is smalled than target partitionit 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 answerthere's not a boot partitionuImage is extracted; on the contrary I expected it will be used by u-boot as-isBackground: the device is a Kobo Glo, and the command is executed by update scripts to update the kernel.
What does this dd command do exactly?
kernel;embedded;dd;u boot
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.