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 <[email protected]> wrote:
On Wednesday 13 January 2010 18:43:31 [email protected] 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: [email protected]
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
