[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Sam Song]

-- Wolfgang Denk <wd@denx.de> wrote:
> > Thanks. Actually, it involves the grey area which
> > a probelm was supposed to produce by hardware or 
> > software. The golden role is to check SW first.
> 
> You must be one of these hardware guys who always
> blame the software.

Firmware guys is better to me. I amn't willing to 
be an native HW fellow although I come from HW 
field. To blame right is my hope. SW is only one
side:-)

[snip]
> We've seen lots of "funny" problems with the many
> boards we lay hands on. Three more things to check:
> 
> * Check the voltages on your system: tolerances ok?
> spikes  or  other noise on the lines? especially 
> close to the CPU?
> * Check the clocks. Check the clocks again.
> * check for unconnected pins, missing pull-ups or
> -downs, or incorrect resistor values

Ummm, this is really what I want. It seems I should
look back more to take case HW side:-)

Thanks so much,

Sam

_________________________________________________________
Do You Yahoo!?
150??MP3????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/
???????????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com
1G??1000???????????
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Clemens Koller]

Hi, Sam!

As Wolfgang said, check the voltages, caps, terminations...

You might also try to actively lower/rise the voltages of
your board/ram/... a bit. If your problem changes, I would
bet it's a hardware problem.

Greets,

Clemens

Sam Song wrote:
> -- Wolfgang Denk <wd@denx.de> wrote:
> 
>>>Thanks. Actually, it involves the grey area which
>>>a probelm was supposed to produce by hardware or 
>>>software. The golden role is to check SW first.
>>
>>You must be one of these hardware guys who always
>>blame the software.
> 
> 
> Firmware guys is better to me. I amn't willing to 
> be an native HW fellow although I come from HW 
> field. To blame right is my hope. SW is only one
> side:-)
> 
> [snip]
> 
>>We've seen lots of "funny" problems with the many
>>boards we lay hands on. Three more things to check:
>>
>>* Check the voltages on your system: tolerances ok?
>>spikes  or  other noise on the lines? especially 
>>close to the CPU?
>>* Check the clocks. Check the clocks again.
>>* check for unconnected pins, missing pull-ups or
>>-downs, or incorrect resistor values
> 
> 
> Ummm, this is really what I want. It seems I should
> look back more to take case HW side:-)
> 
> Thanks so much,
> 
> Sam
> 

-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Thomas Kastner]

Hello Sam,

cooler spray might help find the cause, too.
For example I once had a similar problem that looked like a SDRAM
problem. In the end I found out that the oscillator sourcing the CPU's
PLL input was a little weak and the CPU's internal PLL sometimes went
crazy, causing this strange behaviour. Cooler spray on the oscillator
marginally raised the slew rate and the system ran stable.

Check the clocks, especially termination.

If you have any chance to reduce the SDRAM clock rate, try that. Maybe
by changing dividers in software or replacing a hardware oscillator.

Generally speaking cooler spray has saved me a lot of time finding the
cause of timing problems, so this really might be worth a try.

Kind regards,
Thomas

Clemens Koller wrote:
> Hi, Sam!
> 
> As Wolfgang said, check the voltages, caps, terminations...
> 
> You might also try to actively lower/rise the voltages of
> your board/ram/... a bit. If your problem changes, I would
> bet it's a hardware problem.
> 
> Greets,
> 
> Clemens
> 
> Sam Song wrote:
> 
>>-- Wolfgang Denk <wd@denx.de> wrote:
>>
>>
>>>>Thanks. Actually, it involves the grey area which
>>>>a probelm was supposed to produce by hardware or 
>>>>software. The golden role is to check SW first.
>>>
>>>You must be one of these hardware guys who always
>>>blame the software.
>>
>>
>>Firmware guys is better to me. I amn't willing to 
>>be an native HW fellow although I come from HW 
>>field. To blame right is my hope. SW is only one
>>side:-)
>>
>>[snip]
>>
>>
>>>We've seen lots of "funny" problems with the many
>>>boards we lay hands on. Three more things to check:
>>>
>>>* Check the voltages on your system: tolerances ok?
>>>spikes  or  other noise on the lines? especially 
>>>close to the CPU?
>>>* Check the clocks. Check the clocks again.
>>>* check for unconnected pins, missing pull-ups or
>>>-downs, or incorrect resistor values
>>
>>
>>Ummm, this is really what I want. It seems I should
>>look back more to take case HW side:-)
>>
>>Thanks so much,
>>
>>Sam
>>
> 
> 


-- 
Thomas Kastner
Dipl.-Ing. (FH)
Entwicklung Hard- und Software

