|
| From: | Stuart Hughes |
| Subject: | Re: [Ltib] Issues regarding JFFS2/NOR |
| Date: | Mon, 14 Sep 2009 10:41:00 +0100 |
| User-agent: | Thunderbird 2.0.0.16 (X11/20080707) |
Hi Michael, I've checked in a change to do this as discussed. Regards, Stuart Stuart Hughes wrote:
Hi Michael,I'll try to think about the path of least surprises for the default value, I will probably leave it as 8MB as it may act as a hint that a Flash size is expected, I'll add some help documentation to the option.I'm not sure when I'll get to this, but hopefully soon. Regards, Stuart Michael Jones wrote:Hi Stuart,I like your suggested fix. As far as the 8MB default size- I might've considered leaving this at 0. If someone chooses "Pad out image size", but then chooses a "Total size" which is smaller than the unpadded image itself, then they'll just get the minimum image size- unpadded (this is the behavior of mkfs.jffs2), the same as if they hadn't checked "Pad out image size" in the first place. Maybe LTIB could print a warning in that case. But then again, maybe if the default were zero, it would make the whole option look somewhat counter-intuitive (i.e. looks like 0 is a reasonable value, which suggests that this is the _additional_ padding). But I think the language "Total size" is unambiguous. I don't have a strong opinion one way or the other.I didn't intend to add 1kb to my image at all, I just used it from Hamilton's example, also because it nicely illustrates the surprising result of asking for so little padding and getting so much. But in general, yes- when I use padding on my jffs2 images, it's so that they'll fit exactly into an existing partition, and to give the filesystem some breathing space.sincerely, Michael Stuart Hughes wrote:Hi Michael,Thanks for the analysis, which I agree with. The intention was originally to allow adding some free space to the target image, as you show this isn't what happens for jffs2 (I think it works for ext2 which fiddles with inode/block allocation).I think the best thing would be to change the way this works to named (for jffs2 and other flash deploys):[*] Pad out image size (8192) Total size (KB) In this situation the 'Allocate extra space (Kbytes) would not be shown.The default of 8MB would be a default and anyone selecting this would have to know the actual size of their Flash device (or partition).As you probably know you have to be careful with jffs2 such that if the image is smaller than the partition size and it's not erased then when you mount it you'll get loads of error messages (e.g ffs2_scan_eraseblock() ...). So normally it makes sense to pad out to the full partition (or device) size.What do you think of this proposal?BTW: what was the intention of allocating an extra 1kb in your image, were you trying to round up to the size of a partition?Regards, Stuart Michael Jones wrote:Hamilton & Stuart,Regarding #2, The jffs2 image leaps in size when you request just 1 extra kb of space because of LTIB's (mis)treatment of the --pad argument to mkfs.jffs2. Here's what I see going on:jffs2 is a compressed file system, so in my case the staging directory, rootfs.tmp, is 21.6M, but the resulting rootfs.jffs2 w/o padding is only 7.3M. The --pad argument to mkfs.jffs2 is a minimum size of the final jffs2 _image_, not the sum total of the file sizes of the input directory. So if I pad an extra 1kb into a jffs2 image, I might be able to write a file much larger than 1kb in flash if it compresses well.If DEPLOYMENT_PADDING_KB is non-zero, LTIB takes the size of the staging directory, 21.6M, adds DEPLOYMENT_PADDING_KB to it, and passes this to mkfs.jffs2 as the --pad argument, resulting in a jffs2 image which is 21.6M+, rather than 7.3M+. I get 14.3M more padding than I had bargained for.Knowing this, I can of course call mkfs.jffs2 myself and get the desired result. But correctly handling it with LTIB I think is non-obvious:a. If "Allocate extra space X" is understood to be "Give me room to write X bytes in the resulting file system," this is not possible because the padding needed depends on the compression of those X bytes. b. If it is understood as "add X bytes to the jffs2 image" (this seems like an unlikely demand), you can only then pass the correct value to mkfs.jffs2 after you've built it with no padding to know what your unpadded size is, to which you need to add X. So I guess you _could_ just call mkfs.jffs2 twice. c. I think the meaning that mkfs.jffs2 has for padding is sensible, because it's likely that you're tailoring your jffs2 image for a particular size partition. I'm in favor of an option in LTIB which has the same meaning as in mkfs.jffs2: "if the resulting image is not at least X bytes, then pad it to X bytes" (so that it will fit snugly in my flash partition).-Michael Stuart Hughes wrote:Hi Hamilton, Apologies for my late reply. Steve's answered about the stripping.So far as the reserving extra space on jffs2 I'm not sure what the issue is. Your best bet is to take a look at the output when generating the jffs2 image to check it looks sensible. If it doesn't take a look in bin/Ltibutils.pm around line 850, this is where the sizing is done.Note for jffs2 that if you don't ask for padding then the image is not padded at all (no -p option), if you do ask for padding it is padded out to the full calculated size ($fs_size).Regards, Stuart Hamilton Vera wrote:Hi masters, I am trying to deploy a jffs2 image using ltib ./ltib --version ltib 9.1.1 ($Revision: 1.42 $) Unfortunately I am facing some problems and I would like to know if they are isolated. We are working with iMX27ADSand managed to repeat these problems in your desktops and VM using Ubuntu 9.041-) Stripping The strip option is not working with me. I've built the jffs2 image and mounted it using these procedures : mkdir $dir modprobe mtdram total_size=102400 erase_size=128 modprobe mtdblock dd if=jffs2.img of=/dev/mtdblock0 mount -t jffs2 /dev/mtdblock0 $dir Checking if the libs are stripped file $dir/lib* | grep -i strip libanl-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libblkid.so.1.0: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libBrokenLocale-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libc-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libcom_err.so.2.1: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libcrypt-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libdl-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libe2p.so.2.3: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libext2fs.so.2.4: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libgcc_s.so.1: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libm-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libmemusage.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnsl-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnss_compat-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnss_dns-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnss_files-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnss_hesiod-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnss_nis-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libnss_nisplus-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libpcprofile.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libpthread-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libresolv-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped librt-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libSegFault.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libss.so.2.0: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libstdc++.so.6.0.8: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped libtermcap.so.2.0.8: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped libthread_db-1.0.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libutil-2.5.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped libuuid.so.1.2: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped 2-) Allocate extra space (Kbytes) This acts in an odd way, my image is about 11M; address@hidden:/home/ltib.9$ ls -lah rootfs.jffs2 -rw-r--r-- 1 hamilton hamilton 11M 2009-08-04 11:29 rootfs.jffs2 When I ask ltib to allocate 1 extra kbyte ( (1) Allocate extra space (Kbytes) ) the final image goes to 43 M address@hidden:/home/ltib.9$ ls -lah rootfs.jffs2 -rw-r--r-- 1 hamilton hamilton 43M 2009-08-04 11:37 rootfs.jffs2 3-) Write support to NOR. To add RW support in nor.rootfs we had to modify the vi arch/arm/mach-mx27/mx27ads.c { .name = "nor.rootfs", .size = 12 * 1024 * 1024, .offset = MTDPART_OFS_APPEND, .mask_flags = MTD_WRITEABLE}, To be able to write the nor.rootfs, the block changes to: { .name = "nor.rootfs", .size = 12 * 1024 * 1024, .offset = MTDPART_OFS_APPEND}, The MTD_WRITEABLE sets partition to RO, I've found the same code for other boards, I would be grateful if someone else verify this. Thanks in advanceMATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich_______________________________________________ LTIB home page: http://ltib.org Ltib mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/ltib
| [Prev in Thread] | Current Thread | [Next in Thread] |