----- Ursprüngliche Mail -----

quoted

But let me advertise ubiblock a second time.

Sorry, I could not understand about the ubiblock request. Is it
possible to elaborate little more ?
We are already using squashfs on top of our UBI volumes (including
rootfs mounting).
This is the kernel command line we pass:
rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30
And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel.
Do we need to do something different for ubiblock ?

From that command line I understand that you are *not* using squashfs on top of UBI.
You use mtdblock. ubiblock is a mechanism to turn an UBI volume into a read-only
block device.
See: http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock

quoted

If you place your squashfs on a UBI static volume, UBI knows the exact length
and you can checksum it
more easily.

Yes, we use squashfs on UBI volumes, but our volume type is still dynamic.
Also, you said, UBI knows the exact length, you mean the whole image length ?
How can we get this length at runtime ?

You need a static volume for that. If you update a static volume the length is
known by UBI.

Also, how can we get the checksum of the entire UBI volume content
(ignoring the erased/empty/bad block content) ?

Just read from the volume. /dev/ubiX_Y.

Or, you mean to say, the whole checksum logic is in-built inside the
UBI layer and users don't need to worry about the integrity at all ?

Static volumes have a crc32 checksum over the whole content.
Of course this offers no cryptographic integrity.
See: http://www.linux-mtd.infradead.org/doc/ubi.html#L_overview

Thanks,
//richard

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies