[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Stephen Warren]

All ARCHs have the same definition of MKIMAGE. Move it to Makefile.lib
to avoid duplication.

All ARCHs have similar definitions of cmd_uimage. Place a sufficiently
parameterized version in Makefile.lib to avoid duplication.

The centralized cmd_uimage definition will allow the future introduction
of a centralized Kconfig option to make cmd_uimage use -T kernel_noload
rather than -T kernel.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
---
NOTE: I have not tested this patch in any way at all for architectures
other than ARM.

 arch/arm/boot/Makefile          |   23 +++++++++--------------
 arch/avr32/boot/images/Makefile |    9 +++------
 arch/blackfin/boot/Makefile     |   19 ++++++++-----------
 arch/microblaze/boot/Makefile   |   10 +++-------
 arch/sh/boot/Makefile           |    8 ++------
 arch/sparc/boot/Makefile        |    9 +++------
 arch/unicore32/boot/Makefile    |   12 ++----------
 scripts/Makefile.lib            |   24 ++++++++++++++++++++++++
 8 files changed, 54 insertions(+), 60 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index fc871e7..c877087 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -11,8 +11,6 @@
 # Copyright (C) 1995-2002 Russell King
 #
 
-MKIMAGE         := $(srctree)/scripts/mkuboot.sh
-
 ifneq ($(MACHINE),)
 include $(srctree)/$(MACHINE)/Makefile.boot
 endif
@@ -69,22 +67,19 @@ $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
 
 clean-files := *.dtb
 
