linaro-media-create: needs to make image file a multiple of SD erase block size

Bug #658511 reported by Peter Maydell
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro Image Tools
Fix Released
Undecided
Unassigned

Bug Description

Currently the linaro-media-create script creates image files (if invoked with --img_file) which are a multiple of the "cylinder size" in length. However, if the image is not an exact number of SD erase blocks in size then when it is passed to qemu the result is that Linux cannot access the half-erase-block at the end. The effect of this is that Linux complains that the partition is too large for the device:
[ 1.695709] mmc0: new SDHC card at address 4567
[ 1.703765] mmcblk0: mmc0:4567 QEMU! 3.99 GiB
[ 1.705596] mmcblk0: p1 p2
[ 1.722625] mmcblk0: p2 size 8241345 extends beyond EOD, truncated

and then fsck complains:

fsck from util-linux-ng 2.17.2
rootfs: The filesystem size (according to the superblock) is 1030168 blocks
The physical size of the device is 1030118 blocks
Either the superblock or the partition table is likely to be corrupt!

I'm going to attach a straightforward patch to linaro-media-create which forces the created image size to be a multiple of 256K (which is the largest permitted SDHC erase block size). Without this patch, running an image under qemu fails; with this patch it boots OK to a root prompt.

(images created with linaro-media-create --image_file 1005.img --rootfs ext3 --dev beagle --binary linaro-m-headless-tar-20100928-0.tar.gz --hwpack hwpack_linaro-omap3_20101005-37_armel_supported.tar.gz)

(NB that bug 626907 suggests that we ought to be aligning everything to the erase block size even on physical media; fixing that would fix this in passing but would be a more invasive set of changes.)

Related branches

Revision history for this message
Peter Maydell (pmaydell) wrote :
Revision history for this message
Matt Waddel (mwaddel) wrote :

Hi Peter,

I tried this patch and qemu fails during boot. The system hangs:
...
[ 1.301300] console [ttyS2] enabled, bootconsole disabled
[ 1.301300] console [ttyS2] enabled, bootconsole disabled
[ 1.352844] brd: module loaded
[ 1.361602] loop: module loaded
[ 1.376190] omap2-nand driver initializing

It's been a really long time since I tried qemu on a beagle board
image (so it's probably user error). Here's the commands I used
to create and run the image:

./linaro-media-create --image_file 1005.img --rootfs ext3 --dev beagle --binary image/linaro-m-headless-tar-20101012-0.tar.gz --hwpack hwpack_linaro-omap3_20101012-48_armel_supported.tar.gz

sudo qemu-maemo-system-arm -M beagle -m 256 -sd ./1005.img -clock unix -serial stdio

Do you see anything wrong?

Revision history for this message
Matt Waddel (mwaddel) wrote :
Revision history for this message
Peter Maydell (pmaydell) wrote :

That looks like bug 628471 -- are you sure you're using the most recent qemu-maemo?
(0.0~20100921+871d996-0ubuntu1~linaro1 ; https://launchpad.net/~linaro-maintainers/+archive/tools/+packages ; currently only built for maverick.)

Revision history for this message
Matt Waddel (mwaddel) wrote :

Yep, the new qemu-maemo fixed the booting problem.

So using this patch and removing the --image-file specific boot.cmd referenced in bug 638966 creates a qemu booting beagle image. I vote for making these 2 changes and closing the bugs. I'll create a merge proposal.

Matt Waddel (mwaddel)
Changed in linaro-image-tools:
status: New → In Progress
Matt Waddel (mwaddel)
Changed in linaro-image-tools:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.