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