-quiet_cmd_uimage = UIMAGE  $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
-		   -C none -a $(LOADADDR) -e $(STARTADDR) \
-		   -n 'Linux-$(KERNELRELEASE)' -d $< $@
-
-ifeq ($(CONFIG_ZBOOT_ROM),y)
-$(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
+ifneq ($(LOADADDR),)
+  UIMAGE_LOADADDR=$(LOADADDR)
 else
-$(obj)/uImage: LOADADDR=$(ZRELADDR)
+  ifeq ($(CONFIG_ZBOOT_ROM),y)
+    UIMAGE_LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
+  else
+    UIMAGE_LOADADDR=$(ZRELADDR)
+  endif
 endif
 
-$(obj)/uImage: STARTADDR=$(LOADADDR)
-
 check_for_multiple_loadaddr = \
-if [ $(words $(LOADADDR)) -gt 1 ]; then \
-	echo 'multiple load addresses: $(LOADADDR)'; \
+if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \
+	echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \
 	echo 'This is incompatible with uImages'; \
 	echo 'Specify LOADADDR on the commandline to build an uImage'; \
 	false; \
diff --git a/arch/avr32/boot/images/Makefile b/arch/avr32/boot/images/Makefile
index 1848bf0..c9d8ab5 100644
--- a/arch/avr32/boot/images/Makefile
+++ b/arch/avr32/boot/images/Makefile
@@ -6,8 +6,6 @@
 # for more details.
 #
 
-MKIMAGE		:= $(srctree)/scripts/mkuboot.sh
-
 extra-y		:= vmlinux.bin vmlinux.gz
 
 OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note.gnu.build-id
@@ -17,10 +15,9 @@ $(obj)/vmlinux.bin: vmlinux FORCE
 $(obj)/vmlinux.gz: $(obj)/vmlinux.bin FORCE
 	$(call if_changed,gzip)
 
-quiet_cmd_uimage = UIMAGE $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A avr32 -O linux -T kernel	\
-		-C gzip -a $(CONFIG_LOAD_ADDRESS) -e $(CONFIG_ENTRY_ADDRESS)	\
-		-n 'Linux-$(KERNELRELEASE)' -d $< $@
+UIMAGE_LOADADDR = $(CONFIG_LOAD_ADDRESS
+UIMAGE_ENTRYADDR = $(CONFIG_ENTRY_ADDRESS)
+UIMAGE_COMPRESSION = gzip
 
 targets += uImage uImage.srec
 $(obj)/uImage: $(obj)/vmlinux.gz
diff --git a/arch/blackfin/boot/Makefile b/arch/blackfin/boot/Makefile
index 0a49279..6d2690a 100644
--- a/arch/blackfin/boot/Makefile
+++ b/arch/blackfin/boot/Makefile
@@ -6,20 +6,17 @@
 # for more details.
 #
 
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
-
 targets := vmImage vmImage.bin vmImage.bz2 vmImage.gz vmImage.lzma vmImage.lzo vmImage.xip
 extra-y += vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.lzo vmlinux.bin.xip
 
-UIMAGE_OPTS-y :=
-UIMAGE_OPTS-$(CONFIG_RAMKERNEL) += -a $(CONFIG_BOOT_LOAD)
-UIMAGE_OPTS-$(CONFIG_ROMKERNEL) += -a $(CONFIG_ROM_BASE) -x
-
-quiet_cmd_uimage = UIMAGE  $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(ARCH) -O linux -T kernel \
-                   -C $(2) -n '$(CPU_REV)-$(KERNELRELEASE)' \
-                   -e $(shell $(NM) vmlinux | awk '$$NF == "__start" {print $$1}') \
-                   $(UIMAGE_OPTS-y) -d $< $@
+ifeq ($(CONFIG_RAMKERNEL),y)
+UIMAGE_LOADADDR = $(CONFIG_BOOT_LOAD)
+else # CONFIG_ROMKERNEL must be set
+UIMAGE_LOADADDR = $(CONFIG_BOOT_LOAD)
+endif
+UIMAGE_ENTRYADDR = $(shell $(NM) vmlinux | awk '$$NF == "__start" {print $$1}')
+UIMAGE_NAME = '$(CPU_REV)-$(KERNELRELEASE)'
+UIMAGE_OPTS-$(CONFIG_ROMKERNEL) += -x
 
 $(obj)/vmlinux.bin: vmlinux FORCE
 	$(call if_changed,objcopy)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index 0c796cf..ca76ecd 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -2,8 +2,6 @@
 # arch/microblaze/boot/Makefile
 #
 
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
-
 obj-y += linked_dtb.o
 
 targets := linux.bin linux.bin.gz simpleImage.%
@@ -35,11 +33,9 @@ quiet_cmd_strip = STRIP   $@
 	cmd_strip = $(STRIP) -K microblaze_start -K _end -K __log_buf \
 				-K _fdt_start vmlinux -o $@
 
-quiet_cmd_uimage = UIMAGE  $@.ub
-	cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A microblaze -O linux -T kernel \
-		-C none -n 'Linux-$(KERNELRELEASE)' \
-		-a $(CONFIG_KERNEL_BASE_ADDR) -e $(CONFIG_KERNEL_BASE_ADDR) \
-		-d $@ $@.ub
+UIMAGE_IN = $@
+UIMAGE_OUT = $@.ub
+UIMAGE_LOADADDR = $(CONFIG_KERNEL_BASE_ADDR)
 
 $(obj)/simpleImage.%: vmlinux FORCE
 	$(call if_changed,cp,.unstrip)
diff --git a/arch/sh/boot/Makefile b/arch/sh/boot/Makefile
index e4ea31a..58592df 100644
--- a/arch/sh/boot/Makefile
+++ b/arch/sh/boot/Makefile
@@ -8,8 +8,6 @@
 # Copyright (C) 1999 Stuart Menefy
 #
 
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
-
 #
 # Assign safe dummy values if these variables are not defined,
 # in order to suppress error message.
@@ -61,10 +59,8 @@ KERNEL_ENTRY	:= $(shell /bin/bash -c 'printf "0x%08x" \
 			$(KERNEL_MEMORY) + \
 			$(CONFIG_ZERO_PAGE_OFFSET) + $(CONFIG_ENTRY_OFFSET)]')
 
-quiet_cmd_uimage = UIMAGE  $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A sh -O linux -T kernel \
-		   -C $(2) -a $(KERNEL_LOAD) -e $(KERNEL_ENTRY) \
-		   -n 'Linux-$(KERNELRELEASE)' -d $< $@
+UIMAGE_LOADADDR = $(KERNEL_LOAD)
+UIMAGE_ENTRYADDR = $(KERNEL_ENTRY)
 
 $(obj)/vmlinux.bin: vmlinux FORCE
 	$(call if_changed,objcopy)
diff --git a/arch/sparc/boot/Makefile b/arch/sparc/boot/Makefile
index 9205416..19e1bc7 100644
--- a/arch/sparc/boot/Makefile
+++ b/arch/sparc/boot/Makefile
@@ -5,7 +5,6 @@
 
 ROOT_IMG	:= /usr/src/root.img
 ELFTOAOUT	:= elftoaout
-MKIMAGE 	:= $(srctree)/scripts/mkuboot.sh
 
 hostprogs-y	:= piggyback btfixupprep
 targets		:= tftpboot.img btfix.o btfix.S image zImage vmlinux.aout
@@ -92,11 +91,9 @@ $(obj)/image.bin: $(obj)/image FORCE
 $(obj)/image.gz: $(obj)/image.bin
 	$(call if_changed,gzip)
 
-quiet_cmd_uimage = UIMAGE  $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A sparc -O linux -T kernel \
-               -C gzip -a $(CONFIG_UBOOT_LOAD_ADDR) \
-	       -e $(CONFIG_UBOOT_ENTRY_ADDR) -n 'Linux-$(KERNELRELEASE)' \
-               -d $< $@
+UIMAGE_LOADADDR = $(CONFIG_UBOOT_LOAD_ADDR
+UIMAGE_ENTRYADDR = $(CONFIG_UBOOT_ENTRY_ADDR)
+UIMAGE_COMPRESSION = gzip
 
 quiet_cmd_uimage.o = UIMAGE.O $@
       cmd_uimage.o = $(LD) -Tdata $(CONFIG_UBOOT_FLASH_ADDR) \
diff --git a/arch/unicore32/boot/Makefile b/arch/unicore32/boot/Makefile
index 79e5f88..ec7fb70 100644
--- a/arch/unicore32/boot/Makefile
+++ b/arch/unicore32/boot/Makefile
@@ -11,8 +11,6 @@
 # Copyright (C) 2001~2010 GUAN Xue-tao
 #
 
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
-
 targets := Image zImage uImage
 
 $(obj)/Image: vmlinux FORCE
@@ -26,14 +24,8 @@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
 	$(call if_changed,objcopy)
 	@echo '  Kernel: $@ is ready'
 
-quiet_cmd_uimage = UIMAGE  $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A unicore -O linux -T kernel \
-		   -C none -a $(LOADADDR) -e $(STARTADDR) \
-		   -n 'Linux-$(KERNELRELEASE)' -d $< $@
-
-$(obj)/uImage: LOADADDR=0x0
-
-$(obj)/uImage: STARTADDR=$(LOADADDR)
+UIMAGE_ARCH = unicore
+UIMAGE_LOADADDR = 0x0
 
 $(obj)/uImage: $(obj)/zImage FORCE
 	$(call if_changed,uimage)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 00c368c..7b0be18 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -304,6 +304,30 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
 	lzop -9 && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
 	(rm -f $@ ; false)
 
+# U-Boot mkimage
+# ---------------------------------------------------------------------------
+
+MKIMAGE := $(srctree)/scripts/mkuboot.sh
+
+# SRCARCH just happens to match slightly more than ARCH (on sparc), so reduces
+# the number of overrides in arch makefiles
+UIMAGE_ARCH = $(SRCARCH)
+UIMAGE_COMPRESSION = $(if $(2),$(2),none)
+UIMAGE_OPTS-y =
+UIMAGE_TYPE = kernel
+UIMAGE_LOADADDR=arch_must_set_this
+UIMAGE_ENTRYADDR=$(UIMAGE_LOADADDR)
+UIMAGE_NAME = 'Linux-$(KERNELRELEASE)'
+UIMAGE_IN = $<
+UIMAGE_OUT = $@
+
+quiet_cmd_uimage = UIMAGE  $(UIMAGE_OUT)
+      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \
+			-C $(UIMAGE_COMPRESSION) $(UIMAGE_OPTS-y) \
+			-T $(UIMAGE_TYPE) \
+			-a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
+			-n $(UIMAGE_NAME) -d $(UIMAGE_IN) $(UIMAGE_OUT)
+
 # XZ
 # ---------------------------------------------------------------------------
 # Use xzkern to compress the kernel image and xzmisc to compress other things.
-- 
1.7.0.4

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Stephen Warren]

This allows the user to use U-Boot's mkimage's -T kernel_noload option
if their arch Kconfig allows it, and they desire.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
---
The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
that some other architectures will also be able to enable it, but I'm
not familiar enough with any to know which.

 init/Kconfig         |   15 +++++++++++++++
 scripts/Makefile.lib |   15 ++++++++++++---
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 6cfd71d..2035562 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -203,6 +203,21 @@ config KERNEL_LZO
 
 endchoice
 
+config ALLOW_UIMAGE_KERNEL_NOLOAD
+	bool
+
+config UIMAGE_KERNEL_NOLOAD
+	bool "Use mkimage's -T kernel_noload instead of -T kernel"
+	depends on ALLOW_UIMAGE_KERNEL_NOLOAD
+	help
+	  uImage files of type "kernel" embed an absolute load and entry point
+	  address. If the uImage is loaded to a different address, then the
+	  image must be copied the uImage file to the specified load address.
+	  This copy is a waste of time if the uImage is in fact completely
+	  relocatable. If your kernel and bootloader support it, you can build
+	  a "kernel_noload" uImage rather than a "kernel" uImage, which
+	  prevents any such copying. If unsure say N.
+
 config DEFAULT_HOSTNAME
 	string "Default hostname"
 	default "(none)"
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7b0be18..d9c1c87 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -314,9 +314,18 @@ MKIMAGE := $(srctree)/scripts/mkuboot.sh
 UIMAGE_ARCH = $(SRCARCH)
 UIMAGE_COMPRESSION = $(if $(2),$(2),none)
 UIMAGE_OPTS-y =
-UIMAGE_TYPE = kernel
-UIMAGE_LOADADDR=arch_must_set_this
-UIMAGE_ENTRYADDR=$(UIMAGE_LOADADDR)
+ifeq ($(CONFIG_UIMAGE_KERNEL_NOLOAD),y)
+  UIMAGE_TYPE = kernel_noload
+  # Unused by bootloader:
+  UIMAGE_LOADADDR=0
+  # Entry point relative to actual load address:
+  UIMAGE_ENTRYADDR=0
+else
+  UIMAGE_TYPE = kernel
+  # Absolute addresses:
+  UIMAGE_LOADADDR=arch_must_set_this
+  UIMAGE_ENTRYADDR=$(UIMAGE_LOADADDR)
+endif
 UIMAGE_NAME = 'Linux-$(KERNELRELEASE)'
 UIMAGE_IN = $<
 UIMAGE_OUT = $@
-- 
1.7.0.4

[PATCH 3/3] ARM: Allow the user to enable UIMAGE_KERNEL_NOLOAD

[Stephen Warren]

When AUTO_ZRELADDR is enabled, ARM zImages are relocatable, and hence
the user may use mkimage's -T kernel_noload option if their bootloader
supports it.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4040796..5459b2e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2055,6 +2055,7 @@ config CRASH_DUMP
 
 config AUTO_ZRELADDR
 	bool "Auto calculation of the decompressed kernel image address"
+	select ALLOW_UIMAGE_KERNEL_NOLOAD
 	depends on !ZBOOT_ROM && !ARCH_U300
 	help
 	  ZRELADDR is the physical address where the decompressed kernel
-- 
1.7.0.4

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Julian Calaby]

Hi Stephen,

On Wed, Mar 7, 2012 at 11:30, Stephen Warren <swarren@wwwdotorg.org> wrote:
> This allows the user to use U-Boot's mkimage's -T kernel_noload option
> if their arch Kconfig allows it, and they desire.
>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> diff --git a/init/Kconfig b/init/Kconfig
> index 6cfd71d..2035562 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -203,6 +203,21 @@ config KERNEL_LZO
>
> ?endchoice
>
> +config ALLOW_UIMAGE_KERNEL_NOLOAD
> + ? ? ? bool
> +
> +config UIMAGE_KERNEL_NOLOAD
> + ? ? ? bool "Use mkimage's -T kernel_noload instead of -T kernel"
> + ? ? ? depends on ALLOW_UIMAGE_KERNEL_NOLOAD
> + ? ? ? help
> + ? ? ? ? uImage files of type "kernel" embed an absolute load and entry point
> + ? ? ? ? address. If the uImage is loaded to a different address, then the
> + ? ? ? ? image must be copied the uImage file to the specified load address.

You seem to have an excess "the uImage file" in here.

> + ? ? ? ? This copy is a waste of time if the uImage is in fact completely
> + ? ? ? ? relocatable. If your kernel and bootloader support it, you can build
> + ? ? ? ? a "kernel_noload" uImage rather than a "kernel" uImage, which
> + ? ? ? ? prevents any such copying. If unsure say N.
> +
> ?config DEFAULT_HOSTNAME
> ? ? ? ?string "Default hostname"
> ? ? ? ?default "(none)"

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Mike Frysinger]

