ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Issues regarding JFFS2/NOR


From: Stuart Hughes
Subject: Re: [Ltib] Issues regarding JFFS2/NOR
Date: Thu, 10 Sep 2009 13:48:17 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

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 16.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 iMX27ADS
and managed to repeat these problems in your desktops and VM using Ubuntu 9.04

1-) 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 advance


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich





reply via email to

[Prev in Thread] Current Thread [Next in Thread]