lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 2 Nov 2015 03:19:42 +0000 From: Huan Wang <alison.wang@...escale.com> To: Arnd Bergmann <arnd@...db.de> CC: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Jin Jason <Jason.Jin@...escale.com>, Russell King - ARM Linux <linux@....linux.org.uk>, Fabio Estevam <festevam@...il.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "shawnguo@...nel.org" <shawnguo@...nel.org> Subject: RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig > 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists