From patchwork Mon Jun 16 20:27:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Geoff Levand X-Patchwork-Id: 4362681 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.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 788C69F26E for ; Mon, 16 Jun 2014 20:42:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 926E020304 for ; Mon, 16 Jun 2014 20:42:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AC4E1202EB for ; Mon, 16 Jun 2014 20:42:46 +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 1WwdV0-0003eM-UF; Mon, 16 Jun 2014 20:27:26 +0000 Received: from casper.infradead.org ([2001:770:15f::2]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WwdUy-0003eA-Jl for linux-arm-kernel@bombadil.infradead.org; Mon, 16 Jun 2014 20:27:24 +0000 Received: from 107-1-141-74-ip-static.hfc.comcastbusiness.net ([107.1.141.74] helo=[192.168.254.170]) by casper.infradead.org with esmtpsa (Exim 4.80.1 #2 (Red Hat Linux)) id 1WwdUu-0007qe-1Z; Mon, 16 Jun 2014 20:27:20 +0000 Message-ID: <1402950432.3708.22.camel@smoke> Subject: Re: [PATCH 3/4] arm64: export effective Image size to bootloaders From: Geoff Levand To: Mark Rutland Date: Mon, 16 Jun 2014 13:27:12 -0700 In-Reply-To: <1400233839-15140-4-git-send-email-mark.rutland@arm.com> References: <1400233839-15140-1-git-send-email-mark.rutland@arm.com> <1400233839-15140-4-git-send-email-mark.rutland@arm.com> X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Cc: peter.maydell@linaro.org, trini@kernel.crashing.org, marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, rob.herring@linaro.org, leif.lindholm@linaro.org, ijc@hellion.org.uk, dave.martin@arm.com, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 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 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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 Hi Mark, Sorry for such a delay in my reply. On Fri, 2014-05-16 at 10:50 +0100, Mark Rutland wrote: > Both the image load offset and the effective image size are forced to be > little-endian regardless of the native endianness of the kernel to > enable bootloaders to load a kernel of arbitrary endianness. Bootloaders > which wish to make use of the load offset can inspect the effective > image size field for a non-zero value to determine if the offset is of a > known endianness. Doing this conversion in the linker script seems complicated. My thought was to just have an image header field that specifies the byte order, in the same way that the EI_DATA part of the ELF e_ident field does. Another advantage of having the byte order in the header is that tools other than a boot loader that need to know the byte order can get that info from the header, otherwise they would need to guess the order with some kind of inspection. A patch I had planned to post for this is below. > --- a/Documentation/arm64/booting.txt > +++ b/Documentation/arm64/booting.txt > @@ -72,8 +72,8 @@ The decompressed kernel image contains a 64-byte header as follows: > > u32 code0; /* Executable code */ > u32 code1; /* Executable code */ > - u64 text_offset; /* Image load offset */ > - u64 res0 = 0; /* reserved */ > + u64 text_offset; /* Image load offset, little endian */ > + u64 image_size; /* Effective Image size, little endian */ It seems __le64 would be a better type to use here, if the value is decided to be little endian. > u64 res1 = 0; /* reserved */ > u64 res2 = 0; /* reserved */ > u64 res3 = 0; /* reserved */ > @@ -86,9 +86,27 @@ Header notes: From a63dd2f24105c55734238efaacdac5048bbedf39 Mon Sep 17 00:00:00 2001 From: Geoff Levand Date: Thu, 12 Jun 2014 11:23:23 -0700 Subject: [PATCH] arm64: Add byte order to image header When working with a raw arm64 image one needs to know the byte order of the image header to properly interpret the multi-byte values of the header. Add a character value to the image header indicating the byte order the image was built with: 1=LSB (little endian), 2=MSB (big endian), 0=no support. A zero value will indicate a kernel that pre-dates this change. Signed-off-by: Geoff Levand --- arch/arm64/kernel/head.S | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index b96a732..70c3656 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -109,7 +109,11 @@ * DO NOT MODIFY. Image header expected by Linux boot-loaders. */ b stext // branch to kernel start, magic - .long 0 // reserved + CPU_LE(.byte 1) // 1=LSB (little endian) + CPU_BE(.byte 2) // 2=MSB (big endian) + .byte 0 // reserved + .byte 0 // reserved + .byte 0 // reserved .quad TEXT_OFFSET // Image load offset from start of RAM .quad 0 // reserved .quad 0 // reserved