On Tuesday 06 March 2012 19:30:36 Stephen Warren wrote:
> --- a/arch/blackfin/boot/Makefile
> +++ b/arch/blackfin/boot/Makefile
> 
> +ifeq ($(CONFIG_RAMKERNEL),y)
> +UIMAGE_LOADADDR = $(CONFIG_BOOT_LOAD)
> +else # CONFIG_ROMKERNEL must be set
> +UIMAGE_LOADADDR = $(CONFIG_BOOT_LOAD)
> +endif

this part is wrong :).  the else branch should be $(CONFIG_ROM_BASE).

> +UIMAGE_ENTRYADDR = $(shell $(NM) vmlinux | awk '$$NF == "__start" {print
> $$1}')

i feel like if we tried harder, we could automate the -e arg for all arches.  
i understand if you don't want to undertake that though.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120306/5db9b985/attachment-0001.sig>

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Guan Xuetao]

On Tue, 2012-03-06 at 17:30 -0700, Stephen Warren wrote:
> This allows the user to use U-Boot's mkimage's -T kernel_noload option
> if their arch Kconfig allows it, and they desire.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> that some other architectures will also be able to enable it, but I'm
> not familiar enough with any to know which.
> 
>  init/Kconfig         |   15 +++++++++++++++
>  scripts/Makefile.lib |   15 ++++++++++++---
>  2 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 6cfd71d..2035562 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -203,6 +203,21 @@ config KERNEL_LZO
>  
>  endchoice
>  
> +config ALLOW_UIMAGE_KERNEL_NOLOAD
> +	bool
> +
> +config UIMAGE_KERNEL_NOLOAD
> +	bool "Use mkimage's -T kernel_noload instead of -T kernel"
> +	depends on ALLOW_UIMAGE_KERNEL_NOLOAD
> +	help
> +	  uImage files of type "kernel" embed an absolute load and entry point
> +	  address. If the uImage is loaded to a different address, then the
> +	  image must be copied the uImage file to the specified load address.
> +	  This copy is a waste of time if the uImage is in fact completely
> +	  relocatable. If your kernel and bootloader support it, you can build
> +	  a "kernel_noload" uImage rather than a "kernel" uImage, which
> +	  prevents any such copying. If unsure say N.
> +
>  config DEFAULT_HOSTNAME
>  	string "Default hostname"
>  	default "(none)"
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 7b0be18..d9c1c87 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -314,9 +314,18 @@ MKIMAGE := $(srctree)/scripts/mkuboot.sh
>  UIMAGE_ARCH = $(SRCARCH)
>  UIMAGE_COMPRESSION = $(if $(2),$(2),none)
>  UIMAGE_OPTS-y =
> -UIMAGE_TYPE = kernel
> -UIMAGE_LOADADDR=arch_must_set_this
> -UIMAGE_ENTRYADDR=$(UIMAGE_LOADADDR)
> +ifeq ($(CONFIG_UIMAGE_KERNEL_NOLOAD),y)
> +  UIMAGE_TYPE = kernel_noload
> +  # Unused by bootloader:
> +  UIMAGE_LOADADDR=0
> +  # Entry point relative to actual load address:
> +  UIMAGE_ENTRYADDR=0
> +else
> +  UIMAGE_TYPE = kernel
> +  # Absolute addresses:
> +  UIMAGE_LOADADDR=arch_must_set_this
> +  UIMAGE_ENTRYADDR=$(UIMAGE_LOADADDR)
> +endif
>  UIMAGE_NAME = 'Linux-$(KERNELRELEASE)'
>  UIMAGE_IN = $<
>  UIMAGE_OUT = $@
Hi, Stephen,
It seems that UIMAGE_ARCH and UIMAGE_LOADADDR can't be modified from
arch-Makefiles.

