Sascha, > -----Original Message----- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 8:51 AM > To: Menon, Nishanth > Cc: [email protected] > 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 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ U-Boot-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/u-boot-users
