This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

File system is too big

Other Parts Discussed in Thread: AM3517

Hi,all
When I made jffs2 image as http://processors.wiki.ti.com/index.php/Create_a_JFFS2_Target_Image#Making_a_JFFS2_image,
the rootfs.jffs2 was 190M(the source filesystem is ti-sdk-am3517-evm-05.02.00.00/filesystem/tisdk-rootfs-am3517-evm.tar.gz).It's too big for AM3517, an error occured when booting :
TFTP error:'File is too big,try increasing block size' as below

In fact , nand  flash size is 512MB of AM3517 ZOOM, so it's enough. And I need Matrix GUI ant Qt ,so it's difficult for me to increase the source filesystem.


I guessed that the default maximun size of filesystem is 32768KB,or 32MB, so 192MB is too big. A suggestion is that modifying Default RAM disk size(kbytes) when make menuconfig, the path is Device Drivers——>Block devices——>RAM block device support——>Default RAM disk size (kbytes). However, I changed it into 262144 KB,or 256MB(default is 32768 KB), but result is the same.
Anyone knows how to solve the problem?

PS. x-loader,u-boot,kernel all are pre-images of CCS-5.0.1.00026-Sitara-ARM.tar.gz.

  • Just a question, have you made sure that the large file system is not over lapping with something else that is already loaded into RAM?  I had a problem where when I tftp'ed my filesystem over it was too large and over wrote UBoot.  I fixed this by changing my load address to 80000000 for the tftp command then I could write it NAND. 

  • I'm far from been an expert in the matter but isn't it the goal of jffs2 to access directly the flash and avoiding copying the whole filesystem into ram? Should the ramdisk be simply disabled when using jffs2 ?

     

    Pierre-Olivier

  • My problem was getting to NAND in the first place.  At some point it has to be loaded to RAM to be copied to NAND but after that you are right.  You shouldn't need a ram disk.  The MTD block driver should just handle the NAND updates from there (assuming you set up your bootargs correctly.)

  • TFTP by default has a block size of 512 bytes and 32MB total. Wiki says that the TFTP allows negotiation of block size. Just that server and client have to support it. I don't know if x-loader or u-boot support it or how to specify a larger block size.

    You need an alternative method of getting your JFFS image onto the target. Depends what resources are available with your platform.

  • I just follow the scripts provided by the AM35x-OMAP35x-PSP-SDK-03.00.01.06.tgz(Path is /scripts/am3517/reflash-micron.txt), so I think it's OK to copy the whole filesystem

  • Brandy Jabkiewicz said:

    Just a question, have you made sure that the large file system is not over lapping with something else that is already loaded into RAM?  I had a problem where when I tftp'ed my filesystem over it was too large and over wrote UBoot.  I fixed this by changing my load address to 80000000 for the tftp command then I could write it NAND. 

     

    At first I used script reflash-micron.txt(Path is scripts\am3517\reflash-micron.txt) to reflash my filesystem----so I don't  think it' over lapping,the script is as below:

    setenv rf_blank_ram   mw.b 0x82000000 0xff 0x2000000
    setenv rf_er_xloader  nand erase 0 80000
    setenv rf_er_uboot    nand erase 80000 1e0000
    setenv rf_er_env      nand erase 260000 20000
    setenv rf_er_kernel   nand erase 280000 500000
    setenv rf_er_ramdisk  nand erase 780000 2000000
    setenv rf_er_fs       nand erase 780000 2000000
    setenv rf_get_xloader tftpboot 0x82000000 images/boot-strap/am3517/x-load.bin.ift
    setenv rf_get_uboot   tftpboot 0x82000000 images/u-boot/am3517/u-boot.bin
    setenv rf_get_kernel  tftpboot 0x82000000 images/kernel/am3517/uImage
    setenv rf_get_ramdisk tftpboot 0x82000000 images/fs/am3517/ramdisk.gz
    setenv rf_get_min_rd  tftpboot 0x82000000 images/fs/ramdisk-base.gz
    setenv rf_get_fs      tftpboot 0x82000000 images/fs/am3517/rootfs.jffs2
    setenv rf_wr_xloader  nandecc hw\; nand write.i 0x82000000 0 80000
    setenv rf_wr_uboot    nandecc sw\; nand write.i 0x82000000 80000 1e0000
    setenv rf_wr_kernel   nandecc sw\; nand write.i 0x82000000 280000 500000
    setenv rf_wr_ramdisk  nandecc sw\; nand write.i 0x82000000 780000 2000000
    setenv rf_wr_fs       nandecc sw\; nand write.i 0x82000000 780000 2000000
    setenv rf_ev          run rf_er_env
    setenv rf_xl          run rf_blank_ram\; run rf_er_xloader\; run rf_get_xloader\; run rf_wr_xloader
    setenv rf_ub          run rf_blank_ram\; run rf_er_uboot\; run rf_get_uboot\; run rf_wr_uboot
    setenv rf_kn          run rf_blank_ram\; run rf_er_kernel\; run rf_get_kernel\; run rf_wr_kernel
    setenv rf_rd          run rf_blank_ram\; run rf_er_ramdisk\; run rf_get_ramdisk\; run rf_wr_ramdisk
    setenv rf_min_rd      run rf_blank_ram\; run rf_er_ramdisk\; run rf_get_min_rd\; run rf_wr_ramdisk
    setenv rf_fs          run rf_blank_ram\; run rf_er_fs\; run rf_get_fs\; run rf_wr_fs
    setenv rf_all_rd      run rf_xl\; run rf_ub\; run rf_kn\; run rf_rd
    setenv rf_all_min_rd  run rf_xl\; run rf_ub\; run rf_kn\; run rf_min_rd
    setenv rf_all_fs      run rf_xl\; run rf_ub\; run rf_kn\; run rf_fs
    printenv
    echo done

    and then I modified somethine parameters(inculding load address to 80000000), one of these modified scripts is

    setenv rf_blank_ram   mw.b 0x80000000 0xff 0x8000000
    setenv rf_er_xloader  nand erase 0 80000
    setenv rf_er_uboot    nand erase 80000 1e0000
    setenv rf_er_env      nand erase 260000 20000
    setenv rf_er_kernel   nand erase 280000 500000
    setenv rf_er_ramdisk  nand erase 780000 8000000
    setenv rf_er_fs       nand erase 780000 8000000
    setenv rf_get_xloader tftpboot 0x80000000 images/boot-strap/am3517/x-load.bin.ift
    setenv rf_get_uboot   tftpboot 0x80000000 images/u-boot/am3517/u-boot.bin
    setenv rf_get_kernel  tftpboot 0x80000000 images/kernel/am3517/uImage
    setenv rf_get_ramdisk tftpboot 0x80000000 images/fs/am3517/ramdisk.gz
    setenv rf_get_min_rd  tftpboot 0x80000000 images/fs/ramdisk-base.gz
    setenv rf_get_fs      tftpboot 0x80000000 images/fs/am3517/rootfs.jffs2
    setenv rf_wr_xloader  nandecc hw\; nand write.i 0x80000000 0 80000
    setenv rf_wr_uboot    nandecc sw\; nand write.i 0x80000000 80000 1e0000
    setenv rf_wr_kernel   nandecc sw\; nand write.i 0x80000000 280000 500000
    setenv rf_wr_ramdisk  nandecc sw\; nand write.i 0x80000000 780000 8000000
    setenv rf_wr_fs       nandecc sw\; nand write.i 0x80000000 780000 8000000
    setenv rf_ev          run rf_er_env
    setenv rf_xl          run rf_blank_ram\; run rf_er_xloader\; run rf_get_xloader\; run rf_wr_xloader
    setenv rf_ub          run rf_blank_ram\; run rf_er_uboot\; run rf_get_uboot\; run rf_wr_uboot
    setenv rf_kn          run rf_blank_ram\; run rf_er_kernel\; run rf_get_kernel\; run rf_wr_kernel
    setenv rf_rd          run rf_blank_ram\; run rf_er_ramdisk\; run rf_get_ramdisk\; run rf_wr_ramdisk
    setenv rf_min_rd      run rf_blank_ram\; run rf_er_ramdisk\; run rf_get_min_rd\; run rf_wr_ramdisk
    setenv rf_fs          run rf_blank_ram\; run rf_er_fs\; run rf_get_fs\; run rf_wr_fs
    setenv rf_all_rd      run rf_xl\; run rf_ub\; run rf_kn\; run rf_rd
    setenv rf_all_min_rd  run rf_xl\; run rf_ub\; run rf_kn\; run rf_min_rd
    setenv rf_all_fs      run rf_xl\; run rf_ub\; run rf_kn\; run rf_fs
    printenv
    echo done

    However ,it still went wrong,even can't tftp. In fact I'm not sure the difference between 0x8000,0000 and 0x8200,0000----and different as http://wiki.tiprocessors.com/index.php/AM35x-OMAP35x-PSP_04.02.00.07_UserGuide#NAND_Support. Is there anything wrong?

  •  

    Hi Jianhua,

    Have you considered using the Flash tool that comes with SDK05.01 for AM35x: http://processors.wiki.ti.com/index.php/Flash_v1.6_User_Guide ?

    Also let me clarify what you want to do.  You mention a ramdisk, but ramdisks are usually small and they stay in RAM. But it sounds like you would like to flash your file system into Nand. Is that correct?
    I took a look at the scripts you mentioned from AM35x-OMAP35x-PSP-SDK-03.00.01.06.tgz, they are setup for a maximum filesystem size of only 32M, so they would need to be modified to handle your 190MB file system.  
    Please let me know if you are successful.
    The second alternative is probably the easiest to do, but it puts only the filesystem into NAND. If you want u-boot and xloader also in NAND then this method will not work for you.

     

  • Hi,

    Another option i can suggest it, use MMC/SD card for filesystem image download to DDR memory and then flash it to NAND. Also please note that the issue which you are seeing is from u-boot and nothing to do with Linux configuration, and flashing NAND using u-boot is only possible from DDR => NAND.

    Follow below steps -

    # Copy image from MMC/SD

            # mmc init

            # mw.b 80000000 ff  <total size>

            # fatload mmc 0 0x80000000 <filesystem name>

    # Flash it to NAND

            #  nandecc <expected ecc>

            # nand write 0x80000000 0x780000 <file size>

     

    This should work.

    Thanks,

    Vaibhav

  • Jeff L said:

     

    Hi Jianhua,

    Have you considered using the Flash tool that comes with SDK05.01 for AM35x: http://processors.wiki.ti.com/index.php/Flash_v1.6_User_Guide ?

    Also let me clarify what you want to do.  You mention a ramdisk, but ramdisks are usually small and they stay in RAM. But it sounds like you would like to flash your file system into Nand. Is that correct?
    I took a look at the scripts you mentioned from AM35x-OMAP35x-PSP-SDK-03.00.01.06.tgz, they are setup for a maximum filesystem size of only 32M, so they would need to be modified to handle your 190MB file system.  
    Please let me know if you are successful.
    The second alternative is probably the easiest to do, but it puts only the filesystem into NAND. If you want u-boot and xloader also in NAND then this method will not work for you.

     

    Hi Jeff

    Sorry so late to reply you.

     Yes, my purpose is flashing the file system into nand(LogicPD AM3517EVM)

    As http://processors.wiki.ti.com/index.php/Flash_v1.6_User_Guide , I found that  File systems cannot be programmed to NAND

        flash using this Flash Tool mentioned by 6 of http://processors.wiki.ti.com/index.php/Flash_v1.6_User_Guide#Details_about_the_Flash_GUI

    I tried the second method as http://processors.wiki.ti.com/index.php/How_to_Flash_Linux_System_from_U-boot#Flashing_the_Root_File_System_to_NAND

    but an error occured as below when I use the command  flash_eraseall –j /dev/mtd4

    Erasing 128 Kibyte @ 0 --  0 % complete.libmtd: error!: unaligned address 2, mtd4 page size is 2048

    flash_eraseall: /dev/mtd4: MTD writeoob failure: Invalid argument
    Erasing 128 Kibyte @ 20000 --  0 % complete.libmtd: error!: unaligned address 131074, mtd4 page size is 2048

    flash_eraseall: /dev/mtd4: MTD writeoob failure: Invalid argument
    Erasing 128 Kibyte @ 40000 --  0 % complete.libmtd: error!: unaligned address 262146, mtd4 page size is 2048

    flash_eraseall: /dev/mtd4: MTD writeoob failure: Invalid argument
    Erasing 128 Kibyte @ 60000 --  0 % complete.libmtd: error!: unaligned address 393218, mtd4 page size is 2048

    I could not continue the following steps

  • some addition info:

    If I used flash_eraseall /dev/mtd4 ,it was OK

    /dev/mtd4 is my file system

  • Hi Jinahua,

    Sorry for the bad information. I did not realize a JFFS2 file system could not be flashed from the flash tool.  That is an issue we are working to resolve.

    The best choice for you would be to follow Viabhav Hiremath's post. You can flash your file system from an SD card using u-boot.

    Please let me know if you have any issues.

  • Googled around for that flash_eraseall error. Looks to be a bug introduced in version 1.4.0 and fixed in 1.4.4. Check your version number with "flash_eraseall --version". Looks like TI let the buggy version slip into your current file system. You would have to cross-compile the latest version of mtd-utils and install it on your target.