• State Answer Suggested
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 3177 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

IPNC DM368 SDK 4.0 ubifs bad image sequence number

deoksu min
Prodigy 40 points
Other Parts Discussed in Thread: CODECOMPOSER

Dear All,

I have the problem about UBI file sytem at Appropho IPNC SDK 4.0.

To make ubifs : ( installed some libraries as libacl1-dev, liblzo2-dev and uuid-dev on ubuntu 10.04 PC)

      hotst> make ubifsall

           After comiling, the below is major execute command to generate ubifs in Makefile.

             $(UBIFS_PATH)/mkfs.ubifs/mkfs.ubifs -r  $(TARGET_FS) -m 2048 -e 126976 -c 313 -o ubifs.img

              $(UBIFS_PATH)/ubi-utils/ubinize -v -o ipnc_$(HARDWARE)_ubifs -m 2048 -p 128KiB  $(HARDWARE)_ubinize.cfg

       host> vi dm368_ubinize.cfg

              [ubifs]
              mode=ubi
              image=ubifs.img
              vol_id=0
              vol_size=38MiB
              vol_type=dynamic
              vol_name=rootfs
              vol_flags=autoresize

There is an error booting message : when the generated ubifs(ipnc_dm368_ubifs) is upload to DM368IPNC-MT5, it's happened like this.

        Starting kernel ...

        [    1.939551] UBI error: process_eb: bad image sequence number 1262318900 in PEB 192, expected 1732479461
        [    1.949619] UBI error: ubi_init: cannot attach mtd3
        [    2.033534] Error: Driver 'davinci-mcbsp' is already registered, aborting...
        [    2.082915] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
        [    2.091319] Backtrace:
        [    2.093811] Function entered at [<c002e4ec>] from [<c0311888>]
        [    2.099655]  r7:00008000 r6:c2813000 r5:c0023668 r4:c03b2920
        [    2.105478] Function entered at [<c0311870>] from [<c03118f4>]
        [    2.111396] Function entered at [<c031188c>] from [<c0008fcc>]
        [    2.117248]  r3:00000000 r2:00000000 r1:c2825f78 r0:c03317d6
        [    2.123033] Function entered at [<c0008de8>] from [<c0009178>]
        [    2.128882] Function entered at [<c00090e4>] from [<c00084b4>]
        [    2.134777]  r5:c0022e04 r4:c03b21d8
        [    2.138389] Function entered at [<c00083a4>] from [<c0042e0c>]
        [    2.144287]  r5:c00083a4 r4:00000000

According to mtd_utils version or to change the option as "-c 350", the image sequence number is expected  a differential variables. But the message "bad image sequence number 1262318900 in PEB 192" is fixed.

I need your help. please give me your advice!

thanks.

 

 

  • 0
    Prodigy 40 points

    Dear All,

    I have finded a solution.

    It should be erase whole NAND flash memory and rewrite UBL, UBOOT, Kernel and UBIFS.

    I guess the unnecessary data is remains at the NAND Flash.

    Thanks.

  • 0 in reply to deoksu min
    Prodigy 80 points

    I came across this post when experiencing the similar situation.  After looking into this further, I think it relates to the size of the UBI partition and the programming of the new file system.  The steps in the TI documentation do not erase the entire partition, only about 24 M.  The mkfs.ubifs indicates the filesystem can grow to just less than 38M (the -e and -c options 126976*313).  The UBI documentation indicates this type of error can occur when a new filesystem is programmed overtop of an old filesystem, but does not completely extend to the end of the UBI allocated range.  So erasing the entire UBI filesystem partition and then programming in the new UBI image worked for me without having to reflash the entire device.

  • 0 in reply to Alan1
    Expert 1840 points

    sorry, I wonder that how can I erase all nand without using CCS. Have any way to erase all nand and rewrite UBL, UBOOT just through Uboot consol.

    Thanks

  • 0 in reply to bioz
    Prodigy 80 points

    Using the uboot tftpboot, nand erase and nand write commands you can erase and reprogram all nand from console.  Look through documentation/google for correct syntax.  However, if a mistake is made in the process, you'll need a method to recover which doesn't depend on the nand.

  • 0 in reply to Alan1
    Expert 1840 points

    I have already tried to do this but after erase, rewrite uboot, ubl, kernel and cram file the camera can not boot. I may make wrong in nand address. SO can you tell me exactly which address of nand should be erased. My camera have same nand with appro reference camera. Thanks

  • 0 in reply to bioz
    Prodigy 40 points

    There are some NAND erasing methods.

    First, If it is possible to boot until u-boot,  you can use the command as "nand erase.chip clean".

    It should be write to NAND device with UBL and U-Boot and reboot your system.

    Others, TI supported the flash-Utils that I have downaloded "flash-utils-03.21.00.04". Using CodeComposer with JTAG, the building code, NANDEraser, is enable to erase NAND flash. Unfortunly I don't know download-site.

    good lucks! 

     

  • 0 in reply to deoksu min
    Expert 1840 points

    nand erase clean;

    tftpboot 0x80700000 ubl_432arm_340ddr_ipnc_dm368.bin; nand erase 0x080000 0x08000; nand write 0x80700000 0x080000 0x08000;

    tftpboot 0x80700000 u-boot-1.3.4-dm368_ipnc.bin; nand erase 0x160000 0x28000; nand write 0x80700000 0x160000 0x28000;

    tftpboot 0x80700000 diagnostic_ipnc_dm368.bin; nand erase 0x360000 0x30000; nand write 0x80700000 0x360000 0x30000;

    at the uboot consol, after I do some command above and reset the camera cannot load UBL any more.

    I may wrong something, please help me to figure out. thanks

    p/s: I am working with APPRO camera DM368 and Soft V4.0

  • 0 in reply to bioz
    Prodigy 80 points

    Are you using the files they supplied?  When you tftp the files in with u-boot, it will report the file size.  Ensure the lengths you specify to write are larger than the size reported during the tftp.  I don't remember the correct syntax, but some versions of u-boot either default the write to the filesize received or allow you to specify $filesize as the argument.

  • 0 in reply to Alan1
    Expert 1840 points

    I used the original binary file that supplied by appro so those errors should be ignored. I still wonder about what happening :( any one have some others hint.

  • 0 in reply to bioz
    Prodigy 80 points

    My last two cents:  Does the unit boot from NAND after programming from CCS?  With the JTAG disconnected?  If so, you may try only erasing and programming each section individually from u-boot to see when you have a failure.  I.E. don't erase all of flash, only the section which contains the piece you want to program.  I would try just erasing/programming the linux section first, then u-boot, then UBL.  Check to see if you can still boot after each section.  I.E. just erasing/reprogramming linux should not interfere with u-boot, u-boot section doesn't interfere with UBL.  It will allow you to focus on only the corrupted step or tell you that there is something wide scale wrong.  If you're not booting from NAND after a CCS program, then make sure you aren't configured to be using the SD card.  If none of that helps, you may want to attach a log file with the commands/responses of the normal programming steps through u-boot for someone to examine.