Any news on this. Still waiting for patches :)
On Sun, Jan 27, 2013 at 2:04 PM, Jan Schmidt <thay...@noraisin.net> wrote:
> On Sun, 2013-01-27 at 13:32 +0200, Andrei Gherzan wrote:
> > On Sun, Jan 27, 2013 at 10:17:57PM +1100, Jan Schmidt wrote:
> > > On Sun, 2013-01-27 at 00:47 +0200, Andrei Gherzan wrote:
> > > > On Sat, Jan 26, 2013 at 10:18:24PM +1100, Jan Schmidt wrote:
> > > > > When constructing the SD card image, the code was using
> > > > > the inherited ROOTFS_SIZE, which is the size of the
>
> *snip*
>
> > > > > --- a/classes/sdcard_image-rpi.bbclass
> > > > > +++ b/classes/sdcard_image-rpi.bbclass
> > > > > @@ -13,14 +13,16 @@ inherit image_types
> > > > > # Default
> Free space = 1.3x
> > > > > # Use
> IMAGE_OVERHEAD_FACTOR to add more space
> > > > > # <--------->
> > > > > -# 4KiB 20MiB SDIMG_ROOTFS
> > > > > +# 4KiB ~20MiB SDIMG_ROOTFS
> > > >
> > > > Why ~20M? As you see in the class BOOT_SPACE ?= "20480". So that is
> 20MiB.
> > >
> > > I was trying to make it clear in the comment that if the user changes
> > > the BOOT_SPACE size, it will always be rounded up to the nearest 4MB. I
> > > couldn't think of a great way. Also, I didn't pay enough attention -
> the
> > > comment is saying IMAGE_ROOTFS_ALIGNMENT is 4kB, but it should be MiB.
> > >
> >
> > Uh, I understand now your point here. Well, I don't think that user
> needs to
> > know that if he wants 20470 as BOOT_SPACE, he's partition will end up
> 20480.
> > Because this is something related to performance and it's in his benefit
> after
> > all. So let's drop this for now.
>
> OK.
>
> > About the 4kB thing - yes. Needs fix.
>
> OK.
>
> *snip*
>
> > > > > BOOT_SPACE_ALIGNED=$(expr ${BOOT_SPACE_ALIGNED} -
> ${BOOT_SPACE_ALIGNED} % ${IMAGE_ROOTFS_ALIGNMENT})
> > > > > - SDIMG_SIZE=$(expr ${IMAGE_ROOTFS_ALIGNMENT} +
> ${BOOT_SPACE_ALIGNED} + $ROOTFS_SIZE + ${IMAGE_ROOTFS_ALIGNMENT})
> > > > > + ROOTFS_SIZE=`du -ks ${SDIMG_ROOTFS} | awk '{print $1}'`
> > > >
> > > > Are you sure `du -ks ${ROOTFS_SIZE} | awk '{print $1}'` is aligned to
> > > > IMAGE_ROOTFS_ALIGNMENT? I'm not so sure about this. So you might
> need to align
> > > > it the way BOOT_SPACE is aligned.
> > >
> > > No, the ROOTFS_SIZE will be whatever the base recipe creates. I don't
> > > think it will have any particular alignment, except by accident - in
> the
> > > sense that it's probably stored on an ext3 filesystem that has 4kB
> > > allocation blocks and therefore 'du -sk' will round it up to that. We
> > > would need to explicitly round up to 4MiB, but I'm not sure why to do
> > > that -
> > >
> >
> > Check this out:
> > http://android.bytearrays.com/android/what-means-sd-card-alignment/
>
> Sure, but the largst cluster sizes I've seen are 32KB (do they come
> bigger yet?) 4MiB seems like a large amount for anticipation of future
> cluster sizes.
>
> > > > > + SDIMG_SIZE=$(expr ${IMAGE_ROOTFS_ALIGNMENT} +
> ${BOOT_SPACE_ALIGNED} + ${ROOTFS_SIZE})
> > > > >
> > > > > # Initialize sdcard image file
> > > > > dd if=/dev/zero of=${SDIMG} bs=1 count=0 seek=$(expr 1024
> \* ${SDIMG_SIZE})
> > > > > @@ -71,7 +74,7 @@ IMAGE_CMD_rpi-sdimg () {
> > > > > parted -s ${SDIMG} unit KiB mkpart primary fat32
> ${IMAGE_ROOTFS_ALIGNMENT} $(expr ${BOOT_SPACE_ALIGNED} \+
> ${IMAGE_ROOTFS_ALIGNMENT})
> > > > > parted -s ${SDIMG} set 1 boot on
> > > > > # Create rootfs partition
> > > > > - parted -s ${SDIMG} unit KiB mkpart primary ext2 $(expr
> ${BOOT_SPACE_ALIGNED} \+ ${IMAGE_ROOTFS_ALIGNMENT}) $(expr
> ${BOOT_SPACE_ALIGNED} \+ ${IMAGE_ROOTFS_ALIGNMENT} \+ ${ROOTFS_SIZE})
> > > > > + parted -s ${SDIMG} unit KiB mkpart primary ext2 $(expr
> ${BOOT_SPACE_ALIGNED} \+ ${IMAGE_ROOTFS_ALIGNMENT}) $(expr ${SDIMG_SIZE} -
> 1)
> > > > > parted ${SDIMG} print
> > > >
> > > > Don't think that -1 is needed here.
> > >
> > > No, you're right - it shouldn't be. I got a weird error where parted
> > > failed to create the partition in the image file, saying it ran past
> the
> > > end. Possibly related to the error you mentioned you saw that made you
> > > pad with IMAGE_ROOTFS_ALIGNMENT in the first place. I think I'll
> > > investigate more.
> > >
> > > There's a couple of things to check and fix here, so I think I'll
> > > withdraw this patch and re-send it later after more testing. The first
> 2
> > > patches still should be OK though.
> > >
> >
> > Please do. Btw, after a smoke test the boot process failed with your
> > modifications:
>
> Interesting! That certainly didn't happen for me. It may depend on the
> exact size and internal layout of the rootfs image being written to the
> SD image file. I'll test as many combinations as I can before
> re-submitting.
>
> J.
>
> > [ 2.274940] mmcblk0: mmc0:b368 SMI 3.84 GiB
> > [ 2.281131] mmcblk0: p1 p2
> > [ 2.304604] EXT4-fs (mmcblk0p2): feature flags set on rev 0 fs,
> running
> > e2fsck is recommended
> > [ 2.313147] EXT4-fs (mmcblk0p2): bad geometry: block count 57344
> exceeds
> > size of device (45539 blocks)
> > [ 2.323630] List of all partitions:
> > [ 2.327160] b300 4027392 mmcblk0 driver: mmcblk
> > [ 2.332487] b301 20480 mmcblk0p1
> > 00000000-0000-0000-0000-000000000000
> > [ 2.340085] b302 45539 mmcblk0p2
> > 00000000-0000-0000-0000-000000000000
> > [ 2.347592] No filesystem could mount root, tried: ext4
> > [ 2.352910] Kernel panic - not syncing: VFS: Unable to mount root fs
> on
> > unknown-block(179,2)
> > [ 2.361384] [<c0013b98>] (unwind_backtrace+0x0/0xf0) from [<c0398cb8>]
> > (panic+0x90/0x1dc)
> > [ 2.369575] [<c0398cb8>] (panic+0x90/0x1dc) from [<c04ebcb4>]
> > (mount_block_root+0x1f0/0x250)
> > [ 2.378011] [<c04ebcb4>] (mount_block_root+0x1f0/0x250) from
> [<c04ebf28>]
> > (mount_root+0xf0/0x118)
> > [ 2.386879] [<c04ebf28>] (mount_root+0xf0/0x118) from [<c04ec0a4>]
> > (prepare_namespace+0x154/0x1b4)
> > [ 2.395833] [<c04ec0a4>] (prepare_namespace+0x154/0x1b4) from
> [<c04eb8f4>]
> > (kernel_init+0x168/0x1a4)
> > [ 2.404971] [<c04eb8f4>] (kernel_init+0x168/0x1a4) from [<c000eae0>]
> > (kernel_thread_exit+0x0/0x8)
> > PANIC: VFS: Unable to mount root fs on unknown-block(179,2
> >
>
> --
> Jan Schmidt <thay...@noraisin.net>
>
>
--
*Andrei Gherzan*
m: +40.744.478.414 | f: +40.31.816.28.12
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
