[PATCH 2/2] ARM: read kernel size from zImage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 01, 2017 at 09:10:36AM +0100, Simon Horman wrote:
> On Mon, Oct 23, 2017 at 11:08:34AM +0100, Russell King wrote:
> > Read the new extension data which tells the boot agent about the
> > requirements for booting the kernel image, such as how much RAM
> > will be consumed by the kernel through decompression and booting.
> > This is necessary to control the placement of the DTB and
> > compressed RAM disk to avoid these objects being corrupted.
> > 
> > Tested-by: Tony Lindgren <tony at atomide.com>
> > Signed-off-by: Russell King <rmk at armlinux.org.uk>
> 
> Thanks, applied.

Thanks, since I rebased my tree, I've realised that wasn't quite the
patch I intended, but it'll do for now.

Building the latest tree gives me a new warning:

gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt -D_FILE_OFFSET_BITS=64 -I./kexec/arch/arm/include  -c -MD -o kexec/kexec.o kexec/kexec.c
kexec/kexec.c: In function ?print_crashkernel_region_size?:
kexec/kexec.c:1232:9: warning: format ?%lu? expects argument of type ?long unsigned int?, but argument 2 has type ?uint64_t {aka long long unsigned int}? [-Wformat=]
  printf("%lu\n", (start != end) ? (end - start + 1) : 0UL);
         ^

caused by:

commit 76b31203222a9833f424e98a134603c2f840c82b
Author: Daniel Kiper <daniel.kiper at oracle.com>
Date:   Fri Feb 17 16:47:25 2017 -0600

    kexec: Add option to get crash kernel region size

On 32-bit architectures, "%lu" expects an unsigned long, but uint64_t is
an unsigned long long.  On 64-bit architectures, "%lu" also expects an
unsigned long, but uint64_t is unsigned long, so there's no warning.

The problem for ARM here is that a 64-bit value is passed as an
even-odd register pair, so for the above printf, that would be r2, r3.
However, "%lu" will expect the value in the first register following
the format pointer, that being r1.  So we end up printing garbage here.

Either we use "%llu" and cast the value to an unsigned long long
(needlessly widening on 64-bit arches), or "%lu" and cast to unsigned
long (truncating) or we need a definition of the format to be used for
uint64_t types (tends to be messy.)

-- 
Russell King



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux