NAND and DDR2 Configurations for UBL, U-Boot, and Linux on DM6467T

Hi,

Apart from DDR and EMIF guides, it is good to go through http://www.ti.com/lit/an/spraas0d/spraas0d.pdf document also. This document describes the functionality of the TMS320DM6467 Digital Media System-on-Chip (DMSoC) ARM ROM boot loader (RBL) software.

It's difficult to point out source files where NAND and DDR initializations will be done as the files will depend on the release version being used. So if you go through the code execution flow, you will easily figure out where these things should be done. One thing for sure. DDR will be initialized only in UBL and it will not be re-initialized again in U-Boot and Linux. Also, if you are not using NAND boot mode, NAND will not be initialized in UBL and U-Boot.

Both U-Boot and Linux are generic enough to support majority of NAND parts. You may end up adding support for your NAND part only in UBL.

Regards,

Sudhakar

Hi Andrew,

I have some tips too and a few posts about using a new NAND, and DDR.  Although for our DDR we tried to choose one that had the same addressing scheme so that not much would have to be changed.

1.  The nand_flash_writer.out will most likely need to be updated.  The version I had did not have my NAND id and the default parameters were not correct for my Nand.  My nand also had 5 address writes instead of the default of 4.  This was fairly obvious to correct.  The main files we looked at were: davincihd_nandflash_id.c, davincihd_nandflash.c

2.  In the UBL, we noticed that it was not initializing SDTIM0 and SDTIM1 correctly but that the default values from POR on were correct.  So we changed platform.asm to maintain the default values instead of the values from TI.  And also we had to add the 5th address writer in nand.c.  To be sure also, we changed the NAND_NOT_FOUND defaults to match our NAND as well.

3.  In uboot_git, we found that we did not have the same NAND problems as will nand flash writer and UBL.  It seemed to have more flexibilty in recognizing NANDs.

Here are the posts I had about choosing the right devices.  Might be a good reference. 

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/96174.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/96523.aspx

http://e2e.ti.com/support/embedded/f/354/t/128587.aspx

Please feel free to "friend me" if you get stuck and would like to go into more details not publically.  I will do what I can to help.

Good luck!

Brandy

Thank you both!  You sent me down a productive path.  Here are my findings, and further questions.  Please correct me if I went wrong anywhere, and let me know if I overlooked anything.

1. I hadn't even thought about the UBL and U-boot writing utilities.  Our NAND chip does use 5 address write cycles.  I have been using sfh_DM646x.exe tool to write UBL and U-boot to NAND, since our custom board will have a UART interface, but no JTAG interface.  A quick look at the code leads me to believe it will dynamically choose between 4 and 5 address write cycles(DM646x/Common/drivers/src/nand.c).  It also looks like A1CR (a.k.a ABCR, AB1CR, ACFGx) is set to 0x3FFFFFFC.  In other words, it sets all timing parameters to the maximum, supposedly in order to be compatible with any NAND chip out there. (DM646x/Common/src).  Has anyone had success using sfh_DM646x.exe with 5 address write cycle flash?  This tool is described on the TI wiki: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility 

2a (DDR) In the DM6467T UBL source code from DVSDK 3.10.00,SDTIM0 and SDTIM1 are configured for 297MHz DDR2. (src/platform.asm) The DM6467T EVM uses 400MHz DDR2, running at 396MHz.  Are these settings actually compatible, or are they being overwritten somewhere else, or was the UBL binary posted on the DVSDK 3.10 download page generated from different source code?  I downloaded the UBL source code from flash-utils-dm646x.tar.gz at http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_3_10/latest/index_FDS.html. 

2b (NAND) This version of the UBL source code already has support for 4 and 5 byte address write cycles.  (src/nand.c: NANDWritePage())  As for timing, UBL sets register A1CR (a.k.a AB1CR and ACFGx) to 0x3FFFFFFC, the most conservative and compatible setting.

3a (U-boot). That's a relief.  In digging through the U-boot code and the Linux code, I found that much of the NAND code is identical between the two.  It looks like they both accommodate 4 and 5 address write cycles.  In U-boot, ACFGx is set to the actual timings of the DM644x EVM, in the DM644x configuration.  In the DM6467T configuration, the ACFGx register is never touched, and so remains at whatever it was set to in UBL.  In my case: 0x3FFFFFFC.  This is good for compatibility, but might slow things down if anyone cared how fast NAND opeartions happened fin U-boot.

3b (Linux). Linux NAND timings are set in arch/arm/mach-davinci/board-dm646x-evm.c, in the evm_nand_flash_timing struct.  These values are in units of ns, NOT emif clock cycles.  The conversion is done in aemif.c. 

4. Can UBL be compiled in CCSv5 under Linux?  I tried to import the project using Project->Import Legacy CCSv3.3 Project, but it failed.  If not, what versions of CCS can it be compiled with? 

2a.  Did anyone ever get to the bottom of this?  I verified that the old settings are being used on the DM6467T by reading the register, ruling out the explanation that the released binary was generated from different source code.  The board really runs on values calculated for a different system.  Is the DDR interface that flexible, or did we just luck out that all the differences erred on the side of extra time?

4. I was able to compile UBL in CCSv5.  CCSv5 doesn't support importing CCSv2 projects, so I had to recreate the project and piece together the options by reading the text of the .pjt file.  See details here: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/146081.aspx