MarekMicro GmbH
Fuggerstr. 9
D-92224 Amberg

Tel:   +49 96 21 / 97 32 - 124
Fax:   +49 96 21 / 97 32 - 199
eMail: thomas.kastner at marekmicro.de
http://www.marekmicro.de

PGP: http://pgpkeys.pca.dfn.de/pks/lookup?search=0xA197D41B

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Sam Song]

Thomas Kastner <thomas.kastner@marekmicro.de> wrote:
[snip]
> Generally speaking cooler spray has saved me a lot
> of time finding the cause of timing problems, so 
> this really might be worth a try.

Thanks. Good idea to try.

> Clemens Koller wrote:
[snip]
> > You might also try to actively lower/rise the
> > voltages of your board/ram/... a bit. If your 
> > problem changes, I would bet it's a hardware 
> > problem.

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Sam Song]

Scott McNutt <smcnutt@psyent.com> wrote:
> > Just wanna to confirm one thing. If one board's 
> > SDRAM init was good enough but with poor layout
> > (Layout design or PCB Processing), it would crash
> > like this?
> 
> Yes, if your clock signals were not routed cleanly
> ... but re-check your SDRAM init first.

Thanks. Actually, it involves the grey area which a 
probelm was supposed to produce by hardware or 
software. The golden role is to check SW first.

[snip]
> The good part is that u-boot remains stable (due to
> some handy design decisions) ... and the POST cache
> tests are a great starting point to determine if the
> problem exists ... in a deterministic manner ;-)

Really a nice explanation and experience share. 

I have been thinking one puzzle related u-boot itself.
I noticed that sometimes u-boot would hang after 
relocation on my board. The chance is slim but have 
an effect on normal operation. Maybe 1 out of 10 
times. Especially when power down and on in a short 
interval like no more than 1 minute. I don't know 
whether this symptom is due to SDRAM init problem.

My wild guess is some elements like capacitances 
don't discharge enough to restore the original state
they should be. 

U-Boot 1.0.0 (Aug 20 2004 - 21:11:30)
&nbsp;
CPU: PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB Cache
Board: DMTXX
DRAM:  128 MB 

Code reached to relocate_code()->board_init_r().
Stoped before flash_init().

Does anyone encounter such a problem? Ideas?

Thanks in advance,

Sam

_________________________________________________________
Do You Yahoo!?
150??MP3????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/
???????????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com
1G??1000???????????
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Wolfgang Denk]

In message <20050525083355.6524.qmail@web15904.mail.cnb.yahoo.com> you wrote:
>
> Thanks. Actually, it involves the grey area which a 
> probelm was supposed to produce by hardware or 
> software. The golden role is to check SW first.

You must be one of these hardware guys who always blame the software.
I hope you have your asbestos ready in case you need them soon ;-)


> I have been thinking one puzzle related u-boot itself.
> I noticed that sometimes u-boot would hang after 
> relocation on my board. The chance is slim but have 
> an effect on normal operation. Maybe 1 out of 10 
> times. Especially when power down and on in a short 
> interval like no more than 1 minute. I don't know 
> whether this symptom is due to SDRAM init problem.

This is one of the possible reasons.

> Does anyone encounter such a problem? Ideas?

We've seen lots of "funny" problems with the many boards we lay hands
on. Three more things to check:

* Check the voltages on your system: tolerances ok? spikes  or  other
  noise on the lines? especially close to the CPU?
* Check the clocks. Check the clocks again.
* check for unconnected pins, missing pull-ups or -downs, or incorrect
  resistor values



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... The things love can drive a man to -- the  ecstasies,  the  mise-
ries,  the broken rules, the desperate chances, the glorious failures
and the glorious victories.
	-- McCoy, "Requiem for Methuselah", stardate 5843.7

[U-Boot-Users] uboot 1.1.2 problem

[Jerry Van Baren]

Your SDRAM configuration is wrong or your board layout doesn't support 
the faster speeds.

FAQ:
http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation

gvb


