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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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