Hi Albert,
On Fri, Mar 2, 2012 at 8:57 AM, Albert ARIBAUD
<albert.u.b...@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<vap...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
