[U-Boot] U-Boot malloc implementation on arm - problem after relocation

[Marcin Krzemiński]

2015-10-07 20:25 GMT+02:00 mar.krzeminski <mar.krzeminski at gmail.com>:

>
>
> W dniu 07.10.2015 o 19:38, Andreas Färber pisze:
>
>> Hi Marcin,
>>
>> Am 07.10.2015 um 15:58 schrieb Marcin Krzemiński:
>>
>>> Since I use qemu it
>>> is very hard to debug with gdb u-boot after relocation( or I do not know
>>> how to do it), so I am almost blind.
>>>
>> QEMU has a built-in gdb stub that you can just connect to as gdb remote
>> target, similar to how you would connect to a JTAG adapter's gdb server.
>> See documentation of qemu-system-arm -gdb and -s options.
>>
>> It should behave the same as with a physical remote target, otherwise
>> please report to qemu-devel or a suitable bug tracker.
>>
>> Regards,
>> Andreas
>>
>> Hi Andreas,
>
> I am debugging under qemu, and I can debug easily just to a moment before
> relocation.
> If I reload symbols to my relocation address qemu does not stop at
> breakpoints (after I reinserted them).
> As I understand qemus list there is a problem with relocated code. Anyway,
> you're right I'll ask.
> Regarding my problem, debugging with prints showed me that it fails when
> malloc tries to extend top area,
> and the top pointer seem to be in SDRAM.
> If I do not use malloc before relocation (with enabled malloc_f) all seems
> to work just fine.
>
> Regards,
> Marcin
>
>
> Hello,

I managed to run debugging - it was problem with eclipse settings.
With debugger I found out that my problem is cause by bss.
Malloc implementation uses bss, and I use malloc without bss (in
board_early_init_f )
and CONFIG_SYS_MALLOC_F_LEN.
After relocation static variable was not initialized for first malloc call,
so size to memset was to big and that caused a problem.
My question is when or if ever bss will be relocated?

Regrads,
Marcin