Patchwork [2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD

login
register
mail settings
Submitter Stephen Warren
Date March 7, 2012, 12:30 a.m.
Message ID <1331080238-1524-2-git-send-email-swarren@wwwdotorg.org>
Download mbox | patch
Permalink /patch/145125/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Stephen Warren - March 7, 2012, 12:30 a.m.
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(-)
Julian Calaby - March 7, 2012, 12:52 a.m.
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,
Guan Xuetao - March 7, 2012, 6:52 a.m.
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

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jean-Christophe PLAGNIOL-VILLARD - March 7, 2012, 6:08 p.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - March 7, 2012, 6:10 p.m.
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!
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jean-Christophe PLAGNIOL-VILLARD - March 7, 2012, 6:36 p.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - March 7, 2012, 6:40 p.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolas Pitre - March 7, 2012, 6:50 p.m.
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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolas Pitre - March 7, 2012, 7:02 p.m.
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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jean-Christophe PLAGNIOL-VILLARD - March 7, 2012, 7:08 p.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolas Pitre - March 7, 2012, 7:31 p.m.
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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - March 7, 2012, 8:27 p.m.
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?
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolas Pitre - March 7, 2012, 9:03 p.m.
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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux - March 7, 2012, 9:28 p.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux - March 7, 2012, 9:30 p.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolas Pitre - March 7, 2012, 10:43 p.m.
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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

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 = $@