From patchwork Tue Jun 26 14:16:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fabrizio Castro X-Patchwork-Id: 10489141 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C006C602D8 for ; Tue, 26 Jun 2018 14:17:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AE94528A32 for ; Tue, 26 Jun 2018 14:17:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A324F28A34; Tue, 26 Jun 2018 14:17:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 4DFF528A32 for ; Tue, 26 Jun 2018 14:17:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=Z7YFhgPxs7FWFUkMvJMbtQENgcsTRfvwa8mn/NdE2kA=; b=OU4 XvE7QegGkFcNskLxiwMHr8EVR7/N5RFCf7SkI2KkqpJgLHLbznF022U3WWfvAizWLQwR4LAQ2DD3I Z/58dHRdfSt5m3uExoPKAVpIs/Gkdu8mryf/hBYtnxaW9Jbz6zxNrdKfAOiO+W0iMHQ/6QuOp1gj+ bXjZD0DJv/DsBjZL2SDIYIQcBYFFVloi4h4liistsg0wW0VMgAg9FgdsK6wAifE5I2y3TajdiZCCM 9Ochj9IS/uKGmb9OzS5qMY2GE1DDT1sdy9eyjDKZp6BuUFJnGQYJxqxuZJLP5RHFPdBr3t7RG7dwL vWz16b9HcZaJG5g9TgIDp893CPXmwrg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fXomB-0004i7-Hz; Tue, 26 Jun 2018 14:16:59 +0000 Received: from relmlor4.renesas.com ([210.160.252.174] helo=relmlie3.idc.renesas.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fXom7-0004go-FL for linux-arm-kernel@lists.infradead.org; Tue, 26 Jun 2018 14:16:57 +0000 Received: from unknown (HELO relmlir1.idc.renesas.com) ([10.200.68.151]) by relmlie3.idc.renesas.com with ESMTP; 26 Jun 2018 23:16:42 +0900 Received: from relmlii1.idc.renesas.com (relmlii1.idc.renesas.com [10.200.68.65]) by relmlir1.idc.renesas.com (Postfix) with ESMTP id 1911E84C91; Tue, 26 Jun 2018 23:16:42 +0900 (JST) X-IronPort-AV: E=Sophos;i="5.51,274,1526310000"; d="scan'208";a="283643696" Received: from unknown (HELO fabrizio-dev.ree.adwin.renesas.com) ([10.226.36.229]) by relmlii1.idc.renesas.com with ESMTP; 26 Jun 2018 23:16:39 +0900 From: Fabrizio Castro To: Russell King Subject: [RFC PATCH] ARM: Debug kernel copy by printing Date: Tue, 26 Jun 2018 15:16:35 +0100 Message-Id: <1530022595-6806-1-git-send-email-fabrizio.castro@bp.renesas.com> X-Mailer: git-send-email 2.7.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180626_071655_777467_EE917C0A X-CRM114-Status: GOOD ( 19.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fabrizio Castro , Chris Paterson , Geert Uytterhoeven , =?UTF-8?q?=C5=81ukasz=20Stelmach?= , linux-kernel@vger.kernel.org, Biju Das , linux-renesas-soc@vger.kernel.org, Simon Horman , linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP It may happen that when we relocate the kernel we corrupt other sensible memory (e.g. the memory needed by U-Boot for dealing with bootm command) while copying the kernel. If we overwrite the content of the memory area used by U-Boot's command bootm (described by U-Boot's parameters bootm_low and bootm_size), the kernel won't be able to boot. Troubleshooting the problem then is not straightforward. This commit allows the user to easily print information on where the kernel gets copied from/to in order to help with the design of the system memory map (e.g. bootm_low and bootm_size) at boot up. Signed-off-by: Fabrizio Castro Reviewed-by: Chris Paterson Acked-by: Biju Das --- Dear All, shmobile_defconfig doesn't use kernel modules, everything gets built-in. iwg20d and iwg22d platforms from iWave use uImage to boot, DRAM starts at address 0x40000000, the kernel gets loaded up in memory at address 0x40007fc0, bootm_low is 0x40e00000, and bootm_size is 0x100000. The kernel is getting larger and larger, so much so that during the relocation the kernel is copying itself right where the bootm memory area lives, preventing Linux from booting. Here is what this patch prints when applied on top of tag next-20180625 and running on the iwg22d: C:0x400080C0-0x404922A0->0x40E90800-0x4131A9E0 The designer then has to pick up a suitable memory range for bootm memory area to fix this, but the only way to successfully achieve this is by knowing where the kernel is going to copy itself in memory, so that he can stay clear of it. Other platforms that use the same defconfig suffer from the same issue (e.g. Koelsch et al.) as they have been designed some time ago or the original BSP was based on an LTS kernel. Debugging this basically requires a JTAG debugger at this stage. Do you think this patch could be considered acceptable? If not, what would be the best way to get useful/sensible/debug information out of the kernel when the problem occours? Comments welcome! Thanks, Fab arch/arm/boot/compressed/head.S | 43 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 517e0e1..6c7ccb4 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -114,6 +114,35 @@ #endif .endm + /* + * Debug kernel copy by printing the memory addresses involved + */ + .macro dbgkc, begin, end, cbegin, cend +#ifdef DEBUG + kputc #'\n' + kputc #'C' + kputc #':' + kputc #'0' + kputc #'x' + kphex \begin, 8 /* Start of compressed kernel */ + kputc #'-' + kputc #'0' + kputc #'x' + kphex \end, 8 /* End of compressed kernel */ + kputc #'-' + kputc #'>' + kputc #'0' + kputc #'x' + kphex \cbegin, 8 /* Start of kernel copy */ + kputc #'-' + kputc #'0' + kputc #'x' + kphex \cend, 8 /* End of kernel copy */ + kputc #'\n' + kputc #'\r' +#endif + .endm + .section ".start", #alloc, #execinstr /* * sort out different calling conventions @@ -450,6 +479,20 @@ dtb_check_done: add r6, r9, r5 add r9, r9, r10 +#ifdef DEBUG + sub r10, r6, r5 + sub r10, r9, r10 + /* + * We are about to copy the kernel to a new memory area. + * The boundaries of the new memory area can be found in + * r10 and r9, whilst r5 and r6 contain the boundaries + * of the memory we are going to copy. + * Calling dbgkc will help with the printing of this + * information. + */ + dbgkc r5, r6, r10, r9 +#endif + 1: ldmdb r6!, {r0 - r3, r10 - r12, lr} cmp r6, r5 stmdb r9!, {r0 - r3, r10 - r12, lr}