[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

uImage files typically encode a single absolute load and entry address.
This is inconvenient when attempting to share that uImage across multiple
SoCs with different physical RAM addresses. Recent versions of mkimage
implement a "kernel_noload" image type which encodes no absolute load
address, and a relative entry address. This works well for uImage-wrapped
ARM zImages, since they are relocatable.

This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
"image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
I assume I should put this into the ARM patch tracker if it's OK?

 arch/arm/Kconfig       |   15 +++++++++++++++
 arch/arm/boot/Makefile |   15 ++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0884b67..27e7672 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2066,6 +2066,21 @@ config AUTO_ZRELADDR
 	  0xf8000000. This assumes the zImage being placed in the first 128MB
 	  from start of memory.
 
+config UIMAGE_NOLOAD
+	bool "Using mkimage's kernel_noload image type"
+	depends on AUTO_ZRELADDR
+	help
+	  Say Y here to build a uImage using type "kernel_noload" instead of
+	  "kernel".
+
+	  uImage files typically encode a single absolute load and entry
+	  address. This is inconvenient when attempting to share that uImage
+	  across multiple SoCs with different physical RAM addresses. Recent
+	  versions of mkimage implement a "kernel_noload" image type which
+	  encodes no absolute load address, and a relative entry address.
+	  This works well for uImage-wrapped ARM zImages, since they are
+	  relocatable.
+
 endmenu
 
 menu "CPU Power Management"
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index fc871e7..45c3cbe 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -70,10 +70,21 @@ $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
 clean-files := *.dtb
 
 quiet_cmd_uimage = UIMAGE  $@
-      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
+      cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux \
+		   -T $(UIMAGE_TYPE) \
 		   -C none -a $(LOADADDR) -e $(STARTADDR) \
 		   -n 'Linux-$(KERNELRELEASE)' -d $< $@
 
+ifeq ($(CONFIG_UIMAGE_NOLOAD),y)
+
+$(obj)/uImage: UIMAGE_TYPE := kernel_noload
+$(obj)/uImage: override LOADADDR := 0
+$(obj)/uImage: STARTADDR := 0 # Relative to load address
+
+else
+
+$(obj)/uImage: UIMAGE_TYPE := kernel
+
 ifeq ($(CONFIG_ZBOOT_ROM),y)
 $(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
 else
@@ -82,6 +93,8 @@ endif
 
 $(obj)/uImage: STARTADDR=$(LOADADDR)
 
+endif
+
 check_for_multiple_loadaddr = \
 if [ $(words $(LOADADDR)) -gt 1 ]; then \
 	echo 'multiple load addresses: $(LOADADDR)'; \
-- 
1.7.0.4

[PATCH 2/2] ARM: tegra: Add zreladdr etc to Makefile.boot for Tegra30

[Stephen Warren]

These previously weren't present, because they're different for Tegra20
and Tegra30, which forced one to specify LOADADDR= when building uImages
for kernels with both Tegra20 and Tegra30 support enabled.

My expectation now is that everyone will turn on CONFIG_UIMAGE_NOLOAD and
hence not be inconvenienced by having this information present.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This somewhat depends on the previous patch or it'll be annoying to build
multi-SoC Tegra kernels, so I guess it should get merged through the same
tree.

 arch/arm/mach-tegra/Makefile.boot |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index 9a82094..b6101f8 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -2,6 +2,10 @@ zreladdr-$(CONFIG_ARCH_TEGRA_2x_SOC)	+= 0x00008000
 params_phys-$(CONFIG_ARCH_TEGRA_2x_SOC)	:= 0x00000100
 initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC)	:= 0x00800000
 
+zreladdr-$(CONFIG_ARCH_TEGRA_3x_SOC)	+= 0x80008000
+params_phys-$(CONFIG_ARCH_TEGRA_3x_SOC)	:= 0x80000100
+initrd_phys-$(CONFIG_ARCH_TEGRA_3x_SOC)	:= 0x80800000
+
 dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
 dtb-$(CONFIG_MACH_PAZ00) += tegra-paz00.dtb
 dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
-- 
1.7.0.4

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> uImage files typically encode a single absolute load and entry address.
> This is inconvenient when attempting to share that uImage across multiple
> SoCs with different physical RAM addresses. Recent versions of mkimage
> implement a "kernel_noload" image type which encodes no absolute load
> address, and a relative entry address. This works well for uImage-wrapped
> ARM zImages, since they are relocatable.
> 
> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> I assume I should put this into the ARM patch tracker if it's OK?
Again a new option for uImage no why not just boot the zImage

in this case the uImage is useless

Best Regards,
J.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> > uImage files typically encode a single absolute load and entry address.
> > This is inconvenient when attempting to share that uImage across multiple
> > SoCs with different physical RAM addresses. Recent versions of mkimage
> > implement a "kernel_noload" image type which encodes no absolute load
> > address, and a relative entry address. This works well for uImage-wrapped
> > ARM zImages, since they are relocatable.
> >
> > This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> >
> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > ---
> > I assume I should put this into the ARM patch tracker if it's OK?
>
> Again a new option for uImage no why not just boot the zImage
> 
> in this case the uImage is useless

U-Boot doesn't support zImage at present.

A patch was posted to support it at least for ARM, but needed a little
work before it could be committed.

-- 
nvpublic

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
> > On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> > > uImage files typically encode a single absolute load and entry address.
> > > This is inconvenient when attempting to share that uImage across multiple
> > > SoCs with different physical RAM addresses. Recent versions of mkimage
> > > implement a "kernel_noload" image type which encodes no absolute load
> > > address, and a relative entry address. This works well for uImage-wrapped
> > > ARM zImages, since they are relocatable.
> > >
> > > This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > > "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> > >
> > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > ---
> > > I assume I should put this into the ARM patch tracker if it's OK?
> >
> > Again a new option for uImage no why not just boot the zImage
> > 
> > in this case the uImage is useless
> 
> U-Boot doesn't support zImage at present.
> 
> A patch was posted to support it at least for ARM, but needed a little
> work before it could be committed.
Sorry I see no advantage to have the uImage build by the kernel anymore as
we have a relocatable zImage

I'll even drop its support

Best Regards,
J.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Tim Bird]

