Hello All and Freescale engineers.
T1040QDS 2 stage boot from SPI NOR Flash (on CS#0). u-boot 2013.10 from Freescale. ELDK 5.4 powerpc toolchain.
CPC was initialy used as CPC-SRAM so we need to re-initialize CPC. There is already code in u-boot that seems to perform the required tasks.
1) invalidate_cpc() called in cpu_init_f().
2) enable_cpc() called in cpu_init_r().
I have CONFIG_SYS_FSL_CPC in the configuration file (include/configs/T1040QDS.h). So the aforementioned functions should get called but this causes u-boot to hang! (It hangs in enable_cpc()). If I comment out CONFIG_SYS_FSL_CPC I can properly get the u-boot command prompt.
Tracing shows that during invalidate_cpc() has correct cpc:
(gdb) p cpc
$5 = (cpc_corenet_t *) 0xfe010000
BUT
(gdb) x/16x cpc
0xfe010000: 0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef
0xfe010010: 0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef
0xfe010020: 0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef
0xfe010030: 0xdeadbeef 0xdeadbeef 0xdeadbeef 0xdeadbeef
It seems it is pointing to DDR-RAM but the TLB mapping should have handled this. That is my assumption. With these values, the "if" condition in invalidate_cpu() that checks CPC_SRCR0_SRAMEN just continues. This is not the case when enable_cpc() executes, which causes a hang.
The TLB and LAWs are all pointing to CCSRBARH and CCSRBARL.
T1040#0>rd ccsrbarh
ccsrbarh : 0x0000000f 15
T1040#0>rd ccsrbarl
ccsrbarl : 0xfe000000 -33554432
T1040#0>rd lawar1
lawar1 : 0x81e00017 -2116026345
T1040#0>rd lawbarl1
lawbarl1 : 0xfe000000 -33554432
T1040#0>rd lawbarh1
lawbarh1 : 0x0000000f 15
T1040#0>tlb1 0 7
IDX TID EPN SIZE V TS RPN U0-U3 WIMGE UUUSSS
0 : 00 fffc0000 256KB V 0 -> 00_fffc0000 0000 -I-G- R--RWX
1 : 00 fe000000 16MB V 0 -> 0f_fe000000 0000 -I-G- R--RWX
2 : 00 e0000000 256MB V 0 -> 0f_e0000000 0000 W--G- ---R-X
3 : 00 80000000 1GB V 0 -> 0c_00000000 0000 -I-G- R--RWX
4 : 00 f8000000 256KB V 0 -> 0f_f8000000 0000 -I-G- R--RWX
5 : 00 f4000000 16MB V 0 -> 0f_f4000000 0000 ----- R--RWX
6 : 00 f5000000 16MB V 0 -> 0f_f5000000 0000 -I-G- R--RWX
7 : 00 f6000000 16MB V 0 -> 0f_f6000000 0000 ----- R--RWX
T1040#0>md 0x0fe010000
0_fe010000 : deadbeef deadbeef deadbeef deadbeef ................
0_fe010010 : deadbeef deadbeef deadbeef deadbeef ................
0_fe010020 : deadbeef deadbeef deadbeef deadbeef ................
0_fe0100f0 : deadbeef deadbeef deadbeef deadbeef ................
T1040#0>md 0xffe010000
f_fe010000 : 80000000 00000000 50b1c004 00000000 ........P.......
f_fe010010 : 00000000 00000000 00000000 00000000 ................
f_fe010020 : 00000000 00000000 00000000 00000000 ................
T1040#0>md 0xfe010000
0_fe010000 : deadbeef deadbeef deadbeef deadbeef ................
0_fe010010 : deadbeef deadbeef deadbeef deadbeef ................
0_fe010020 : deadbeef deadbeef deadbeef deadbeef ................
Anyone has any idea on what I'm doing wrong?
All the best,
Rommel
All,
I've figured it out but first to answer some queries ..
scottwood ELDK5.4 has 4.7.2.
sinanakman yep it's the 3000. Thanks for the tip, it looks OK from the BDI.
It seems the actual problem was the LAW for DDR-SRAM was not programmed correctly.
I used the PBI commands to CPC-SRAM LAW in LAW15 but it seems the DDR detection/initialization code also wants to use this slot. That's the only difference I saw with NOR boot u-boot. Changed to CPC-SRAM to use LAW14, and it's looking better than before.
Hi Rommel, following up Scott's observation on needing to input effective address, assuming this is a BDI3000 unit, please enter MEMACC CORE at the telnet command line (not on your gdb session) and try the md commands again.
Hope this helps.
Sinan Akman