Yigit Can wrote:
> 
> 
> Hello,
> 
> We have recently ported uboot1.1.2 to our propriatery mpc852T board in 
> 50 Mhz and it works fine.
> 
> but in 100Mhz version of the same board, the linux crashes with output 
> below. We are only changing the CONFIG_8XX_CPUCLK_DEFAULT 50000000 to 
> 100000000 with the mptpr value to ensure refresh cycles of the sdram.
> 
> we have adjusted the refresh timing of the sdram to 12.5 us successfully 
> but the linux keeps crashing. We have also tried the different versions 
> of the eldk but it keeps crashing at the same place. The board passes 
> from the dram test in uboot.
> 
> we using micron 48lc4m32b2-7 as 2 banks. Can upm ram array cause 
> problems like these or
> 
> Where can be the problem ? If you can help we will be very appriciate.
> 
> Thank you.
> 
> Best Regards
> Yi?it Can
> 
> 
> output :
> 
> 
> U-Boot (1.1.2) (May 23 2005 - 14:34:07)
> 
> CPU:   MPC852TxxZPnn at 100 MHz [40.0...133.0 MHz]
>       4 kB I-Cache 4 kB D-Cache FEC present
> Board: MPC852T (Rev:ABA)
> DRAM:  32 MB
> Testing DRAM from 0x00000000 to 0x02000000
> DRAM test phase 1:
> DRAM test phase 2:
> DRAM test passed.
> Top of RAM usable for U-Boot at: 02000000
> Reserving 510k for U-Boot at: 01f80000
> Reserving 1024k for malloc() at: 01e80000
> Reserving 60 Bytes for Board Info at: 01e7ffc4
> Reserving 52 Bytes for Global Data at: 01e7ff90
> Stack Pointer at: 01e7ff78
> New Stack Pointer is: 01e7ff78
> Now running in RAM - U-Boot at: 01f80000
> FLASH:
> ## Get flash bank 1 size @ 0x40000000
> Manuf. ID @ 0x40000000: 0x00010001
> Manufacturer: AMD
> Device ID @ 0x40000004: 0x227e227e
> Chip: AMLV320MT
> ## Prelim. Flash bank size: 00800000
> ## Before remap: BR0: 0x40000001    OR0: 0xe00005f0
> ## BR0: 0x40000001    OR0: 0xff8005f0
> Manuf. ID @ 0x40000000: 0x00010001
> Manufacturer: AMD
> Device ID @ 0x40000004: 0x227e227e
> Chip: AMLV320MT
> Protect monitor: 40000000 ... 4007b1ff
> flash_protect ON: from 0x40000000 to 0x4007B1FF
> protect on 0
> protect on 1
> protect on 2
> protect on 3
> Protect primary   environment: 40020000 ... 4003ffff
> flash_protect ON: from 0x40020000 to 0x4003FFFF
> protect on 1
> Protect redundand environment: 40040000 ... 4005ffff
> flash_protect ON: from 0x40040000 to 0x4005FFFF
> protect on 2
> 8 MB
> In:    serial
> Out:   serial
> Err:   serial
> Reset Ethernet PHY
> U-Boot relocated to 01f80000
> Net:   FEC ETHERNET
> 
> Type "run flash_nfs" to mount root filesystem over NFS
> 
> ### main_loop entered: bootdelay=3
> 
> ### main_loop: bootcmd="run netboot"
> Hit any key to stop autoboot:  0
> Trying FEC ETHERNET
> Using FEC ETHERNET device
> TFTP from server 192.168.2.54; our IP address is 192.168.2.127
> Filename 'pImage'.
> Load address: 0x100000
> Loading: #################################################################
>         ###############################################
> done
> Bytes transferred = 571491 (8b863 hex)
> Trying FEC ETHERNET
> Using FEC ETHERNET device
> TFTP from server 192.168.2.54; our IP address is 192.168.2.127
> Filename 'pRamdisk'.
> Load address: 0x200000
> Loading: #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         ###########################################
> done
> Bytes transferred = 2549563 (26e73b hex)
> ## Booting image at 00100000 ...
>   Image Name:   Linux-2.4.4
>   Created:      2005-05-03  11:22:39 UTC
>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>   Data Size:    571427 Bytes = 558 kB
>   Load Address: 00000000
>   Entry Point:  00000000
>   Verifying Checksum ... OK
>   Uncompressing Kernel Image ... OK
> ## Current stack ends at 0x01E7F948 => set upper limit to 0x00800000
> ## cmdline at 0x007FFF00 ... 0x007FFF4D
> bd address  = 0x01E7FFC4
> memstart    = 0x00000000
> memsize     = 0x02000000
> flashstart  = 0x40000000
> flashsize   = 0x00800000
> flashoffset = 0x0007B200
> sramstart   = 0x00000000
> sramsize    = 0x00000000
> immr_base   = 0xFFF00000
> bootflags   = 0x00000001
> intfreq     =    100 MHz
> busfreq     =     50 MHz
> ethaddr     = AA:BB:CC:DD:EE:FF
> IP addr     = 192.168.2.127
> baudrate    = 115200 bps
> ## Loading RAMDisk Image at 00200000 ...
>   Image Name:   Application ramdisk image
>   Created:      2005-05-10   7:13:09 UTC
>   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>   Data Size:    2549499 Bytes =  2.4 MB
>   Load Address: 00000000
>   Entry Point:  00000000
>   Verifying Checksum ... OK
> ## initrd at 0x00200040 ... 0x0046E73A (len=2549499=0x26E6FB)
>   Loading Ramdisk to 01c10000, end 01e7e6fb ... OK
> ## Transferring control to Linux (at address 00000000) ...
> Linux version 2.4.4 (root at suse) (gcc version 2.95.4 20010319 
> (prerelease/franzo/20011204)) #173 Tue May 3 14:22:20 EEST 2005
> On node 0 totalpages: 8192
> zone(0): 8192 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: ip=192.168.2.127:192.168.2.54:192.168.2.200::::off 
> panic=1 ramdisk_size=9000k
> Decrementer Frequency: 6250000
> Calibrating delay loop... 99.73 BogoMIPS
> Oops: kernel access of bad area, sig: 11
> NIP: C002B764 XER: 00002E00 LR: C002B758 SP: C014DF40 REGS: c014de90 
> TRAP: 0300
> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: C004F2E8, DSISR: 82000000
> TASK = c014c020[0] 'swapper' Last syscall: 0
> last math 00000000 last altivec 00000000
> GPR00: 81630009 C014DF40 C014C020 00000001 00009032 001AA000 C0170000 
> 00000000
> GPR08: 00010000 00000028 00000000 FFFFFFFF FFFFFFFF 00004000 01FFAA00 
> 007FFF4D
> GPR16: 00000001 00000000 007FFF00 01FFACD8 00000000 FFFFFFFF 01E7FC10 
> 00000003
> GPR24: E2E26C18 007FFEC0 01A079F4 00000000 0340F3E9 C004F308 C004F2E0 
> FFFFFFFF
> Call backtrace:
> 007FFEC0 C002C190 C015ED70 C015EF94 C015D5E4 C015C6D4 C00021E4
> Kernel panic: Attempted to kill the idle task!
> In idle task - not syncing
> Rebooting in 1 seconds..
> 
> 
> 

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Sam Song]

Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
wrote:

