[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