[U-Boot] [PATCH 2/2] 85xx: Ensure BSS segment doesn't start at address 0x0

[Wolfgang Denk]

Dear Peter Tyser,

In message <1254783670-21301-3-git-send-email-ptyser at xes-inc.com> you wrote:
> When U-Boot is relocated from flash to RAM pointers are modified
> accordingly.  However, pointers initialzed with NULL values should not
> be modified so that they maintain their intended NULL value.  The
> address of the BSS segment must be modified during relocation which
> means that it must not have a NULL value.
> 
> Signed-off-by: Peter Tyser <ptyser at xes-inc.com>
> ---
>  cpu/mpc85xx/u-boot.lds.S |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/cpu/mpc85xx/u-boot.lds.S b/cpu/mpc85xx/u-boot.lds.S
> index a347cd1..ef3de66 100644
> --- a/cpu/mpc85xx/u-boot.lds.S
> +++ b/cpu/mpc85xx/u-boot.lds.S
> @@ -131,6 +131,14 @@ SECTIONS
>  
>    . = RESET_VECTOR_ADDRESS + 0x4;
>  
> +  /*
> +   * Make sure that the bss segment doesn't start at 0x0, otherwise its
> +   * address won't be updated during relocation fixups
> +   */
> +#if !((RESET_VECTOR_ADDRESS + 0x4) & 0xffffffff)

This seems to be a pretty complicated way of writing

	#if (RESET_VECTOR_ADDRESS == 0xFFFFFFFC)

?

> +  . |= 0x10;

I'm not sure if all this is always doing what we want, or if it's
always working the same way. When building on 32 bit machines, dot
will wrap around for "0xFFFFFFFC + 4" and result in 0; ". |= 0x10"
makes it 0x10 then.

When built using a 64 bit host, 0xFFFFFFFC + 4 = 0x100000000, and the
OR makes it 0x100000010. But here this OR was not needed.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"My name is Linus Torvalds, you messed with my kernel, prepare to die"
                                                  - Linus Torvalds in
      <Pine.LNX.3.91.960426110644.24860I-100000 at linux.cs.Helsinki.FI>