On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:58 Wed 29 Feb     , Stephen Warren wrote:
>> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
>>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
>>>> uImage files typically encode a single absolute load and entry address.
>>>> This is inconvenient when attempting to share that uImage across multiple
>>>> SoCs with different physical RAM addresses. Recent versions of mkimage
>>>> implement a "kernel_noload" image type which encodes no absolute load
>>>> address, and a relative entry address. This works well for uImage-wrapped
>>>> ARM zImages, since they are relocatable.
>>>>
>>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
>>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
>>>>
>>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>>> ---
>>>> I assume I should put this into the ARM patch tracker if it's OK?
>>>
>>> Again a new option for uImage no why not just boot the zImage
>>>
>>> in this case the uImage is useless
>>
>> U-Boot doesn't support zImage at present.
>>
>> A patch was posted to support it at least for ARM, but needed a little
>> work before it could be committed.
> Sorry I see no advantage to have the uImage build by the kernel anymore as
> we have a relocatable zImage
> 
> I'll even drop its support

This seems at least premature, and possibly ill-advised in general.
There are lots of U-Boot images out in the field, many of which that
are rarely updated. A lot of workflow will be disrupted unnecessarily
by a change like this.

Could you wait to drop uImage build support in the kernel until
U-Boot supports zImage, and has worked it's way into the field
for a few years?
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:33 Wed 29 Feb     , Tim Bird wrote:
> On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> >> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
> >>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> >>>> uImage files typically encode a single absolute load and entry address.
> >>>> This is inconvenient when attempting to share that uImage across multiple
> >>>> SoCs with different physical RAM addresses. Recent versions of mkimage
> >>>> implement a "kernel_noload" image type which encodes no absolute load
> >>>> address, and a relative entry address. This works well for uImage-wrapped
> >>>> ARM zImages, since they are relocatable.
> >>>>
> >>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> >>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> >>>>
> >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >>>> ---
> >>>> I assume I should put this into the ARM patch tracker if it's OK?
> >>>
> >>> Again a new option for uImage no why not just boot the zImage
> >>>
> >>> in this case the uImage is useless
> >>
> >> U-Boot doesn't support zImage at present.
> >>
> >> A patch was posted to support it at least for ARM, but needed a little
> >> work before it could be committed.
> > Sorry I see no advantage to have the uImage build by the kernel anymore as
> > we have a relocatable zImage
> > 
> > I'll even drop its support
> 
> This seems at least premature, and possibly ill-advised in general.
> There are lots of U-Boot images out in the field, many of which that
> are rarely updated. A lot of workflow will be disrupted unnecessarily
> by a change like this.
> 
> Could you wait to drop uImage build support in the kernel until
> U-Boot supports zImage, and has worked it's way into the field
> for a few years?
I'm fine to keep for now on but not to add new feature

Barebox (former U-Boot v2) support zImage for quite a while and
relocable one for too.

Best Regards,
J.
>  -- Tim
> 
> =============================
> Tim Bird
> Architecture Group Chair, CE Workgroup of the Linux Foundation
> Senior Staff Engineer, Sony Network Entertainment
> =============================
> 

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Marek Vasut]

Dear Jean-Christophe PLAGNIOL-VILLARD,

> On 10:33 Wed 29 Feb     , Tim Bird wrote:
> > On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> > >> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 
5:30 AM:
> > >>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> > >>>> uImage files typically encode a single absolute load and entry
> > >>>> address. This is inconvenient when attempting to share that uImage
> > >>>> across multiple SoCs with different physical RAM addresses. Recent
> > >>>> versions of mkimage implement a "kernel_noload" image type which
> > >>>> encodes no absolute load address, and a relative entry address.
> > >>>> This works well for uImage-wrapped ARM zImages, since they are
> > >>>> relocatable.
> > >>>> 
> > >>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > >>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> > >>>> 
> > >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > >>>> ---
> > >>>> I assume I should put this into the ARM patch tracker if it's OK?
> > >>> 
> > >>> Again a new option for uImage no why not just boot the zImage
> > >>> 
> > >>> in this case the uImage is useless
> > >> 
> > >> U-Boot doesn't support zImage at present.
> > >> 
> > >> A patch was posted to support it at least for ARM, but needed a little
> > >> work before it could be committed.
> > > 
> > > Sorry I see no advantage to have the uImage build by the kernel anymore
> > > as we have a relocatable zImage
> > > 
> > > I'll even drop its support
> > 
> > This seems at least premature, and possibly ill-advised in general.
> > There are lots of U-Boot images out in the field, many of which that
> > are rarely updated. A lot of workflow will be disrupted unnecessarily
> > by a change like this.
> > 
> > Could you wait to drop uImage build support in the kernel until
> > U-Boot supports zImage, and has worked it's way into the field
> > for a few years?
> 
> I'm fine to keep for now on but not to add new feature
> 
> Barebox (former U-Boot v2) support zImage for quite a while and
> relocable one for too.

