[U-Boot] U-Boot Crashes with Dumps
Hi all!
I begin use U-Boot at my custom board based on ppc440x5.
Here is Mem Info that we are using on board:
16MB Nor flash with base address 0xfc000000 512MB DDR with base addr 0x00000000 256kb ISRAM with base addr 0xc0000000
TEXT_BASE 0xfffc0000
Tlb entries for board is: tlbentry( 0xff000000, SZ_16M, 0xff000000, 0, AC_R|AC_X|AC_W) ------Flash tlbentry( 0xc0000000, SZ_256K, 0xc0000000, 0, AC_R|AC_W|AC_X|SA_I) ------ISRAM tlbentry( 0x00000000, SZ_256M, 0x00000000, 0, AC_R|AC_W|AC_X|SA_I|SA_G) ------DDR tlbentry( 0x10000000, SZ_256M, 0x10000000, 0, AC_R|AC_W|AC_X|SA_I|SA_G) ------DDR
I am trying to get a clean build of U-Boot to run on the PPC440x5 based customized board. I have the latest versions U-Boot. The system executes through board_init_f( ) without any problems, and gets into board_init_r( ). The console output is as follows:
512 MB (ECC is ON, 400 MHz, CL 7) Top of RAM usable for U-Boot at: 20000000 Reserving 170k for U-Boot at: 1ffd5000 Reserving 1040k for malloc() at: 1fed1000 Reserving 128 Bytes for Board Info at: 1fed0f80 Reserving 64 Bytes for Global Data at: 1fed0f40 Stack Pointer at: 1fed0f28 New Stack Pointer is: 1fed0f28 relocate addr_sp = 1fed0f28, id = 1fed0f40, addr = 1ffd5000
Now running in RAM - U-Boot at: 1ffd5000
NIP: 1FFD7764 XER: 00000000 LR: 1FFD7764 REGS: 1fed0e20 TRAP: 0200 DEAR: FFED0F18 MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD7338 1FED0F10 1FED0F40 1FFD5000 1FFD88E0 00000000 00000000 1FFD7764 GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00 20015000 GPR16: 00000000 00000000 00000000 00000000 48FF2422 00000610 00002C20 00000000 GPR24: 00000000 1FED0F40 1FFD5000 1FED5000 1FED0F80 1FFD5000 20002B10 1FED1000 Call backtrace: 1FFD88D8 1FFD76D8 00000000 machine check
Here I am trying to use backtrace to debug but system is waiting at folloing console o/p.
[root@u-boot]$ cp ../../11dec_rec/u-boot/backtrace . [root@u-boot]$backtrace System.map 0xdffeb000 Reading symbols from System.map Using Address Offset 0xdffeb000
Please help me on this.
Regards, Anup B.
On Tuesday 12 January 2010 08:02:51 anupbehare@gmail.com wrote:
I begin use U-Boot at my custom board based on ppc440x5.
What kind of PPC4xx ist this? PPC440EPx?
Here is Mem Info that we are using on board:
16MB Nor flash with base address 0xfc000000 512MB DDR with base addr 0x00000000 256kb ISRAM with base addr 0xc0000000
TEXT_BASE 0xfffc0000
Tlb entries for board is: tlbentry( 0xff000000, SZ_16M, 0xff000000, 0, AC_R|AC_X|AC_W) ------Flash tlbentry( 0xc0000000, SZ_256K, 0xc0000000, 0, AC_R|AC_W|AC_X|SA_I) ------ISRAM tlbentry( 0x00000000, SZ_256M, 0x00000000, 0, AC_R|AC_W|AC_X|SA_I|SA_G) ------DDR tlbentry( 0x10000000, SZ_256M, 0x10000000, 0, AC_R|AC_W|AC_X|SA_I|SA_G) ------DDR
I am trying to get a clean build of U-Boot to run on the PPC440x5 based customized board. I have the latest versions U-Boot. The system executes through board_init_f( ) without any problems, and gets into board_init_r( ). The console output is as follows:
512 MB (ECC is ON, 400 MHz, CL 7) Top of RAM usable for U-Boot at: 20000000 Reserving 170k for U-Boot at: 1ffd5000 Reserving 1040k for malloc() at: 1fed1000 Reserving 128 Bytes for Board Info at: 1fed0f80 Reserving 64 Bytes for Global Data at: 1fed0f40 Stack Pointer at: 1fed0f28 New Stack Pointer is: 1fed0f28 relocate addr_sp = 1fed0f28, id = 1fed0f40, addr = 1ffd5000
Now running in RAM - U-Boot at: 1ffd5000
NIP: 1FFD7764 XER: 00000000 LR: 1FFD7764 REGS: 1fed0e20 TRAP: 0200 DEAR: FFED0F18 MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD7338 1FED0F10 1FED0F40 1FFD5000 1FFD88E0 00000000 00000000 1FFD7764 GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00 20015000 GPR16: 00000000 00000000 00000000 00000000 48FF2422 00000610 00002C20 00000000 GPR24: 00000000 1FED0F40 1FFD5000 1FED5000 1FED0F80 1FFD5000 20002B10 1FED1000 Call backtrace: 1FFD88D8 1FFD76D8 00000000 machine check
When U-Boot crashes/hangs upon relocation to SDRAM, you most likely have a problem with your SDRAM configuration. Again, which CPU are you using? How is the SDRAM connected (DIMM or onboard). I suggest you check your SDRAM controller setup again.
Here I am trying to use backtrace to debug but system is waiting at folloing console o/p.
[root@u-boot]$ cp ../../11dec_rec/u-boot/backtrace . [root@u-boot]$backtrace System.map 0xdffeb000 Reading symbols from System.map Using Address Offset 0xdffeb000
This link might help:
http://www.denx.de/wiki/DULG/DebuggingUBoot
Especially chapter 10.1.2. Debugging of U-Boot After Relocation.
Cheers, 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
In my case CONFIG_SYS_MONITOR_LEN is 256KB and CONFIG_SYS_MONITOR_BASE is 0xfffc0000 my destaddr is 0x1ffd5000
so gd->reloc_off = destaddr - CONFIG_SYS_MONITOR_BASE; so gd->reloc_off = 0x20015000 also gd->malloc = 0x1fed1000
After that it continuously restarts with error machine check exception.
Is that mean ram initialization is not done or some thing with reloc_off as it is going in -ve.
On 12-Jan-2010 12:56pm, Stefan Roese sr@denx.de wrote:
On Tuesday 12 January 2010 08:02:51 anupbehare@gmail.com wrote:
I begin use U-Boot at my custom board based on ppc440x5.
What kind of PPC4xx ist this? PPC440EPx?
Here is Mem Info that we are using on board:
16MB Nor flash with base address 0xfc000000
512MB DDR with base addr 0x00000000
256kb ISRAM with base addr 0xc0000000
TEXT_BASE 0xfffc0000
Tlb entries for board is:
tlbentry( 0xff000000, SZ_16M, 0xff000000, 0, AC_R|AC_X|AC_W) ------Flash
tlbentry( 0xc0000000, SZ_256K, 0xc0000000, 0, AC_R|AC_W|AC_X|SA_I)
------ISRAM
tlbentry( 0x00000000, SZ_256M, 0x00000000, 0, AC_R|AC_W|AC_X|SA_I|SA_G)
------DDR
tlbentry( 0x10000000, SZ_256M, 0x10000000, 0, AC_R|AC_W|AC_X|SA_I|SA_G)
------DDR
I am trying to get a clean build of U-Boot to run on the PPC440x5 based
customized board. I have the latest versions U-Boot.
The system executes through board_init_f( ) without any problems, and
gets
into board_init_r( ). The console output is as follows:
512 MB (ECC is ON, 400 MHz, CL 7)
Top of RAM usable for U-Boot at: 20000000
Reserving 170k for U-Boot at: 1ffd5000
Reserving 1040k for malloc() at: 1fed1000
Reserving 128 Bytes for Board Info at: 1fed0f80
Reserving 64 Bytes for Global Data at: 1fed0f40
Stack Pointer at: 1fed0f28
New Stack Pointer is: 1fed0f28
relocate addr_sp = 1fed0f28, id = 1fed0f40, addr = 1ffd5000
Now running in RAM - U-Boot at: 1ffd5000
NIP: 1FFD7764 XER: 00000000 LR: 1FFD7764 REGS: 1fed0e20 TRAP: 0200 DEAR:
FFED0F18
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD7338 1FED0F10 1FED0F40 1FFD5000 1FFD88E0 00000000 00000000
1FFD7764
GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00
20015000
GPR16: 00000000 00000000 00000000 00000000 48FF2422 00000610 00002C20
00000000
GPR24: 00000000 1FED0F40 1FFD5000 1FED5000 1FED0F80 1FFD5000 20002B10
1FED1000
Call backtrace:
1FFD88D8 1FFD76D8 00000000
machine check
When U-Boot crashes/hangs upon relocation to SDRAM, you most likely have a
problem with your SDRAM configuration. Again, which CPU are you using? How is
the SDRAM connected (DIMM or onboard). I suggest you check your SDRAM
controller setup again.
Here I am trying to use backtrace to debug but system is waiting at
folloing console o/p.
[root@u-boot]$ cp ../../11dec_rec/u-boot/backtrace .
[root@u-boot]$backtrace System.map 0xdffeb000
Reading symbols from System.map
Using Address Offset 0xdffeb000
This link might help:
Especially chapter 10.1.2. Debugging of U-Boot After Relocation.
Cheers,
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
On Tuesday 12 January 2010 10:09:57 anupbehare@gmail.com wrote:
In my case CONFIG_SYS_MONITOR_LEN is 256KB and CONFIG_SYS_MONITOR_BASE is 0xfffc0000 my destaddr is 0x1ffd5000
so gd->reloc_off = destaddr - CONFIG_SYS_MONITOR_BASE; so gd->reloc_off = 0x20015000 also gd->malloc = 0x1fed1000
After that it continuously restarts with error machine check exception.
Is that mean ram initialization is not done or some thing with reloc_off as it is going in -ve.
Again, I strongly suspect problems in your SDRAM configuration. You didn't provide any answers to my questions: Why CPU type are you using? Are you using a DIMM or soldered SDRAM? Which SDRAM setup code are you using?
Cheers, 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 am using PPC440GX and DIMM SDRAM.
On 12-Jan-2010 3:20pm, Stefan Roese sr@denx.de wrote:
On Tuesday 12 January 2010 10:09:57 anupbehare@gmail.com wrote:
In my case CONFIG_SYS_MONITOR_LEN is 256KB
and CONFIG_SYS_MONITOR_BASE is 0xfffc0000
my destaddr is 0x1ffd5000
so gd->reloc_off = destaddr - CONFIG_SYS_MONITOR_BASE;
so gd->reloc_off = 0x20015000
also gd->malloc = 0x1fed1000
After that it continuously restarts with error machine check exception.
Is that mean ram initialization is not done or some thing with
reloc_off as
it is going in -ve.
Again, I strongly suspect problems in your SDRAM configuration. You didn't
provide any answers to my questions: Why CPU type are you using? Are you using
a DIMM or soldered SDRAM? Which SDRAM setup code are you using?
Cheers,
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
On Tuesday 12 January 2010 11:07:13 anupbehare@gmail.com wrote:
I am using PPC440GX and DIMM SDRAM.
OK, so you are using the code cpu/ppc4xx/44x_spd_ddr.c to configure the SDRAM controller. You should enable DEBUG in this code to see a bit more about the configuration.
BTW: I suggest you take a look at the ocotea SDRAM config options set in include/configs/ocotea.h. You should for example set CONFIG_PROG_SDRAM_TLB and then remove the SDRAM TLB entries from your init.S.
Cheers, 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
participants (2)
-
anupbehare＠gmail.com -
Stefan Roese