On Thu, Dec 8, 2011 at 11:43 PM, Ulf Samuelsson <[email protected]> wrote: > On 2011-12-08 22:30, Andrea Adami wrote: >> >> On Thu, Dec 8, 2011 at 4:10 PM, Martin Jansa<[email protected]> >> wrote: >>> >>> On Thu, Dec 08, 2011 at 07:57:52AM -0700, Tom Rini wrote: >>>> >>>> On Tue, Dec 6, 2011 at 4:23 PM, Andrea Adami<[email protected]> >>>> wrote: >>>>> >>>>> * Building the jffs2 filesystem to include summary information speeds >>>>> up >>>>> * the mount process considerably at the cost of increased size. >>>>> * The rate of speedup is generally higher on NAND chips and on the >>>>> chips >>>>> * where the erase block size is large. >>>>> >>>>> Signed-off-by: Andrea Adami<[email protected]> >>> >>> I'll repeat my comment from yesterday, but IMHO it would be easier to >>> see the difference between those 2 images if the IMAGE_CMD_jffs2 output >>> is >>> renamed to .jffs2.nosummary and IMAGE_CMD_sum.jffs2 (or renamed >>> IMAGE_CMD_jffs2.summary) >>> produces .jffs2.summary (or even just .jffs2 if we can agree that >>> .summary is >>> what enduser wants by default) >> >> I tried to keep the patch not too invasive and did not introduce a >> special EXTRA string for sumtool. >> The most widely used options (-p -l -e) are common, though. >> >> Unfortunately summary means we have a bigger image: >> 44M Dec 8 16:14 core-image-sato-c7x0-20111208151047.rootfs.jffs2 >> 57M Dec 8 16:14 core-image-sato-c7x0-20111208151047.rootfs.sum.jffs2 >> >> Being some devices have strict size requirements I think it is better >> to build both kind of images. >> > Not sure exactly what sumtools does, > but as I understood it, it does things which > the targets need to be doing at first startup otherwise.
No, this operation cannot be done runtime. http://www.embedded-linux.co.uk/tutorial/jffs2-summary " The tools that does that, mkfs.jffs2, does not do anything about summary nodes, or to put it another way, by default you will end up with an image that takes a long time to mount. The secret is that you have to use a second tool from mtdutils: sumtool. " Regards Andrea > > Does that not mean that the target rootfs will grow > from 44 MB to 57 MB during that process? > > If it does, you never want to have the non-sumtool version. > (I guess if you downloaded the file over a 20 bps channel to > a nuclear submarine, you would disagree) > > BR > Ulf > > > > > >> Cheers >> >> Andrea >> >>> But other than that it looks fine and will make my IMAGE_DEPENDS_jffs2 a >>> bit shorter. >>> >>> Regards, >>> >>>> Acked-by: Tom Rini<[email protected]> >>>> >>>>> --- >>>>> meta/classes/image_types.bbclass | 5 ++++- >>>>> 1 files changed, 4 insertions(+), 1 deletions(-) >>>>> >>>>> diff --git a/meta/classes/image_types.bbclass >>>>> b/meta/classes/image_types.bbclass >>>>> index 29b6380..bd4b7bc 100644 >>>>> --- a/meta/classes/image_types.bbclass >>>>> +++ b/meta/classes/image_types.bbclass >>>>> @@ -35,6 +35,8 @@ XZ_COMPRESSION_LEVEL ?= "-e -9" >>>>> XZ_INTEGRITY_CHECK ?= "crc32" >>>>> >>>>> IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime >>>>> --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}" >>>>> +IMAGE_CMD_sum.jffs2 = "${IMAGE_CMD_jffs2}&& sumtool -i >>>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \ >>>>> + -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 >>>>> ${EXTRA_IMAGECMD}" >>>>> >>>>> IMAGE_CMD_cramfs = "mkcramfs ${IMAGE_ROOTFS} >>>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs ${EXTRA_IMAGECMD}" >>>>> >>>>> @@ -138,6 +140,7 @@ EXTRA_IMAGECMD_btrfs ?= "" >>>>> >>>>> IMAGE_DEPENDS = "" >>>>> IMAGE_DEPENDS_jffs2 = "mtd-utils-native" >>>>> +IMAGE_DEPENDS_sum.jffs2 = "mtd-utils-native" >>>>> IMAGE_DEPENDS_cramfs = "cramfs-native" >>>>> IMAGE_DEPENDS_ext2 = "genext2fs-native" >>>>> IMAGE_DEPENDS_ext2.gz = "genext2fs-native" >>>>> @@ -157,4 +160,4 @@ IMAGE_DEPENDS_ubi = "mtd-utils-native" >>>>> IMAGE_DEPENDS_ubifs = "mtd-utils-native" >>>>> >>>>> # This variable is available to request which values are suitable for >>>>> IMAGE_FSTYPES >>>>> -IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz >>>>> ext2.lzma live squashfs squashfs-lzma ubi tar tar.gz tar.bz2 tar.xz cpio >>>>> cpio.gz cpio.xz cpio.lzma" >>>>> +IMAGE_TYPES = "jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 >>>>> ext3.gz ext2.lzma live squashfs squashfs-lzma ubi tar tar.gz tar.bz2 >>>>> tar.xz >>>>> cpio cpio.gz cpio.xz cpio.lzma" >>>>> -- >>>>> 1.7.3.4 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Openembedded-core mailing list >>>>> [email protected] >>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >>>> >>>> >>>> >>>> -- >>>> Tom >>>> >>>> _______________________________________________ >>>> Openembedded-core mailing list >>>> [email protected] >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >>> >>> -- >>> Martin 'JaMa' Jansa jabber: [email protected] >>> >>> _______________________________________________ >>> Openembedded-core mailing list >>> [email protected] >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >>> >> _______________________________________________ >> Openembedded-core mailing list >> [email protected] >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > -- > Best Regards > Ulf Samuelsson > eMagii > > > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
