I compiled the P1010RDB boot loader using the PowerPC gcc version 4.9.0. The binary failed to boot with a DATA TLB exception. After investigating and producing an objdump, I saw the following in the function cpu_init_early_f:
void cpu_init_early_f(void *fdt) { ... #ifdef CONFIG_A003399_NOR_WORKAROUND ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR; u32 *dst, *src; void (*setup_ifc_sram)(void); #endif ... init_laws(); ...
setup_ifc_sram = (void *)SRAM_BASE_ADDR; dst = (u32 *) SRAM_BASE_ADDR; src = (u32 *) setup_ifc; for (i = 0; i < 1024; i++) *dst++ = *src++;
setup_ifc_sram();
/* CLEANUP */ clrbits_be32(&l2cache->l2ctl, (MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2SRAM_ENTIRE)); out_be32(&l2cache->l2srbar0, 0x0); #endif
invalidate_tlb(1); ... init_tlbs(); }
The GCC powerpc objdump gives: eff433f4: 4b ff ec 0d bl eff42000 <init_laws> eff433f8: 3c 80 80 00 lis r4,-32768 eff433fc: 3c 60 10 09 lis r3,4105 eff43400: 60 84 15 00 ori r4,r4,5376 eff43404: 38 a0 00 08 li r5,8 eff43408: 38 c0 00 15 li r6,21 eff4340c: 38 e0 00 00 li r7,0 eff43410: 4b ff e0 91 bl eff414a0 <write_tlb> eff43414: 3d 40 ff e2 lis r10,-30 eff43418: 39 20 00 00 li r9,0 eff4341c: 61 4a 01 00 ori r10,r10,256 eff43420: 7c 00 04 ac msync eff43424: 91 2a 00 00 stw r9,0(r10) eff43428: 39 00 00 0c li r8,12 eff4342c: 7c 00 04 ac msync eff43430: 91 0a 0d 44 stw r8,3396(r10) eff43434: 3d 00 80 01 lis r8,-32767 eff43438: 3d 40 ff e2 lis r10,-30 eff4343c: 7c 00 04 ac msync eff43440: 91 0a 00 00 stw r8,0(r10) eff43444: 91 29 00 00 stw r9,0(r9) eff43448: 7f e0 00 08 trap
invalidate_tlb and init_tlbs are NOT present and the function ends with a trap instruction instead of blr.
The line of code "dst = (u32 *) SRAM_BASE_ADDR;" seems to be the problem. If removed, the object dump shows the call for the last two functions and returns. Also the compiler options -fno-delete-null-pointer-checks or using memcpy fixes the problem.
Likely related to the following options found in the documentation https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Maybe related to the following: -fisolate-erroneous-paths-attribute Detect paths which trigger erroneous or undefined behaviour due a NULL value being used in a way which is forbidden by a returns_nonnull or nonnull attribute. Isolate those paths from the main control flow and turn the statement with erroneous or undefined behaviour into a trap. This is not currently enabled, but may be enabled by -O2 in the future.
Any thoughts?
Renaud