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

NAND speed in u-boot on the AM3517

JemiahAitch
Intellectual 290 points
Other Parts Discussed in Thread: AM3517

I'm running Linux on the AM3517 using the AM35x-OMAP35x-PSP version 03.00.01.06. I'm attempting to improve the speed at which NAND can be read in u-boot and my focus is on the GPMC configuration. Presently I measure 16bit reads from NAND are done at ~2.5MHZ (This was a minor speed increase over the stock PSP code that was achieved by a small change to  nand_read_buf16).  I'm looking at the code in drivers/mtd/nand/omap_gpmc.c:board_nand_init.  Would anyone be willing to give an explanation of how the timing of the GPMC bus is configured?  The code in board_nand_init  sets the value nand->chip_delay to 100 but there is no explanation of what that value is. Does anyone know?

Thanks,

Jemiah

.

  • 0
    TI__Guru 64470 points

    After performing a few greps of the u-boot source for chip_delay, this parameter appears to be used by the nand_base.c driver code as a NAND device specific delay when the RDY/BUSY pin of the NAND device is not used/monitored/etc.

    The omap_gpmc.c file indicates this chip_delay parameter (in the comments just before the board_nand_init() definition) is a chip dependent delay for transfering data from array to read regs (tR).  I presume this tR delay is documented in the specific NAND datasheet.

     

    The actual GPMC configuration (ie. setting up the registers) is performed in ./cpu/arm_cortexa8/omap3/mem.c.

  • 0 in reply to BrandonAzbell
    Intellectual 290 points

    Thanks Brandon.  That's a big help. I'll dig in to that.

    Jemiah

    .

  • 0 in reply to JemiahAitch
    Prodigy 110 points

    Hi Jemiah,

    My posting:

    http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/125801.aspx

    Might be applicable to this discussion.  If the GPMC configuration and SDRC configuration with which you benchmarked is the same as what I used, then we're in good agreement that the time per iteration of a) ldrh from GPMC Nand and b) strh to SDRC DD2 SDRAM is ~415 ns, equivalent to 2.4 million such iterations per second.  (You noted 2.5 MHz.)  See attached PDF in my posting.

    The GPMC configuration for the CS0 region can be tuned so that the reads from Nand go down to 50 ns, and the SDRC configuration can be tuned to whatever is optimal for Logic PD's selection of DDR2 SDRAM for the AM3517 SOM-M2.  That's the relatively easy part.  What's surprising and difficult to reconcile from a computer architecture perspective, if what I'm observing from my benchmarking is accurate, is that the performance of the core has the appearance that it queues up the loads and stores to the two independent memory controllers (GPMC and SDRC) as if they were one memory controller.  Overcoming this means implementing code to use the hardware DMA controller, which is quite difficult to justify during the xloader/uboot boot process since the CPU has nothing else to do to justify delegating to the DMA controller.

    Man

  • 0 in reply to Man Nguyen
    Intellectual 290 points

    Hi Man,

       We came to effectively the same conclusion. Without activating DMA, the MMU and the data cache our customer would never see the performance they desired. That said, activating those features is not a small task. From what I understand there's a recent patch to the u-boot project [1] that has started this process but we haven't integrated this into our release yet.

     

    Thanks,

    Jemiah

     

    [1] http://www.denx.de/wiki/U-Boot/

    .