All of lore.kernel.org
 help / color / mirror / Atom feed
From: khilman@linaro.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: zImage: ensure header in LE format for BE8 kernels
Date: Thu, 19 Jun 2014 13:57:01 -0700	[thread overview]
Message-ID: <7hk38cvcrm.fsf@paris.lan> (raw)
In-Reply-To: <alpine.LFD.2.11.1406191630260.16842@knanqh.ubzr> (Nicolas Pitre's message of "Thu, 19 Jun 2014 16:32:12 -0400 (EDT)")

Nicolas Pitre <nicolas.pitre@linaro.org> writes:

> On Thu, 19 Jun 2014, Kevin Hilman wrote:
>
>> I think this should probably be officialized since we've taken away the
>> ability for magic-number checking tools (like 'file') to distinguish
>> between big- and little-endian zImages.
>> 
>> For now, I've updated my tools to check for 'setend be' in ARM and
>> Thumb2 mode, but if this does get officialized, I'll gladly move over to
>> it.
>
> Would you ACK this patch?
>
> ----- >8
> ARM: zImage: identify kernel endianness
>
> With patch #8067/1 applied, it is no longer possible to determine the

minor nit: I'd rather see a commit id (commit subject) instead of the
reference in RMK's patch tracker, but other than that...

> endianness of a compiled kernel image.  This normally shouldn't matter
> to the boot environment, except for those cases where the selection of
> a ramdisk or root filesystem with a matching endianness has to be
> automated.
>
> Let's add a flag to the zImage header indicating the actual endianness.
> Four bytes from offset 0x30 can be interpreted as follows:
>
> 	04 03 02 01	big endian kernel
>
> 	01 02 03 04	little endian kernel
>
> Anything else should be interpreted as "unknown", in which case it is
> most likely that patch #8067/1 was not applied either and the zImage
> magic number at offset 0x24 could be used instead to determine
> endianness. No zImage before this patch ever produced 0x01020304 nor
> 0x04030201 at offset 0x30 so there is no confusion possible.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>

Acked-by: Kevin Hilman <khilman@linaro.org>

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@linaro.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	Taras Kondratiuk <taras.kondratiuk@linaro.org>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Russell King <linux@arm.linux.org.uk>,
	Jason Cooper <jason@lakedaemon.net>,
	Victor Kamensky <victor.kamensky@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Dooks <ben.dooks@codethink.co.uk>,
	Olof Johansson <olof@lixom.net>,
	Linaro Networking <linaro-networking@linaro.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: zImage: ensure header in LE format for BE8 kernels
Date: Thu, 19 Jun 2014 13:57:01 -0700	[thread overview]
Message-ID: <7hk38cvcrm.fsf@paris.lan> (raw)
In-Reply-To: <alpine.LFD.2.11.1406191630260.16842@knanqh.ubzr> (Nicolas Pitre's message of "Thu, 19 Jun 2014 16:32:12 -0400 (EDT)")

Nicolas Pitre <nicolas.pitre@linaro.org> writes:

> On Thu, 19 Jun 2014, Kevin Hilman wrote:
>
>> I think this should probably be officialized since we've taken away the
>> ability for magic-number checking tools (like 'file') to distinguish
>> between big- and little-endian zImages.
>> 
>> For now, I've updated my tools to check for 'setend be' in ARM and
>> Thumb2 mode, but if this does get officialized, I'll gladly move over to
>> it.
>
> Would you ACK this patch?
>
> ----- >8
> ARM: zImage: identify kernel endianness
>
> With patch #8067/1 applied, it is no longer possible to determine the

minor nit: I'd rather see a commit id (commit subject) instead of the
reference in RMK's patch tracker, but other than that...

> endianness of a compiled kernel image.  This normally shouldn't matter
> to the boot environment, except for those cases where the selection of
> a ramdisk or root filesystem with a matching endianness has to be
> automated.
>
> Let's add a flag to the zImage header indicating the actual endianness.
> Four bytes from offset 0x30 can be interpreted as follows:
>
> 	04 03 02 01	big endian kernel
>
> 	01 02 03 04	little endian kernel
>
> Anything else should be interpreted as "unknown", in which case it is
> most likely that patch #8067/1 was not applied either and the zImage
> magic number at offset 0x24 could be used instead to determine
> endianness. No zImage before this patch ever produced 0x01020304 nor
> 0x04030201 at offset 0x30 so there is no confusion possible.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>

Acked-by: Kevin Hilman <khilman@linaro.org>

  reply	other threads:[~2014-06-19 20:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10 16:27 [PATCH] ARM: zImage: ensure header in LE format for BE8 kernels Taras Kondratiuk
2014-04-10 16:27 ` Taras Kondratiuk
2014-04-10 17:03 ` Nicolas Pitre
2014-04-10 17:03   ` Nicolas Pitre
2014-06-17 14:29 ` Russell King - ARM Linux
2014-06-17 14:29   ` Russell King - ARM Linux
2014-06-17 16:07   ` Nicolas Pitre
2014-06-17 16:07     ` Nicolas Pitre
2014-06-18 17:55 ` Kevin Hilman
2014-06-18 17:55   ` Kevin Hilman
2014-06-18 18:14   ` Stephen Boyd
2014-06-18 18:14     ` Stephen Boyd
2014-06-18 18:21     ` Kevin Hilman
2014-06-18 18:21       ` Kevin Hilman
2014-06-18 18:22       ` Stephen Boyd
2014-06-18 18:22         ` Stephen Boyd
2014-06-18 19:01         ` Kevin Hilman
2014-06-18 19:01           ` Kevin Hilman
2014-06-18 21:35           ` Nicolas Pitre
2014-06-18 21:35             ` Nicolas Pitre
2014-06-19 18:27             ` Kevin Hilman
2014-06-19 18:27               ` Kevin Hilman
2014-06-19 20:32               ` Nicolas Pitre
2014-06-19 20:32                 ` Nicolas Pitre
2014-06-19 20:57                 ` Kevin Hilman [this message]
2014-06-19 20:57                   ` Kevin Hilman
2014-06-19 21:49                   ` Nicolas Pitre
2014-06-19 21:49                     ` Nicolas Pitre

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=7hk38cvcrm.fsf@paris.lan \
    --to=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.