From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7D96C432C0 for ; Wed, 27 Nov 2019 23:21:52 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7C5E0215F2 for ; Wed, 27 Nov 2019 23:21:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EGZFWzkt"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="IjC7afpg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C5E0215F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iEFJy9sLEKgt5sChOtb6aXAWtqarVk6fDmsrKt70uYU=; b=EGZFWzktMDmMMQ FuXF6WQ4ol0T6yL5+ctpLwsNHTA4Loo8zPVG5HMASVJhh+XKHCvn5xaFqipVEZslUT/pyV8DCxzwe y8+qS3AKUrG7TJfl3SKozL/6P3Nc72hdNd6oGVsUdcOulDabT3zRiAqjV79vjrarFcwo1QU0ikc7S 5C/bCyD18/Z+zJwJttXGlqjROVX2c7LKe0wWaYdw2JOz5jZb6ZqnpdPeQSSDzd4Hr+RzJhknJ3iap 6ANAZlciLzwE8gj7PQbYAikBFtCFoUHecUjsIIKmtiyX4gkYWzfU54AVWxbnRf2gTt+3+CSbKAt1H yhVpmsqciEIJaXcLDaUQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ia6d2-0001kj-Oj; Wed, 27 Nov 2019 23:21:48 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ia6d0-0000Qv-3d for linux-arm-kernel@lists.infradead.org; Wed, 27 Nov 2019 23:21:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ua2UG/3P9FGM6hlUDIsduttPdTTUDw7lB1+OC0/Vfew=; b=IjC7afpgiGMCcN4wtGhOcSgAp IBpLPlsr+Nb0dfjpSQITFGlg9cdDYE+YLytWxj+dAlh1QFZ5rsVVHTJEjeuPXLA+ZLytfzENdxqJC Xtl0lkHMghG6tdcGWtLM+Gu8QOjKU6T2NJXmkeUJuT3CDqrYgPC5CViy3LKtnRLd4YHPHmvAtD5oH pXSPlBWSep8AOrtyYM2g+Jye9/vNXyiDr7Y2tgxMtpo+tRcRxNMQCqcsifEbTfE4PYXBg5MvnJsbp w7ssCmpKKNTAQ+Nd9CTgcEIDsoFN/8MYItxVxm9ZNyqSdrlyuqCMfJH5QHd3NBzURQFvvtI0WOnA4 fL0WaxJzw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:45502) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ia6aW-0005x5-LR; Wed, 27 Nov 2019 23:19:12 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1ia6aK-0000gJ-V4; Wed, 27 Nov 2019 23:19:00 +0000 Date: Wed, 27 Nov 2019 23:19:00 +0000 From: Russell King - ARM Linux admin To: Chris Packham Subject: Re: ARM expections for location of kernel, ramdisk and dtb Message-ID: <20191127231900.GG25745@shell.armlinux.org.uk> References: <20191127092615.GC25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191127_152146_145145_376066BE X-CRM114-Status: GOOD ( 25.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Hamish Martin , "ard.biesheuvel@linaro.org" , "linus.walleij@linaro.org" , "nico@fluxnic.net" , "linux-kernel@vger.kernel.org" , "stefan@agner.ch" , "tglx@linutronix.de" , "natechancellor@gmail.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 27, 2019 at 10:15:57PM +0000, Chris Packham wrote: > Hi Russell, > > On Wed, 2019-11-27 at 09:26 +0000, Russell King - ARM Linux admin > wrote: > > On Wed, Nov 27, 2019 at 08:20:12AM +0000, Chris Packham wrote: > > > Hi All, > > > > > > We're updating our systems to use the latest kernel. For many of them > > > this is a fairly large leap. One problem we've hit is that durng boot > > > the dtb is clobbered by the uncompressed kernel. > > > > > > Here's a snippet of output from u-boot > > > > > > ## Loading kernel from FIT Image at 62000000 ... > > > Using 'XS916MXS@2' configuration > > > Trying 'kernel@1' kernel subimage > > > Description: linux > > > Created: 2019-11-27 6:53:48 UTC > > > Type: Kernel Image > > > Compression: uncompressed > > > Data Start: 0x62000174 > > > Data Size: 3495432 Bytes = 3.3 MiB > > > Architecture: ARM > > > OS: Linux > > > Load Address: 0x00800000 > > > Entry Point: 0x60800000 > > > ... > > > Booting using the fdt blob at 0x63b90f6c > > > Loading Kernel Image ... OK > > > Loading Ramdisk to 6e7c6000, end 70000000 ... OK > > > Loading Device Tree to 607fb000, end 607fffd8 ... OK > > > > > > Starting kernel ... > > > > > > Uncompressing Linux... done, booting the kernel. > > > > > > Error: invalid dtb and unrecognized/unsupported machine ID > > > r1=0x0000206e, r2=0x00000000 > > > > > > Between old and new the location of the devicetree hasn't actually > > > changed. But what has changed is the size of the kernel the self > > > extracting kernel unpacks to 0x60008000 and with our current > > > configuration extends into where the dtb is located. > > > > > > Documentation/arm/booting.rst says that "The dtb must be placed in a > > > region of memory where the kernel decompressor will not overwrite it". > > > > > > This suggests that the problem is with our u-boot configuration, but > > > how is u-boot supposed to know where the self-extracting kernel is > > > going to place things? As far as I can tell u-boot is doing a > > > reasonable job of finding a place to put the dtb which it thinks is > > > unused. I'm not sure why it's picked 0x607fb000 instead of putting it > > > just under the ramdisk but regardless with the information u-boot has > > > that address is up for grabs. > > > > > > Has this come up before? The self-extraction code is fairly careful not > > > to overwrite itself but doesn't seem to pay any attention to the dtb > > > which surprised me. So I wonder if I'm missing something? > > > > The self-extraction hasn't changed much over the years, and basically > > follows the same method which has worked for the vast majority of > > platforms. > > > > Where things fall down is where things are placed too close, and yes, > > as the kernel grows, what was reasonable years ago becomes too close > > with modern kernels. > > > > The problem has been compounded by the various different compression > > algorithms that can now be used for the compressed kernel. > > > > I don't think it's that we don't know how big the extracted kernel will > be. It's just that we aren't doing anything with that information w.r.t > the dtb. I believe u-boot tried at one point to instigate some kind of standard placement of the kernel / dtb with respect to the available RAM, but vendors tried hard to ignore u-boot and go their own way - resulting in systems that didn't boot without customising various u-boot environment variables. It's very annoying when vendors ignore the community... -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel