[U-Boot-Users] [Patch] Fix malloc hang on 82xx after relocation fixes

[Rune Torgersen]

Temporarily set gd->reloc_off so malloc_bin_reloc will work correctly after the relocation fixup patches.
Signed-off-by: Rune Torgersen <runet at innovsys.com>

---

> From: Rune Torgersen
> Sent: Wednesday, October 24, 2007 8:41 AM
> Subject: [U-Boot-Users] Malloc hangs on 82xx boards
> 
> the relocation fixup patches (by Grant Likely and others) messes up
> malloc on at least 8260 boards.
> What seems to be happening is that the malloc end address does not get
> set anymore, and is therefore 0, and malloc start and lengths then end
> up being negative and ends up in the middle of the IMMR somewhere.
> 
> Net effect is that no 826x board I have tried so fat (8260ADS, 8266ADS
> and an internal board) will boot using u-boot 1.3.0-rc3.
> 
> I can get it to work by 
> 1) Commenting out "#define CONFIG_RELOC_FIXUP_WORKS" on line 90 in
> include common.h
> or
> 2) Backing out commits f82b3b6304b620ef7e28bfaa1ea887a2ad2fa325 and
> e9514751cfa5cce61ea699fa0d3eb37898a5eeb5.
> 
> 2) basically reverts to setting malloc end address from a 
> #define again.
> 
> I need help to figure out how to fix this, and this most 
> likely affects
> ALL 82xx boards (at least).

I finally tracked it down.
Not sure on how to best fix this.

Malloc uses a statically initialized memory struct with differnet bins in it
(an array of type struct malloc_chunk). This array is initialized on compile time. 
There are fwd and back pointers in this struct to basically make it a linked list. 
These pointers are in the text segment, and will therefore be pointing to the flash.

When u-boot is relocated to flash, malloc_bin_reloc() gets called to relocate 
these pointers to RAM instead.

When CONFIG_RELOC_FIXUP_WORKS is defined, gd->reloc_off is set to 0, and the 
pointers will continue to point to flash.

The correct fix would be to have the compiler set the addresses in the array correct 
at compile time, but I do not think that is possible, as we don't always know 
where we'll end up in RAM until runtime.

Another solution would be to generate the table dynamically after relocation.

Right now, this hack will allow at least 82xx to boot with the new relocation stuff in place.

diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 9aa67f9..88363eb 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -779,8 +779,17 @@ void board_init_r (gd_t *id, ulong dest_addr)
 
 	/* initialize malloc() area */
 	mem_malloc_init ();
+
+#if defined(CONFIG_RELOC_FIXUP_WORKS)
+	/* Set reloc offset temporarily so malloc_bin_reloc will work */
+	gd->reloc_off = dest_addr - CFG_MONITOR_BASE;
+#endif
 	malloc_bin_reloc ();
 
+#if defined(CONFIG_RELOC_FIXUP_WORKS)
+	gd->reloc_off = 0;
+#endif
+
 #ifdef CONFIG_SPI
 # if !defined(CFG_ENV_IS_IN_EEPROM)
 	spi_init_f ();