Help!Some memory doesn't work on PPC405Ex based board!

Help!Some memory doesn't work on PPC405Ex based board!

[SunNeo]

[-- Attachment #1: Type: text/plain, Size: 4739 bytes --]


Hi, All,
I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC "Kilauea" evb.

 

In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot Linux-2.6.29, the kernel hangs somewhere. What interesting is, if I configured the system to use only 512MB memory at U-Boot, the Linux can boot normally.

 

The following is some error info I dumped:

 

<6>Using Kilauea machine description
<5>Linux version 2.6.29.1 (root@localhost.localdomain) (gcc version 4.2.2) #4 Mon Apr 13 19:26:57 CST 2009
<4>Found initrd at 0xeedaa000:0xeffff8f3
<7>Found legacy serial port 0 for /plb/opb/serial@ef600200
<7>  mem=ef600200, taddr=ef600200, irq=0, clk=7407407, speed=0
<7>Found legacy serial port 1 for /plb/opb/serial@ef600300
<7>  mem=ef600300, taddr=ef600300, irq=0, clk=7407407, speed=0
<7>Top of RAM: 0x40000000, Total RAM: 0x40000000
<7>Memory hole size: 0MB
<4>Zone PFN ranges:
<4>  DMA      0x00000000 -> 0x00030000
<4>  Normal   0x00030000 -> 0x00030000
<4>  HighMem  0x00030000 -> 0x00040000
<4>Movable zone start PFN for each node
<4>early_node_map[1] active PFN ranges
<4>    0: 0x00000000 -> 0x00040000
<7>On node 0 totalpages: 262144
<7>free_area_init_node: node 0, pgdat c03304a0, node_mem_map c07fd000
<7>  DMA zone: 1536 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 195072 pages, LIFO batch:31
<7>  HighMem zone: 512 pages used for memmap
<7>  HighMem zone: 65024 pages, LIFO batch:15
<6>MMU: Allocated 1088 bytes of context maps for 255 contexts
<4>Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
<5>Kernel command line: ramdisk_size=65536 root=/dev/ram rw ip=10.204.29.214:10.204.29.153:10.204.28.1:255.255.252.0:obs600:eth0:off panic=1 console=ttyS0,115200
<4>UIC0 (32 IRQ sources) at DCR 0xc0
<4>UIC1 (32 IRQ sources) at DCR 0xd0
<4>UIC2 (32 IRQ sources) at DCR 0xe0
<4>PID hash table entries: 4096 (order: 12, 16384 bytes)
<7>time_init: decrementer frequency = 400.000000 MHz
<7>time_init: processor frequency   = 400.000000 MHz
<6>clocksource: timebase mult[a00000] shift[22] registered
<7>clockevent: decrementer mult[6666] shift[16] cpu[0]
<6>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
<6>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
<7>High memory: 262144k
<6>Memory: 1016784k/1048576k available (3136k kernel code, 31244k reserved, 136k data, 140k bss, 144k init)
<6>SLUB: Genslabs=10, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440)
<4>Mount-cache hash table entries: 512
<4>Instruction machine check in kernel mode.
<4>Oops: Machine check, sig: 7 [#1]
<4>Kilauea
<4>Modules linked in:
<4>NIP: c000c63c LR: c000eb44 CTR: ee82a000
<4>REGS: eeda7f50 TRAP: 0202   Not tainted  (2.6.29.1)
<4>MSR: 00021030 <ME,CE,IR,DR>  CR: 90029030  XER: c0000060
<4>TASK = ee82a3e0[2] 'kthreadd' THREAD: ee82e000
<6>GPR00: 3ffa80dc 3ffae128 ee82a3e0 3ffae138 88000000 00000000 00000000 c023d0ac 
<6>GPR08: c0342e54 c000eb44 00021032 c000c63c c035d000 00000000 3ffb2f00 00000000 
<6>GPR16: 3ffa80dc 3ffae1e8 00000000 00000000 00000000 00000000 00000000 00000000 
<6>GPR24: c03153d0 ee82ffb8 c00350f4 c031544c c0315458 ee82df08 c00350f4 ee82dee4 
<4>NIP [c000c63c] program_check_exception+0x0/0x59c
<4>LR [c000eb44] ret_from_except_full+0x0/0x4c
<4>Call Trace:
<4>Instruction dump:
<4>3920000b 409eff88 4bffff90 813f0080 7fe3fb78 39290004 913f0080 80010014 
<4>83e1000c 7c0803a6 38210010 4bffff14 <9421ffe0> 7c0802a6 7d800026 bfc10018 
<4>---[ end trace 31fd0ba7d8756001 ]---
<4>Oops: Exception in kernel mode, sig: 4 [#2]
<4>Kilauea
<4>Modules linked in:
<4>NIP: ee82ff80 LR: ee82ffb0 CTR: ee82a000
<4>REGS: ee835f50 TRAP: c03153d0   Tainted: G      D     (2.6.29.1)
<4>MSR: c0312318 <FP,DE,DR>  CR: 00029030  XER: c02368e0
<4>TASK = ee82a7c0[3] 'kthreadd' THREAD: ee834000
<6>GPR00: 3ffa80dc ee836000 ee82a7c0 00000000 ee82ffb0 00029030 00000000 ee82ff80 
<6>GPR08: c0312318 00000000 00000000 c0312318 c033b260 00000000 3ffb2f00 00000000 
<6>GPR16: 3ffa80dc 3ffae1e8 00000000 00000000 00000000 00000000 00000000 00000000 
<6>GPR24: c03153d0 ee82ffb8 c00350f4 c031544c c0315458 ee82df08 c00350f4 ee82dee4 
<4>NIP [ee82ff80] 0xee82ff80
<4>LR [ee82ffb0] 0xee82ffb0
<4>Call Trace:
<4>Instruction dump:
<4>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX 
<4>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX 
<4>---[ end trace 31fd0ba7d8756002 ]---

 

Please help,

 

Best Regards,

Sun

 

_________________________________________________________________
Messenger安全保护中心，免费修复系统漏洞，保护Messenger安全！
http://im.live.cn/safe/

[-- Attachment #2: Type: text/html, Size: 5970 bytes --]

Re: Help!Some memory doesn't work on PPC405Ex based board!

[Stefan Roese]

On Monday 13 April 2009, SunNeo wrote:
> I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC
> "Kilauea" evb.
>
> In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex
> CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot
> Linux-2.6.29, the kernel hangs somewhere.

Does it just hang "somewhere", or always at the same location? A random hangup 
could mean that you are having a memory problem (hardware, or wrong 
initialization).

> What interesting is, if I 
> configured the system to use only 512MB memory at U-Boot, the Linux can
> boot normally.

Are you using DIMM's on your platform? Or soldered chips? Which memory 
initialization code are you using in U-Boot? And which autocalibration code?

Did you do some intensive memory test?

Best regards,
Stefan

RE: Help!Some memory doesn't work on PPC405Ex based board!

[SunNeo]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]


Hi, Stefan,

 

Thanks for your help.

 

My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is soldered on the board.


As I said, my board was similar with "Kilauea" evb, so I created my configuration header file from Kilauea's at U-Boot. In the configuration file, register value for the DDR SDRAM controller is defined. But I have removed DDR autocalibraton related configuration from the configuration file, do you think this will cause any issues?

 

I'm not sure what you mean about "intensive memory test". I use "mm" cmd under U-Boot command prompt to modify value of high 512M memory, and this command works well.

 

About booting Linux, the kernel hangs at the same location. Always after this print info "<4>Mount-cache hash table entries: 512".


Best Regards,

Sun

 
> From: sr@denx.de
> To: linuxppc-dev@ozlabs.org
> Subject: Re: Help!Some memory doesn't work on PPC405Ex based board!
> Date: Tue, 14 Apr 2009 11:23:02 +0200
> CC: sunwx2001@hotmail.com
> 
> On Monday 13 April 2009, SunNeo wrote:
> > I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC
> > "Kilauea" evb.
> >
> > In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex
> > CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot
> > Linux-2.6.29, the kernel hangs somewhere.
> 
> Does it just hang "somewhere", or always at the same location? A random hangup 
> could mean that you are having a memory problem (hardware, or wrong 
> initialization).
> 
> > What interesting is, if I 
> > configured the system to use only 512MB memory at U-Boot, the Linux can
> > boot normally.
> 
> Are you using DIMM's on your platform? Or soldered chips? Which memory 
> initialization code are you using in U-Boot? And which autocalibration code?
> 
> Did you do some intensive memory test?
> 
> Best regards,
> Stefan

_________________________________________________________________
打工，挣钱，买房子，快来MClub一起”金屋藏娇”！
http://club.msn.cn/?from=10

[-- Attachment #2: Type: text/html, Size: 2469 bytes --]

Re: Help!Some memory doesn't work on PPC405Ex based board!

[Stefan Roese]

Hi Sun,

On Tuesday 14 April 2009, SunNeo wrote:
> My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM
> is soldered on the board.
>
> As I said, my board was similar with "Kilauea" evb, so I created my
> configuration header file from Kilauea's at U-Boot. In the configuration
> file, register value for the DDR SDRAM controller is defined. But I have
> removed DDR autocalibraton related configuration from the configuration
> file, do you think this will cause any issues?

Yes, this could definitely cause some SDRAM related problems. But this is 
off-topic here. We should continue this discussion on the U-Boot mailing list 
instead (on CC). So please when you reply to this mail, remove the 
linuxppc-dev list from the recipients list.

Best regards,
Stefan

Re: Help!Some memory doesn't work on PPC405Ex based board!

[Grant Erickson]

On 4/14/09 4:08 AM, SunNeo wrote:
> My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is
> soldered on the board.
> 
> As I said, my board was similar with "Kilauea" evb, so I created my
> configuration header file from Kilauea's at U-Boot. In the configuration file,
> register value for the DDR SDRAM controller is defined. But I have removed DDR
> autocalibraton related configuration from the configuration file, do you think
> this will cause any issues?

Sun:

Does your board have ECC? While it seems like simply following the static,
non-auto-calibrating configuration of the Kilauea or Haleakala board would
be sufficient, my experience is that it is not, especially if your design
has ECC.

Should you decide to escalate the issue with AMCC, I suspect
auto-calibration will be the first thing they ask you to enable and re-check
your design with.

Per Stefan's comments, unless you use an intensive and comprehensive memory
test of some sort, just running u-boot is not necessarily a sufficient
validation that memory works as it, in many configurations, touches and uses
little of the overall RAM during its operation.

Regards,

Grant

Re: Help!Some memory doesn't work on PPC405Ex based board!

[Feng Kan]

Hi SunNeo:

The fact that it is hanging at the same place in kernel seems strange.
Usually when dram initialization is incorrect,
the kernel would not run at all. Uboot just hangs at relocate code. I
suggest you turn on early kernel printf to see
if you get some other outputs.

P.S when you have discrete memory on board. you have to be sure that
your calibration values are correct. The RDCC
RQDC value should be best possible. You can run the fix initialization
and then lift the autocalibration routine
to the end of the fix dram init to determine the best RFDC RQDC windows.
After that recode the fix values for those
registers.

Feng Kan
AMCC Software

SunNeo wrote:
> Hi, Stefan,
>  
> Thanks for your help.
>  
> My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is soldered on the board.
>
> As I said, my board was similar with "Kilauea" evb, so I created my configuration header file from Kilauea's at U-Boot. In the configuration file, register value for the DDR SDRAM controller is defined. But I have removed DDR autocalibraton related configuration from the configuration file, do you think this will cause any issues?
>  
> I'm not sure what you mean about "intensive memory test". I use "mm" cmd under U-Boot command prompt to modify value of high 512M memory, and this command works well.
>  
> About booting Linux, the kernel hangs at the same location. Always after this print info "<4>Mount-cache hash table entries: 512".
>
> Best Regards,
> Sun
>  
>   
>> From: sr@denx.de
>> To: linuxppc-dev@ozlabs.org
>> Subject: Re: Help!Some memory doesn't work on PPC405Ex based board!
>> Date: Tue, 14 Apr 2009 11:23:02 +0200
>> CC: sunwx2001@hotmail.com
>>
>> On Monday 13 April 2009, SunNeo wrote:
>>     
>>> I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC
>>> "Kilauea" evb.
>>>
>>> In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex
>>> CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot
>>> Linux-2.6.29, the kernel hangs somewhere.
>>>       
>> Does it just hang "somewhere", or always at the same location? A random hangup 
>> could mean that you are having a memory problem (hardware, or wrong 
>> initialization).
>>
>>     
>>> What interesting is, if I 
>>> configured the system to use only 512MB memory at U-Boot, the Linux can
>>> boot normally .
>>>       
>> Are you using DIMM's on your platform? Or soldered chips? Which memory 
>> initialization code are you using in U-Boot? And which autocalibration code?
>>
>> Did you do some intensive memory test?
>>
>> Best regards,
>> Stefan
>>     
>
>
>   _____  
>
> 把MSN装进手机，更多聊天乐趣等你挖掘！ 立刻下载！ <http://mobile.msn.com.cn/> 
>
>