> I have succeeded in getting the debugger to break early on during boot. > I have it set to break at start_here, in arch/powerpc/kernel/head_32.S. > > My U-Boot bootloader indicates that the fdt is being loaded to address > 0x7f8000, which translates to VA 0xc07f8000. See this output: > > Booting using the fdt blob at 0x2269f1c > Uncompressing Kernel Image ... OK > Loading Ramdisk to 0fea0000, end 0ff76699 ... OK > Loading Device Tree to 007f8000, end 007ff78f ... OK > > As soon an the debugger hit the start_here breakpoint, I ran the > following command. It should dump out the flat device tree to a file, > which I can then analyze: > > (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f > > On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree > in fdt.bin. I see the stuff I would expect. > > On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin. > So clearly something is overwriting the fdt. > > However, note that this happens *before* lockdep_init() runs. Grepping > for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing. > I'm not sure exactly how this is related to lockdep. > > Some more suggestions for things to try would be great. For now, I'm > going to try getting the debugger to break near the end of U-Boot, to > see if the memory is overwritten there, and not in Linux.
I suspect your uboot setup. The one thing lockdep does is massively increase the amount of kernel bss. I suspect you are just overlapping DT and bss and hence wiping out the DT when clearing the bss. I would have expected uboot to warn (the kernel ELF header contains the BSS size) but apparently that isn't the case. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev