[OE-core] [PATCH 1/2] image_types.bbclass: implement jffs2 summary images (sum.jffs2)

Thu Dec 8 22:48:06 UTC 2011

On Thu, Dec 8, 2011 at 11:43 PM, Ulf Samuelsson
<openembedded-core at emagii.com> wrote:
> On 2011-12-08 22:30, Andrea Adami wrote:
>>
>> On Thu, Dec 8, 2011 at 4:10 PM, Martin Jansa<martin.jansa at gmail.com>
>>  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<andrea.adami at gmail.com>
>>>>  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<andrea.adami at gmail.com>
>>>
>>> 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<tom.rini at gmail.com>
>>>>
>>>>> ---
>>>>>  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
>>>>> Openembedded-core at lists.openembedded.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>
>>>>
>>>>
>>>> --
>>>> Tom
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>> --
>>> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
> --
> Best Regards
> Ulf Samuelsson
> eMagii
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core