From mboxrd@z Thu Jan 1 00:00:00 1970 From: anupbehare at gmail.com Date: Tue, 12 Jan 2010 09:09:57 +0000 Subject: [U-Boot] U-Boot Crashes with Dumps In-Reply-To: <201001120826.31712.sr@denx.de> Message-ID: <0016e68ee3e493c943047cf4040b@google.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 wrote: > On Tuesday 12 January 2010 08:02:51 anupbehare at 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 at u-boot]$ cp ../../11dec_rec/u-boot/backtrace . > > [root at 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 at denx.de