From patchwork Wed Mar 2 14:31:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Andreas_F=C3=A4rber?= X-Patchwork-Id: 8481161 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 9B6F39F314 for ; Wed, 2 Mar 2016 14:34:01 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A3ECE2035E for ; Wed, 2 Mar 2016 14:34:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 94FC32013D for ; Wed, 2 Mar 2016 14:33:59 +0000 (UTC) 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 1ab7p6-0000zZ-Vq; Wed, 02 Mar 2016 14:32:20 +0000 Received: from mx2.suse.de ([195.135.220.15]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ab7p3-0000hp-CL for linux-arm-kernel@lists.infradead.org; Wed, 02 Mar 2016 14:32:18 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4BDFDAC01; Wed, 2 Mar 2016 14:31:54 +0000 (UTC) Subject: Re: [PATCH v2 0/6] ARM64: meson: GXBaby (S905) and Vega S95 enablement To: Mark Rutland References: <1456886101-22967-1-git-send-email-afaerber@suse.de> <20160302135216.GB11670@leverpostej> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= X-Enigmail-Draft-Status: N1110 Organization: SUSE Linux GmbH Message-ID: <56D6F958.2000109@suse.de> Date: Wed, 2 Mar 2016 15:31:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302135216.GB11670@leverpostej> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160302_063217_844410_22B175D0 X-CRM114-Status: GOOD ( 16.61 ) X-Spam-Score: -1.9 (-) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Matthias Brugger , Catalin Marinas , linux-meson@googlegroups.com, Nicolas Saenz , Sudeep Holla , Will Deacon , LKML , =?UTF-8?Q?Andr=c3=a9_Przywara?= , Carlo Caione , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD,UNPARSEABLE_RELAY,WEIRD_PORT autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Am 02.03.2016 um 14:52 schrieb Mark Rutland: > On Wed, Mar 02, 2016 at 03:34:55AM +0100, Andreas Färber wrote: >> Note: On the Vega S95 I need to change TEXT_OFFSET as follows, >> in order to avoid the vendor U-Boot overwriting itself (fwiu); >> for the Mini Mx that's reportedly not necessary. >> >> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile >> index 354d75402ace..b7cebdb8b1ce 100644 >> --- a/arch/arm64/Makefile >> +++ b/arch/arm64/Makefile >> @@ -62,7 +62,7 @@ head-y := arch/arm64/kernel/head.o >> ifeq ($(CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET), y) >> TEXT_OFFSET := $(shell awk 'BEGIN {srand(); printf "0x%03x000\n", int(512 * rand())}') >> else >> -TEXT_OFFSET := 0x00080000 >> +TEXT_OFFSET := 0x01080000 >> endif >> >> # KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - 3)) - (1 << 61) > > Absolute NAK to this. TEXT_OFFSET is not open for platform-specific > modification. Please read again. There is nothing to NAK here, it's a workaround for testing my patches on my device! Even my own git queue has it clearly labeled as "HACK:". Nothing you say here indicates that this is breaking any particular kernel feature or damaging the device, so unless you propose a different way to solve the problem I see no way around it for now. > Why can you not just load the Image 2MB higher regardless? Does the > U-Boot on this platform actually read TEXT_OFFSET and take it into > account? Yes, U-Boot checks the ELF(?) header and tries to copy the image to the indicated offset if it isn't loaded there already. The vendor's kernel has the adjusted offset and works; if I use unmodified mainline kernels then I get weird exceptions from before entering the kernel, my assumption being that U-Boot code gets overwritten. http://openlinux.amlogic.com:8000/download/ARM/u-boot/ This problem might go away if we had a proper upstream-based U-Boot; I'm not familiar enough with U-Boot to fix that myself and would hate to mess with U-Boot on eMMC, for lack of JTAG pins on this device. The Odroid-C2 (which I do not have access to yet) has instructions how to place U-Boot on an SD card, making it safer to experiment with. http://odroid.com/dokuwiki/doku.php?id=en:c2_partition_table >> This in turn runs into an apparent regression introduced with the >> text offset randomization: >> >> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S >> index 6ebd204da16a..afdec27c8871 100644 >> --- a/arch/arm64/kernel/head.S >> +++ b/arch/arm64/kernel/head.S >> @@ -48,7 +48,7 @@ >> #elif (PAGE_OFFSET & 0x1fffff) != 0 >> #error PAGE_OFFSET must be at least 2MB aligned >> #elif TEXT_OFFSET > 0x1fffff >> -#error TEXT_OFFSET must be less than 2MB >> +//#error TEXT_OFFSET must be less than 2MB >> #endif >> >> #define KERNEL_START _text > > This is not a regression. As above, TEXT_OFFSET is not supposed to be > modified in a platform-specific manner. It is in fact an unexplained behavioral change in http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da57a369d3bc5cd61db90f7e9555840381db9b09 As you can see, previously 0x1080000 was a valid value, and this regressed with the new randomization feature. It obviously works with the larger offset for me, so the "must be" seems questionable. Regards, Andreas diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 3ba0fc0..69dafe9 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -37,8 +37,12 @@ #define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET) -#if (KERNEL_RAM_VADDR & 0xfffff) != 0x80000 -#error KERNEL_RAM_VADDR must start at 0xXXX80000 +#if (TEXT_OFFSET & 0xf) != 0 +#error TEXT_OFFSET must be at least 16B aligned +#elif (PAGE_OFFSET & 0xfffff) != 0 +#error PAGE_OFFSET must be at least 2MB aligned +#elif TEXT_OFFSET > 0xfffff +#error TEXT_OFFSET must be less than 2MB #endif .macro pgtbl, ttb0, ttb1, virt_to_phys