[U-Boot] memory corruption on nios2 due to overlap of gbl data and malloc

[Graeme Russ]

Hi Albert,

On Fri, Mar 2, 2012 at 8:57 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Graeme,
>
> Le 29/02/2012 23:41, Graeme Russ a écrit :
>>
>> Hi Mike,
>>
>> On Thu, Mar 1, 2012 at 9:29 AM, Mike Frysinger<vapier at gentoo.org>  wrote:
>>>
>>> On Wednesday 29 February 2012 17:22:26 Graeme Russ wrote:
>>>>
>>>> On Thu, Mar 1, 2012 at 6:04 AM, Mike Frysinger wrote:
>>>>>
>>>>> On Tuesday 28 February 2012 18:32:57 Graeme Russ wrote:
>>>>>>
>>>>>> And this is why I dislike the implementation - You have to do all
>>>>>> sorts
>>>>>> of weird calucations to put things in the right place when, in fact,
>>>>>> the location of gd and bd in memory is totally irrelavent.
>>>>>
>>>>>
>>>>> right, that's why i minimized the pain for Blackfin users -- this is
>>>>> all
>>>>> handled in the arch's config-pre.h header.  board porters only need to
>>>>> declare the size of regions they care about (monitor and heap sizes).
>>>>>
>>>>>> Ow, ouch! - And that padding makes things more fun - The memory layout
>>>>>> is
>>>>>>
>>>>>> U-Boot | gd | pad | bd | pad | heap
>>>>>
>>>>>
>>>>> fwiw, i documented the Blackfin memory layout:
>>>>>
>>>>> http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:memory-la
>>>>> yout
>>>>
>>>>
>>>> I had a look at this and noticed that you statically allocate locations
>>>> for
>>>> gd and bd (CONFIG_SYS_GBL_DATA_ADDR, CONFIG_SYS_BD_INFO_ADDR)
>>>>
>>>> Considering that:
>>>>
>>>> a) the gd pointer is in a register (P3) and thus easily locatable by a
>>>>    debugger, and;
>>>> b) the bd pointer is in gd
>>>>
>>>> Is there any reason not to have gd and bd in BSS?
>>>
>>>
>>> in the Blackfin case, most likely not.  we don't do relocation, and the
>>> bss is
>>> cleared long before board_init_f() gets called.  the only reason for
>>> allowing
>>> the config to override would be if someone wanted to put gd/bd into
>>> on-chip L1
>>> data, but i can't imagine this structure being performance critical
>>> enough to
>>> warrant that.
>>
>>
>> I thought as much - I moved gd/bd into BSS for x86 without really thinking
>> about why everyone else calculates the location of these data structures
>> around the stack and heap. The longer I think about it, the more I think
>> that it was not a bad move and that maybe other arches can follow suit as
>> part of standardising the init sequences
>
>
> ARMs relocate and don't have a valid BSS until board_init_r() but require gd
> as early as board_init_f().

So does x86 - A temporary gd is kept in Cache-As-RAM until SDRAM is
initialised.

I just noticed that for x86, only bd is in bss - I still calculate a
permanent resting place for gd around the relocated U-Boot, heap and stack
but I plan to change this so the init sequence will be:

 - Create temporary gd and stack in CAR for board_init_f
 - After SDRAM is initialised and the new stack created, 'pivot' U-Boot so
   it is running from flash, but using SDRAM for stack
 - Copy gd from CAR to stack
 - Copy U-Boot to SDDRAM, clear BSS, do relocation fixups
 - Copy gd from stack to BSS
 - 'pivot' execution from flash to SDRAM (this may involve resetting the
   stack pointer, just to save a few bytes used by the no longer needed
   call stack and temporary gd, but this is not a neccessity)
 - Create heap below U-Boot

So the end memory layout is:

----------- Top Of SDRAM -----------
          .bss   \
          .data  + - U-Boot.bin
          .text  /
------------------------------------

          heap

------------------------------------

          stack (grows down)

....................................

          Free Memory

--- Bottom of SDRAM (0x00000000) ---


Simple :)

Regards,

Graeme