On the other hand, noone uses barebox and you should stop with this obvious 
malice towards uboot please. I believe for most people it's easier to spend time 
only on implementing their hardware support into U-Boot, not waste time 
implementing basic components that are still missing in barebox.

Last but not least, the uImage contains additional checksum on the whole image, 
which is useful on flash media.

That said, I'm all for having uImage support in kernel and for adding this 
NOLOAD option.

Best regards,
Marek Vasut

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:40 Mon 12 Mar     , Marek Vasut wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> > On 10:33 Wed 29 Feb     , Tim Bird wrote:
> > > On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> > > >> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 
> 5:30 AM:
> > > >>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> > > >>>> uImage files typically encode a single absolute load and entry
> > > >>>> address. This is inconvenient when attempting to share that uImage
> > > >>>> across multiple SoCs with different physical RAM addresses. Recent
> > > >>>> versions of mkimage implement a "kernel_noload" image type which
> > > >>>> encodes no absolute load address, and a relative entry address.
> > > >>>> This works well for uImage-wrapped ARM zImages, since they are
> > > >>>> relocatable.
> > > >>>> 
> > > >>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > > >>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> > > >>>> 
> > > >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > >>>> ---
> > > >>>> I assume I should put this into the ARM patch tracker if it's OK?
> > > >>> 
> > > >>> Again a new option for uImage no why not just boot the zImage
> > > >>> 
> > > >>> in this case the uImage is useless
> > > >> 
> > > >> U-Boot doesn't support zImage at present.
> > > >> 
> > > >> A patch was posted to support it at least for ARM, but needed a little
> > > >> work before it could be committed.
> > > > 
> > > > Sorry I see no advantage to have the uImage build by the kernel anymore
> > > > as we have a relocatable zImage
> > > > 
> > > > I'll even drop its support
> > > 
> > > This seems at least premature, and possibly ill-advised in general.
> > > There are lots of U-Boot images out in the field, many of which that
> > > are rarely updated. A lot of workflow will be disrupted unnecessarily
> > > by a change like this.
> > > 
> > > Could you wait to drop uImage build support in the kernel until
> > > U-Boot supports zImage, and has worked it's way into the field
> > > for a few years?
> > 
> > I'm fine to keep for now on but not to add new feature
> > 
> > Barebox (former U-Boot v2) support zImage for quite a while and
> > relocable one for too.
> 
> On the other hand, noone uses barebox and you should stop with this obvious 
> malice towards uboot please. I believe for most people it's easier to spend time 
> only on implementing their hardware support into U-Boot, not waste time 
> implementing basic components that are still missing in barebox.
Speak for yourself please
> 
> Last but not least, the uImage contains additional checksum on the whole image, 
> which is useful on flash media.
>
> That said, I'm all for having uImage support in kernel and for adding this 
> NOLOAD option.
I'm going to repeat myself, we work on kernel here NOT bootloader specific bla
bla. The standard image for the kernel is zImage. After if you want to use
your specifc bootloader stuff do it outside of the kernel.

My comment is the same for ANY bootloader. Do your specifc stuff at your place
not HERE.

Best Regards,
J.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Uwe Kleine-König]

On Wed, Feb 29, 2012 at 10:33:58AM -0800, Tim Bird wrote:
> On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> >> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
> >>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> >>>> uImage files typically encode a single absolute load and entry address.
> >>>> This is inconvenient when attempting to share that uImage across multiple
> >>>> SoCs with different physical RAM addresses. Recent versions of mkimage
> >>>> implement a "kernel_noload" image type which encodes no absolute load
> >>>> address, and a relative entry address. This works well for uImage-wrapped
> >>>> ARM zImages, since they are relocatable.
> >>>>
> >>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> >>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> >>>>
> >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >>>> ---
> >>>> I assume I should put this into the ARM patch tracker if it's OK?
> >>>
> >>> Again a new option for uImage no why not just boot the zImage
> >>>
> >>> in this case the uImage is useless
> >>
> >> U-Boot doesn't support zImage at present.
> >>
> >> A patch was posted to support it at least for ARM, but needed a little
> >> work before it could be committed.
> > Sorry I see no advantage to have the uImage build by the kernel anymore as
> > we have a relocatable zImage
> > 
> > I'll even drop its support
> 
> This seems at least premature, and possibly ill-advised in general.
> There are lots of U-Boot images out in the field, many of which that
> are rarely updated. A lot of workflow will be disrupted unnecessarily
> by a change like this.
> 
> Could you wait to drop uImage build support in the kernel until
> U-Boot supports zImage, and has worked it's way into the field
> for a few years?
I admit I didn't check for a few years, but regarding that the values
used to build the uImage from a zImage are (or at least were) quite bad,
I'd say deprecate the uImage target today.

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:12 PM:
> On Wed, Feb 29, 2012 at 10:33:58AM -0800, Tim Bird wrote:
> > On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> > >> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
> > >>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> > >>>> uImage files typically encode a single absolute load and entry address.
> > >>>> This is inconvenient when attempting to share that uImage across multiple
> > >>>> SoCs with different physical RAM addresses. Recent versions of mkimage
> > >>>> implement a "kernel_noload" image type which encodes no absolute load
> > >>>> address, and a relative entry address. This works well for uImage-wrapped
> > >>>> ARM zImages, since they are relocatable.
> > >>>>
> > >>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > >>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> > >>>>
> > >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > >>>> ---
> > >>>> I assume I should put this into the ARM patch tracker if it's OK?
> > >>>
> > >>> Again a new option for uImage no why not just boot the zImage
> > >>>
> > >>> in this case the uImage is useless
> > >>
> > >> U-Boot doesn't support zImage at present.
> > >>
> > >> A patch was posted to support it at least for ARM, but needed a little
> > >> work before it could be committed.
> > > Sorry I see no advantage to have the uImage build by the kernel anymore as
> > > we have a relocatable zImage
> > >
> > > I'll even drop its support
> >
> > This seems at least premature, and possibly ill-advised in general.
> > There are lots of U-Boot images out in the field, many of which that
> > are rarely updated. A lot of workflow will be disrupted unnecessarily
> > by a change like this.
> >
> > Could you wait to drop uImage build support in the kernel until
> > U-Boot supports zImage, and has worked it's way into the field
> > for a few years?
>
> I admit I didn't check for a few years, but regarding that the values
> used to build the uImage from a zImage are (or at least were) quite bad,
> I'd say deprecate the uImage target today.

