* [U-Boot] U-Boot Crashes with Dumps
@ 2010-01-12 7:02 anupbehare at gmail.com
2010-01-12 7:26 ` Stefan Roese
0 siblings, 1 reply; 15+ messages in thread
From: anupbehare at gmail.com @ 2010-01-12 7:02 UTC (permalink / raw)
To: u-boot
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 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
Please help me on this.
Regards,
Anup B.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-12 7:02 [U-Boot] U-Boot Crashes with Dumps anupbehare at gmail.com
@ 2010-01-12 7:26 ` Stefan Roese
2010-01-12 9:09 ` anupbehare at gmail.com
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Roese @ 2010-01-12 7:26 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-12 7:26 ` Stefan Roese
@ 2010-01-12 9:09 ` anupbehare at gmail.com
2010-01-12 9:50 ` Stefan Roese
0 siblings, 1 reply; 15+ messages in thread
From: anupbehare at gmail.com @ 2010-01-12 9:09 UTC (permalink / raw)
To: u-boot
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 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-12 9:09 ` anupbehare at gmail.com
@ 2010-01-12 9:50 ` Stefan Roese
2010-01-12 10:07 ` anupbehare at gmail.com
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Roese @ 2010-01-12 9:50 UTC (permalink / raw)
To: u-boot
On Tuesday 12 January 2010 10:09:57 anupbehare at 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 at denx.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-12 9:50 ` Stefan Roese
@ 2010-01-12 10:07 ` anupbehare at gmail.com
2010-01-12 10:20 ` Stefan Roese
0 siblings, 1 reply; 15+ messages in thread
From: anupbehare at gmail.com @ 2010-01-12 10:07 UTC (permalink / raw)
To: u-boot
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 at 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 at denx.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-12 10:07 ` anupbehare at gmail.com
@ 2010-01-12 10:20 ` Stefan Roese
0 siblings, 0 replies; 15+ messages in thread
From: Stefan Roese @ 2010-01-12 10:20 UTC (permalink / raw)
To: u-boot
On Tuesday 12 January 2010 11:07:13 anupbehare at 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 at denx.de
^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <001636d351d9aa42b7047d069e1b@google.com>]
* [U-Boot] U-Boot Crashes with Dumps
[not found] <001636d351d9aa42b7047d069e1b@google.com>
@ 2010-01-13 7:38 ` Stefan Roese
2010-01-13 17:43 ` anupbehare at gmail.com
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Roese @ 2010-01-13 7:38 UTC (permalink / raw)
To: u-boot
[Please keep the list on Cc]
On Wednesday 13 January 2010 08:21:32 anupbehare at gmail.com wrote:
> I am using denali controller.
> Here we can not use 44x_spd_ddr.c as registers are complitly different, so
> we have implemented sdram.c for doing specific initialization...
This seems wrong. You are using the 440GX *and* the Denali SDRAM core? The
440GX doesn't use the Denali SDRAM controller. Only the 440EPx/GRx use Denali.
Please explain what you are doing here.
> We have done ddr training, which was successfully completed I think that
> means DDR initialization is proper.
What exactly do you mean with "ddr training"? DDR setup is complex stuff. Many
things can go wrong here.
> But when the control enter into board_init_r() we get machine check
> exception and u-boot is in continuously reboot mode.
If you are sure that your SDRAM setup is correct, then you need to debug where
exactly this crash happens. Either use the JTAG debugger (BDI2000/3000) or add
printf's. But I still suspect SDRAM problems.
> after that we are not able to access the flash with Crack monkey tool to
> flash the u-boot binary .
"Crack monkey tool"? What's that? You should be able to access the FLASH again
after resetting the CPU.
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [U-Boot] U-Boot Crashes with Dumps
2010-01-13 7:38 ` Stefan Roese
@ 2010-01-13 17:43 ` anupbehare at gmail.com
2010-01-14 7:30 ` Stefan Roese
0 siblings, 1 reply; 15+ messages in thread
From: anupbehare at gmail.com @ 2010-01-13 17:43 UTC (permalink / raw)
To: u-boot
I am using board having ppc440x5 core with customized chip and not a
standard 440Gx.
Board is using Denali controller, as the register are completely different
we can not use the standard u-boot initialization.
We performed board specific initialization and training for DDR2.
When the code enter into board_init_r() console shows following messages:
Top of RAM usable for U-Boot at: 20000000
Reserving 178k for U-Boot at: 1ffd3000
Reserving 1040k for malloc() at: 1fecf000
Reserving 128 Bytes for Board Info at: 1fecef80
Reserving 64 Bytes for Global Data at: 1fecef40
New Stack Pointer is: 1fecef28
Now running in RAM - U-Boot at: 1ffd3000
Bus Fault @ 0x1ffd5764, fixup 0x00000000
Machine Check Exception.
NIP: 1FFD5764 XER: 00000000 LR: 1FFD5764 REGS: 1fecee20 TRAP: 0200 DEAR:
00000000
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 1FFD5338 1FECEF10 1FECEF40 1FFD3000 1FFD6814 00000034 00000034
1FFD5764
GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00
20013000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
GPR24: 00000000 1FECEF40 1FFD3000 1FED3000 1FFD3000 1FECEF80 20002B10
20013000
Call backtrace:
1FFD680C 1FFD56D8 A462C4EC
machine check
We tried to debug it with BDI as per steps given @
http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
We have verified by using BDI that uboot code is placed in DDR, but getting
an exception and u-boot is in continuously reboot mode.
Will it ok if we disable the MSR for ME,EE,CE? Or still it looks DDR
initialization issue ?
~Anup B
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-13 17:43 ` anupbehare at gmail.com
@ 2010-01-14 7:30 ` Stefan Roese
2010-01-14 9:39 ` anupbehare at gmail.com
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Roese @ 2010-01-14 7:30 UTC (permalink / raw)
To: u-boot
On Wednesday 13 January 2010 18:43:31 anupbehare at gmail.com wrote:
> I am using board having ppc440x5 core with customized chip and not a
> standard 440Gx.
>
> Board is using Denali controller, as the register are completely different
> we can not use the standard u-boot initialization.
OK, I see. So you have a customized non-440EPx/GRx chip with the Denali DDR(2)
controller. You are aware that we have a full blown Denali DDR(2) controller
setup routine with SPD detection? This one is only for 440EPx/GRx right now,
since these were the only PPC4xx variants equipped with this core till now:
cpu/ppc4xx/denali_spd_ddr2.c
cpu/ppc4xx/denali_data_eye.c
You should try to use this code as it is known to work on other PPC4xx
platforms in various configurations.
> We performed board specific initialization and training for DDR2.
>
> When the code enter into board_init_r() console shows following messages:
>
> Top of RAM usable for U-Boot at: 20000000
> Reserving 178k for U-Boot at: 1ffd3000
> Reserving 1040k for malloc() at: 1fecf000
> Reserving 128 Bytes for Board Info at: 1fecef80
> Reserving 64 Bytes for Global Data at: 1fecef40
> New Stack Pointer is: 1fecef28
>
> Now running in RAM - U-Boot at: 1ffd3000
> Bus Fault @ 0x1ffd5764, fixup 0x00000000
> Machine Check Exception.
>
> NIP: 1FFD5764 XER: 00000000 LR: 1FFD5764 REGS: 1fecee20 TRAP: 0200 DEAR:
> 00000000
> MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
>
> GPR00: 1FFD5338 1FECEF10 1FECEF40 1FFD3000 1FFD6814 00000034 00000034
> 1FFD5764
> GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00
> 20013000
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> GPR24: 00000000 1FECEF40 1FFD3000 1FED3000 1FFD3000 1FECEF80 20002B10
> 20013000
> Call backtrace:
> 1FFD680C 1FFD56D8 A462C4EC
> machine check
>
>
> We tried to debug it with BDI as per steps given @
> http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
>
> We have verified by using BDI that uboot code is placed in DDR, but getting
> an exception and u-boot is in continuously reboot mode.
Did you try adding some printf's to board_init_r(), to see where exactly this
crash occurs? That's what I would do.
> Will it ok if we disable the MSR for ME,EE,CE? Or still it looks DDR
> initialization issue ?
Could be DDR, could be something else. You need to further debug this.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-14 7:30 ` Stefan Roese
@ 2010-01-14 9:39 ` anupbehare at gmail.com
2010-01-14 10:15 ` Wolfgang Denk
2010-01-14 10:24 ` Stefan Roese
0 siblings, 2 replies; 15+ messages in thread
From: anupbehare at gmail.com @ 2010-01-14 9:39 UTC (permalink / raw)
To: u-boot
One update to you on debuging board_init_r()..
We bypass the trap_init call, control enters into the flash_init() in
cfi_flash.c
I am get following console o/p:
fwrite addr fc000000 cmd ff 000000ff000000ff 64 bit x 32 bit
fwrite addr fc0002a8 cmd 98 0000009800000098 64 bit x 32 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000005100000051
fwrite addr fc002aa8 cmd 98 0000009800000098 64 bit x 32 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000005100000051
fwrite addr fc000000 cmd f0 00000000000000f0 64 bit x 64 bit
fwrite addr fc000000 cmd ff 00000000000000ff 64 bit x 64 bit
fwrite addr fc0002a8 cmd 98 0000000000000098 64 bit x 64 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000051
fwrite addr fc002aa8 cmd 98 0000000000000098 64 bit x 64 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000051
not found
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
*** failed ***
### ERROR ### Please RESET the board ###
to more debug we bypass the hang call for time being and we obtain u-boot
prompt.
now as I am getting u-boot prompt that means DDR initilised properly.
now I am debuging for trap_init and flash_init().
~Anup
On 14-Jan-2010 1:00pm, Stefan Roese <sr@denx.de> wrote:
> On Wednesday 13 January 2010 18:43:31 anupbehare at gmail.com wrote:
> > I am using board having ppc440x5 core with customized chip and not a
> > standard 440Gx.
> >
> > Board is using Denali controller, as the register are completely
> different
> > we can not use the standard u-boot initialization.
> OK, I see. So you have a customized non-440EPx/GRx chip with the Denali
> DDR(2)
> controller. You are aware that we have a full blown Denali DDR(2)
> controller
> setup routine with SPD detection? This one is only for 440EPx/GRx right
> now,
> since these were the only PPC4xx variants equipped with this core till
> now:
> cpu/ppc4xx/denali_spd_ddr2.c
> cpu/ppc4xx/denali_data_eye.c
> You should try to use this code as it is known to work on other PPC4xx
> platforms in various configurations.
> > We performed board specific initialization and training for DDR2.
> >
> > When the code enter into board_init_r() console shows following
> messages:
> >
> > Top of RAM usable for U-Boot at: 20000000
> > Reserving 178k for U-Boot at: 1ffd3000
> > Reserving 1040k for malloc() at: 1fecf000
> > Reserving 128 Bytes for Board Info at: 1fecef80
> > Reserving 64 Bytes for Global Data at: 1fecef40
> > New Stack Pointer is: 1fecef28
> >
> > Now running in RAM - U-Boot at: 1ffd3000
> > Bus Fault @ 0x1ffd5764, fixup 0x00000000
> > Machine Check Exception.
> >
> > NIP: 1FFD5764 XER: 00000000 LR: 1FFD5764 REGS: 1fecee20 TRAP: 0200 DEAR:
> > 00000000
> > MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> >
> > GPR00: 1FFD5338 1FECEF10 1FECEF40 1FFD3000 1FFD6814 00000034 00000034
> > 1FFD5764
> > GPR08: 00000600 00002098 00000030 2FAF07FE FFFFFFFF C000B330 20002A00
> > 20013000
> > GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > 00000000
> > GPR24: 00000000 1FECEF40 1FFD3000 1FED3000 1FFD3000 1FECEF80 20002B10
> > 20013000
> > Call backtrace:
> > 1FFD680C 1FFD56D8 A462C4EC
> > machine check
> >
> >
> > We tried to debug it with BDI as per steps given @
> > http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
> >
> > We have verified by using BDI that uboot code is placed in DDR, but
> getting
> > an exception and u-boot is in continuously reboot mode.
> Did you try adding some printf's to board_init_r(), to see where exactly
> this
> crash occurs? That's what I would do.
> > Will it ok if we disable the MSR for ME,EE,CE? Or still it looks DDR
> > initialization issue ?
> Could be DDR, could be something else. You need to further debug this.
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-14 9:39 ` anupbehare at gmail.com
@ 2010-01-14 10:15 ` Wolfgang Denk
2010-01-16 9:53 ` anup behare
2010-01-14 10:24 ` Stefan Roese
1 sibling, 1 reply; 15+ messages in thread
From: Wolfgang Denk @ 2010-01-14 10:15 UTC (permalink / raw)
To: u-boot
Dear anupbehare at gmail.com,
In message <001636ed6c7e8c9189047d1cab86@google.com> you wrote:
>
> We bypass the trap_init call, control enters into the flash_init() in
> cfi_flash.c
...
> to more debug we bypass the hang call for time being and we obtain u-boot
> prompt.
This is random hacking and will not take you anywhere.
The Golden Rule (TM) is to stop at the very first error, and analyze
and _fix_ it before continuing.
I bet a case of beer that your RAM initialization is broken, and all
your changes are just hushing up the problems, which will bite you
later, harder.
Follow Stefan's advice and get your RAM setup working reliably and
stable, before doing anything else.
Feel free to ignore the advice if you like wasting your time, but then
please stop asking here so you not also waste our time, too.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Don't think; let the machine do it for you!" - E. C. Berkeley
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-14 10:15 ` Wolfgang Denk
@ 2010-01-16 9:53 ` anup behare
0 siblings, 0 replies; 15+ messages in thread
From: anup behare @ 2010-01-16 9:53 UTC (permalink / raw)
To: u-boot
Hi Wolfgnag,
I am apologize for debugging with by passing the previous exception.
I was curious about u-boot prompt.
Now i have implemented the steps suggested by stefan, and debugging the
same.
~Anup
On Thu, Jan 14, 2010 at 3:45 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear anupbehare at gmail.com,
>
> In message <001636ed6c7e8c9189047d1cab86@google.com> you wrote:
> >
> > We bypass the trap_init call, control enters into the flash_init() in
> > cfi_flash.c
> ...
> > to more debug we bypass the hang call for time being and we obtain u-boot
> > prompt.
>
> This is random hacking and will not take you anywhere.
>
> The Golden Rule (TM) is to stop at the very first error, and analyze
> and _fix_ it before continuing.
>
> I bet a case of beer that your RAM initialization is broken, and all
> your changes are just hushing up the problems, which will bite you
> later, harder.
>
> Follow Stefan's advice and get your RAM setup working reliably and
> stable, before doing anything else.
>
> Feel free to ignore the advice if you like wasting your time, but then
> please stop asking here so you not also waste our time, too.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "Don't think; let the machine do it for you!" - E. C. Berkeley
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [U-Boot] U-Boot Crashes with Dumps
2010-01-14 9:39 ` anupbehare at gmail.com
2010-01-14 10:15 ` Wolfgang Denk
@ 2010-01-14 10:24 ` Stefan Roese
2010-01-16 9:48 ` anup behare
1 sibling, 1 reply; 15+ messages in thread
From: Stefan Roese @ 2010-01-14 10:24 UTC (permalink / raw)
To: u-boot
On Thursday 14 January 2010 10:39:57 anupbehare at gmail.com wrote:
> now as I am getting u-boot prompt that means DDR initilised properly.
> now I am debuging for trap_init and flash_init().
Could be that your DDR init code somehow generates an exception that is
triggered once trap_init() is called. This is also know to happen in the
common denali_data_eye code. See here:
#if defined(CONFIG_DDR_DATA_EYE)
/*
* Running denali_core_search_data_eye() when ECC is enabled
* causes non-ECC machine checks. This clears them.
*/
print_mcsr();
mtspr(SPRN_MCSR, mfspr(SPRN_MCSR));
print_mcsr();
#endif
I suggest you analyse this and the Denali registers for any source/status of a
generated exception.
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [U-Boot] U-Boot Crashes with Dumps
2010-01-14 10:24 ` Stefan Roese
@ 2010-01-16 9:48 ` anup behare
2010-01-18 8:00 ` Stefan Roese
0 siblings, 1 reply; 15+ messages in thread
From: anup behare @ 2010-01-16 9:48 UTC (permalink / raw)
To: u-boot
Thanks Stenfan for your valuable inputs.
I have implemented the code suggested by you after completing the ddr
initialization :
#if defined(CONFIG_DDR_DATA_EYE)
/*
* Running denali_core_search_data_eye() when ECC is enabled
* causes non-ECC machine checks. This clears them.
*/
print_mcsr();
mtspr(SPRN_MCSR, mfspr(SPRN_MCSR));
print_mcsr();
#endif
before mtspr and after mtspr i am getting the same prints i.e EE,ME,CE
disabled.
I am further debugging the same issue.
On Thu, Jan 14, 2010 at 3:54 PM, Stefan Roese <sr@denx.de> wrote:
> On Thursday 14 January 2010 10:39:57 anupbehare at gmail.com wrote:
> > now as I am getting u-boot prompt that means DDR initilised properly.
> > now I am debuging for trap_init and flash_init().
>
> Could be that your DDR init code somehow generates an exception that is
> triggered once trap_init() is called. This is also know to happen in the
> common denali_data_eye code. See here:
>
> #if defined(CONFIG_DDR_DATA_EYE)
> /*
> * Running denali_core_search_data_eye() when ECC is enabled
> * causes non-ECC machine checks. This clears them.
> */
> print_mcsr();
> mtspr(SPRN_MCSR, mfspr(SPRN_MCSR));
> print_mcsr();
> #endif
>
> I suggest you analyse this and the Denali registers for any source/status
> of a
> generated exception.
>
> 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
>
^ permalink raw reply [flat|nested] 15+ messages in thread* [U-Boot] U-Boot Crashes with Dumps
2010-01-16 9:48 ` anup behare
@ 2010-01-18 8:00 ` Stefan Roese
0 siblings, 0 replies; 15+ messages in thread
From: Stefan Roese @ 2010-01-18 8:00 UTC (permalink / raw)
To: u-boot
On Saturday 16 January 2010 10:48:21 anup behare wrote:
> Thanks Stenfan for your valuable inputs.
>
> I have implemented the code suggested by you after completing the ddr
> initialization :
>
> #if defined(CONFIG_DDR_DATA_EYE)
> /*
> * Running denali_core_search_data_eye() when ECC is enabled
> * causes non-ECC machine checks. This clears them.
> */
> print_mcsr();
> mtspr(SPRN_MCSR, mfspr(SPRN_MCSR));
> print_mcsr();
> #endif
>
> before mtspr and after mtspr i am getting the same prints i.e EE,ME,CE
> disabled.
Please note that I am not referring to MSR, but to the MCSR register here. Not
all PPC4xx variants have this register implemented. But most 44x ones should
(SPR 0x23c).
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-01-18 8:00 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-12 7:02 [U-Boot] U-Boot Crashes with Dumps anupbehare at gmail.com
2010-01-12 7:26 ` Stefan Roese
2010-01-12 9:09 ` anupbehare at gmail.com
2010-01-12 9:50 ` Stefan Roese
2010-01-12 10:07 ` anupbehare at gmail.com
2010-01-12 10:20 ` Stefan Roese
[not found] <001636d351d9aa42b7047d069e1b@google.com>
2010-01-13 7:38 ` Stefan Roese
2010-01-13 17:43 ` anupbehare at gmail.com
2010-01-14 7:30 ` Stefan Roese
2010-01-14 9:39 ` anupbehare at gmail.com
2010-01-14 10:15 ` Wolfgang Denk
2010-01-16 9:53 ` anup behare
2010-01-14 10:24 ` Stefan Roese
2010-01-16 9:48 ` anup behare
2010-01-18 8:00 ` Stefan Roese
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox