| Message ID | 1331080238-1524-2-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 = $@
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(-)