• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 100 subscribers
  • Views 1719 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

while TMDSLCDK138 EVM B/D reboot testing, partition information is unstable

Brent Jang
Prodigy 70 points

Other Parts Discussed in Thread: TMDSLCDK138

I bought TMDSLCDK138 EVM B/D few months ago and did some stress test on this board.

Testing sequence is, 80 seconds power on and 15 seconds power off, with sequence programmable power supply.

Though all the partition is read only, there's partition information missing with such amount of testing time.

3 hours is shortest, and 3 days are maximum duration time without error.

Sometimes kernel is not loadable, sometimes ramdisk is not readable.

In this case, I can't use TMDSLCDK138's components with my new product.

I tested Squashfs, Cramfs, Jffs2, Yaffs2, EXT2/3 but the result is the same.

Any idea what is the reason of this?

Thank you.

following is test log.

case 1. Kernel partition missing

In:    serial

Out:   serial

Err:   serial

Net:   DaVinci-EMAC

Recovery>>> Check Boot Option :

bootcmd : nand read 0xc0700000 0x180000 0x300000; bootm 0xc0700000

Hit any key to stop autoboot:  0

 

NAND read: device 0 offset 0x180000, size 0x300000

Skipping bad block 0x00180000

Skipping bad block 0x001a0000

Skipping bad block 0x001c0000

Skipping bad block 0x001e0000

Skipping bad block 0x00200000

Skipping bad block 0x002a0000

Skipping bad block 0x002c0000

Skipping bad block 0x002e0000

Skipping bad block 0x00300000

3145728 bytes read: OK

Wrong Image Format for bootm command

ERROR: can't get kernel image!

Sanion-Boot >

 

case 2. Ramdisk missing

## Booting kernel from Legacy Image at c0700000 ...

Kernel Load Addr Test by sootoo23: c0700000

   Image Name:   Linux-3.3.0

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    2065704 Bytes = 2 MiB

   Load Address: c0008000

   Entry Point:  c0008000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK

 

Starting kernel ...

 

Uncompressing Linux... done, booting the kernel.

     =================중간 생략 =================

console [netcon0] enabled

netconsole: network logging started

davinci_emac davinci_emac.1: using random MAC addr: 66:03:b8:d2:05:2f

VFS: Mounted root (squashfs filesystem) readonly on device 31:3.

Freeing init memory: 156K

end_request: I/O error, dev mtdblock3, sector 6544

SQUASHFS error: squashfs_read_data failed to read block 0x31d1a1

SQUASHFS error: Unable to read data cache entry [31d1a1]

SQUASHFS error: Unable to read page, block 31d1a1, size 1080000

SQUASHFS error: Unable to read data cache entry [31d1a1]

SQUASHFS error: Unable to read page, block 31d1a1, size 1080000

SQUASHFS error: Unable to read data cache entry [31d1a1]

SQUASHFS error: Unable to read page, block 31d1a1, size 1080000

  • 0
    TI__Mastermind 35645 points
    Hi,

    We will work on this and will let you know the update shortly.

    Thanks & regards,
    Sivaraj K
  • 0
    TI__Guru** 116100 points
    Dear Brent,
    Can you please provide the SDK version used for this test ?
    SD card booting or NAND flash ?

    Before the error occurs, at what stage you removed the power ? I hope you can see that.
    Ex:
    If we get some kernel error while testing, please do check at what stage removed/shutdown the power (you can check the last sequence) ?
    I hope it would be in kernel loading stage...
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 70 points
    Thank you for your concern.

    The version of the SDK in use is MCSDK_1_01_00_02 (u-boot: 2012.04.01-psp03.22.00.06, linux: 3.3-psp03.22.00.06).
    And I'm using NAND as boot device.

    As my previous description about testing sequence, power on time is 80 sec, this is enough time for kernel loading... :(
    So, power down is not happen during kernel loading...
  • 0 in reply to Brent Jang
    TI__Guru** 116100 points

    Dear Brent Jang,
    Are you running any application after kernel loaded ? (i.e accessing the NAND flash contents)


    Testing sequence is, 80 seconds power on and 15 seconds power off, with sequence programmable power supply.

    Do you got success on any board with this testing ?

    Let me check with team on this issue.

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 70 points
    Dear Titus,

    There's no application running after kernel load.
    And, sure, our company's previous products endured power on-off test from QC team.

    SD boot seems okay with our test method, only NAND has problem.

    Regards.
  • 0 in reply to Brent Jang
    TI__Guru** 116100 points
    Dear Brent Jang,
    Thanks.
    Have you tried the same test with our EVM boards (LCDK)?
    Can you please try some UBIFS, ext3 ??

    www.embeddedarm.com/.../resource.php
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 70 points
    Have you tried the same test with our EVM boards (LCDK)?
    > I made this thread because my EVM's NAND partition information is not stable, sure I did.

    I tried Squashfs / Cramfs / Jffs2 / Yaffs2 / EXT2 / EXT3 already.
    UBIFS is not yet.
    Is it necessary to try UBIFS?

    Thank you.
  • 0 in reply to Brent Jang
    TI__Guru** 116100 points
    I have informed to internal team for this issue.
    In how many LCDK boards, you are seeing this problem ?
  • 0 in reply to Titusrathinaraj Stalin
    TI__Guru** 116950 points
    Brent,

    I don`t think the board manufacturer does this level of stress testing with these boards as these boards are evaluation boards that are not meant for taking products to production. We have hundreds of customer who are in production with this device who using the NAND filesystem so I don`t believe this to be an issue with the device itself but it could be a board level issue.

    Is this the only board on which you are seeing these failures. Is your test setup using hardware ECC or software ECC? The device can only support upto 4 bit ECC corrections. Is the software that you are using 4 bit ECC and is there some way to check that the blocks with the RamFS and UBIFS are showing more than 4 bit ECC. Can you elaborate, how you are flashing your images to NAND ? Are you using SFT or u-boot to flash the NAND. Does the board recover after reflashing the images to NAND ?

    Regards,
    Rahul
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 70 points
    I got only one LCDK board.

    Thank you.
  • 0 in reply to Rahul Prabhu
    Prodigy 70 points
    Dear Rahul,

    >> I don`t think the board manufacturer does this level of stress testing with these boards as these boards are evaluation boards that are not
    >> meant for taking products to production. We have hundreds of customer who are in production with this device who using the NAND
    >> filesystem so I don`t believe this to be an issue with the device itself but it could be a board level issue.

    We had to test the stability of candidate device before choosing target platform.
    I agree with your idea that there's many manufacturers using L138 without problem.
    Which I don't is if sequential power on/off that gives enough time to complete boot-up, fails only because it's repeated,
    there's also possibilities that boot-up fail can be happen with our customer.

    >> Is this the only board on which you are seeing these failures. Is your test setup using hardware ECC or software ECC? The device can only
    >> support upto 4 bit ECC corrections. Is the software that you are using 4 bit ECC and is there some way to check that the blocks with the
    >> RamFS and UBIFS are showing more than 4 bit ECC. Can you elaborate, how you are flashing your images to NAND ?
    >> Are you using SFT or u-boot to flash the NAND. Does the board recover after reflashing the images to NAND ?

    For now, I'm not using ECC options (SDK's default setting is maybe using but I didn't intended).
    Yes, does the board recover after reflashing.