From: Huan Wang <alison.wang@freescale.com>
To: Arnd Bergmann <arnd@arndb.de>
CC: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
        Jin Jason <Jason.Jin@freescale.com>,
        Russell King - ARM Linux <linux@arm.linux.org.uk>,
        Fabio Estevam <festevam@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>
Subject: RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig
Thread-Topic: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig
Thread-Index: AQHQ8SjkL5VPm4WkUE22VnJn+5lonZ5AhnkAgAFdj6CAAIuhAIAI4e9QgAAC8gCAH5incIAAL4AAgADYhcCAAK4fgIARF6wggAaVf4CABAZtcA==
Date: Mon, 2 Nov 2015 03:19:42 +0000
Message-ID: <BN3PR0301MB0867A9DA25D6D192EDAACB3BFE2C0@BN3PR0301MB0867.namprd03.prod.outlook.com>
References: <1442480614-32345-1-git-send-email-b18965@freescale.com>
 <5073362.oArWDzYkxD@wuerfel>
 <BN3PR0301MB0867C51A52319367F981C630FE230@BN3PR0301MB0867.namprd03.prod.outlook.com>
 <3938714.zt8Y4X5ull@wuerfel>
In-Reply-To: <3938714.zt8Y4X5ull@wuerfel>
Accept-Language: zh-CN, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 03:19:42.7696
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1283
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1678
Lines: 35

> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/