[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0

[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0

[Peter Tyser]

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.  If the
BSS segment is linked at address 0 its address will not be
updated as necessary during relocation.

This is a temporary workaround.  The end goal is to add support to
U-Boot to dynamically locate the BSS at an arbitrary address at
runtime.  When the ability to fixup the BSS inteligently is
added, this workaround can be removed and the 85xx link script
can put the BSS at a fixed address at link time.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
Changes since v1:
- Updated commit title and description
- Cleaned up logic to determine if we need to fixup bss address

 cpu/mpc85xx/u-boot.lds |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/cpu/mpc85xx/u-boot.lds b/cpu/mpc85xx/u-boot.lds
index a347cd1..183dce9 100644
--- a/cpu/mpc85xx/u-boot.lds
+++ b/cpu/mpc85xx/u-boot.lds
@@ -131,6 +131,17 @@ SECTIONS
 
   . = RESET_VECTOR_ADDRESS + 0x4;
 
+  /*
+   * Make sure that the bss segment isn't linked at 0x0, otherwise its
+   * address won't be updated during relocation fixups.  Note that
+   * this is a temporary fix.  Code to dynamically the fixup the bss
+   * location will be added in the future.  When the bss relocation
+   * fixup code is present this workaround should be removed.
+   */
+#if (RESET_VECTOR_ADDRESS == 0xfffffffc)
+  . |= 0x10;
+#endif
+
   __bss_start = .;
   .bss (NOLOAD)       :
   {
-- 
1.6.2.1

[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0

[Wolfgang Denk]

Dear Peter Tyser,

In message <1254933900-16859-1-git-send-email-ptyser@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.  If the
> BSS segment is linked at address 0 its address will not be
> updated as necessary during relocation.
> 
> This is a temporary workaround.  The end goal is to add support to
> U-Boot to dynamically locate the BSS at an arbitrary address at
> runtime.  When the ability to fixup the BSS inteligently is
> added, this workaround can be removed and the 85xx link script
> can put the BSS at a fixed address at link time.
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> Changes since v1:
> - Updated commit title and description
> - Cleaned up logic to determine if we need to fixup bss address
> 
>  cpu/mpc85xx/u-boot.lds |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)

Applied to "reloc" branch, thanks.

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
Save yourself!  Reboot in 5 seconds!

[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0

[Kumar Gala]

On Oct 7, 2009, at 5:34 PM, Wolfgang Denk wrote:

> Dear Peter Tyser,
>
> In message <1254933900-16859-1-git-send-email-ptyser@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.  If the
>> BSS segment is linked at address 0 its address will not be
>> updated as necessary during relocation.
>>
>> This is a temporary workaround.  The end goal is to add support to
>> U-Boot to dynamically locate the BSS at an arbitrary address at
>> runtime.  When the ability to fixup the BSS inteligently is
>> added, this workaround can be removed and the 85xx link script
>> can put the BSS at a fixed address at link time.
>>
>> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
>> ---
>> Changes since v1:
>> - Updated commit title and description
>> - Cleaned up logic to determine if we need to fixup bss address
>>
>> cpu/mpc85xx/u-boot.lds |   11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> Applied to "reloc" branch, thanks.

Is the intent to merge "reloc" for v2009.11 or post?

- k

[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0

[Stefan Roese]

On Thursday 08 October 2009 04:47:57 Kumar Gala wrote:
> >> Changes since v1:
> >> - Updated commit title and description
> >> - Cleaned up logic to determine if we need to fixup bss address
> >>
> >> cpu/mpc85xx/u-boot.lds |   11 +++++++++++
> >> 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > Applied to "reloc" branch, thanks.
> 
> Is the intent to merge "reloc" for v2009.11 or post?

AFAIK, this branch will be merged in this release. Bigger changes like the bss 
move to a fixed address and consolidation of the relocation code in C are 
postponed to the next release.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0

[Wolfgang Denk]

Dear Kumar Gala,

In message <ECB99FF0-6A99-4165-B5FA-F5B4CE143B71@kernel.crashing.org> you wrote:
> 
> > Applied to "reloc" branch, thanks.
> 
> Is the intent to merge "reloc" for v2009.11 or post?

Yes :-)

I will merge it by the end of this week, as previously announced.

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
"No one talks peace unless he's ready to back it up with war."
"He talks of peace if it is the only way to live."
	-- Colonel Green and Surak of Vulcan, "The Savage Curtain",
	   stardate 5906.5.