[U-Boot-Users] [Patch 2/4] U-Boot-V2: ARM: introduce CONFIG_SKIP_RELOCATION

Menon, Nishanth x0nishan at ti.com
Wed May 7 16:41:21 CEST 2008


Sascha,
> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Wednesday, May 07, 2008 8:51 AM
> To: Menon, Nishanth
> Cc: u-boot-users at 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 




More information about the U-Boot mailing list