[U-Boot-Users] [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION
Introduce CONFIG_SKIP_RELOCATION as alternative define. This may be desired in some conditions where U-Boot is downloaded directly into SRAM during NAND/Peripheral download mode and is not expected to be relocated.
This patch also organizes SKIP_LOWLEVEL_INIT and SKIP_RELOCATION in a common arm feature dependent section.
Signed-off-by: Nishanth Menon x0nishan@ti.com
Index: u-boot-v2.git/arch/arm/cpu/start-arm.S =================================================================== --- u-boot-v2.git.orig/arch/arm/cpu/start-arm.S 2008-05-05 09:35:00.000000000 -0500 +++ u-boot-v2.git/arch/arm/cpu/start-arm.S 2008-05-05 09:35:05.000000000 -0500 @@ -160,6 +160,10 @@ bl board_init_lowlevel #endif
+ /* + * In some circumstances, we may choose not to relocate u-boot + */ +#ifndef CONFIG_SKIP_RELOCATION relocate: /* relocate U-Boot to RAM */ adr r0, _start /* r0 <- current position of code */ ldr r1, _TEXT_BASE /* test if we run from flash or RAM */ @@ -176,6 +180,7 @@ stmia r1!, {r3-r10} /* copy to target address [r1] */ cmp r0, r2 /* until source end addreee [r2] */ ble copy_loop +#endif
/* Set up the stack */ stack_setup: Index: u-boot-v2.git/arch/arm/Kconfig =================================================================== --- u-boot-v2.git.orig/arch/arm/Kconfig 2008-05-05 09:34:44.000000000 -0500 +++ u-boot-v2.git/arch/arm/Kconfig 2008-05-05 09:35:25.000000000 -0500 @@ -74,6 +74,7 @@ bool select ARM926EJS
+ choice prompt "Select your board"
@@ -140,7 +141,7 @@ The i.MX SoCs have a Pin which can output different reference frequencies. Say y here if you want to have the clko command which lets you select the frequency to output on this pin. - + source arch/arm/mach-netx/Kconfig
menu "Arm specific settings " @@ -164,6 +165,27 @@ If you want to start a 2.6 kernel and use an initrd image say y here.
+menu "Boot Features" + +config SKIP_LOWLEVEL_INIT + bool + default n + depends on ARM + prompt "Skip lowlevel init" + help + This entry skips the SDRAM initialising on many ARM based boards. + It enables using U-boot as a second stage bootloader. + +config SKIP_RELOCATION + bool + default n + depends on ARM + prompt "Skip U-Boot Relocation" + help + This entry skips the relocation logic on certain platforms + It enables using U-boot as a second stage bootloader. +endmenu + endmenu
source common/Kconfig Index: u-boot-v2.git/common/Kconfig =================================================================== --- u-boot-v2.git.orig/common/Kconfig 2008-05-05 09:34:44.000000000 -0500 +++ u-boot-v2.git/common/Kconfig 2008-05-05 09:35:05.000000000 -0500 @@ -216,14 +216,6 @@ help Enable build of u-boot with -g.
-config SKIP_LOWLEVEL_INIT - bool - depends on ARM - prompt "Skip lowlevel init" - help - This entry skips the SDRAM initialising on many ARM based boards. - It enables using U-boot as a second stage bootloader. - config ENABLE_FLASH_NOISE bool prompt "verbose flash handling"
In message 8E8BB316C604E94AA019A54D0A5A82A201A2C94B@dlee13.ent.ti.com you wrote:
Introduce CONFIG_SKIP_RELOCATION as alternative define. This may be desired in some conditions where U-Boot is downloaded directly into SRAM during NAND/Peripheral download mode and is not expected to be relocated.
This patch also organizes SKIP_LOWLEVEL_INIT and SKIP_RELOCATION in a common arm feature dependent section.
Your patch is corrupted - your mailer line-wrapped it:
+config SKIP_LOWLEVEL_INIT
- bool
- default n
- depends on ARM
- prompt "Skip lowlevel init"
- help
This entry skips the SDRAM initialising on many ARM basedboards.
^^^^^^^^^^^^^ here for example.
PLease fix your mailer before resending.
I strongly recommend to use git and git tools for such work.
Best regards,
Wolfgang Denk
On Wed, May 07, 2008 at 06:55:56AM -0500, Menon, Nishanth wrote:
Introduce CONFIG_SKIP_RELOCATION as alternative define. This may be desired in some conditions where U-Boot is downloaded directly into SRAM during NAND/Peripheral download mode and is not expected to be relocated.
If U-Boot is not expected to be relocated, TEXT_BASE should be in SRAM in which case the relocation loop just does nothing. So you end up in saving 12 * 4 bytes of space. Is it really worth to introduce an #ifdef for such a small saving?
Sascha
This patch also organizes SKIP_LOWLEVEL_INIT and SKIP_RELOCATION in a common arm feature dependent section.
Signed-off-by: Nishanth Menon x0nishan@ti.com
Index: u-boot-v2.git/arch/arm/cpu/start-arm.S
--- u-boot-v2.git.orig/arch/arm/cpu/start-arm.S 2008-05-05 09:35:00.000000000 -0500 +++ u-boot-v2.git/arch/arm/cpu/start-arm.S 2008-05-05 09:35:05.000000000 -0500 @@ -160,6 +160,10 @@ bl board_init_lowlevel #endif
- /*
* In some circumstances, we may choose not to relocate u-boot*/+#ifndef CONFIG_SKIP_RELOCATION relocate: /* relocate U-Boot to RAM */ adr r0, _start /* r0 <- current position of code */ ldr r1, _TEXT_BASE /* test if we run from flash or RAM */ @@ -176,6 +180,7 @@ stmia r1!, {r3-r10} /* copy to target address [r1] */ cmp r0, r2 /* until source end addreee [r2] */ ble copy_loop +#endif
/* Set up the stack */ stack_setup: Index: u-boot-v2.git/arch/arm/Kconfig =================================================================== --- u-boot-v2.git.orig/arch/arm/Kconfig 2008-05-05 09:34:44.000000000 -0500 +++ u-boot-v2.git/arch/arm/Kconfig 2008-05-05 09:35:25.000000000 -0500 @@ -74,6 +74,7 @@ bool select ARM926EJS
choice prompt "Select your board"
@@ -140,7 +141,7 @@ The i.MX SoCs have a Pin which can output different reference frequencies. Say y here if you want to have the clko command which lets you select the frequency to output on this pin.
source arch/arm/mach-netx/Kconfig
menu "Arm specific settings " @@ -164,6 +165,27 @@ If you want to start a 2.6 kernel and use an initrd image say y here.
+menu "Boot Features"
+config SKIP_LOWLEVEL_INIT
- bool
- default n
- depends on ARM
- prompt "Skip lowlevel init"
- help
This entry skips the SDRAM initialising on many ARM basedboards.
It enables using U-boot as a second stage bootloader.+config SKIP_RELOCATION
- bool
- default n
- depends on ARM
- prompt "Skip U-Boot Relocation"
- help
This entry skips the relocation logic on certain platformsIt enables using U-boot as a second stage bootloader.+endmenu
endmenu
source common/Kconfig Index: u-boot-v2.git/common/Kconfig =================================================================== --- u-boot-v2.git.orig/common/Kconfig 2008-05-05 09:34:44.000000000 -0500 +++ u-boot-v2.git/common/Kconfig 2008-05-05 09:35:05.000000000 -0500 @@ -216,14 +216,6 @@ help Enable build of u-boot with -g.
-config SKIP_LOWLEVEL_INIT
- bool
- depends on ARM
- prompt "Skip lowlevel init"
- help
This entry skips the SDRAM initialising on many ARM basedboards.
It enables using U-boot as a second stage bootloader.config ENABLE_FLASH_NOISE bool prompt "verbose flash handling"
Sascha,
-----Original Message----- From: Sascha Hauer [mailto:s.hauer@pengutronix.de] Sent: Wednesday, May 07, 2008 8:51 AM To: Menon, Nishanth Cc: u-boot-users@lists.sourceforge.net Subject: Re: [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION
On Wed, May 07, 2008 at 06:55:56AM -0500, Menon, Nishanth wrote:
Introduce CONFIG_SKIP_RELOCATION as alternative define. This may be desired in some conditions where U-Boot is downloaded directly into SRAM during NAND/Peripheral download mode and is not expected to be relocated.
If U-Boot is not expected to be relocated, TEXT_BASE should be in SRAM in which case the relocation loop just does nothing. So you end up in saving 12 * 4 bytes of space. Is it really worth to introduce an #ifdef for such a small saving?
Probably not much of a saving, been looking at the code, and I see CONFIG_RELOCATABLE depending on ppc. It may not be just the savings part of 48bytes. There can be additional stuff an SOC might choose to do. (ppc start.S also uses the define to save 4 instructions or so). Cleaner approach might make sense to remove the CONFIG_RELOCATABLE dependency on ppc and make it a global configuration. Allowing any platform to choose what ever it wants to do. I will redo the patch accordingly if you are ok with using CONFIG_RELOCATABLE (including fixing my brain dead mailer's issues hopefully :( ).
Regards, Nishanth Menon
On Wed, May 07, 2008 at 09:41:21AM -0500, Menon, Nishanth wrote:
Sascha,
-----Original Message----- From: Sascha Hauer [mailto:s.hauer@pengutronix.de] Sent: Wednesday, May 07, 2008 8:51 AM To: Menon, Nishanth Cc: u-boot-users@lists.sourceforge.net Subject: Re: [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION
On Wed, May 07, 2008 at 06:55:56AM -0500, Menon, Nishanth wrote:
Introduce CONFIG_SKIP_RELOCATION as alternative define. This may be desired in some conditions where U-Boot is downloaded directly into SRAM during NAND/Peripheral download mode and is not expected to be relocated.
If U-Boot is not expected to be relocated, TEXT_BASE should be in SRAM in which case the relocation loop just does nothing. So you end up in saving 12 * 4 bytes of space. Is it really worth to introduce an #ifdef for such a small saving?
Probably not much of a saving, been looking at the code, and I see CONFIG_RELOCATABLE depending on ppc. It may not be just the savings part of 48bytes. There can be additional stuff an SOC might choose to do. (ppc start.S also uses the define to save 4 instructions or so). Cleaner approach might make sense to remove the CONFIG_RELOCATABLE dependency on ppc and make it a global configuration. Allowing any platform to choose what ever it wants to do.
CONFIG_RELOCATABLE on powerpc means something different. On arm we start U-Boot by running it at an address != link address and _copy_ (not relocate) ourselves to the address we are linked at. On powerpc real relocation is done if CONFIG_RELOCATABLE is enabled. Hence the option you wanted to add should better have the name CONFIG_SKIP_COPY_TO_SDRAM or something like that.
Sascha
Sascha,
-----Original Message----- From: Sascha Hauer [mailto:s.hauer@pengutronix.de] Sent: Wednesday, May 07, 2008 10:29 AM To: Menon, Nishanth Cc: u-boot-users@lists.sourceforge.net Subject: Re: [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION
CONFIG_RELOCATABLE on powerpc means something different. On arm we start U-Boot by running it at an address != link address and _copy_ (not relocate) ourselves to the address we are linked at. On powerpc real relocation is done if CONFIG_RELOCATABLE is enabled. Hence the option you wanted to add should better have the name CONFIG_SKIP_COPY_TO_SDRAM or something like that.
Hmm.. good point. My ignorance on ppc is kicking me ;).. I will remove the SKIP_COPY part from my patch. Couple of questions: a) Are we ok with removing dependency of ARM from "config SKIP_LOWLEVEL_INIT" in common/Kconfig (as opposed to my patch in which I moved it to arch/arm/Kconfig)? Considering that it is used: arch/m68k/cpu/start-mcfv4e.S
b) Further am wondering if it is fine to convert ARCH_HAS_INIT_LOWLEVEL to CONFIG_ARCH_HAS_INIT_LOWLEVEL in common/Kconfig and make it arch independent?
Regards, Nishanth Menon
On Wed, May 07, 2008 at 10:38:35AM -0500, Menon, Nishanth wrote:
Sascha,
-----Original Message----- From: Sascha Hauer [mailto:s.hauer@pengutronix.de] Sent: Wednesday, May 07, 2008 10:29 AM To: Menon, Nishanth Cc: u-boot-users@lists.sourceforge.net Subject: Re: [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION
CONFIG_RELOCATABLE on powerpc means something different. On arm we start U-Boot by running it at an address != link address and _copy_ (not relocate) ourselves to the address we are linked at. On powerpc real relocation is done if CONFIG_RELOCATABLE is enabled. Hence the option you wanted to add should better have the name CONFIG_SKIP_COPY_TO_SDRAM or something like that.
Hmm.. good point. My ignorance on ppc is kicking me ;).. I will remove the SKIP_COPY part from my patch. Couple of questions: a) Are we ok with removing dependency of ARM from "config SKIP_LOWLEVEL_INIT" in common/Kconfig (as opposed to my patch in which I moved it to arch/arm/Kconfig)? Considering that it is used: arch/m68k/cpu/start-mcfv4e.S
so SKIP_LOWLEVEL_INIT would depend on CONFIG_ARCH_HAS_INIT_LOWLEVEL?
b) Further am wondering if it is fine to convert ARCH_HAS_INIT_LOWLEVEL to CONFIG_ARCH_HAS_INIT_LOWLEVEL in common/Kconfig and make it arch independent?
ok
Regards Sascha
Sascha,
-----Original Message----- From: Sascha Hauer [mailto:s.hauer@pengutronix.de] Sent: Thursday, May 08, 2008 10:16 AM To: Menon, Nishanth Cc: u-boot-users@lists.sourceforge.net Subject: Re: [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION
Hmm.. good point. My ignorance on ppc is kicking me ;).. I will remove the SKIP_COPY part from my
patch. Couple of questions:
a) Are we ok with removing dependency of ARM from "config SKIP_LOWLEVEL_INIT" in common/Kconfig (as
opposed to my patch in which I moved it to arch/arm/Kconfig)? Considering that it is used: arch/m68k/cpu/start-mcfv4e.S
so SKIP_LOWLEVEL_INIT would depend on CONFIG_ARCH_HAS_INIT_LOWLEVEL?
No it should not. It should ideally be CONFIG_MACH_HAS_INIT_LOWLEVEL? And enabling this will call board_init_lowlevel.
Regards, Nishanth Menon
In message 20080507152912.GJ4326@pengutronix.de you wrote:
CONFIG_RELOCATABLE on powerpc means something different. On arm we start U-Boot by running it at an address != link address and _copy_ (not relocate) ourselves to the address we are linked at. On powerpc real relocation is done if CONFIG_RELOCATABLE is enabled. Hence the option you wanted to add should better have the name CONFIG_SKIP_COPY_TO_SDRAM or something like that.
This is something that I always wanted to fix. The ARM implementation is broken by design - unfortunately it has been also used for MIPS, and other architectures. It would be much better if we had real relocation to a (dynamically determined) address on ARM too, instead of such a fixed mapping.
Best regards,
Wolfgang Denk
CONFIG_RELOCATABLE on powerpc means something different. On arm we start U-Boot by running it at an address != link address and _copy_ (not relocate) ourselves to the address we are linked at. On powerpc real relocation is done if CONFIG_RELOCATABLE is enabled. Hence the option you wanted to add should better have the name CONFIG_SKIP_COPY_TO_SDRAM or something like that.
This is something that I always wanted to fix. The ARM implementation is broken by design - unfortunately it has been also used for MIPS, and other architectures. It would be much better if we had real relocation to a (dynamically determined) address on ARM too, instead of such a fixed mapping.
Best regards,
Wolfgang Denk
As more and more architectures support booting from just about anything than a parallel flash, maybe it is better to have a CONFIG_COPY_TO_SDRAM than its negative form.
Whats the big benefit of beeing able to select where U-boot runs? I could understand if there was a need for a compile time parameter.
Best Regards Ulf Samuelsson
On Wed, May 07, 2008 at 07:56:25PM +0200, Wolfgang Denk wrote:
In message 20080507152912.GJ4326@pengutronix.de you wrote:
CONFIG_RELOCATABLE on powerpc means something different. On arm we start U-Boot by running it at an address != link address and _copy_ (not relocate) ourselves to the address we are linked at. On powerpc real relocation is done if CONFIG_RELOCATABLE is enabled. Hence the option you wanted to add should better have the name CONFIG_SKIP_COPY_TO_SDRAM or something like that.
This is something that I always wanted to fix. The ARM implementation is broken by design - unfortunately it has been also used for MIPS, and other architectures. It would be much better if we had real relocation to a (dynamically determined) address on ARM too, instead of such a fixed mapping.
I wouldn't say broken. With a fixed mapping you get smaller code size and for many cases it's just enough. So I vote for having both.
Regards Sascha
participants (4)
-
Menon, Nishanth -
Sascha Hauer -
Ulf Samuelsson -
Wolfgang Denk