[T1040QDS] CCSR mapping

rommelcustodio · ‎04-17-2014

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

rommelcustodio · ‎04-21-2014

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.

sinanakman · ‎04-21-2014

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

scottwood · ‎04-18-2014

It looks like the debugger is accessing physical addresses, not effective addresses.

Have you verified exactly where the code is hanging, by reading PC? What version of GCC does ELDK 5.4 come with?