Regards,

Guan Xuetao

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Hans-Christian Egtvedt]

Around Tue 06 Mar 2012 17:30:36 -0700 or thereabout, Stephen Warren wrote:
> All ARCHs have the same definition of MKIMAGE. Move it to Makefile.lib
> to avoid duplication.
> 
> All ARCHs have similar definitions of cmd_uimage. Place a sufficiently
> parameterized version in Makefile.lib to avoid duplication.
> 
> The centralized cmd_uimage definition will allow the future introduction
> of a centralized Kconfig option to make cmd_uimage use -T kernel_noload
> rather than -T kernel.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> NOTE: I have not tested this patch in any way at all for architectures
> other than ARM.
> 
>  arch/arm/boot/Makefile          |   23 +++++++++--------------
>  arch/avr32/boot/images/Makefile |    9 +++------

For the AVR32 related changes

Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>

-- 
Best regards, Hans-Christian Egtvedt

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Josh Boyer]

On Tue, Mar 6, 2012 at 7:30 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> All ARCHs have the same definition of MKIMAGE. Move it to Makefile.lib
> to avoid duplication.
>
> All ARCHs have similar definitions of cmd_uimage. Place a sufficiently
> parameterized version in Makefile.lib to avoid duplication.
>
> The centralized cmd_uimage definition will allow the future introduction
> of a centralized Kconfig option to make cmd_uimage use -T kernel_noload
> rather than -T kernel.
>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> NOTE: I have not tested this patch in any way at all for architectures
> other than ARM.
>
> ?arch/arm/boot/Makefile ? ? ? ? ?| ? 23 +++++++++--------------
> ?arch/avr32/boot/images/Makefile | ? ?9 +++------
> ?arch/blackfin/boot/Makefile ? ? | ? 19 ++++++++-----------
> ?arch/microblaze/boot/Makefile ? | ? 10 +++-------
> ?arch/sh/boot/Makefile ? ? ? ? ? | ? ?8 ++------
> ?arch/sparc/boot/Makefile ? ? ? ?| ? ?9 +++------
> ?arch/unicore32/boot/Makefile ? ?| ? 12 ++----------
> ?scripts/Makefile.lib ? ? ? ? ? ?| ? 24 ++++++++++++++++++++++++
> ?8 files changed, 54 insertions(+), 60 deletions(-)

