[U-Boot-Users] u-boot hangs after relocating itself to ram

[Jerry Van Baren]

Andre Puschmann wrote:
> Wolfgang Denk wrote:
>> In message <ekhurb$vvk$1 at sea.gmane.org> you wrote:
>>
>>> I have ported u-boot to a custom board based on a freescale mpc5200. I
>>> can successfully copy u-boot into flash using the connected bdi2000 and
>>> we get some output on the debug port. It seems that the board crashes
>>> right after relocation to ram (see output). I already
>>> read the regarding faq entry but I'm not sure if this problem has
>>> something to do with faulty sdram initialization.
>> Guess why the FAQ is there?
>>
>>> Can this be a sdram related problem or what might cause this behavior?
>> Please re-read the FAQ.
>>
>>> Any comments and suggestions are more than welcome.
>> The FAQ is based on (a)  a  lot  of  experience  and  (b)  a  lot  of
>> questions from engineers who've been there before you. Don't ignore
>> it.
> 
> Hello,
> I really admire the experience of all those engineers and don't wanna
> spam the list.
> I read the FAQ many times and double-checked the sdram initialization as
> well as compared it with other code.
> 
> But I still didn't find the problem and I'm still hanging at this point.
> 
> Are there any other configuration parts that are necessary to know at
> this point of u-boot loading?
> 
> 
> here is the dram init-code I'm using:
> <code>
> #define SDRAM_MODE 0x00CD0000 /* burst_len = 8, cas = 3, wrt_str set */
> #define SDRAM_CONTROL 0x504F0000
> #define SDRAM_CONFIG1 0x62322900
> #define SDRAM_CONFIG2 0x88C70004
> 
> /* configure SDRAM start/end */
> *(vu_long *)MPC5XXX_SDRAM_CS0CFG = 0x00000016;  /* 8MB at 0x00000000 */
> *(vu_long *)MPC5XXX_SDRAM_CS1CFG = 0x00000000;	/* disabled */
> 
> /* setup config registers */
> *(vu_long *)MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
> *(vu_long *)MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;
> 
> /* unlock mode register */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN);
> 
> /* precharge all banks */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_PRE);
> 
> /* set mode register */
> *(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
> 
> /* precharge all banks */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL | MODE_EN | SOFT_REF;
> 
> /* auto refresh */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = (SDRAM_CONTROL | MODE_EN | SOFT_REF);
> 
> /* set mode register */
> *(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
> 
> /* normal operation */
> *(vu_long *)MPC5XXX_SDRAM_CTRL = SDRAM_CONTROL;
> </code>
> 
> 
>> Best regards,
>>
>> Wolfgang Denk
>>
> 
> Thanks for your help.
> 
> 
> Andre

Is the instruction that is crashing correct?  When you dump the 
equivalent location in flash, is that same exact instruction there?  If 
you look at the offending location in SDRAM with your debugger, do you 
see the same instruction as when it crashes?  (Debuggers tend to read 
memory slowly, so it may read the right value where an instruction fetch 
may misread the value.)

If it is a SDRAM problem, the answer to the above questions will likely 
be "no" - this is indicating SDRAM has been corrupted.  This could be 
due to an initialization problem, but could be a flaky board (layout 
problems).  Can you run your board at a slower clock rate?

If the culprit instruction is identical in flash, it is very likely a 
configuration/code issue, not a SDRAM initialization or board layout issue.

gvb