Latest revision as of 16:10, 23 November 2010

Preparing flash / disk images for qemu

Flash images

You need a kernel and root filesystem for your Gumstix board. Additionally, download one of the u-boot images for your platform.

Verdex

The flash image emulates the flash memory on the Gumstix motherboard. It's a single file that has the size of the emulated flash memory (32MB in the case of the verdex board emulated by qemu). It will contain the same images as the real flash, at the same offsets:

• The u-boot image at offset 0
• The root file system image at offset 256kB
• The kernel image at the end of the image offset 31MB

The following 3 files are needed

• u-boot-verdex-400-r1587.bin - u-boot
• gumstix-basic-image-gumstix-custom-verdex.jffs2 - root file system
• uImage-2.6.21-r1-gumstix-custom-verdex.bin - kernel.

Except for the u-boot image which is not yet built by openembedded, those files can be found in the tmp/deploy/glibc/images/ sub-directory of gumstix-oe after running bitbake.

To assemble the image flash.img run the following commands:

$ dd of=flash.img bs=128k count=256 if=/dev/zero
$ dd of=flash.img bs=128k conv=notrunc if=u-boot-verdex-400-r1587.bin
$ dd of=flash.img bs=128k conv=notrunc seek=2 if=gumstix-basic-image-gumstix-custom-verdex.jffs2
$ dd of=flash.img bs=128k conv=notrunc seek=248 if=uImage-2.6.21-r1-gumstix-custom-verdex.bin

Connex

For Connex boards with 16MB flash the steps slightly differ:

$ dd of=cflash.img bs=128k count=128 if=/dev/zero
$ dd of=cflash.img bs=128k conv=notrunc if=u-boot-connex-400-r1604.bin
$ dd of=cflash.img bs=128k conv=notrunc seek=2 if=gumstix-basic-image-gumstix-custom-connex.jffs2
$ dd of=cflash.img bs=128k conv=notrunc seek=120 if=uImage-2.6.21-r1-gumstix-custom-connex.bin

mmc/CF images

Those images are used to emulate the flash memory cards that are present on netmicroSD, netMMC, netCF... expansion boards. It is possible to boot from them or just to store more data in them.

On the Linux host, the losetup(1) utility is used to access those images as real block devices,

/!\ The current qemu version seems to be limited to 1GB card images. The examples presented here will thus use 1GB images.

• Creating the empty image

dd of=mmc.img bs=1M count=1024 if=/dev/zero

• Creating a block device for the whole image

losetup /dev/loop0 mmc.img

• Running fdisk to partition the card

fdisk /dev/loop0

Partitionning the card

In the most simple case, one single partition (VFAT, ext2 or ext3) can cover the whole card. However, in order to boot from the card and use it for the root file system, at least 2 partitions, one small VFAT to hold the kernel and the u-boot script, and a bigger one, ext2 for the root file system. The folloing example shows a basic setup (using fdisk 'p' command):

  Command (m for help): p

 Disk /dev/loop0: 1073 MB, 1073741824 bytes
 255 heads, 63 sectors/track, 130 cylinders
 Units = cylinders of 16065 * 512 = 8225280 bytes
 Disk identifier: 0x25c4dea4

      Device Boot      Start         End      Blocks   Id  System
 /dev/loop0p1               1           7       56196    6  FAT16
 /dev/loop0p2               8         130      987997+  83  Linux

Accessing the partitions

In order to access the partitions, 2 more loop devices have to be created with losetup. The offsets into the main loop device (/dev/loop0) need to be specified. For this, use fdisk -ul to find the starting block of your partitions:

Disk /dev/loop0: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders, total 2097152 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x25c4dea4

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1              63      112454       56196    6  FAT16
/dev/loop0p2          112455     2088449      987997+  83  Linux

Partition 1 starts at block 63 (which is 63*512 = 32256 bytes) and partition 2 starts at block 112455 (which is 112455*512 = 57576960 bytes).

The following commands will then create the 2 loop devices:

losetup -o 32256 /dev/loop1 /dev/loop0
losetup -o 57576960 /dev/loop2 /dev/loop0

/dev/loop1 and /dev/loop2 will now access the 2 partitions.

Formatting and mounting

The loop device will extend to the end of the image file, even though the partition does not. For this reason it is important to specify the amount of blocks when creating the filesystem. The number of blocks were shown in the previous fdisk output. (Be aware that mkfs may give a warning about a block count mismatch. This is because the loop device may be larger than the partition. In this situation, the warning can be ignored.)

 mkfs -t vfat /dev/loop1 56196
 mkfs -t ext2 /dev/loop2 987997

 mkdir /mnt/1
 mkdir /mnt/2

 mount /dev/loop1 /mnt/1
 mount /dev/loop2 /mnt/2

Copying data

The kernel image (called uImage on the docs on using root on MMC/SD), the u-boot script gumstix-factory.script are needed on /mnt/1.

To transfer the root filesystem to /mnt/2, un-tar the gumstix-basic-image-gumstix-custom-verdex.tar.gz found in the tmp/deploy/glibc/images/gumstix-custom-verdex/ directory.

Cleaning up

Before starting qemu, both partitions should be un-monted and the 3 loop devices should be un-configured. Failing to do that will almost certainly corrupt the images.

umount /mnt/2
umount /mnt/1
losetup -d /dev/loop2 
losetup -d /dev/loop1
losetup -d /dev/loop0