From patchwork Tue Jun 4 05:27:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 2657011 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork1.kernel.org (Postfix) with ESMTP id 6A9D23FC8C for ; Tue, 4 Jun 2013 05:28:36 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UjjnL-0003MK-H5; Tue, 04 Jun 2013 05:28:31 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UjjnI-0001xb-S8; Tue, 04 Jun 2013 05:28:28 +0000 Received: from mail-qc0-x22e.google.com ([2607:f8b0:400d:c01::22e]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UjjnF-0001x8-AC for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2013 05:28:26 +0000 Received: by mail-qc0-f174.google.com with SMTP id m16so2657913qcq.19 for ; Mon, 03 Jun 2013 22:28:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:x-gm-message-state; bh=M+Ol/pQf4wPhDhjEEWxe5/8pIoQt6ID/zdeRSO6Ttfg=; b=dslWO4ntzGH1e8S4eyETYhVqj/vxjRdeuANHu/fBqoL1CWWtlFZ/yexzdyzzFKBGuI DXrEHtGkixjC99ba1XjzAInvydXN2mdCr4ljoGFPozh/vBXrSHq+YaY67I0cI5sayxn0 MuHOiJXdaYb8YkauyELXe/uOC1N6GENu503BZOntKiMAIY1w8Tso1vX37y8falKCwet7 7o7D6t1pGLjQnEiEoTkJJH59UHYmthEycyt+R7W6PKZ2yy/RRGyAL3fT6mcpuJS4c0eh Azs+KoX3NPRZyg5xTCxbcD3xGeb+f9fc3UGI9ua0AACKT2dLNK0bdme1fG3zYoYi7RjM rLZQ== X-Received: by 10.229.119.72 with SMTP id y8mr556886qcq.39.1370323682013; Mon, 03 Jun 2013 22:28:02 -0700 (PDT) Received: from xanadu.home (modemcable044.209-83-70.mc.videotron.ca. [70.83.209.44]) by mx.google.com with ESMTPSA id j3sm65155738qav.1.2013.06.03.22.28.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 22:28:01 -0700 (PDT) Date: Tue, 4 Jun 2013 01:27:59 -0400 (EDT) From: Nicolas Pitre To: Stephen Boyd Subject: Re: [PATCH] ARM: avoid mis-detecting some V7 cores in the decompressor In-Reply-To: <51AD1FE9.80709@codeaurora.org> Message-ID: References: <1368049671-22879-1-git-send-email-sboyd@codeaurora.org> <5193E424.9090605@codeaurora.org> <519E57D2.3050000@codeaurora.org> <20130523231531.GT18614@n2100.arm.linux.org.uk> <20130524220539.GB599@codeaurora.org> <51AD0703.6050408@codeaurora.org> <20130603222321.GP18614@n2100.arm.linux.org.uk> <51AD1AB3.9050908@codeaurora.org> <20130603224555.GR18614@n2100.arm.linux.org.uk> <51AD1FE9.80709@codeaurora.org> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQkQBTAs25FC8gTqXvpRKhFg1bXL2DD5xEjjUezc3IWjevJVGMG2b87We99DLFG3x+r2E2nh X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130604_012825_424172_DEAAB1EC X-CRM114-Status: GOOD ( 33.26 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Brian Swetland , Russell King - ARM Linux , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.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+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Mon, 3 Jun 2013, Stephen Boyd wrote: > On 06/03/13 15:45, Russell King - ARM Linux wrote: > > On Mon, Jun 03, 2013 at 03:37:39PM -0700, Stephen Boyd wrote: > >> In my case I'm booting a kernel with textoffset = 0x208000 but RAM > >> starts at 0x0. Does "minimum of RAM start" mean 0x0 or 0x200000? > > The basic requirement for zImage's is no less than the start of RAM > > plus 32K. Or let me put it another way - start of writable memory > > plus 32K. > > > > Whether you need an offset of 0x200000 or not is not for the > > decompressor to know. If you're having to avoid the first 0x200000 > > bytes of memory for some reason (eg, secure firmware or DSP needs > > it left free) then there's no way for the decompressor to know that, > > so it's irrelevant. > > > > So, lets say that your platform has a DSP which needs the first 0x200000 > > bytes left free. So the boot loader _already_ needs to know to load > > the image not at zero, but above 0x200000. The additional 32K > > requirement is really nothing new and so should be treated in just the > > same way. > > > > Leave at least 32K of usable memory below the zImage at all times. > > Understood. On my device writeable RAM actually starts at 0x0 but I have > compiled in support for devices which don't have writeable memory at > 0x0, instead they have writeable memory starting at 0x200000. Because I > have a kernel supporting more than one device with differing memory > layouts I run into this problem. The same problem will occur to any > devices in the multi-platform kernel when a device with unwriteable > memory near the bottom (such as MSM8960) joins the multi-platform defconfig. > > Let me try to word it in your example. I have compiled in support for a > platform that has a DSP which needs the first 0x200000 bytes left free. > I have also compiled in support for a platform that doesn't have this > requirement. I plan to run the zImage on the second platform (the one > without the DSP requirement). The bootloader I'm running this zImage on > has no idea that I've compiled in support for the other platform with > the DSP requirement so it assumes it can load the zImage at the start of > RAM (0x0) plus 32K. This is bad because then the page tables get written > into my compressed data and it fails to decompress. I've looked at the code and I think that #1 in your initial options is probably best here. I agree with Russell about #2 being way too complex for only this case. So, right before calling into cache_on, you could test if r4 - 16K >= pc and r4 < pc + (_end - .) then skip cache_on. Something like this untested patch: diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 9a94f344df..9e0dbbccdd 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -182,7 +182,16 @@ not_angel: ldr r4, =zreladdr #endif - bl cache_on + /* Set up a page table only if we don't overwrite ourself */ + ldr r0, 1f + add r0, r0, pc + cmp r4, r0 + mov r0, pc + cmpcc r0, r4 + blcs cache_on + b restart + .align 2 +1: .word _end - . + 0x4000 restart: adr r0, LC0 ldmia r0, {r1, r2, r3, r6, r10, r11, r12}