From: Mark Rutland <mark.rutland@arm.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: linux-meson@googlegroups.com, "Carlo Caione" <carlo@caione.org>,
linux-arm-kernel@lists.infradead.org,
"Matthias Brugger" <mbrugger@suse.com>,
"Nicolas Saenz" <nicolassaenzj@gmail.com>,
"André Przywara" <andre.przywara@arm.com>,
"Sudeep Holla" <sudeep.holla@arm.com>,
devicetree@vger.kernel.org,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will.deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/6] ARM64: meson: GXBaby (S905) and Vega S95 enablement
Date: Wed, 2 Mar 2016 15:17:03 +0000 [thread overview]
Message-ID: <20160302151703.GD11670@leverpostej> (raw)
In-Reply-To: <56D6F958.2000109@suse.de>
On Wed, Mar 02, 2016 at 03:31:52PM +0100, Andreas Färber wrote:
> 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:".
Sure; I appreciate you need a workaround for the broken bootloader
currently on the device.
I'm simply heading off any attempts to upstream such changes.
> 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.
As far as I am aware, this should not result in damage to your device.
However, it runs directly counter to single-image, and other parts of
the kernel _may_ rely on the existing limits on TEXT_OFFSET. So it's not
suitable for upstream, and you _may_ encounter issues as a result.
> > 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;
So the vendor deliberately changed the kernel Image in an unsupported
fashion, resulting in a divergent boot protocol.
This is incredibly unfortunate.
> 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 is probably the right path to a solution.
> >> 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
Yes, strictly speaking it is a change.
No, it is not a regression, since TEXT_OFFSET was _never_ open to such
platform-specific modification.
Thanks,
Mark.
next prev parent reply other threads:[~2016-03-02 15:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 2:34 [PATCH v2 0/6] ARM64: meson: GXBaby (S905) and Vega S95 enablement Andreas Färber
2016-03-02 2:34 ` [PATCH v2 1/6] ARM64: Enable Amlogic Meson GXBaby platform Andreas Färber
2016-03-02 2:34 ` [PATCH v2 2/6] devicetree: bindings: Add vendor prefix for Tronsmart Andreas Färber
2016-03-02 2:34 ` [PATCH v2 3/6] Documentation: devicetree: amlogic: Document Meson GXBaby Andreas Färber
2016-03-05 4:27 ` Rob Herring
2016-03-02 2:34 ` [PATCH v2 4/6] ARM64: dts: Prepare configs for Amlogic " Andreas Färber
2016-03-02 2:35 ` [PATCH v2 5/6] Documentation: devicetree: amlogic: Document Tronsmart Vega S95 boards Andreas Färber
2016-03-05 4:27 ` Rob Herring
2016-03-02 2:35 ` [PATCH v2 6/6] ARM64: dts: amlogic: Add Tronsmart Vega S95 configs Andreas Färber
2016-03-02 13:52 ` [PATCH v2 0/6] ARM64: meson: GXBaby (S905) and Vega S95 enablement Mark Rutland
2016-03-02 14:31 ` Andreas Färber
2016-03-02 15:17 ` Mark Rutland [this message]
2016-03-07 8:20 ` Carlo Caione
2016-03-21 22:36 ` Kevin Hilman
2016-03-22 20:29 ` Andreas Färber
2016-03-23 8:06 ` Carlo Caione
2016-03-23 18:10 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160302151703.GD11670@leverpostej \
--to=mark.rutland@arm.com \
--cc=afaerber@suse.de \
--cc=andre.przywara@arm.com \
--cc=carlo@caione.org \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-meson@googlegroups.com \
--cc=mbrugger@suse.com \
--cc=nicolassaenzj@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).