Re: [PATCH] ARM: zImage: ensure header in LE format for BE8 kernels

Nicolas Pitre [off-list ref] writes:

On Wed, 18 Jun 2014, Kevin Hilman wrote:

quoted

On Wed, Jun 18, 2014 at 11:22 AM, Stephen Boyd [off-list ref] wrote:

quoted

On 06/18/14 11:21, Kevin Hilman wrote:

quoted

On Wed, Jun 18, 2014 at 11:14 AM, Stephen Boyd [off-list ref] wrote:

quoted

On 06/18/14 10:55, Kevin Hilman wrote:

quoted

All of that to say, with this patch applied, I need a new (and
reliable) way to determine the endianness of a kernel just by looking
at the zImage.  Recommendations welcome.

Assuming that you have the .config configured to be built into the
kernel you could use extract-ikconfig

$ ./scripts/extract-ikconfig zImage | grep CONFIG_CPU_ENDIAN_BE8

Unfortunately, I can't rely on having that built in since I want the
boot tools to be as generic as possible.

Yeah ok. Perhaps you can look for the 'setend be' instruction right
after the magic values instead.

Yeah, that works, as long as I can always assume that instruction will
be at the same offset (currently at 0x30).

Well... then you also have to test for the Thumb2 variant. 

Ah, right.

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.

Kevin

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
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 <redacted>

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index c95feab6ce..413fd94b53 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S

@@ -128,6 +128,7 @@ start:
 		.word	_magic_sig	@ Magic numbers to help the loader
 		.word	_magic_start	@ absolute load/run zImage address
 		.word	_magic_end	@ zImage end address
+		.word	0x04030201	@ endianness flag
 
  THUMB(		.thumb			)
 1: