From patchwork Wed Apr 16 19:14:19 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 28501 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-vc0-f198.google.com (mail-vc0-f198.google.com [209.85.220.198]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 68F39206A6 for ; Wed, 16 Apr 2014 19:16:07 +0000 (UTC) Received: by mail-vc0-f198.google.com with SMTP id il7sf38277347vcb.9 for ; Wed, 16 Apr 2014 12:16:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:subject:in-reply-to :message-id:references:user-agent:mime-version:cc:precedence:list-id :list-unsubscribe:list-archive:list-post:list-help:list-subscribe :sender:errors-to:x-original-sender :x-original-authentication-results:mailing-list:content-type :content-transfer-encoding; bh=Dudff5QI4OdSFIOMjnm6ubU+GbW9uVwZSrEAMpjTeU8=; b=eBf05QyaKVE5jnjW5tfBaAnz3fiyeUUbAngENcwwTinRil5o5/SioYO8Osy2gebtoc 3+cyutkn5GVNH5uRYgebarLc7qPh8rj/F9U8PecqPFSYQmkvfvXFIJXEFwP1n2+6UCmq jpLhbc+Iwkuw0d70pPVBGYoRNBrOQAydYrSGBOpUC4VAzvSOALFRTYdWkbi5PHbN+8g+ weFEJFibZhIWtKvYDcIKVTL1tXLttC9zQgoTtcL9ftHgrAnimf521aS0p58wVyYq8x8y XLdIFoAucwu2AMTMjx/MT5xbT5fEN3RLEaOpIGAdCAECwxxT2zpW9LiNBNXpt6XaGDw6 nwfw== X-Gm-Message-State: ALoCoQnt0X6V21HXrHxKo3AgIrIQMHoEx2XKNrt4KvF/f/uEiNrj6infzyZPh+wLP8hU+wC9JV8I X-Received: by 10.236.69.74 with SMTP id m50mr4349487yhd.0.1397675767156; Wed, 16 Apr 2014 12:16:07 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.85.99 with SMTP id m90ls830123qgd.12.gmail; Wed, 16 Apr 2014 12:16:07 -0700 (PDT) X-Received: by 10.220.106.84 with SMTP id w20mr3429126vco.18.1397675767028; Wed, 16 Apr 2014 12:16:07 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx.google.com with ESMTPS id kj3si3421481vdb.132.2014.04.16.12.16.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 12:16:07 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.128.173 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.173; Received: by mail-ve0-f173.google.com with SMTP id oy12so11158516veb.18 for ; Wed, 16 Apr 2014 12:16:06 -0700 (PDT) X-Received: by 10.220.162.6 with SMTP id t6mr4390441vcx.12.1397675766935; Wed, 16 Apr 2014 12:16:06 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.221.72 with SMTP id ib8csp336742vcb; Wed, 16 Apr 2014 12:16:06 -0700 (PDT) X-Received: by 10.229.17.69 with SMTP id r5mr6295901qca.7.1397675766235; Wed, 16 Apr 2014 12:16:06 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id b1si9539975qcs.28.2014.04.16.12.16.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Apr 2014 12:16:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WaVIE-0004nw-EF; Wed, 16 Apr 2014 19:14:46 +0000 Received: from mail-qa0-f45.google.com ([209.85.216.45]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WaVIC-0004ZS-E0 for linux-arm-kernel@lists.infradead.org; Wed, 16 Apr 2014 19:14:45 +0000 Received: by mail-qa0-f45.google.com with SMTP id cm18so10582026qab.18 for ; Wed, 16 Apr 2014 12:14:20 -0700 (PDT) X-Received: by 10.224.169.5 with SMTP id w5mr4926845qay.96.1397675660642; Wed, 16 Apr 2014 12:14:20 -0700 (PDT) Received: from xanadu.home (modemcable177.143-130-66.mc.videotron.ca. [66.130.143.177]) by mx.google.com with ESMTPSA id 1sm23106200qgg.5.2014.04.16.12.14.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 12:14:20 -0700 (PDT) Date: Wed, 16 Apr 2014 15:14:19 -0400 (EDT) From: Nicolas Pitre To: Christopher Covington Subject: Re: Change of TEXT_OFFSET for multi_v7_defconfig In-Reply-To: <534EAD6C.3040502@codeaurora.org> Message-ID: References: <534D0D91.8020406@linaro.org> <534EAD6C.3040502@codeaurora.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140416_121444_616884_B23DDC96 X-CRM114-Status: GOOD ( 29.63 ) X-Spam-Score: -0.7 (/) X-Spam-Report: SpamAssassin version 3.3.2 on bombadil.infradead.org summary: Content analysis details: (-0.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.45 listed in list.dnswl.org] Cc: Peter Maydell , Daniel Thompson , Joel Fernandes , linux-arm-msm@vger.kernel.org, Stephen Boyd , Peter Crosthwaite , QEMU Developers , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: , List-Help: , List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: nicolas.pitre@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.173 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 On Wed, 16 Apr 2014, Christopher Covington wrote: > On 04/15/2014 06:44 AM, Daniel Thompson wrote: > > Hi Folks > > > > I've just been rebasing some of my development branches against v3.15rc1 > > and observed some boot regressions due to TEXT_OFFSET changing from > > 0x8000 to 0x208000. > > > > Now the boot regression turned out to be fault in the JTAG boot tools I > > was using (it had internally hardcoded to TEXT_OFFSET to 0x8000 when > > calculating what physical load address to use). I've fixed the JTAG > > loader and my own boards now boots fine. > > Your tools are not alone in being affected by this change. QEMU is considering > changing their hard-coded value to 0x8000 [1], which I was eager to see until > being reminded of this (that patch would still be an improvement, but not > enough for users of new multiplatform kernels). > > The boot-wrapper [2] (the default bootloader for ARM's proprietary models > which could potentially be used on other systems) is also affected. Why would QEMU and the ARM boot-wrap-per care about the kernel TEXT_OFFSET value? I may understand the desire to boot a plain uncompressed Image over JTAG and in this case you are amongst a very small group of people doing so and therefore should be knowing what you're doing. In other words this is a minor inconvenient to a few people. But both QEMU and the boot-wrapper should deal with zImage. That's the only image format with documented load offset is guaranteed not to change i.e. it can be loaded at about any offset as zImage knows how to relocate itself as needed. There is nowhere a guarantee that TEXT_OFFSET can't change. And if you think booting zImage on ARM models is too slow, then simply try out CONFIG_KERNEL_LZO. > My current thinking is that even if we temporarily removed variance (the > jumping about) by maybe building every image with the maximum offset that any > image could have, there would still be variance between images built before > and after that change, and maybe also when some new platform gets added with > an even higher offset. So if there's going to be variance, could we maybe make > it no longer a problem? There is already no problem with zImage. > It seems to me that if external/uncompressed image loaders could query the > text offset in a straightforward manner, variance between images could be > easily dealt with. Would reading it out of ELF metadata be a reasonable > mechanism? Could the ELF format vmlinux be a suitable general replacement for > the raw Image? The ELF image only has virtual addresses in it. And the virtual address of the kernel may be changed independently of TEXT_OFFSET with CONFIG_VMSPLIT_*. > Now at least with my current .config, the vmlinux only has virtual addresses. > Documentation/arm/Booting says the MMU has to be off at boot time so this > still might not be the ideal input for image loaders. Tools could hard-code > the phsyical-to-virtual offset instead of the TEXT_OFFSET. Is that less likely > to vary? Physical offset does vary from one platform to another, so this particular physical-to-virtual offset is actually determined at run time and the kernel runtime patched during early boot -- see __fixup_pv_table in arch/arm/kernel/head.S. > Or could we patch up the linker script to set zero-based ELF load > memory addresses (LMAs) [4] so that the physical addresses are almost right, > you just might have to add a system-specific RAM offset, perhaps pulled out of > the device tree? If that won't work, we could generate some kind of > vmlinux-phys with physical addresses. The latter two options might also > simplify external debugging before __turn_mmu_on(). I like the sound of the > LMA approach best, assuming it doesn't break existing stuff (I notice a few AT > directives in vmlinux.lds.S). Some of this might transfer to arm64 as well. > What do you all think? If you really really want to get at the TEXT_OFFSET value in the uncompressed image, the simplest way would be: This way the first word for Image would always be 0xea000000 and the second one would be TEXT_OFFSET. No other kernel Image binaries ever had 0xea000000 as their first word so that also let you validate whether or not the TEXT_OFFSET value is there. Nicolas diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index f8c08839ed..de84d0635a 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -78,6 +78,11 @@ __HEAD ENTRY(stext) + + b 1f + .word TEXT_OFFSET @ located at a 4-byte offset in Image +1: + ARM_BE8(setend be ) @ ensure we are in BE8 mode THUMB( adr r9, BSYM(1f) ) @ Kernel is always entered in ARM.