[U-Boot-Users] A question about sdram_init

Wolfgang Denk wd at denx.de
Fri May 14 01:39:04 CEST 2004

In message <BAY2-F154cU2MvLbqer00014ec9 at hotmail.com> you wrote:
> >I guess this is on a MIPS64 system? Or ARM9? Or x86, or what?
> I am using PPC405 on a custom board, similiar as WALNUT.

Frank, frankly: you must learn to give us some  more  information  if
you expect useful replies.

> > > 1. The sdram() hanged after 2nd line, i.e. after set up 4MB. But it 
> >didn't
> > > go through 3rd line and didn't return.

For example, until now you didn't bother to tell us which source file
you are talking about. or what are the characteristics of your board.
"similiar as WALNUT"? This doesn't mean anything.

> I don't have a debugger. But I do have LEDs on the board, so I simply use 

Get a debugger, so you can  singlestep,  check  register  and  memory
contents, etc.

> >How do you know your code is correct?
> I didn't write any code. All these three lines were in original 
> sdram_init(). Original sdram_init() tried to detect sdram with different 

Which source file  are  you  talking  about?  cpu/ppc4xx/sdram.c?  or
cpu/ppc4xx/spd_sdram.c? or what?

> BTW, I commented out udelay(200). But I don't think it will have any affect.

Why did you do that? RAM chips may have a power  on  delay.  Did  you
read the RAM manufacturer's users manual?

> My doubt is the first line:
> /*1st*/ mtsdram0(mem_mcopt1, 0x00000000);
> It disabled the memory controller. Will this cause any memory problem?

Obviously not, as it seems to be working fine on a  couple  of  other
PPC systems.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"There is nothing new under the sun, but there are lots of old things
we don't know yet."                                  - Ambrose Bierce

More information about the U-Boot mailing list