• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 447 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.

DM6446 U-BOOT Nand chip detection is too long / slow nand operation

David Goshadze
Prodigy 20 points

Hi!

We've developed DM6446 based custom board. The board works fine, except one strange thing - There is 2.6 seconds delay during nand chip detection :

 

0.000 0.000: DM644x initialization passed!
0.000 0.000:
0.000 0.000: TI UBL Version: 1.50
0.000 0.000:
0.000 0.000: Booting Catalog Boot Loader
0.000 0.000:
0.000 0.000: BootMode = NAND
0.000 0.000:
0.000 0.000: Starting NAND Copy...
0.000 0.000:
0.000 0.000: Valid magicnum, 0xA1ACED66, found in block 0x00000006.
0.000 0.000:
0.181 0.181:    DONE
0.181 0.000:
0.181 0.000: Jumping to entry point at 0x81080000.
0.181 0.000:
0.181 0.000:
0.181 0.000:
0.181 0.000:
0.181 0.000:
0.181 0.000: U-Boot 1.2.0 (Jan 15 2010 - 22:11:00)
0.181 0.000:
0.181 0.000:
0.181 0.000:
0.181 0.000: DRAM:  256 MB
0.181 0.000:
0.181 0.000: unknown vendor=0 Flash:  0 kB
0.181 0.000:
0.181 0.000: NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0xa1 (Samsung NAND 128MiB 1,8V 8-bit)
0.181 0.000:                                    
2.835 2.654: 128 MiB     <---------- 2.654 seconds delay!!!
2.835 0.000:
3.119 0.284: In:    serial
3.119 0.000:
3.119 0.000: Out:   serial
3.119 0.000:
3.119 0.000: Err:   serial
3.119 0.000:
3.251 0.132: ARM Clock :- 297MHz
3.251 0.000:
3.267 0.016: DDR Clock :- 162MHz

I also think that nand operation is quite slow.

For example Kernel image (1.3 MB in my case) copy from nand to DDR in approx. 2 second which is too long in my opinion.

I would appreciate any help/hints very much.

David.

 

  • 0
    TI__Mastermind 41665 points

    While I can agree that this is a bit slow, I don't think what you are seeing is unusual, below is a boot log on my DM6446 EVM with time stamps, and it looks like it takes my board about 2.6 seconds as well to identify the NAND.

    DM6446 EVM Boot Log said:

    [Mon Jan 18 16:16:24.364 2010] DM644x initialization passed!
    [Mon Jan 18 16:16:24.364 2010] TI UBL Version: 1.50
    [Mon Jan 18 16:16:24.364 2010] Booting Catalog Boot Loader
    [Mon Jan 18 16:16:24.364 2010] BootMode = NAND
    [Mon Jan 18 16:16:24.364 2010] Starting NAND Copy...
    [Mon Jan 18 16:16:24.380 2010] Valid magicnum, 0xA1ACED66, found in block 0x00000006.
    [Mon Jan 18 16:16:24.552 2010]    DONE
    [Mon Jan 18 16:16:24.552 2010] Jumping to entry point at 0x81080000.
    [Mon Jan 18 16:16:24.552 2010]
    [Mon Jan 18 16:16:24.552 2010]
    [Mon Jan 18 16:16:24.552 2010] U-Boot 1.2.0 (Apr 13 2009 - 12:08:08)
    [Mon Jan 18 16:16:24.552 2010]
    [Mon Jan 18 16:16:24.552 2010] I2C:   ready
    [Mon Jan 18 16:16:24.552 2010] DRAM:  256 MB
    [Mon Jan 18 16:16:24.552 2010] unknown vendor=0 Flash:  0 kB
    [Mon Jan 18 16:16:24.567 2010] NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0x36 (Samsung NAND 64MiB 1,8V 8-bit)
    [Mon Jan 18 16:16:27.161 2010] 64 MiB
    [Mon Jan 18 16:16:27.239 2010] In:    serial
    [Mon Jan 18 16:16:27.239 2010] Out:   serial
    [Mon Jan 18 16:16:27.239 2010] Err:   serial
    [Mon Jan 18 16:16:27.255 2010] ARM Clock :- 297MHz

    [Mon Jan 18 16:16:27.270 2010] DDR Clock :- 162MHz

    This is something you would have to dig into the U-Boot source a bit to find what it is doing, you may be able to cut down the time significantly if it is just verifying the type/size of the NAND and you can guarantee the values and bypass the check.

    You may also want to check the EMIF settings you are using to interface with the NAND, if your NAND device is faster than what is configured in U-Boot you may be able to tweak the timings to improve performance further.

  • 0 in reply to Bernie Thompson TI
    Prodigy 20 points

    Hi Bernie!

    And thank you for your reply.

    I also thought this behavior is normal until I checked with DM355 EVM board (also with u-boot 1.2.0):

    It initializes 2 Nand chips instantly (less then 10 ms).

    An what it does in between writing "NAND: Nade device: Manufacturer ID ......" and displaying capacity "2 GiB" is printing "Bad block table found at ..." and displaing bad block information.

    Maybe the problem is related to bad blocks (I used "nand scrub" once).

    I thought about digging into u-boot, but I wanted to check wether known solution exitst.

    In my project minimizing boot time is essential.

    I think I can optimize the rest of boot process as in http://tiexpressdsp.com/index.php/All_This_For_1_Second_Boot

    But this nand detection delay seems to be problem for me.

    David.

     

     

     

  • 0 in reply to David Goshadze
    TI__Mastermind 41665 points

    David Goshadze said:
    An what it does in between writing "NAND: Nade device: Manufacturer ID ......" and displaying capacity "2 GiB" is printing "Bad block table found at ..." and displaing bad block information.

    I suppose this means that U-Boot is going through a bad block checking procedure, which is probably a good idea for long term reliability, particularly if your application is doing a lot of NAND writes, though you may be able to skip this after having done it once, or not run it so often as long as the bad block table is maintained.

    One other thought since you mention it is faster on DM355 is ECC calculations, the DM6446 has a simple hardware ECC calculation mechanism whereas the DM355 has one that is more advanced with 4 bit ECC, this may also play some role. The best way to verify what is going on though is to dig into the U-Boot sources.

  • 0
    Expert 1080 points

    David Goshadze said:

    For example Kernel image (1.3 MB in my case) copy from nand to DDR in approx. 2 second which is too long in my opinion. 

    Hi David,

    I have the same slow nand operation problem as you mentioned in quote above on my custom DM6446 board. Below is my bootcmd:

    setenv bootcmd 'nand read 0x82000000 0x460000 0x1a36200; nboot 80700000 0 2e0000;bootm'

    Since I also " nand read " the  ~20 MB ramdisk image from NAND it takes about ~40 sec to copy .

     

    Did you solve the slow NAND operation problem ? How can I accelerate the uboot nand read ?

    Thanks and regards.

    Ferhat