> Your SDRAM configuration is wrong or your board
> layout doesn't support the faster speeds.

Just wanna to confirm one thing. If one board's 
SDRAM init was good enough but with poor layout
(Layout design or PCB Processing), it would crash
like this? Could it boot after relocation? 

I know my assumption isn't reasonable. Well, I have
a similar experience on 823. That board could only
get the output before relocation in u-boot. Never 
for booting Linux. After a fix on some pull-ups 
around CPU and good PCB processing, it worked fine.

So I can make sure one thing. Not all crash after 
relocation is due to SDRAM init. That's just our 
software engineer/developer can do. Perhaps it is 
related with mini error on schematic design or PCB 
layout including processing. 

A little bit out of topic. Sorry for this:-)

Sam 

_________________________________________________________
Do You Yahoo!?
150??MP3????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/
???????????????????
http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com
1G??1000???????????
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Scott McNutt]

>>Your SDRAM configuration is wrong or your board
>>layout doesn't support the faster speeds.
> 
> Just wanna to confirm one thing. If one board's 
> SDRAM init was good enough but with poor layout
> (Layout design or PCB Processing), it would crash
> like this?

Yes, if your clock signals were not routed cleanly
... but re-check your SDRAM init first.

I experienced a similar problem that was caused by
the phase difference between CLKIN and the SDRAM
clock that only occurred during 8-beat burst write
cycles. In many designs there are only two things
that generate these cycles: the CPM during (burst)
writes to SDRAM, and the CPU during a dcache flush.

Since u-boot normally doesn't run with the data
cache enabled, and u-boot usually puts buffers in
the CPM shared memory (rather than SDRAM) ... you
won't see any errors ... until after the kernel
enables the data cache.

The bad part is that the data error occurs during
the write (dcache writing a line), but the kernel
crashes after reloading the (corrupted) cache line
(e.g. - reading in a pointer that was corrupted).
So it's _very_ difficult to observe this problem
when the kernel boots.

The good part is that u-boot remains stable (due to
some handy design decisions) ... and the POST cache
tests are a great starting point to determine if the
problem exists ... in a deterministic manner ;-)

Regards,
--Scott

BTW: We ended up dropping in a PLL so we could
adjust the clock phase as needed.