Is there a reason you skipped powerpc?

josh

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Stephen Warren]

On 03/06/2012 08:56 PM, Mike Frysinger wrote:
> On Tuesday 06 March 2012 19:30:36 Stephen Warren wrote:
>> --- a/arch/blackfin/boot/Makefile
>> +++ b/arch/blackfin/boot/Makefile
>>
>> +ifeq ($(CONFIG_RAMKERNEL),y)
>> +UIMAGE_LOADADDR = $(CONFIG_BOOT_LOAD)
>> +else # CONFIG_ROMKERNEL must be set
>> +UIMAGE_LOADADDR = $(CONFIG_BOOT_LOAD)
>> +endif
> 
> this part is wrong :).  the else branch should be $(CONFIG_ROM_BASE).

Thanks. I've fixed that locally.

>> +UIMAGE_ENTRYADDR = $(shell $(NM) vmlinux | awk '$$NF == "__start" {print
>> $$1}')
> 
> i feel like if we tried harder, we could automate the -e arg for all arches.  
> i understand if you don't want to undertake that though.

Yes, this might be possible. I'd guess the symbol name varies between
archs, but that can probably be taken care of. This is probably best
left as a follow-on patch though, since it's a behavioral change,
whereas this patch is just consolidation.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> This allows the user to use U-Boot's mkimage's -T kernel_noload option
> if their arch Kconfig allows it, and they desire.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> that some other architectures will also be able to enable it, but I'm
> not familiar enough with any to know which.
I'm going to repeat. I don't think any impromevent here.

with no specific kernel load address the uImage for is useless/

And this no the job of the kernel to build a boot loader specific boot image
format.

And the uImage format here is called the legacy format where now U-Boot
support a new format based on DT format.

Will you plan to add it too?

no sorry I don't think it's the right way to go.

On X86 we boot zImage simply. The new uImage option to do not specify the load
address add nothing more than just boot a zImage for kernel point of view.

Further more on server the vendor will use grub mostly (even on ARM) and will
expect to boot a zImage.

Best Regards,,
J.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Stephen Warren]

On 03/06/2012 11:52 PM, Guan Xuetao wrote:
> On Tue, 2012-03-06 at 17:30 -0700, Stephen Warren wrote:
>> This allows the user to use U-Boot's mkimage's -T kernel_noload option
>> if their arch Kconfig allows it, and they desire.
...
> Hi, Stephen,
> It seems that UIMAGE_ARCH and UIMAGE_LOADADDR can't be modified from
> arch-Makefiles.

Oh dear, you're right. I suck at testing:-( I've fixed this locally.

For reference, Makefile.lib is included after the Makefile in the
relevant source directory, whereas my patch assumed the other way
around. So, rather than setting defaults in Makefile.lib and having
foo/Makefile override them, I should set the non-defaults in
foo/Makefile, and have Makefile.lib provide default values for variables
that aren't already set. Testing indicates this solves the problem!

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Mike Frysinger]

