From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932621AbbJ0Oyw (ORCPT ); Tue, 27 Oct 2015 10:54:52 -0400 Received: from mail-bl2on0140.outbound.protection.outlook.com ([65.55.169.140]:38887 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932152AbbJ0Oyu (ORCPT ); Tue, 27 Oct 2015 10:54:50 -0400 From: Huan Wang To: Arnd Bergmann CC: "linux-arm-kernel@lists.infradead.org" , Jin Jason , Russell King - ARM Linux , Fabio Estevam , "linux-kernel@vger.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+5lonZ5AhnkAgAFdj6CAAIuhAIAI4e9QgAAC8gCAH5incIAAL4AAgADYhcCAAK4fgIARF6wg Date: Tue, 27 Oct 2015 14:40:21 +0000 Message-ID: References: <1442480614-32345-1-git-send-email-b18965@freescale.com> <5232654.e6dagm53H4@wuerfel> <5073362.oArWDzYkxD@wuerfel> In-Reply-To: <5073362.oArWDzYkxD@wuerfel> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=alison.wang@freescale.com; x-originating-ip: [192.88.171.1] x-microsoft-exchange-diagnostics: 1;BN3PR0301MB1281;5:5Ul1S+hmtDBAXtQXO+2adVykdIBteoca93FH3ABr2jI+Y3Mvw2CAYUW5ffUmkvPC4ERgiHE+LQjRLdif2lkLZ6udgwdZ/ImcQ36YjpBe+OR5iIQPmnOmSRpE9CyhobDvzWt4VJFXM4ljrZTgLcmNwQ==;24:QDgVjVqBrfd25pTglscA1KVMr7/RN/K6eWP6uudLzJTALQbW4/6s22+qMp/xtVsmaI5P2/ppmF52Ah/H2N7mSd0jSP2VqNbLaJoGTDMSajE=;20:CXKuDZ8OoATecC28V0b7zfM5Pu15xDw+6AjghGj3XJmqdMrlZxMrY2wTRNvxd9qenDsZywUbed2aNA/3GBUtFQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1281; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(101931422205132); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026);SRVR:BN3PR0301MB1281;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1281; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(45984002)(24454002)(189002)(199003)(377454003)(2900100001)(66066001)(122556002)(74316001)(189998001)(2950100001)(40100003)(101416001)(50986999)(76176999)(54356999)(5004730100002)(5007970100001)(10400500002)(5008740100001)(5003600100002)(92566002)(76576001)(110136002)(11100500001)(5001960100002)(5002640100001)(93886004)(5001920100001)(97736004)(19580395003)(19580405001)(87936001)(106116001)(106356001)(33656002)(105586002)(86362001)(77096005)(102836002)(81156007)(99286002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0301MB1281;H:BN3PR0301MB0867.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 14:40:21.1328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1281 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t9REu3Oh030585 > On Thursday 15 October 2015 02:11:57 Huan Wang wrote: > > > On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > wrote: > > > > > > Any suggestion? Thanks. > > > > > > > > > > Try enabling DEBUG_LL for your platform to get some debug > > > > > output, if you still don't get any helpful messages, try also > > > > > inserting > > > > > > > > > > printascii(__func__); > > > > > > > > > > statements in the early boot process to see how far you get > before the hang. > > > > > > > > > > [Alison Wang] ls1021a uses duart as the default serial port, not > > lpuart. So > > 8250/16550 serial driver is used. Let me explain my debug process in > detail. > > Ah, I see. > > > When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and > > get the print message " Booting Linux on physical CPU 0xf00" after > "Starting kernel" > > as below. > > > > Starting kernel ... > > [ 0.000000] Booting Linux on physical CPU 0xf00 > > ..... > > > > But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " > > Booting Linux on physical CPU 0xf00". It only hangs at "Starting > kernel ...". > > > > Moreover, I add some asm code in __turn_mmu_on to print some simple > > characters, and I could get the print characters when > > CONFIG_VMSPLIT_3G is used. So I guess there is something wrong with > the page tables. > > 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. Best Regards, Alison Wang {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 From: alison.wang@freescale.com (Huan Wang) Date: Tue, 27 Oct 2015 14:40:21 +0000 Subject: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig In-Reply-To: <5073362.oArWDzYkxD@wuerfel> References: <1442480614-32345-1-git-send-email-b18965@freescale.com> <5232654.e6dagm53H4@wuerfel> <5073362.oArWDzYkxD@wuerfel> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > On Thursday 15 October 2015 02:11:57 Huan Wang wrote: > > > On Wednesday 14 October 2015 10:18:47 Huan Wang wrote: > > > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote: > > > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang > wrote: > > > > > > Any suggestion? Thanks. > > > > > > > > > > Try enabling DEBUG_LL for your platform to get some debug > > > > > output, if you still don't get any helpful messages, try also > > > > > inserting > > > > > > > > > > printascii(__func__); > > > > > > > > > > statements in the early boot process to see how far you get > before the hang. > > > > > > > > > > [Alison Wang] ls1021a uses duart as the default serial port, not > > lpuart. So > > 8250/16550 serial driver is used. Let me explain my debug process in > detail. > > Ah, I see. > > > When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and > > get the print message " Booting Linux on physical CPU 0xf00" after > "Starting kernel" > > as below. > > > > Starting kernel ... > > [ 0.000000] Booting Linux on physical CPU 0xf00 > > ..... > > > > But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " > > Booting Linux on physical CPU 0xf00". It only hangs at "Starting > kernel ...". > > > > Moreover, I add some asm code in __turn_mmu_on to print some simple > > characters, and I could get the print characters when > > CONFIG_VMSPLIT_3G is used. So I guess there is something wrong with > the page tables. > > 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. Best Regards, Alison Wang