Re: [U-Boot] Help!Some memory doesn't work on PPC405Ex based board!
Feng Kan, Stefan and Grant,
Thanks for all your suggestion.
I tried to add auto-calibration related configuration to my configuation file, but Linux still hangs at the same location. It seems error happened when threads of Linux Kernel tried to access the high 512m memory.
Just like the Kilauea evb, there is no ECC on my board, and I use the same regisger setting for DDR Controller as Kilauea. Maybe you know, Kilauea uses the "MT47H64M16HR" DDRII SDRAM and only one rank. My board uses the "MT47H256M8THN" and two ranks. So, I changed setting of MB0CF & MB1CF.
I think I can confirm all 1024M memory can work well at U-Boot. And if I add the parameter "mem=512M" to bootargs, and set "initrd_high" to "20000000", Linux can boot normally.
Best Regards,
Sun
Date: Tue, 14 Apr 2009 09:30:46 -0700 From: fkan@amcc.com To: sunwx2001@hotmail.com CC: support@amcc.com; linuxppc-dev@ozlabs.org Subject: Re: Help!Some memory doesn't work on PPC405Ex based board!
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/
_________________________________________________________________ 打工，挣钱，买房子，快来MClub一起”金屋藏娇”！ http://club.msn.cn/?from=10
Sun,
On Wednesday 15 April 2009, SunNeo wrote:
I tried to add auto-calibration related configuration to my configuation file, but Linux still hangs at the same location. It seems error happened when threads of Linux Kernel tried to access the high 512m memory.
I suggest you debug this further, either by adding some printk's or using a debugger to see where exactly the crash happens.
Just like the Kilauea evb, there is no ECC on my board, and I use the same regisger setting for DDR Controller as Kilauea. Maybe you know, Kilauea uses the "MT47H64M16HR" DDRII SDRAM and only one rank. My board uses the "MT47H256M8THN" and two ranks. So, I changed setting of MB0CF & MB1CF.
When using the 2nd rank you need to change the termination settings as well (SDRAM0_MODT0, SDRAM_MODT1, SDRAM0_CODT). Using the original values from Kilauea is definitely a problem which could lead to all kind of problems.
I think I can confirm all 1024M memory can work well at U-Boot.
Again, you don't really know if the whole memory is working correctly just because you are able to boot to the U-Boot prompt. Intensive memory tests (with and without burst access) are necessary here.
And if I add the parameter "mem=512M" to bootargs, and set "initrd_high" to "20000000", Linux can boot normally.
Understood. I still think that this is a problem with incorrect SDRAM configuration. Take a look at the termination registers mentioned above and configure them correctly.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist.
The following is a summary of my job:
1. My board combines 4 Hynix H5PS2G83AFR (256MB * 8bits) to make a 1GB memory, use only one 1 rank, no ECC. 2. My board is similar to AMCC Kilauea EVB. For U-Boot-2009.01, I created my configuration file from Kilauea's, and remove Nand flash, FPGA related configuration. 3. For DDR SDRAM controller, I use same configuration as Kilauea's, memory size (MB0CF) excepted. Have enabled auto-calibration. 4. Have performed memory test with "mtest" command at U-Boot, no error happened. 5. There is no PCI device on my board. U-Boot hangs when it perform PCI scan. So I remove all PCI related configuration from my configuration file at U-Boot. 6. I use "kilauea_defconfig" to compile Linux-2.6.25. Also, I disabled Nand Flash and PCI from "menuconfig". 7. To boot my Linux, I use Kilauea's dtb file directly. I have to keep PCIE node in this dtb file, because my Ethernet port will not work well without this PCIE node. 8. Use the 1GB memory to boot Linux, an error info "Kernel stack overflow in process ee8153e0, r1=ee82bfa0" is reported, and kernel hangs. 9. Add the parameter "mem=516M" to bootargs, Linux can boot up normally. But if add "mem=517M" to bootargs, Linux hangs.
The following is error info dumped during Linux Boot:
## Transferring control to Linux (at address 00000000) ... Booting using OF flat tree... id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit Using Kilauea machine description Linux version 2.6.25-rc2-00492-g8adfc2c (root@localhost.localdomain) (gcc versio n 4.2.2) #2 Wed Apr 22 14:15:31 CST 2009 Found initrd at 0xeedaa000:0xeffff8f3 Found legacy serial port 0 for /plb/opb/serial@ef600200 mem=ef600200, taddr=ef600200, irq=0, clk=7407407, speed=0 Found legacy serial port 1 for /plb/opb/serial@ef600300 mem=ef600300, taddr=ef600300, irq=0, clk=7407407, speed=0 console [udbg0] enabled Entering add_active_range(0, 0, 196608) 0 entries of 256 used setup_arch: bootmem arch: exit Top of RAM: 0x30000000, Total RAM: 0x30000000 Memory hole size: 0MB Zone PFN ranges: DMA 0 -> 196608 Normal 196608 -> 196608 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 196608 On node 0 totalpages: 196608 DMA zone: 1536 pages used for memmap DMA zone: 0 pages reserved DMA zone: 195072 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 195072 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 n oflashcfg=1 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 UIC2 (32 IRQ sources) at DCR 0xe0 PID hash table entries: 4096 (order: 12, 16384 bytes) time_init: decrementer frequency = 600.000000 MHz time_init: processor frequency = 600.000000 MHz clocksource: timebase mult[6aaaab] shift[22] registered clockevent: decrementer mult[9999] shift[16] cpu[0] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 757504k/786432k available (2804k kernel code, 28764k reserved, 108k data , 88k bss, 132k init) SLUB: Genslabs=10, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay loop... 1196.03 BogoMIPS (lpj=2392064) Mount-cache hash table entries: 512 Kernel stack overflow in process ee8153e0, r1=ee82bfa0 NIP: c02e0000 LR: ee82bfb0 CTR: ee8153e0 REGS: ee82bef0 TRAP: ee82bfb0 Not tainted (2.6.25-rc2-00492-g8adfc2c) MSR: fffffffb <EE,PR,FP,ME,IR,DR> CR: 00029030 XER: c0016c3c TASK = ee8153e0[2] 'kthreadd' THREAD: ee82a000 GPR00: 00000078 ee82bfa0 ee8153e0 00800711 ee82bf20 ffffffff ffffffff ffffffff GPR08: c02e3b30 ee815408 c02e3b30 c02e3b00 ee82bf40 ffffffff c02e3b00 00000000 GPR16: ee8153e0 ee815408 c02e3b30 c02e3b00 ee82bf60 c0016398 3ffb0648 c02e2a7c GPR24: 00000078 ee8153e0 c02e3b00 ee8153e0 ee82bf80 c0015260 3ffb0648 c02e2a7c NIP [c02e0000] exception_stack_bottom+0x0/0x1000 LR [ee82bfb0] 0xee82bfb0 Call Trace: [ee82bfa0] [ee8153e0] 0xee8153e0 (unreliable) [ee82bfb0] [c0032d80] kthreadd+0x38/0x164 [ee82bff0] [c000d460] kernel_thread+0x44/0x60 Kernel panic - not syncing: kernel stack overflow Rebooting in 1 seconds..<0>System Halted, OK to turn off power
Best Regards
Sun
From: sr@denx.de To: sunwx2001@hotmail.com Subject: Re: Help!Some memory doesn't work on PPC405Ex based board! Date: Wed, 15 Apr 2009 10:08:40 +0200 CC: fkan@amcc.com; gerickson@nuovations.com; support@amcc.com; u-boot@lists.denx.de
Sun,
On Wednesday 15 April 2009, SunNeo wrote:
I tried to add auto-calibration related configuration to my configuation file, but Linux still hangs at the same location. It seems error happened when threads of Linux Kernel tried to access the high 512m memory.
I suggest you debug this further, either by adding some printk's or using a debugger to see where exactly the crash happens.
Just like the Kilauea evb, there is no ECC on my board, and I use the same regisger setting for DDR Controller as Kilauea. Maybe you know, Kilauea uses the "MT47H64M16HR" DDRII SDRAM and only one rank. My board uses the "MT47H256M8THN" and two ranks. So, I changed setting of MB0CF & MB1CF.
When using the 2nd rank you need to change the termination settings as well (SDRAM0_MODT0, SDRAM_MODT1, SDRAM0_CODT). Using the original values from Kilauea is definitely a problem which could lead to all kind of problems.
I think I can confirm all 1024M memory can work well at U-Boot.
Again, you don't really know if the whole memory is working correctly just because you are able to boot to the U-Boot prompt. Intensive memory tests (with and without burst access) are necessary here.
And if I add the parameter "mem=512M" to bootargs, and set "initrd_high" to "20000000", Linux can boot normally.
Understood. I still think that this is a problem with incorrect SDRAM configuration. Take a look at the termination registers mentioned above and configure them correctly.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
_________________________________________________________________ 打工，挣钱，买房子，快来MClub一起”金屋藏娇”！ http://club.msn.cn/?from=10
On 4/22/09 10:00 PM, SunNeo wrote:
I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist.
The following is a summary of my job:
- Have performed memory test with "mtest" command at U-Boot, no error happened.
Sun:
It's been awhile since I looked at the code for mtest; however, it may not be entirely comprehensive or exhaustive depending on how you configured your u-boot build and the arguments you invoked it with. Do verify that it is operating over the largest range of RAM possible and that it is doing an array of tests (walking 1s, alternating bit patterns, etc.).
Also, AMCC has available (perhaps available through your FAE if not on MyAMCC or AMCC.com itself) a DDR planning spreadsheet. While the last revision I used had a few bugs, it certainly was useful to validate our DDR configuration against. I'd recommend obtaining it and reviewing your settings.
Beyond that, does the same kernel work on Kilauea? Have you set up a build environment where you can make small, incremental changes and verify those on Kilauea and then on your board and have confidence that only those things you changed are changing?
Once the wrinkles got worked out of the DDR settings in the PPC405EX[r] boards I've worked with in the last year, they all worked as well as Kilauea without notable changes to the Linux kernel, version 2.6.25 up through 2.6.28 (all from the Denx GIT repository).
- Add the parameter "mem=516M" to bootargs, Linux can boot up normally. But
if add "mem=517M" to bootargs, Linux hangs.
That should be instructive. Start tweaking mtest or writing your own memory tests to tease out a pattern from that. Failing that, what other values work here? What values fail?
Regards,
Grant Erickson Principal Nuovations
Sun,
On Thursday 23 April 2009, Grant Erickson wrote:
On 4/22/09 10:00 PM, SunNeo wrote:
I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist.
The following is a summary of my job:
- Have performed memory test with "mtest" command at U-Boot, no error happened.
Sun:
It's been awhile since I looked at the code for mtest; however, it may not be entirely comprehensive or exhaustive depending on how you configured your u-boot build and the arguments you invoked it with. Do verify that it is operating over the largest range of RAM possible and that it is doing an array of tests (walking 1s, alternating bit patterns, etc.).
Take a look at the mem test included in the POST framework (post/drivers/memory.c). This should be more extensive.
<snip>
- Add the parameter "mem=516M" to bootargs, Linux can boot up normally.
But if add "mem=517M" to bootargs, Linux hangs.
That should be instructive. Start tweaking mtest or writing your own memory tests to tease out a pattern from that. Failing that, what other values work here? What values fail?
And I'm wondering why you are using such an old Linux kernel version. I suggest to at least test a recent arch/powerpc version. Perhaps this gives other results.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Have performed a slow memory post using code in post/drivers/memory.c, still no error. I found memsize in post/driver/memory.c has a limit of 256MB, so I modify it to 1024M.
Have tried Linux-2.6.29, same result.
Best Regards,
Sun
From: sr@denx.de To: sunwx2001@hotmail.com Subject: Re: Help!Some memory doesn't work on PPC405Ex based board! Date: Thu, 23 Apr 2009 10:07:41 +0200 CC: gerickson@nuovations.com; fkan@amcc.com; support@amcc.com; u-boot@lists.denx.de
Sun,
On Thursday 23 April 2009, Grant Erickson wrote:
On 4/22/09 10:00 PM, SunNeo wrote:
I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist.
The following is a summary of my job:
- Have performed memory test with "mtest" command at U-Boot, no error
happened.
Sun:
It's been awhile since I looked at the code for mtest; however, it may not be entirely comprehensive or exhaustive depending on how you configured your u-boot build and the arguments you invoked it with. Do verify that it is operating over the largest range of RAM possible and that it is doing an array of tests (walking 1s, alternating bit patterns, etc.).
Take a look at the mem test included in the POST framework (post/drivers/memory.c). This should be more extensive.
<snip>
- Add the parameter "mem=516M" to bootargs, Linux can boot up normally.
But if add "mem=517M" to bootargs, Linux hangs.
That should be instructive. Start tweaking mtest or writing your own memory tests to tease out a pattern from that. Failing that, what other values work here? What values fail?
And I'm wondering why you are using such an old Linux kernel version. I suggest to at least test a recent arch/powerpc version. Perhaps this gives other results.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
_________________________________________________________________ Live Search视频搜索，快速检索视频的利器！ http://www.live.com/?scope=video
On Thursday 23 April 2009, SunNeo wrote:
Have performed a slow memory post using code in post/drivers/memory.c, still no error.
Another idea: Did you also try using DDR autocalibration method A? Standard is method B but A takes a lot longer. (See the Method_A and Method_B algorithm discription in the file cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c). Perhaps this gives some further results.
I found memsize in post/driver/memory.c has a limit of 256MB, so I modify it to 1024M.
Have tried Linux-2.6.29, same result.
Hmmm. You should perhaps try to debug further where exactly this error is occurring. Via printk's or JTAG debugger. If this error always happens at the same location it could perhaps be located (if it's not a memory problem) in the kernel source code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan and Grant,
I have made some progess, Linux can boot normally with 1 GB memory now. The following is what I did: 1.Chang "Maximum low memory size" from 0x30000000(768M) to 0x20000000(512M) and enable High Memory support for Linux kernel configuration. 2.Add "CONFIG_VERY_BIG_RAM" to U-Boot configuration file, or change U-Boot Env. variable "initrd_high" from 0x30000000 to 0x20000000. This step is to make sure Linux can find ramdisk and I don't think it's critical for my issue.
Now, my question is do you think I have found root cause of my issue? I mean incorrect setting of "Maximum low memory size".
Best Regards,
Sun
From: sr@denx.de To: u-boot@lists.denx.de Subject: Re: [U-Boot] Help!Some memory doesn't work on PPC405Ex based board! Date: Thu, 23 Apr 2009 11:55:35 +0200 CC: sunwx2001@hotmail.com; support@amcc.com; gerickson@nuovations.com
On Thursday 23 April 2009, SunNeo wrote:
Have performed a slow memory post using code in post/drivers/memory.c, still no error.
Another idea: Did you also try using DDR autocalibration method A? Standard is method B but A takes a lot longer. (See the Method_A and Method_B algorithm discription in the file cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c). Perhaps this gives some further results.
I found memsize in post/driver/memory.c has a limit of 256MB, so I modify it to 1024M.
Have tried Linux-2.6.29, same result.
Hmmm. You should perhaps try to debug further where exactly this error is occurring. Via printk's or JTAG debugger. If this error always happens at the same location it could perhaps be located (if it's not a memory problem) in the kernel source code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
_________________________________________________________________ 上Windows Live 中国首页，下载最新版Messenger！ http://www.windowslive.cn
participants (3)
-
Grant Erickson -
Stefan Roese -
SunNeo