That would prevent anyone from using U-Boot without having to go through
manual steps to duplicate what already exists in the uImage target in
the kernel.

The existing target works just fine today.

This patch even allows the existing target to be useful for multi-Soc.

I really don't understand the "lets drop support for something that works
just fine and isn't a maintenance burden" argument.

-- 
nvpublic

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Uwe Kleine-König]

On Wed, Feb 29, 2012 at 11:17:41AM -0800, Stephen Warren wrote:
> Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:12 PM:
> > On Wed, Feb 29, 2012 at 10:33:58AM -0800, Tim Bird wrote:
> > > On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> > > >> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
> > > >>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> > > >>>> uImage files typically encode a single absolute load and entry address.
> > > >>>> This is inconvenient when attempting to share that uImage across multiple
> > > >>>> SoCs with different physical RAM addresses. Recent versions of mkimage
> > > >>>> implement a "kernel_noload" image type which encodes no absolute load
> > > >>>> address, and a relative entry address. This works well for uImage-wrapped
> > > >>>> ARM zImages, since they are relocatable.
> > > >>>>
> > > >>>> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > > >>>> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> > > >>>>
> > > >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > >>>> ---
> > > >>>> I assume I should put this into the ARM patch tracker if it's OK?
> > > >>>
> > > >>> Again a new option for uImage no why not just boot the zImage
> > > >>>
> > > >>> in this case the uImage is useless
> > > >>
> > > >> U-Boot doesn't support zImage at present.
> > > >>
> > > >> A patch was posted to support it at least for ARM, but needed a little
> > > >> work before it could be committed.
> > > > Sorry I see no advantage to have the uImage build by the kernel anymore as
> > > > we have a relocatable zImage
> > > >
> > > > I'll even drop its support
> > >
> > > This seems at least premature, and possibly ill-advised in general.
> > > There are lots of U-Boot images out in the field, many of which that
> > > are rarely updated. A lot of workflow will be disrupted unnecessarily
> > > by a change like this.
> > >
> > > Could you wait to drop uImage build support in the kernel until
> > > U-Boot supports zImage, and has worked it's way into the field
> > > for a few years?
> >
> > I admit I didn't check for a few years, but regarding that the values
> > used to build the uImage from a zImage are (or at least were) quite bad,
> > I'd say deprecate the uImage target today.
> 
> That would prevent anyone from using U-Boot without having to go through
> manual steps to duplicate what already exists in the uImage target in
> the kernel.
> 
> The existing target works just fine today.
It depends what you want to achieve. If you want to make everything
maximally easy for everyone you can optimize the uImage target.

If you want to give incentive for U-Boot to improve, drop the target
today. And note that at least people caring about boot time must not use
the kernel's uImage target anyhow.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:44 PM:
...
> If you want to give incentive for U-Boot to improve, drop the target
> today. And note that at least people caring about boot time must not use
> the kernel's uImage target anyhow.

If you enable the new config option in this patch, then the performance
issue is solved; U-Boot doesn't copy the kernel image any more, and the
kernel decompressor can write directly to the appropriate location without
moving the image first (assuming your board boot script loads the uImage
to a non-conflicting address).

--
nvpublic

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Andre Renaud]

On 01/03/12 08:59, Stephen Warren wrote:
> Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:44 PM:
> ...
>> If you want to give incentive for U-Boot to improve, drop the target
>> today. And note that at least people caring about boot time must not use
>> the kernel's uImage target anyhow.
> 
> If you enable the new config option in this patch, then the performance
> issue is solved; U-Boot doesn't copy the kernel image any more, and the
> kernel decompressor can write directly to the appropriate location without
> moving the image first (assuming your board boot script loads the uImage
> to a non-conflicting address).

I may have missed part of this, but isn't one of the points regarding
this that the zImage decompressor always runs with data cache disabled,
resulting in a slow decompress, where as if the U-Boot decompressor is
used (ie, gzipping the Image, and telling U-Boot to decompress), then it
can run with caches enabled, improving boot speed?

Thus the relocation issue is not really the speed hit, rather it is the
image decompression.

Regards,
Andre

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

