> On Tuesday 27 October 2015 14:40:21 Huan Wang wrote: > > > > > > Ok. What I was suggesting above though was to try to pinpoint > > > exactly where it goes wrong. You have verified that it does not > > > crash before the page tables are enabled, but that is very early. > > > You have also shown that the kernel crashes before the point at > > > which the 'Booting Linux on physical CPU 0xf00' message is printed > > > to the kernel, but that is *much* > > > later: setup_arch() calls parse_early_param(), which in turn sets up > > > early_console_write(). This means the 'Booting Linux on physical CPU > > > 0xf00' > > > is still stuck in the log buffer and you may have crashed someone > > > inbetween. > > > > > > If you can call printascii(), you can try to do that just after > > > enabling the page tables to see if that was the problem like you > > > suspect, or otherwise add more printascii() statements between > > > __turn_mmu_on and > > > parse_early_param() to pinpoint the exact code that breaks. > > [Alison Wang] Thank you very much for your help. The issue is fixed. > > > > Ah, very good. I'm curious what caused the problem in the end. [Alison Wang] The problem is caused by the wrong fdt_high setting (0xcfffffff). When 3G/1G user/kernel memory split is used, U-Boot relocates the device tree blob into high memory when booting the kernel and the kernel is unable to access the blob.
Best Regards, Alison Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/