I see you have relaxed most timing to the slowest. Debugging DDR is not about trial and error because there are so many parameters. Could you get some guidance from hardware designers? If you can't, I suggest you get the spec and do the math yourself, using the DDR driver we have in u-boot. BTW, your TIMING_CFG_2 seems to be fast. I don't know if that would cause any issue. Your mode register also seems suspicious.
York
On 10/28/2013 05:01 AM, Ashish Khetan wrote:
I disabled the 2nd core by using "cfg_core1_enable" and D2_MSRCID1 signal is not connected and we are using DDR controller 2... will this create any obstacles to relocate? Is there any other register configuration for DDR? can somebody help me to understand this or give me some pointer to get more understanding for this... I am getting frusted because I am stuck at this point from last 20 days. please help... thanks in advance and Regards
On Sat, Oct 26, 2013 at 12:20 AM, Ashish Khetan <curieux.khetan@gmail.com mailto:curieux.khetan@gmail.com> wrote:
Thanks For reply, i check DDR configuration using Code warrior, and successfully getting read/write from DDR. I use the following configuration in code warrior and same in u-boot... writemem.l 0xf8006000 0x0000001f # CS0_BNDS writemem.l 0xf8006080 0x80914102 # CS0_CONFIG writemem.l 0xf8006100 0x00070000 # TIMING_CFG_3 writemem.l 0xf8006104 0xFF770F0F # TIMING_CFG_0 writemem.l 0xf8006108 0x7F78F777 # TIMING_CFG_1 writemem.l 0xf800610C 0x00205114 # TIMING_CFG_2 writemem.l 0xf8006110 0x43088008 # DDR_SDRAM_CFG writemem.l 0xf8006114 0x24401000 # DDR_SDRAM_CFG2 writemem.l 0xf8006118 0x43800E52 # DDR_SDRAM_MODE writemem.l 0xf800611C 0x8000C000 # DDR_SDRAM_MODE_2 writemem.l 0xf8006120 0x00000000 # DDR_SDRAM_MD_CNTL writemem.l 0xf8006124 0x05080000 # DDR_SDRAM_INTERVAL writemem.l 0xf8006128 0x00000000 # DDR_DATA_INIT writemem.l 0xf8006130 0x03800000 # DDR_SDRAM_CLK_CNTL sleep 200 writemem.l 0xf8006110 0xC3088008 # DDR_SDRAM_CFG but I did not understand... can you give some light on this. thanks again... On Fri, Oct 25, 2013 at 10:25 PM, York Sun <yorksun@freescale.com <mailto:yorksun@freescale.com>> wrote: It is probably because your DDR wasn't initialized correctly. You can try to dump all DDR registers and check if anyone is suspicious. You can also override any register before enabling the controller. You may also add some memory test before relocation. York On 10/25/2013 06:38 AM, Ashish Khetan wrote: > hii I am using MPC8641D based custom board for evaluation purpose. I am > using minimal configuration for this board i.e. only FLASH and DDR > initialisation. when I compiled U-boot in debug mode its printing > addresses, i check for those addresses and found that it is unable to > relocate itself to DDR(4*MT47H64M16). The following message was printed... > > U-Boot 2013.04 (Oct 25 2013 - 15:05:33) > > Unicore software on multiprocessor system!! > To enable mutlticore build define CONFIG_MP > CPU: 8641, Version: 2.1, (0x80900021) > Core: E600 Core 0 (MSSCR0=8000, PORDEVSR=ab08307), Version: 2.2, > (0x80040202) > Clock Configuration: > CPU:800 MHz, MPX:400 MHz > DDR:200 MHz (400 MT/s data rate), LBC:25 MHz > L1: D-cache 32 KB enabled > I-cache 32 KB enabled > L2: Disabled > Board: Wind River SBC8641D > DRAM: DDR: 512 MiB > Top of RAM usable for U-Boot at: 20000000 > Reserving 114k for U-Boot at: 1ffe3000 > Reserving 136k for malloc() at: 1ffc1000 > Reserving 80 Bytes for Board Info at: 1ffc0fb0 > Reserving 152 Bytes for Global Data at: 1ffc0f18 > Stack Pointer at: 1ffc0f00 > New Stack Pointer is: 1ffc0f00 > > and stuck here... > > Any pointer or link to get more about this will be helpful. > Thanks in Advance > > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de> > http://lists.denx.de/mailman/listinfo/u-boot >