Andre Renaud wrote at Wednesday, February 29, 2012 1:12 PM:
> On 01/03/12 08:59, Stephen Warren wrote:
> > Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:44 PM:
> > ...
> >> If you want to give incentive for U-Boot to improve, drop the target
> >> today. And note that at least people caring about boot time must not use
> >> the kernel's uImage target anyhow.
> >
> > If you enable the new config option in this patch, then the performance
> > issue is solved; U-Boot doesn't copy the kernel image any more, and the
> > kernel decompressor can write directly to the appropriate location without
> > moving the image first (assuming your board boot script loads the uImage
> > to a non-conflicting address).
> 
> I may have missed part of this, but isn't one of the points regarding
> this that the zImage decompressor always runs with data cache disabled,
> resulting in a slow decompress, where as if the U-Boot decompressor is
> used (ie, gzipping the Image, and telling U-Boot to decompress), then it
> can run with caches enabled, improving boot speed?
> 
> Thus the relocation issue is not really the speed hit, rather it is the
> image decompression.

OK, there probably are multiple different issues affecting the performance,
and this patch only affects the one that applies once you've decided to use
uImage to wrap a zImage in the first place.

-- 
nvpublic

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Russell King - ARM Linux]

On Thu, Mar 01, 2012 at 09:12:17AM +1300, Andre Renaud wrote:
> On 01/03/12 08:59, Stephen Warren wrote:
> > Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:44 PM:
> > ...
> >> If you want to give incentive for U-Boot to improve, drop the target
> >> today. And note that at least people caring about boot time must not use
> >> the kernel's uImage target anyhow.
> > 
> > If you enable the new config option in this patch, then the performance
> > issue is solved; U-Boot doesn't copy the kernel image any more, and the
> > kernel decompressor can write directly to the appropriate location without
> > moving the image first (assuming your board boot script loads the uImage
> > to a non-conflicting address).
> 
> I may have missed part of this, but isn't one of the points regarding
> this that the zImage decompressor always runs with data cache disabled,

Most certainly not.  We've had the data cache enabled for years and
years.  And I mean 10+ years.  We may have been lacking support on
some CPUs, but that was because of lack of contributions.

> resulting in a slow decompress, where as if the U-Boot decompressor is
> used (ie, gzipping the Image, and telling U-Boot to decompress), then it
> can run with caches enabled, improving boot speed?

That's pure FUD.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Andre Renaud]

Hi Russell,
>> I may have missed part of this, but isn't one of the points regarding
>> this that the zImage decompressor always runs with data cache disabled,
> 
> Most certainly not.  We've had the data cache enabled for years and
> years.  And I mean 10+ years.  We may have been lacking support on
> some CPUs, but that was because of lack of contributions.
> 
>> resulting in a slow decompress, where as if the U-Boot decompressor is
>> used (ie, gzipping the Image, and telling U-Boot to decompress), then it
>> can run with caches enabled, improving boot speed?
> 
> That's pure FUD.

I don't want to open a can of worms on this, and I certainly haven't
looked into the image decompressor within the Linux kernel, but from a
boot speed point of view we certainly see a significant speed
improvement switching from zImage to gzipped-Image. Do you know which
platforms include the data-cache support in the decompressor?

Regards,
Andre

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Russell King - ARM Linux]

On Thu, Mar 01, 2012 at 09:25:12AM +1300, Andre Renaud wrote:
> Hi Russell,
> >> I may have missed part of this, but isn't one of the points regarding
> >> this that the zImage decompressor always runs with data cache disabled,
> > 
> > Most certainly not.  We've had the data cache enabled for years and
> > years.  And I mean 10+ years.  We may have been lacking support on
> > some CPUs, but that was because of lack of contributions.
> > 
> >> resulting in a slow decompress, where as if the U-Boot decompressor is
> >> used (ie, gzipping the Image, and telling U-Boot to decompress), then it
> >> can run with caches enabled, improving boot speed?
> > 
> > That's pure FUD.
> 
> I don't want to open a can of worms on this, and I certainly haven't
> looked into the image decompressor within the Linux kernel, but from a
> boot speed point of view we certainly see a significant speed
> improvement switching from zImage to gzipped-Image. Do you know which
> platforms include the data-cache support in the decompressor?

All.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Uwe Kleine-König]

On Thu, Mar 01, 2012 at 09:25:12AM +1300, Andre Renaud wrote:
> Hi Russell,
> >> I may have missed part of this, but isn't one of the points regarding
> >> this that the zImage decompressor always runs with data cache disabled,
> > 
> > Most certainly not.  We've had the data cache enabled for years and
> > years.  And I mean 10+ years.  We may have been lacking support on
> > some CPUs, but that was because of lack of contributions.
> > 
> >> resulting in a slow decompress, where as if the U-Boot decompressor is
> >> used (ie, gzipping the Image, and telling U-Boot to decompress), then it
> >> can run with caches enabled, improving boot speed?
> > 
> > That's pure FUD.
> 
> I don't want to open a can of worms on this, and I certainly haven't
> looked into the image decompressor within the Linux kernel, but from a
> boot speed point of view we certainly see a significant speed
> improvement switching from zImage to gzipped-Image. Do you know which
> platforms include the data-cache support in the decompressor?
I'd bet your platform has cache support in the decompressor without
knowing which platform you use. I suggest commenting out

	bl	cache_on

in arch/arm/boot/compressed/head.S to see the difference.

How do you build the uImage containing the zImage? If you use the
in-kernel uImage target booting that usually means:

	- move the zImage to ZRELADDR
	- jump into zImage
	- decompress zImage to somewhere else
	- move decompressed image to ZRELADDR
	- jump to ZRELADDR

That is you have two relocations because the first location for sure
conflicts with the decompressed image.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Russell King - ARM Linux]

