RE: [U-Boot-Users] JFFS2+U-Boot writing an image that has been "SUMMARY"-patched?
Martin Egholm Nielsen wrote:
I'm considering patching my Linux kernel JFFS2 code with the "summary"
patch: http://www.inf.u-szeged.hu/jffs2/mount.php decreasing mount time severely. In short, this patch requires
modifying
some data in the end of each eraseblock - also in the image that
should
be written.
However, I'm planning on using u-boot to write the Linux root-fs -
using
"nand write.jffs2" - and was wondering whether this function (write.jffs2) actually cared about what it was writing?
When I added the option all it did was allow skipping of bad blocks (since JFFS2 blocks don't care where they are in the FLASH) and write the oob data properly for JFFS2. It didn't (and I think still doesn't) examine the JFFS2 data at all. As long as the summary data is location independent it should be OK.
I tried writing "giberish" memory data using write.jffs2, and it
didn't
complain, though. But still, its name ".jffs2" indicate that some knowledge of jffs2 is used?
I only meant it to indicate that the option is for writing jffs2 images, so if changes or added features would break jffs2 compatibility (and some were proposed a while ago) the changes should not be made to the jffs2 option, they would need a new one.
Best regards,
Dave Ellis ~~~~~~~~~~~~~~~~~~~~~~~~~~ SIXNET - "Leading the Industrial Ethernet Revolution" 331 Ushers Road, P.O. Box 767, Clifton Park, NY 12065 USA Tel +1 (518) 877-5173 Fax +1 (518) 877-8346 Email me at: dge@sixnetio.com Detailed product info: www.sixnetio.com ~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Dave,
I'm considering patching my Linux kernel JFFS2 code with the "summary" patch: http://www.inf.u-szeged.hu/jffs2/mount.php decreasing mount time severely. In short, this patch requires modifying some data in the end of each eraseblock - also in the image that should be written.
However, I'm planning on using u-boot to write the Linux root-fs - using "nand write.jffs2" - and was wondering whether this function (write.jffs2) actually cared about what it was writing?
When I added the option all it did was allow skipping of bad blocks (since JFFS2 blocks don't care where they are in the FLASH) and write the oob data properly for JFFS2. It didn't (and I think still doesn't) examine the JFFS2 data at all. As long as the summary data is location independent it should be OK.
Super, I kinda guessed that!
I tried writing "giberish" memory data using write.jffs2, and it didn't complain, though. But still, its name ".jffs2" indicate that some knowledge of jffs2 is used? >
I only meant it to indicate that the option is for writing jffs2 images, so if changes or added features would break jffs2 compatibility (and some were proposed a while ago) the changes should not be made to the jffs2 option, they would need a new one. >
Makes sense!
Thanks for sorting that out - I'll head for jffs2+summary now, then...
// Martin
I'm considering patching my Linux kernel JFFS2 code with the "summary" patch: http://www.inf.u-szeged.hu/jffs2/mount.php decreasing mount time severely. In short, this patch requires modifying some data in the end of each eraseblock - also in the image that should be written.
by the way has anyone tried to put support in U-boot for the other JFFS2 Improvement project that they people at Szeged did? i.e. that uses other compression algorithms?
http://www.inf.u-szeged.hu/jffs2/bbc.php
C Michael Sundius Solico Group LLC 232 Nevada St San Francisco, CA 94110 msundius@sundius.com (415)608-0121
participants (3)
-
C Michael Sundius -
Dave Ellis -
Martin Egholm Nielsen