On Wednesday 07 March 2012 12:41:52 Stephen Warren wrote:
> On 03/06/2012 08:56 PM, Mike Frysinger wrote:
> > On Tuesday 06 March 2012 19:30:36 Stephen Warren wrote:
> >> +UIMAGE_ENTRYADDR = $(shell $(NM) vmlinux | awk '$$NF == "__start"
> >> {print $$1}')
> > 
> > i feel like if we tried harder, we could automate the -e arg for all
> > arches. i understand if you don't want to undertake that though.
> 
> Yes, this might be possible. I'd guess the symbol name varies between
> archs, but that can probably be taken care of.

i think we could avoid the symbol lookup.  if the entry point is set correctly 
in the ELF, we could do:
UIMAGE_ENTRYADDR = $(shell $(READELF) -h vmlinux | \
	awk '$$0 ~ /Entry point address:/ { print $$NF }'

99% sure this would work for Blackfin kernel images ...

> This is probably best
> left as a follow-on patch though, since it's a behavioral change,
> whereas this patch is just consolidation.

of course
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120307/0fe6ffb2/attachment.sig>

[PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions

[Stephen Warren]

On 03/07/2012 07:15 AM, Josh Boyer wrote:
> On Tue, Mar 6, 2012 at 7:30 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> All ARCHs have the same definition of MKIMAGE. Move it to Makefile.lib
>> to avoid duplication.
>>
>> All ARCHs have similar definitions of cmd_uimage. Place a sufficiently
>> parameterized version in Makefile.lib to avoid duplication.
>>
>> The centralized cmd_uimage definition will allow the future introduction
>> of a centralized Kconfig option to make cmd_uimage use -T kernel_noload
>> rather than -T kernel.
...
> Is there a reason you skipped powerpc?

grepping the powerpc makefiles showed no hits on MKIMAGE, mkimage or
cmd_uimage.

Looking a little harder now, this is all inside the shell script
arch/powerpc/boot/wrapper. I'm not really sure quite how to unify that
shell script with the makefile use of mkimage. Do you have any ideas?

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:40 Wed 07 Mar     , Stephen Warren wrote:
> On 03/07/2012 11:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> >> This allows the user to use U-Boot's mkimage's -T kernel_noload option
> >> if their arch Kconfig allows it, and they desire.
> >>
> >> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> >> ---
> >> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> >> that some other architectures will also be able to enable it, but I'm
> >> not familiar enough with any to know which.
> > I'm going to repeat. I don't think any impromevent here.
> > 
> > with no specific kernel load address the uImage for is useless/
> 
> No, the whole point of this type of kernel image is that it doesn't need
> a specific load address; the kernel zImage can run from anywhere in RAM
> (provided AUTO_ZRELADDR is enabled, subject to some slight
> restrictions), and hence the uImage doesn't need to be loaded to or
> moved to any particular location.
> 
> The scripts that U-Boot runs determine where the image gets loaded into
> memory.
so instead of spending time on the uImage add simply the support the zImage to
U-Boot as this AUTO_ZRELADDR have 0 advantage compare to the zImage

> 
> > And this no the job of the kernel to build a boot loader specific boot image
> > format.
> 
> Not everyone agrees with this.
so if a new boot loader apear or a new format the kernel will have to support
it. No
> 
> > And the uImage format here is called the legacy format where now U-Boot
> > support a new format based on DT format.
> > 
> > Will you plan to add it too?
> 
> No. The last time I heard anyone talk about that, it sounded like the
> adoption was basically zero, so it seems pointless. Personally, I find
> creating that kind of image more complex, and don't see any benefits in
> that format either.
> 
> > no sorry I don't think it's the right way to go.
> > 
> > On X86 we boot zImage simply. The new uImage option to do not specify the load
> > address add nothing more than just boot a zImage for kernel point of view.
> 
> U-Boot does not currently have the ability to boot zImage on ARM.
so add it and drop the uImage format
> 
> > Further more on server the vendor will use grub mostly (even on ARM) and will
> > expect to boot a zImage.
> 
> But that is irrelevant for the people who are using U-Boot not grub.
execpt the zIamge is the common boot format for all the server and PC and
other boot loader

Best Regards,
J.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Stephen Warren]

On 03/07/2012 11:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:30 Tue 06 Mar     , Stephen Warren wrote:
>> This allows the user to use U-Boot's mkimage's -T kernel_noload option
>> if their arch Kconfig allows it, and they desire.
>>
>> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
>> ---
>> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
>> that some other architectures will also be able to enable it, but I'm
>> not familiar enough with any to know which.
> I'm going to repeat. I don't think any impromevent here.
> 
> with no specific kernel load address the uImage for is useless/

No, the whole point of this type of kernel image is that it doesn't need
a specific load address; the kernel zImage can run from anywhere in RAM
(provided AUTO_ZRELADDR is enabled, subject to some slight
restrictions), and hence the uImage doesn't need to be loaded to or
moved to any particular location.

The scripts that U-Boot runs determine where the image gets loaded into
memory.

> And this no the job of the kernel to build a boot loader specific boot image
> format.

Not everyone agrees with this.

> And the uImage format here is called the legacy format where now U-Boot
> support a new format based on DT format.
> 
> Will you plan to add it too?

No. The last time I heard anyone talk about that, it sounded like the
adoption was basically zero, so it seems pointless. Personally, I find
creating that kind of image more complex, and don't see any benefits in
that format either.

> no sorry I don't think it's the right way to go.
> 
> On X86 we boot zImage simply. The new uImage option to do not specify the load
> address add nothing more than just boot a zImage for kernel point of view.

U-Boot does not currently have the ability to boot zImage on ARM.

> Further more on server the vendor will use grub mostly (even on ARM) and will
> expect to boot a zImage.

But that is irrelevant for the people who are using U-Boot not grub.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Nicolas Pitre]

On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > if their arch Kconfig allows it, and they desire.
> > 
> > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > ---
> > The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > that some other architectures will also be able to enable it, but I'm
> > not familiar enough with any to know which.
> I'm going to repeat. I don't think any impromevent here.

You know what?  I agree with you... on a conceptual level only though.

In reality, some people are are just too used to it, either for 
emotional reasons or simply because that's what was there before so they 
simply perpetuated it without thinking further, or whatever.  REmoving 
that support would just upset a lot of people.  And frankly we have 
better things to do than starting a flamewar over this.

So the next best thing is to make this u-Boot stuff well contained in a 
common place and make sure it doesn't spread incoherently over multiple 
architecture's directories and makefiles.  This way the u-Boot cruft 
won't be the ARM maintainer, or the PPC maintainer, or the SPARC 
maintainer, or any other architecture maintainer's business, but the 
responsibility of those who do care about it without affecting anyone 
else.

> And the uImage format here is called the legacy format where now U-Boot
> support a new format based on DT format.
> 
> Will you plan to add it too?

Why not if someone cares?  At least this will be done only 
once, centrally, without having to involve architecture maintainers.


Nicolas

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Nicolas Pitre]

On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 11:40 Wed 07 Mar     , Stephen Warren wrote:
> > On 03/07/2012 11:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > >> This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > >> if their arch Kconfig allows it, and they desire.
> > >>
> > >> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > >> ---
> > >> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > >> that some other architectures will also be able to enable it, but I'm
> > >> not familiar enough with any to know which.
> > > I'm going to repeat. I don't think any impromevent here.
> > > 
> > > with no specific kernel load address the uImage for is useless/
> > 
> > No, the whole point of this type of kernel image is that it doesn't need
> > a specific load address; the kernel zImage can run from anywhere in RAM
> > (provided AUTO_ZRELADDR is enabled, subject to some slight
> > restrictions), and hence the uImage doesn't need to be loaded to or
> > moved to any particular location.
> > 
> > The scripts that U-Boot runs determine where the image gets loaded into
> > memory.
> so instead of spending time on the uImage add simply the support the zImage to
> U-Boot as this AUTO_ZRELADDR have 0 advantage compare to the zImage

This was attempted in the past with the result that you might guess.

> > > And this no the job of the kernel to build a boot loader specific boot image
> > > format.
> > 
> > Not everyone agrees with this.
> so if a new boot loader apear or a new format the kernel will have to support
> it. No

Well, apparently new bootloaders are being corrupted by the u-Boot image 
format themselves.

And in the end I don't mind that much, as long as this is once again 
made architecture independent and therefore implemented in an 
architecture independent way in the kernel build system.

> > U-Boot does not currently have the ability to boot zImage on ARM.
> so add it and drop the uImage format

Why don't you try yourself?  I bet you already did in the past.