On Wed, Feb 29, 2012 at 09:39:58PM +0100, Uwe Kleine-K?nig wrote:
> I'd bet your platform has cache support in the decompressor without
> knowing which platform you use. I suggest commenting out
> 
> 	bl	cache_on
> 
> in arch/arm/boot/compressed/head.S to see the difference.
> 
> How do you build the uImage containing the zImage? If you use the
> in-kernel uImage target booting that usually means:
> 
> 	- move the zImage to ZRELADDR
> 	- jump into zImage
> 	- decompress zImage to somewhere else
> 	- move decompressed image to ZRELADDR
> 	- jump to ZRELADDR
> 
> That is you have two relocations because the first location for sure
> conflicts with the decompressed image.

Actually, we do this slightly differently nowadays.  Inside zImage:

	- if zImage location conflicts, move the decompressed data
	  and decompressor to another location
	- decompress zImage to ZRELADDR
	- jump to ZRELADDR

That reduces the size required for copying.  Of course, that copy can
(as it's always been the case) be totally eliminated by ensuring that
you load the zImage out of the way of the decompressed image.

So, really, comparing a standard uImage produced by the standard kernel
with gzipped Image is far from a fair comparison.  And that's actually
another argument for getting rid of the uImage target... it may make
people think a bit about what they're doing rather than accepting
whatever default location someone else chose for their kernel.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Uwe Kleine-König]

On Wed, Feb 29, 2012 at 08:45:27PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 29, 2012 at 09:39:58PM +0100, Uwe Kleine-K?nig wrote:
> > I'd bet your platform has cache support in the decompressor without
> > knowing which platform you use. I suggest commenting out
> > 
> > 	bl	cache_on
> > 
> > in arch/arm/boot/compressed/head.S to see the difference.
> > 
> > How do you build the uImage containing the zImage? If you use the
> > in-kernel uImage target booting that usually means:
> > 
> > 	- move the zImage to ZRELADDR
> > 	- jump into zImage
> > 	- decompress zImage to somewhere else
> > 	- move decompressed image to ZRELADDR
> > 	- jump to ZRELADDR
> > 
> > That is you have two relocations because the first location for sure
> > conflicts with the decompressed image.
> 
> Actually, we do this slightly differently nowadays.  Inside zImage:
> 
> 	- if zImage location conflicts, move the decompressed data
s/de//

