Re: [Ltib] Issues regarding JFFS2/NOR

[Steve Papacharalambous]

On Tue, 2009-08-04 at 12:16 -0300, 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
> 

Hi Hamilton,

By default ltib only strips debug information (symbols), and the status
shown by the "file" command still indicates "not stripped" after the
debug symbols have been stripped.

It is possible to select a more aggressive strip policy in ltib.  This
can be selected as one of the options in the "Target Image Generation"
configuration section.  However although this option strips the binaries
in the root file systems using a more aggressive strip policy, it will
not attempt to apply this to the libraries since stripping symbol tables
from the libraries will usually break them,

Best regards,

Steve