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.

1:01 not found

Other Parts Discussed in Thread: ASH

Hello,

We are using dm365.

We have some issue of failues in boot. It mostly happens in ubl, but sometimes we see failure later in kernel.

We are not sure if it is also related to nand flash issue (ecc) or something else.

The log complains "1:XX not found" , I could not understand where it comes from and if it is flash related issue.

We used ubl 1.5, u-boot 1.3.4 , and kernel 2.6.18).

I made a fix in ubl according to Sudhakar post in 

But I am not sure if I also need to make another ecc fix in u-boot or kernel.

Does this log indicated an ecc issue ?

U-Boot 1.3.4 (Dec 28 2010 - 13:35:36)

I2C: ready
DRAM: 128 MB
NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3
V 8-bit)
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
256 MiB
env1 size: 16380, crc32 61515057
62 61 75 64 72 61 74 65 3D 31 31 35 32 30 30 0 62 6F 6F 74
In: serial
Out: serial
Err: serial
Ethernet PHY: GENERIC @ 0x00
Compilation successful
Hit any key to stop autoboot: 0

Loading from NAND 256MiB 3,3V 8-bit, offset 0x400000
Image Name: Linux-2.6.18_pro500-davinci_evm-
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1516308 Bytes = 1.4 MB
Load Address: 80008000
Entry Point: 80008000
## Booting kernel from Legacy Image at 80700000 ...
Image Name: Linux-2.6.18_pro500-davinci_evm-
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1516308 Bytes = 1.4 MB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux.............................................................
.......................................... done, booting the kernel.
nand_davinci nand_davinci.0: after scan
PM: davinci_pm_probe
ARMON starting...
SW Version:Mar 11 2012
BSP Version:Mar 5 2012
Armon finished intialization
1:01 not found
route: SIOC[ADD|1:02 not found
DEL]RT: No such 1:03 not found
process
1:04 not found
1:05 not found
1:06 not found
1:07 not found
1:08 not found
1:09 not found
1:0a not found
1:0b not found
1:0c not found
1:0d not found
1:0e not found
1:0f not found
1:10 not found
1:11 not found
1:12 not found
1:13 not found
1:14 not found
1:15 not found
1:16 not found
1:17 not found
1:18 not found
1:19 not found
1:1a not found
1:1b not found
1:1c not found
1:1d not found
1:1e not found
1:1f not found
Setting up networking ....
Restarting internet superserver: inetd.
/bin/ash: can't access tty; job control turned off
#

Regards,

Ran

  • Ran,

    It seems to me that your drivers aren't being properly loaded. How are you flashing your images? What partitioning scheme are you using, and what bootargs are you passing to the kernel as well?

    Regards,
    Guilherme
  • Hi Guilherme,

    The above error happens randomly after a long usage of the product.
    That's why I suspect it might be a nand issue.
    What do you think ?

    Regards,
    Ran
  • Ran,

    We had a similar issue... What filesystems are you using? We had trouble using cramfs/squashfs.

    Regards,
    Guilherme

  • Hi,

    I am using YAFFS.

    Thanks,
    Ran
  • I see. Well, never used YAFFS myself, but here are some ideias:

    - Does reflashing the partition solve the issue? If so, it is most likely an ECC error.
    - Try enabling debug messages on yaffs, and make a script that writes constantly to a small partition (around 3 MB), and check if the messages accuse any bad blocks or ecc errors.
    - Follow the return of the mtd_read() function, and check how YAFFS handles the -EUCLEAN return code. This is the code returned when a bitflip is detected and corrected by mtd.
    - If changing your filesystem is a possibility, check UBI (and ubiblk), UBIFS and JFFS2 (if you need a robust system).

    Regards,
    Guilherme

  • Hi Guilherme Costa,

    Many thanks for the ideas.
    On re-flashing the parition, it solved the issue.
    So, as you said, it looks like an ecc issue.
    I use linux 2.6.18 , u-boot 1.3.4 and ubl 1.5, and want to make minimal changes as possible,
    I found TI's sudhakar patch for ubl in :
    e2e.ti.com/.../1831623
    But I am not sure if there should be additional fixes in u-boot and kernel.
    I can't find patch/information on that...
    How to know for sure ?

    Regards,
    Ran
  • Ran,

    My best bet would be studying the code and enabling/adding debug information to see if ECC is being handled correctly.

    Regards,
    Guilherme
  • Hi Guilheme,

    I see this link
    processors.wiki.ti.com/.../Disabling_NAND_HW_ECC_support
    which says that hw ecc should not be used with yaffs.

    Does that makes sense ? We use yaffs for some long time now in all our applications.

    Thanks,
    Ran
  • Hi Guilheme,

    Maybe you can help with this.
    Our problem:
    We have many product which are based on dvsdk 02_01 (linux 2.6.18, u-boot 1.3.4, ubl 1.5).
    We percieved problems with boot mostly in UBL and other times in linux startup.
    We need a solution that can be updated using only ethernet interface.
    The requirement is to keep the kernel 2.6.18 and make a fix in the bsp alone (withoput upgrading to later linux).
    I think the fix should contain both:
    1. fix to ecc issue
    2. option to write ubl/u-boot from linux (so that we can update the version from ethernet).
    processors.wiki.ti.com/.../DM365_Nand_ECC_layout

    I think (2) is required with out version (I see that I can update the ubl/u-boot with this version, but on trying to update the boot parameters partitions, I see that u-boot fails to read that, I'm not sure why).

    Do you have any idea how we can achieve this goal ? I can't find information in e2e.
    On comparing 2.6.18 nand driver to 2.6.32 I see hugh differences.
    I am not sure where to start......
    I wish there was a patch to these problem in 2.6.18.


    Regards,
    Ran

  • Ran,

    Could you post your kernel log? When this error happens, do you get any specific error messages on console?

    I believe that the flash partitions can be written to from Linux without problems...

    Also, I suggest you check the MTD website, as well as the mailing list. If you post your log there, they might be able to help you. I believe there is a YAFFS mailing list as well. Try checking there too =]

    Regards,
    Guilherme
  • Hi Guilherme,

    I've made some progress when using dvsdk 02_01 (our current version):

    1. kernel write ubl & u-boot partition, and they boot ok. From this I assume that u-boot and kernel use same ecc ?

    2. u-boot flash all partitions (u-boot environment, filesystem and kernel) and they all startup ok. from this I assume that u-boot and kernel use same ecc ? (otherwise kernel would not read filesystem correctly)

    3. But on trying to flash u-boot environment from kernel -> it fails to be read ok by u-boot (u-boot use default environment instead)

    How can that be ? Doesn't it contradicat (1) & (2) ?

    Thanks,

    Ran

  • Hi Ran,

    Sorry for the delay in the answer. Are you erasing the partition before trying to flash is from linux?

    Regards,
    Guilherme
  • Hi Guilherme,

    Thank you so much for the time.
    I made the simple fix as described form UBL 1.5, I've checked it using my board (which has no problem), so I am not sure how I can validate that it works....
    Anyway, I have given this solution to product but they informed me that on trying the image on a problemtaic board, the error still exist.
    I belive they made an erase before (I will check that , but now there is some holiday, so I can't verify what they did in the following days).
    I understand from your answer that if they erased as needed, the error should not have been seen...
    I wander what's the issue....I've build the UBL exactly as I seen in this thread.

    Thanks,
    Ran