> 	  and decompressor to another location
> 	- decompress zImage to ZRELADDR
> 	- jump to ZRELADDR
> 
> That reduces the size required for copying.  Of course, that copy can
> (as it's always been the case) be totally eliminated by ensuring that
> you load the zImage out of the way of the decompressed image.
> 
> So, really, comparing a standard uImage produced by the standard kernel
> with gzipped Image is far from a fair comparison.  And that's actually
> another argument for getting rid of the uImage target... it may make
> people think a bit about what they're doing rather than accepting
> whatever default location someone else chose for their kernel.
I'm all in favour to remove the uImage target because back in 2007 we
already had a similar discussion[1]. (Back then I still thought that
improving the uImage support would be a good idea.)

That said I think *in general* having support for U-Boot in the kernel
is fine because I think U-Boot is the bootloader used most. But if you
need some Kconfig settings or more than one Makefile target I think just
building an Image or zImage and doing the U-Boot wrapping without the
help of Linux' build system is preferable.

Best regards
Uwe

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/36547/focus=36588

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:59 Wed 29 Feb     , Uwe Kleine-K?nig wrote:
> On Wed, Feb 29, 2012 at 08:45:27PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 29, 2012 at 09:39:58PM +0100, Uwe Kleine-K?nig wrote:
> > > I'd bet your platform has cache support in the decompressor without
> > > knowing which platform you use. I suggest commenting out
> > > 
> > > 	bl	cache_on
> > > 
> > > in arch/arm/boot/compressed/head.S to see the difference.
> > > 
> > > How do you build the uImage containing the zImage? If you use the
> > > in-kernel uImage target booting that usually means:
> > > 
> > > 	- move the zImage to ZRELADDR
> > > 	- jump into zImage
> > > 	- decompress zImage to somewhere else
> > > 	- move decompressed image to ZRELADDR
> > > 	- jump to ZRELADDR
> > > 
> > > That is you have two relocations because the first location for sure
> > > conflicts with the decompressed image.
> > 
> > Actually, we do this slightly differently nowadays.  Inside zImage:
> > 
> > 	- if zImage location conflicts, move the decompressed data
> s/de//
> 
> > 	  and decompressor to another location
> > 	- decompress zImage to ZRELADDR
> > 	- jump to ZRELADDR
> > 
> > That reduces the size required for copying.  Of course, that copy can
> > (as it's always been the case) be totally eliminated by ensuring that
> > you load the zImage out of the way of the decompressed image.
> > 
> > So, really, comparing a standard uImage produced by the standard kernel
> > with gzipped Image is far from a fair comparison.  And that's actually
> > another argument for getting rid of the uImage target... it may make
> > people think a bit about what they're doing rather than accepting
> > whatever default location someone else chose for their kernel.
> I'm all in favour to remove the uImage target because back in 2007 we
> already had a similar discussion[1]. (Back then I still thought that
> improving the uImage support would be a good idea.)
> 
> That said I think *in general* having support for U-Boot in the kernel
> is fine because I think U-Boot is the bootloader used most. But if you
> need some Kconfig settings or more than one Makefile target I think just
> building an Image or zImage and doing the U-Boot wrapping without the
> help of Linux' build system is preferable.
Agreed at 200%


Best Regards,
J.

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Marek Vasut]

Dear Uwe Kleine-K?nig,

> On Wed, Feb 29, 2012 at 08:45:27PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 29, 2012 at 09:39:58PM +0100, Uwe Kleine-K?nig wrote:
> > > I'd bet your platform has cache support in the decompressor without
> > > knowing which platform you use. I suggest commenting out
> > > 
> > > 	bl	cache_on
> > > 
> > > in arch/arm/boot/compressed/head.S to see the difference.
> > > 
> > > How do you build the uImage containing the zImage? If you use the
> > > 
> > > in-kernel uImage target booting that usually means:
> > > 	- move the zImage to ZRELADDR
> > > 	- jump into zImage
> > > 	- decompress zImage to somewhere else
> > > 	- move decompressed image to ZRELADDR
> > > 	- jump to ZRELADDR
> > > 
> > > That is you have two relocations because the first location for sure
> > > conflicts with the decompressed image.
> > 
> > Actually, we do this slightly differently nowadays.  Inside zImage:
> > 	- if zImage location conflicts, move the decompressed data
> 
> s/de//
> 
> > 	  and decompressor to another location
> > 	
> > 	- decompress zImage to ZRELADDR
> > 	- jump to ZRELADDR
> > 
> > That reduces the size required for copying.  Of course, that copy can
> > (as it's always been the case) be totally eliminated by ensuring that
> > you load the zImage out of the way of the decompressed image.
> > 
> > So, really, comparing a standard uImage produced by the standard kernel
> > with gzipped Image is far from a fair comparison.  And that's actually
> > another argument for getting rid of the uImage target... it may make
> > people think a bit about what they're doing rather than accepting
> > whatever default location someone else chose for their kernel.
> 
> I'm all in favour to remove the uImage target because back in 2007 we
> already had a similar discussion[1]. (Back then I still thought that
> improving the uImage support would be a good idea.)
> 
> That said I think *in general* having support for U-Boot in the kernel
> is fine because I think U-Boot is the bootloader used most. But if you
> need some Kconfig settings or more than one Makefile target I think just
> building an Image or zImage and doing the U-Boot wrapping without the
> help of Linux' build system is preferable.

I believe eventually everyone will converge to having this option enabled. 
Therefore this config option will just be always on and can be squashed away.

> 
> Best regards
> Uwe
> 
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/36547/focus=36588

Best regards,
Marek Vasut

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

Russell King wrote at Wednesday, February 29, 2012 1:45 PM:
...
> So, really, comparing a standard uImage produced by the standard kernel
> with gzipped Image is far from a fair comparison.  And that's actually
> another argument for getting rid of the uImage target... it may make
> people think a bit about what they're doing rather than accepting
> whatever default location someone else chose for their kernel.

That seems like more of an argument for making the uImage target use
-T kernel_noload unconditionally, rather than removing the target.
Since doing so would solve the issue about the kernel picking a load
address.

That is, ignoring any arguments about breaking existing workflows at
least...

-- 
nvpublic

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Andre Renaud]

On 01/03/12 10:27, Stephen Warren wrote:
> Russell King wrote at Wednesday, February 29, 2012 1:45 PM:
> ...
>> So, really, comparing a standard uImage produced by the standard kernel
>> with gzipped Image is far from a fair comparison.  And that's actually
>> another argument for getting rid of the uImage target... it may make
>> people think a bit about what they're doing rather than accepting
>> whatever default location someone else chose for their kernel.
> 
> That seems like more of an argument for making the uImage target use
> -T kernel_noload unconditionally, rather than removing the target.
> Since doing so would solve the issue about the kernel picking a load
> address.
> 
> That is, ignoring any arguments about breaking existing workflows at
> least...

I think this is the case that I was seeing - the current behaviour of
the uImage target, of using the zreladdr as the load/start addresses
essentially guarantees the worst case relocation behaviour.

Regards,
Andre

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Uwe Kleine-König]

On Thu, Mar 01, 2012 at 09:12:17AM +1300, Andre Renaud wrote:
> On 01/03/12 08:59, Stephen Warren wrote:
> > Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:44 PM:
> > ...
> >> If you want to give incentive for U-Boot to improve, drop the target
> >> today. And note that at least people caring about boot time must not use
> >> the kernel's uImage target anyhow.
> > 
> > If you enable the new config option in this patch, then the performance
> > issue is solved; U-Boot doesn't copy the kernel image any more, and the
> > kernel decompressor can write directly to the appropriate location without
> > moving the image first (assuming your board boot script loads the uImage
> > to a non-conflicting address).
> 
> I may have missed part of this, but isn't one of the points regarding
> this that the zImage decompressor always runs with data cache disabled,
> resulting in a slow decompress, where as if the U-Boot decompressor is
> used (ie, gzipping the Image, and telling U-Boot to decompress), then it
> can run with caches enabled, improving boot speed?
This is wrong. The zImage decompressor runs with caches on. The
advantage that U-Boot (maybe) has when doing the decompression itself is
that the cache for reading the zImage is already hot when U-Boot copied it
from NAND to RAM first. (I don't know if U-Boot can decompress directly
from NAND without writing the Image to RAM first?!)

> Thus the relocation issue is not really the speed hit, rather it is the
> image decompression.
I'm sure that letting U-Boot decompress an image that first has to be
moved to prevent it being overwritten during decompression is slower
than jumping into zImage if the image isn't relocated.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Ryan Mallon]

On 01/03/12 06:44, Uwe Kleine-K?nig wrote:

> On Wed, Feb 29, 2012 at 11:17:41AM -0800, Stephen Warren wrote:
>> Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:12 PM:
>>> On Wed, Feb 29, 2012 at 10:33:58AM -0800, Tim Bird wrote:
>>>> On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 08:58 Wed 29 Feb     , Stephen Warren wrote:
>>>>>> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 5:30 AM:
>>>>>>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:

<snip>

>> The existing target works just fine today.
> It depends what you want to achieve. If you want to make everything
> maximally easy for everyone you can optimize the uImage target.
> 
> If you want to give incentive for U-Boot to improve, drop the target
> today. 


This assumes that people will upgrade their bootloaders, which is not
always possible or desirable.

~Ryan

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Marek Vasut]

Dear Ryan Mallon,

> On 01/03/12 06:44, Uwe Kleine-K?nig wrote:
> > On Wed, Feb 29, 2012 at 11:17:41AM -0800, Stephen Warren wrote:
> >> Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:12 PM:
> >>> On Wed, Feb 29, 2012 at 10:33:58AM -0800, Tim Bird wrote:
> >>>> On 02/29/2012 10:14 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>> On 08:58 Wed 29 Feb     , Stephen Warren wrote:
> >>>>>> Jean-Christophe PLAGNIOL-VILLARD wrote at Wednesday, February 29, 2012 
5:30 AM:
> >>>>>>> On 17:03 Tue 28 Feb     , Stephen Warren wrote:
> <snip>
> 
> >> The existing target works just fine today.
> > 
> > It depends what you want to achieve. If you want to make everything
> > maximally easy for everyone you can optimize the uImage target.
> > 
> > If you want to give incentive for U-Boot to improve, drop the target
> > today.
> 
> This assumes that people will upgrade their bootloaders, which is not
> always possible or desirable.
> 
> ~Ryan
> 

Agreed 201%

Best regards,
Marek Vasut

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Mark Brown]

On Wed, Feb 29, 2012 at 08:44:09PM +0100, Uwe Kleine-K?nig wrote:

> If you want to give incentive for U-Boot to improve, drop the target
> today. And note that at least people caring about boot time must not use
> the kernel's uImage target anyhow.

It's not just u-boot, at least Qi also uses uImage (I'm stuck with it on
one platform and don't currently have the time/enthusiasm to fix either
the bootloader selection or the zImage support).

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Stephen Warren]

Stephen Warren wrote at Tuesday, February 28, 2012 5:03 PM:
> uImage files typically encode a single absolute load and entry address.
> This is inconvenient when attempting to share that uImage across multiple
> SoCs with different physical RAM addresses. Recent versions of mkimage
> implement a "kernel_noload" image type which encodes no absolute load
> address, and a relative entry address. This works well for uImage-wrapped
> ARM zImages, since they are relocatable.
> 
> This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.

So Russell, are you NAKing this patch then?

If so, I guess I'll just go and add more cruft to my copy-a-kernel-to-
an-sd-card script. Which is a pity since every other person will have
to do the same, but oh well.

-- 
nvpublic

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Olof Johansson]

On Thu, Mar 01, 2012 at 09:01:04AM -0800, Stephen Warren wrote:
> Stephen Warren wrote at Tuesday, February 28, 2012 5:03 PM:
> > uImage files typically encode a single absolute load and entry address.
> > This is inconvenient when attempting to share that uImage across multiple
> > SoCs with different physical RAM addresses. Recent versions of mkimage
> > implement a "kernel_noload" image type which encodes no absolute load
> > address, and a relative entry address. This works well for uImage-wrapped
> > ARM zImages, since they are relocatable.
> > 
> > This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> 
> So Russell, are you NAKing this patch then?
> 
> If so, I guess I'll just go and add more cruft to my copy-a-kernel-to-
> an-sd-card script. Which is a pity since every other person will have
> to do the same, but oh well.

I'd say send them on to his patch tracker and he can decide from there?

Feel free to add:

Acked-by: Olof Johansson <olof@lixom.net>

Some people seem to have a bone to pick with u-boot, and apparantly want us to
make it harder to use the kernel with the firmware that is already out there.
I personally disagree, but as you said, I'll just add my own wrapper script if
it comes to it. So will everyone else though, and that just seems wasteful.

There hasn't been much churn lately around boot images (unlike the situation
back 5 years ago in the thread that was referenced earlier in this thread, as
far as I can tell).

So while the churn in this case is compensated by added convenience
and productivity for me personally, it's up to Russell to decide if it
goes in.


-Olof

[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[Nicolas Pitre]

On Thu, 1 Mar 2012, Stephen Warren wrote:

> Stephen Warren wrote at Tuesday, February 28, 2012 5:03 PM:
> > uImage files typically encode a single absolute load and entry address.
> > This is inconvenient when attempting to share that uImage across multiple
> > SoCs with different physical RAM addresses. Recent versions of mkimage
> > implement a "kernel_noload" image type which encodes no absolute load
> > address, and a relative entry address. This works well for uImage-wrapped
> > ARM zImages, since they are relocatable.
> > 
> > This is enabled by commit b9b50e89d317c58becd0e2d7fac2e21e3a81dd0a
> > "image: Implement IH_TYPE_KERNEL_NOLOAD" in U-Boot.
> 
> So Russell, are you NAKing this patch then?
> 
> If so, I guess I'll just go and add more cruft to my copy-a-kernel-to-
> an-sd-card script. Which is a pity since every other person will have
> to do the same, but oh well.

What about moving all the u-Boot bells and whistles to a generic 
top-level Kconfig+Makefile to be shared with all architectures?  Really, 
there is nothing very ARM specific here.


Nicolas