Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp9788imm; Tue, 17 Jul 2018 12:56:37 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeSk+NeSlE8Z4p1uikcO+YLQiiprVmyTOx1OUWen+tpDSeah86j3kbxsE0Y/o0XarQsI9LM X-Received: by 2002:a63:1513:: with SMTP id v19-v6mr2971965pgl.358.1531857396934; Tue, 17 Jul 2018 12:56:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531857396; cv=none; d=google.com; s=arc-20160816; b=F9F6qnk0F9NJknBVzK2Lkz9Sa/NfyxpzteTjTdNTzG2SYfKHrxpxKNLQ/z4MsYr3ps r9mKBYVPxsyaQ/Fj3uvFuYJfH7GU0kLzzsiJpX00ugzSkrJkgfcUjKUCHCST/HGlhye2 fPYM4Un5wW5CHubXhxJQJRG4o9wE2fItFJGgEtIoZxP3xpOXQ3cC8+jCmHePppnvxLGX 0QpuXyDT3vdk8m8FYoSIf2lFy2X9gnvTRBehIpYuoDjXZPIb7TF3tO6laRgNkexFALPU GVgxhK1sN6Q3AdtSc9x6WcqiE506RLvaF7lk1QKq5pyp/Ugkb5xUEfEbJ55sB7gyR2of Zd3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=coIlGyC9mOCcMjM/pNzqefV5FEGhzHcpeVDNvY3BPZI=; b=LrLmZS0OGi2L26R3LVJVSSQEjVD2fNTnBSeFcps/P4dNhjnuKZ9AmbHeGcei2KQFFb IkgFG3gbc66IOFW4XEdsyTBse+rGIZrXHKZNynpveC6HeV51R1eyjGEOfrKagxAJ01sb DiB48bUVgGbB1bZyi5ovy1d1GD1ZL0O1Qe8h9UDm4MiisLuDNfVwhnX+G65JPeryYiUU JL6XYb2hgzgZj1sYpU5nK7DhaX+zSHm4Rpq3FK4V64DR089dajmoEstLSwmof4f8yWQD VCVtT6JqxqepUHDl3R5PTvPMU2rYS+i/HONVj3u0TFR1O2JKnWQHoX1I3gcPvYKrUAPe Jx/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="STTL/Fwj"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g15-v6si1609756pgh.418.2018.07.17.12.56.21; Tue, 17 Jul 2018 12:56:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="STTL/Fwj"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730161AbeGQU3u (ORCPT + 99 others); Tue, 17 Jul 2018 16:29:50 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:39434 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729748AbeGQU3u (ORCPT ); Tue, 17 Jul 2018 16:29:50 -0400 Received: by mail-qt0-f194.google.com with SMTP id q12-v6so2012135qtp.6 for ; Tue, 17 Jul 2018 12:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=coIlGyC9mOCcMjM/pNzqefV5FEGhzHcpeVDNvY3BPZI=; b=STTL/FwjZn/UJwzw4EYa849VFZUk7EZH1jFt0TPIQu8FVC/FQXXe8JgTdGSTJUfeHJ zCqN2v5wY+DIQX5fgjbsFNXnliSZlNtcPkahMDJNtQIOZxwZMQC1abOuDY336JWuKrsL ZvdgBK8FzCHxegz81DWkKf0Xdr5lytlTMCNmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=coIlGyC9mOCcMjM/pNzqefV5FEGhzHcpeVDNvY3BPZI=; b=R1/OjXvwdobtpsi6wrxPQ0Y7NmXFspAkvlmlexwFzOA3sPZWBPKUEuKHjvYOaS3n5g OBNx/VnFT5bmBbLg6pKWg9+4ZmImHLiBCFCGLkUYanPeOzn/5OcLU+64gmt9eekb834L 8c5+Zn5JyZwb0Bmg5yWBtibb2vN8yWL4BI9dMLzvkyo0HHhUkGXr9+EauGq9hApb+ze+ +dld8XJhU3HzAlqxKMPC4Fu7jT4OC++Q5TFa9jaCRXf/M/8HEEeR3rYepvS/kYO5iLOq 5GbgzFMFv6EBZXzvJ+bClN1fJMYiDlRzPtVlN3GfTuTQz3PR+AIx4Q0Nwa0//W3uuIn9 s/+g== X-Gm-Message-State: AOUpUlHjrEB2sJ5eC7lVqMXFOhdpA4MZdcu7P6S1In2Z7eJ6/5/xPhr6 ceEfkOsnHlXVHeLDubZEV081Lg== X-Received: by 2002:ac8:503:: with SMTP id u3-v6mr3119304qtg.114.1531857339490; Tue, 17 Jul 2018 12:55:39 -0700 (PDT) Received: from xanadu.home (modemcable228.104-82-70.mc.videotron.ca. [70.82.104.228]) by smtp.gmail.com with ESMTPSA id v71-v6sm1693190qkl.42.2018.07.17.12.55.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Jul 2018 12:55:38 -0700 (PDT) Date: Tue, 17 Jul 2018 15:55:37 -0400 (EDT) From: Nicolas Pitre To: Fabrizio Castro cc: Russell King , =?ISO-8859-2?Q?=A3ukasz_Stelmach?= , Biju Das , Chris Paterson , "linux-arm-kernel@lists.infradead.org" , Simon Horman , Geert Uytterhoeven , "linux-renesas-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "catalin.marinas@arm.com" , "marc.zyngier@arm.com" , "cdall@linaro.org" Subject: RE: [RFC PATCH] ARM: Debug kernel copy by printing In-Reply-To: Message-ID: References: <1530022595-6806-1-git-send-email-fabrizio.castro@bp.renesas.com> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Jul 2018, Fabrizio Castro wrote: > Dear All, > > Has anybody had the chance to look into this? Does it make sense? Any feedback at all? > Thanks! Looks fine to me. > > Fab > > > Subject: [RFC PATCH] ARM: Debug kernel copy by printing > > > > 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: > > addr6, r9, r5 > > addr9, 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. > > + */ > > +dbgkcr5, r6, r10, r9 > > +#endif > > + > > 1:ldmdbr6!, {r0 - r3, r10 - r12, lr} > > cmpr6, r5 > > stmdbr9!, {r0 - r3, r10 - r12, lr} > > -- > > 2.7.4 > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. >