• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 883 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.

Nand probe failure

ranchu
Guru 20755 points
Other Parts Discussed in Thread: OMAP3530

Hello,

I hope you can help me with some strange failure I get when using nand with OMAP3530, using custom board which is boot from nand (all images are stored in nand - x-loader, u-boot, kernel and rfs)

When the u-boot, kernel and filesystem are used with custom board with Micron nand, bth u-boot and kernel detect the nand, and everything works fine (root file system is in nand).

But When I use the totally same version with new board, which has same hardware with little changes, one of them is the nand, which is same nand, but packaged by other manufacture (not micron, but still has the same man id, and device ID: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V 16-bit), I get the following:

1. u-boot detects the nand with no problem (exactly same message as above).

2. kernel does not detect nand - therfor the rootfs fails to mount.

I tried several things including: disabling pinmux in kernel , I also did not find anywhere in kernel where nand gpmc is configured. Therefore I still don't understand why it is successful in u-boot, but fails in kernel boot.

Can it be related to voltage change to nand when u-boot moves to kernel ?

Please Advise.

Thanks!

Ran

  • 0
    TI__Guru** 116100 points

    Hi Ran,

    How about the linux source code for both the working & non-working boards ?

    May be the linux source had missed the IDs (vendor & manufacture) support for the new NAND flash.

  • 0 in reply to Titusrathinaraj Stalin
    Guru 20755 points

    Hi Titus,

    We managed to work with microSemi nand after skipping the overriding of cs gpmc configration in nand (and so continuing to use the u-boot configuration in kernel too).
    We noticed that the following routine: omap2_nand_gpmc_retime (from file linux-04.02.00.07/arch/arm/mach-omap2/gpmc-nand.c)  override the gpmc values. Why does the kernel override the cs values for nand ?
    When we skipped this function it all works OK with microSemi nand.

    Thanks!
    Ran

  • 0 in reply to ranchu
    TI__Guru** 116100 points

    Hi Ran,

    Are you using default 'CS' value for NAND or different one ?

    But When I use the totally same version with new board, which has same hardware with little changes, one of them is the nand, which is same nand, but packaged by other manufacture (not micron, but still has the same man id, and device ID: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V 16-bit), I get the following:

    Then how it could worked for the other boards with little hw modification even you used the samelinux source code, right?

    I'm confused.

  • 0 in reply to Titusrathinaraj Stalin
    Guru 20755 points

    Hi Titus,

    the change between boards is the nand package, so according to my understanding it can be that the same cs configuration which works with 1st nand(micron) will not work with 2nd nand (microSemi) . This is what happens in the kernel. The u-boot uses different cs configuration which works with both nands.
    The question I asked before is why the kernel change the cs configuration of the u-boot in routine omap2_nand_gpmc_retime().

    Thanks,
    Ran