Re: [yocto] [meta-raspberrypi][PATCH 3/3] sdcard-image: Use the size of the generated rootfs
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
> > > rootfs contents. When building (for example) a compressed
> > > rootfs, this allocates a partition much larger than necessary.
> > >
> > > Instead, take the size of the generated rootfs file that is
> > > about to be written into the generated image.
> > >
> > > Also remove the extra ${IMAGE_ROOTFS_ALIGNMENT} padding at
> > > the end of the image, as it isn't needed now.
> > >
> > > Signed-off-by: Jan Schmidt
> > > ---
> > > classes/sdcard_image-rpi.bbclass | 23 +--
> > > 1 file changed, 13 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/classes/sdcard_image-rpi.bbclass
> > > b/classes/sdcard_image-rpi.bbclass
> > > index 421f561..fdac3b2 100644
> > > --- 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.
About the 4kB thing - yes. Needs fix.
> > > # <---> <--> <-->
> > > -#
> > > ---
> > > -# | IMAGE_ROOTFS_ALIGNMENT | BOOT_SPACE | ROOTFS_SIZE|
> > > IMAGE_ROOTFS_ALIGNMENT|
> > > -#
> > > ---
> > > -# ^^^^
> > > ^
> > > -# ||||
> > > |
> > > -# 0 4096 4KiB + 20MiB 4KiB + 20Mib +
> > > SDIMG_ROOTFS 4KiB + 20MiB + SDIMG_ROOTFS + 4KiB
> > > +#
> > > +# | IMAGE_ROOTFS_ALIGNMENT | BOOT_SPACE | ROOTFS_SIZE|
> > > +#
> > > +# ^^^^
> > > +# ||||
> > > +# 0 4096 4KiB + ~20MiB 4KiB + ~20Mib +
> > > SDIMG_ROOTFS
> > > +# rounded up to
> > > +# IMAGE_ROOTFS_ALIGNMENT
> > >
> > >
> > > # Set kernel and boot loader
> > > @@ -29,7 +31,7 @@ IMAGE_BOOTLOADER ?= "bcm2835-bootfiles"
> > > # Boot partition volume id
> > > BOOTDD_VOLUME_ID ?= "${MACHINE}"
> > >
> > > -# Boot partition size [in KiB]
> > > +# Boot partition size [in KiB] (will be rounded up to
> > > IMAGE_ROOTFS_ALIGNMENT)
> > > BOOT_SPACE ?= "20480"
> > >
> > > # Set alignment to 4MB [in KiB]
> > > @@ -60,7 +62,8 @@ IMAGE_CMD_rpi-sdimg () {
> > > # Align partitions
> > > BOOT_SPACE_ALIGNED=$(expr ${BOOT_SPACE} + ${IMAGE_ROOTFS_ALIGNMENT} - 1)
> > > 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
Re: [yocto] [meta-raspberrypi][PATCH 3/3] sdcard-image: Use the size of the generated rootfs
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 57
Re: [yocto] [meta-raspberrypi][PATCH 1/3] linux: Add a Linux 3.6 kernel recipe
On Sat, Jan 26, 2013 at 12:33:23AM +1100, Jan Schmidt wrote: > * Add a recipe to build the linux kernel from the rpi-3.6.y branch at > https://github.com/raspberrypi/linux > * Since this has a higher version, it will be the preferred linux kernel > by default. > > Signed-off-by: Jan Schmidt > --- > recipes-kernel/linux/linux-raspberrypi_3.6.11.bb | 34 > ++ > 1 file changed, 34 insertions(+) > create mode 100644 recipes-kernel/linux/linux-raspberrypi_3.6.11.bb Merged. Thank you, -- 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
Re: [yocto] [meta-raspberrypi][PATCH 2/3] bcm2835-bootfiles: Bump the firmware revision
On Sat, Jan 26, 2013 at 12:33:24AM +1100, Jan Schmidt wrote: > * Pull in a newer firmware revision (0ac68c 7th Jan 2013) from > https://github.com/raspberrypi/firmware for various fixes and > improvements > > Signed-off-by: Jan Schmidt > --- > recipes-bcm/common/firmware.inc |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Merged. Thank you, -- 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
Re: [yocto] [meta-raspberrypi][PATCH 2/2] xserver-xf86-config: fix do_install
On Sat, Jan 26, 2013 at 11:58 PM, Andrei Gherzan wrote:
> On Thu, Jan 24, 2013 at 10:57:42PM +0100, Andreas Müller wrote:
>> for some reason wildcards don't work in current head. Error message was:
>>
>> | DEBUG: Executing shell function do_install
>> | install: cannot stat
>> `/home/Superandy/tmp/oe-core-eglibc/work/raspberrypi-angstrom-linux-gnueabi/xserver-xf86-config/0.1-r18/xorg.conf.d/*':
>> No such file or directory
>>
>
> I can't reproduce your error. For me this works. Maybe was something broken in
> oe-core? Anyway it seems to be fixed now. Would you retest it please
Will do that
>
>> Signed-off-by: Andreas Müller
>> ---
>> .../xorg-xserver/xserver-xf86-config_0.1.bbappend |6 --
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
>> b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
>> index 65931e2..a8b8e8c 100644
>> --- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
>> +++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
>> @@ -1,12 +1,14 @@
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> # Don't forget to bump PRINC if you update the extra files.
>> -PRINC := "${@int(PRINC) + 5}"
>> +PRINC := "${@int(PRINC) + 6}"
>>
>> THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
>> FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
>>
>> -SRC_URI_append_raspberrypi = " file://xorg.conf.d/* "
>> +SRC_URI_append_raspberrypi = " \
>> + file://xorg.conf.d/10-evdev.conf \
>> +"
>>
> I don't find this lin ebreak necesssary here. And if it was, don't combine
> formating commits with other fixes.
>
Oops this was left over from some testing.
Andreas
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
