AM335x NAND Configuration Problem

Hi DAVI.

Depending on how different the two NAND chips are, you can expect to make changes to some or all of the GPMC_CONFIG registers (not just 7).  You may need differences in when OE is activated relative to CS, for just one example.

Section "NAND Device Data Read and Write Phase Control in Stream Mode" in the TRM helps determine the values that need to be set in those registers.  Along with figures "NAND Command Latch Cycle" and "NAND Address Latch Cycle".  It takes time comparing those figures to the timing diagrams in the NAND datasheet to adjust when the various signals are asserted and released.

Regards,

    Steve

Thanks Steve, I'll try that!

I'm still trying to configure the GPMC_CONFIG registers for my NAND chip, but I have some questions regarding those registers.

When I compared the new values with the ones that are set by default for the EVM board I started having a lot of doubts about how should I configure these registers. I'll try to explain it:

Consider the default configuration found on the EVM board: 2Gb NAND chip operating with supply voltage of 3.3V. The registers are configured inside the function gpmc_init() when it calls enable_gpmc_cs_config(), passing the values shown below to each of the GPMC_CONFIG registers (all in the file arch/arm/cpu/armv7/ti81xx/mem.c):

M_NAND_GPMC_CONFIG1 = 0x00000800
8 bit bus width (bits 13-12)
NAND Flash like device (bits 11-10)

M_NAND_GPMC_CONFIG2 = 0x001e1e00
CSWROFFTIME = 30 (bits 20-16)
CSRDOFFTIME = 30 (bits 12-8)

M_NAND_GPMC_CONFIG3 = 0x001e1e00
ADVWROFFTIME = 30 (bits 20-16)
ADVRDOFFTIME = 30 (bits 12-8)

M_NAND_GPMC_CONFIG4 = 0x16051807
WEOFFTIME = 22 (bits 28-24)
WEONTIME  = 5  (bits 19-16)
OEOFFTIME = 24 (bits 12-8)
OEONTIME  = 7  (bits 3-0)

M_NAND_GPMC_CONFIG5 = 0x00151e1e
RDACCESSTIME = 21 (bits 20-16)
WRCYCLETIME  = 30 (bits 12-8)
RDCYCLETIME  = 30 (bits 4-0)

M_NAND_GPMC_CONFIG6 = 0x16000f80
WRACCESSTIME     = 22 (bits 28-24)
CYCLE2CYCLEDELAY = 15 (bits 11-8)
No delay between the two accesses (bit 7)

GPMC_CONFIG7 -> this one is set using the NANDs size and its base address.

Reading the table that describes each register, I find the information that every time parameter is related to GPMC_FCLK, meaning RDCYCLETIME equals 30 GPMC_FCLK cycles, for example, which is actually 300ns (if I'm not mistaken, GPMC_FCLK = 100MHz).

When I check this value against the chip's datasheet, I find that the read cycle time should be 20ns (tRC = 20ns). Nethertheless, this is the configuration that works for every EVM board out there and that was the point I started to think something is odd with the NAND configuration and/or with the processor's TRM... 

Now, back to my 1Gb NAND in 1.8V: using the same example and knowing that tRC = 25ns, how would I set RDCYCLETIME correctly? The TRM states 31 (0x1F) as it's maximum possible value and if somehow setting 30 here gives me 20ns, 31 will not work...

I actually listed all the relevant parameters in each register and there are some other things that doesn't make sense (at least not to me). Another example is the fact that OEOFFTIME is 24 and RDACCESSTIME is 21 (according to the figure NAND Data Read Cycle and the preceding text to it, RDACCESSTIME should be grater than OEOFFTIME...).

Anyhow, right know I don't know where to begin to configure these registers. If someone could tell me what I'm missing or how RDACCESSTIME gets to be set as 30 (0x1E), for example, I think I can do the rest on my own.

Regards.

DAVI

Hi Davi.

First, the tRC parameter from the NAND datasheet is the minimum value.  No maximum is listed, so it is not a violation to be slower.  Having said that, the values used by u-boot do seem unnecessarily slow.  I see nothing wrong with your math and agree that GPMC_FCLK will be 100MHz (OUTM4/2 and OUTM4 is supposed to be 200MHz).

Note that Linux uses its own values for GPMC configuration.  See am335x_nand_timings in arch/arm/mach-omap2/board-am335xevm.c.  The values there are expressed in ns and in the 10s of ns that you expect.

RDACCESSTIME greater than OEOFFTIME utilizes the fact that the NAND chip will keep the data on the bus for a short period of time after OE is deactivated.  The Linux timing also uses that fact.  But that isn't necessary.  The data can be captured during a read cycle (at REACCESSTIME) while OE is still active.

So I think you are on the right track but just finding bigger than expected numbers.

One other question:  Does you hardware have the NAND busy/wait signal connected to GPMC_WAIT0?

Regards,

    Steve

Yes, the GPMC_WAIT0 pin is connected to the R/B# pin.

I'll keep debugging the code and trying to find the right configuration for my NAND. I'll post again if anything changes.

Regards,

Davi