> > > Further more on server the vendor will use grub mostly (even on ARM) and will
> > > expect to boot a zImage.
> > 
> > But that is irrelevant for the people who are using U-Boot not grub.
> execpt the zIamge is the common boot format for all the server and PC and
> other boot loader

Look Jean-Christophe, we do have a kernel maintenance problem here.  
The goal of this patch series is to solve that maintenance problem while 
preserving the same level of support as before, not to change the world.


Nicolas

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:50 Wed 07 Mar     , Nicolas Pitre wrote:
> On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > > This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > > if their arch Kconfig allows it, and they desire.
> > > 
> > > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > > ---
> > > The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > > that some other architectures will also be able to enable it, but I'm
> > > not familiar enough with any to know which.
> > I'm going to repeat. I don't think any impromevent here.
> 
> You know what?  I agree with you... on a conceptual level only though.
> 
> In reality, some people are are just too used to it, either for 
> emotional reasons or simply because that's what was there before so they 
> simply perpetuated it without thinking further, or whatever.  REmoving 
> that support would just upset a lot of people.  And frankly we have 
> better things to do than starting a flamewar over this.
My concern is this new feature is available on new version of U-Boot only
and people that does not have it and built the uImage are going to ask the
question. Why bla bla bla....

Where people are supposed to RTFM

I do do not want to have the answer this and manage this.
> 
> So the next best thing is to make this u-Boot stuff well contained in a 
> common place and make sure it doesn't spread incoherently over multiple 
> architecture's directories and makefiles.  This way the u-Boot cruft 
> won't be the ARM maintainer, or the PPC maintainer, or the SPARC 
> maintainer, or any other architecture maintainer's business, but the 
> responsibility of those who do care about it without affecting anyone 
> else.
Ditto here

People does not read the doc they as lazy and I do not want to manage this.

> 
> > And the uImage format here is called the legacy format where now U-Boot
> > support a new format based on DT format.
> > 
> > Will you plan to add it too?
> 
> Why not if someone cares?  At least this will be done only 
> once, centrally, without having to involve architecture maintainers.
So you manage this because I will not answer one e-mail that ask for help
Because for my point of view RTFM or boot the zImage

Best Regards,
J.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Nicolas Pitre]

On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 13:50 Wed 07 Mar     , Nicolas Pitre wrote:
> > On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > 
> > > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > > > This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > > > if their arch Kconfig allows it, and they desire.
> > > > 
> > > > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > > > ---
> > > > The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > > > that some other architectures will also be able to enable it, but I'm
> > > > not familiar enough with any to know which.
> > > I'm going to repeat. I don't think any impromevent here.
> > 
> > You know what?  I agree with you... on a conceptual level only though.
> > 
> > In reality, some people are are just too used to it, either for 
> > emotional reasons or simply because that's what was there before so they 
> > simply perpetuated it without thinking further, or whatever.  REmoving 
> > that support would just upset a lot of people.  And frankly we have 
> > better things to do than starting a flamewar over this.
> My concern is this new feature is available on new version of U-Boot only
> and people that does not have it and built the uImage are going to ask the
> question. Why bla bla bla....
> 
> Where people are supposed to RTFM
> 
> I do do not want to have the answer this and manage this.

Well, just don't then.


Nicolas

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Stephen Warren]

On 03/07/2012 11:36 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:40 Wed 07 Mar     , Stephen Warren wrote:
>> On 03/07/2012 11:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 17:30 Tue 06 Mar     , Stephen Warren wrote:
>>>> This allows the user to use U-Boot's mkimage's -T kernel_noload option
>>>> if their arch Kconfig allows it, and they desire.
>>>>
>>>> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
>>>> ---
>>>> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
>>>> that some other architectures will also be able to enable it, but I'm
>>>> not familiar enough with any to know which.
>>> I'm going to repeat. I don't think any impromevent here.
>>>
>>> with no specific kernel load address the uImage for is useless/
>>
>> No, the whole point of this type of kernel image is that it doesn't need
>> a specific load address; the kernel zImage can run from anywhere in RAM
>> (provided AUTO_ZRELADDR is enabled, subject to some slight
>> restrictions), and hence the uImage doesn't need to be loaded to or
>> moved to any particular location.
>>
>> The scripts that U-Boot runs determine where the image gets loaded into
>> memory.
>
> so instead of spending time on the uImage add simply the support the zImage to
> U-Boot as this AUTO_ZRELADDR have 0 advantage compare to the zImage

Thinking more about this, I guess the reliance on AUTO_ZRELADDR is wrong
here; Russell, Nico, is the ARM decompressor fully position-independent
irrespective of the AUTO_ZRELADDR setting. That setting just determines
where the decompressor writes its output, not what address the
decompressor can run at, right? So, this KERNEL_NOLOAD feature could be
enabled in all cases on ARM, not only when AUTO_ZRELADDR is enabled.

As such to address Jean-Christophe's most recent comment above, this
patch isn't about adding support for AUTO_ZRELADDR, but for U-Boot's
kernel_noload feature, so comparisons should be drawn between
kernel_noload uImages and zImage, not between AUTO_ZRELADDR and zImage.

In other words:

We already have and need ZRELADDR no matter what, for reasons unrelated
to U-Boot/uImage.

Patch 1 in this series is just consolidating duplicate definitions, and
doesn't introduce any new features, so I think hope you think it's a
good thing no matter what anyone thinks about U-Boot/uImage.

I assume you're only arguing about patches 2 and 3?

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Nicolas Pitre]

On Wed, 7 Mar 2012, Stephen Warren wrote:

> On 03/07/2012 11:36 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:40 Wed 07 Mar     , Stephen Warren wrote:
> >> On 03/07/2012 11:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>> On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> >>>> This allows the user to use U-Boot's mkimage's -T kernel_noload option
> >>>> if their arch Kconfig allows it, and they desire.
> >>>>
> >>>> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> >>>> ---
> >>>> The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> >>>> that some other architectures will also be able to enable it, but I'm
> >>>> not familiar enough with any to know which.
> >>> I'm going to repeat. I don't think any impromevent here.
> >>>
> >>> with no specific kernel load address the uImage for is useless/
> >>
> >> No, the whole point of this type of kernel image is that it doesn't need
> >> a specific load address; the kernel zImage can run from anywhere in RAM
> >> (provided AUTO_ZRELADDR is enabled, subject to some slight
> >> restrictions), and hence the uImage doesn't need to be loaded to or
> >> moved to any particular location.
> >>
> >> The scripts that U-Boot runs determine where the image gets loaded into
> >> memory.
> >
> > so instead of spending time on the uImage add simply the support the zImage to
> > U-Boot as this AUTO_ZRELADDR have 0 advantage compare to the zImage
> 
> Thinking more about this, I guess the reliance on AUTO_ZRELADDR is wrong
> here; Russell, Nico, is the ARM decompressor fully position-independent
> irrespective of the AUTO_ZRELADDR setting.

Absolutely.

> That setting just determines where the decompressor writes its output, 
> not what address the decompressor can run at, right?

Right.

> So, this KERNEL_NOLOAD feature could be
> enabled in all cases on ARM, not only when AUTO_ZRELADDR is enabled.

Except when CONFIG_ZBOOT_ROM is selected (if the uImage format 
allows it), or when the u-Boot environment doesn't know where to load 
the uImage.

FWIW, I really hate this confusing usage of "noload" imposed on us by
we know who.  I thought better than contesting his definition though.

But yes, AUTO_ZRELADDR has no effect on the location where the zImage 
should be _loaded_, except for the 128MB restriction.

> As such to address Jean-Christophe's most recent comment above, this
> patch isn't about adding support for AUTO_ZRELADDR, but for U-Boot's
> kernel_noload feature, so comparisons should be drawn between
> kernel_noload uImages and zImage, not between AUTO_ZRELADDR and zImage.
> 
> In other words:
> 
> We already have and need ZRELADDR no matter what, for reasons unrelated
> to U-Boot/uImage.

Well, I do have a patch series getting rid of ZRELADDR entirely, and 
AUTO_ZRELADDR would then become implicit, unless CONFIG_PHYS_OFFSET is 
defined.


Nicolas

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Russell King - ARM Linux]

On Wed, Mar 07, 2012 at 01:27:50PM -0700, Stephen Warren wrote:
> Thinking more about this, I guess the reliance on AUTO_ZRELADDR is wrong
> here; Russell, Nico, is the ARM decompressor fully position-independent
> irrespective of the AUTO_ZRELADDR setting.

The standard decompressor is fully relocatable into any part of the system
which contains sufficient _RAM_ to contain the size of the zImage plus 64k
malloc space (that's including the BSS for the zImage.)

AUTO_ZRELADDR controls how the _decompressed_ kernel is placed, whether
it is placed at a fixed address controlled by the zreladdr-y symbol
in arch/arm/mach-*/Makefile.boot, or whether it is controlled by where
the zImage is placed - iow, (phys address & 0xf8000000) + TEXT_OFFSET.

> That setting just determines
> where the decompressor writes its output, not what address the
> decompressor can run at, right? So, this KERNEL_NOLOAD feature could be
> enabled in all cases on ARM, not only when AUTO_ZRELADDR is enabled.

I'm not entirely sure about that - there's at least the uboot on some
of the ARM devel platforms which relocates things like the ATAG list if
it's loading a uImage at 0x60008000 vs 0x00008000 (and we want it to be
at the 0x60008000 address so it can see 1GB of memory rather than just
256MB via the low mapping.)

So in some cases we do need control over where the uImage (or zImage)
is loaded by the boot loader.

> In other words:
> 
> We already have and need ZRELADDR no matter what, for reasons unrelated
> to U-Boot/uImage.

That's a tad icky... because a !AUTO_ZRELADDR kernel has no need for a
load address provided it ends up in RAM.  So, uboot enforcing a specific
load address more of an inconvenience rather than a problem.

However, for AUTO_ZRELADDR, the zImage does have to be placed in the
same 128M aligned block of RAM which you want the start of it to be
called PHYS_OFFSET.  So in that sense, an AUTO_ZRELADDR kernel is
more critical with its placement than a !AUTO_ZRELADDR kernel.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Russell King - ARM Linux]

On Wed, Mar 07, 2012 at 04:03:04PM -0500, Nicolas Pitre wrote:
> Well, I do have a patch series getting rid of ZRELADDR entirely, and 
> AUTO_ZRELADDR would then become implicit, unless CONFIG_PHYS_OFFSET is 
> defined.

Not possible, unless you're goign to also rip out uImage support.

Otherwise, how do we deal with platforms like Versatile Express where
uboot does a funky relocation of data depending on whether the uImage
it's loading is for the low 256MB RAM mapping or the high 1GB RAM
mapping.

[PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

[Nicolas Pitre]

On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:

> On Wed, Mar 07, 2012 at 04:03:04PM -0500, Nicolas Pitre wrote:
> > Well, I do have a patch series getting rid of ZRELADDR entirely, and 
> > AUTO_ZRELADDR would then become implicit, unless CONFIG_PHYS_OFFSET is 
> > defined.
> 
> Not possible, unless you're goign to also rip out uImage support.

I wish I could.  At least this new "noload" option would make uImage 
compatible with this.  That won't help existing u-Boot installations 
though, which is why I didn't post that patch series yet as I still 
haven't found a good fallback.

> Otherwise, how do we deal with platforms like Versatile Express where
> uboot does a funky relocation of data depending on whether the uImage
> it's loading is for the low 256MB RAM mapping or the high 1GB RAM
> mapping.

Doesn't it use AUTO_ZRELADDR?  With the newer u-Boot, you'd just load 
uImage to whatever address and u-Boot won't mess with it.


Nicolas