Re: [U-Boot-Users] A question about sdram_init
In message BAY2-F150B8F0GuRQm600014934@hotmail.com you wrote:
To explain the problem easier, I stripped down the sdram_init() to three
DCR
instructions:
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.
- The sdram() hanged after 2nd line, i.e. after set up 4MB. But it
didn't
go through 3rd line and didn't return.
How did you know where it hangs? Did you use a debugger?
I don't have a debugger. But I do have LEDs on the board, so I simply use LEDs to indicate where the program stops. I turn on a yellow LED right before the 2nd line and a green LED right after the 2nd line. Yellow LED was turned on but nothing happened to green one.
I am using IOC to control LED. The code to control LED is pretty simple. For example, to turn on yellow LED: lis 20, 0xF0000030@h ori 20, 20, 0xF0000030@l li21, 0xC0 stb 21, 0(20)
I have been using this LED control for a while. Never got any problem with it.
- If the 1st line is commented, i.e. not disable everything, sdram()
could
return.
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 size. I have 8MB SDRAM on my board, so I just eliminated all the code for 128M, 64M, ..., but keep the code for 4M SDRAM. The codes left only have three lines: void sdram(void) { /*1st*/ mtsdram0(mem_mcopt1, 0x00000000); /*2nd*/ mtsdram0(mem_mb0cf, 0x00008001); /*3rd*/ mtsdram0(mem_mcopt1, 0x80800000); return; }
BTW, I commented out udelay(200). But I don't think it will have any affect.
- Since sdram() is called from start.S, I rewrote all these code in
start.S
in assembly language and let them run in start.S (commented out "bl sdram_init"), these three lines can run without any problem. They didn't interfere each other.
There is no difference between C code and assembly - unless you wrote different code.
That is why I am confused... ;*(
My doubt is the first line: /*1st*/ mtsdram0(mem_mcopt1, 0x00000000);
It disabled the memory controller. Will this cause any memory problem?
Thanks! Frank
_________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/
In message BAY2-F154cU2MvLbqer00014ec9@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.
- 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
participants (2)
-
Frank Young -
Wolfgang Denk