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

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

[Marcin Krzemiński]

Hello,

In my board I have some problems with malloc functionality. In config I
have settings for malloc:
#define CONFIG_SYS_MALLOC_LEN (2 * 1024 * 1024)
#define CONFIG_SYS_MALLOC_F_LEN     (1024)
I am running u-boot without SPL. Uboot starts from SRAM and then relocates
to DRAM.
When I run u-boot from flash (_f functions ) I am opening spi to access one
sector from flash - that is why i need malloc in that phase.
After relocation first call of malloc cause u-boot to genrate data-access
exception. From my debugging it seems, that top pointer from dlmalloc is
still points to malloc region before relocation(SRAM). 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.
Do you know what I am doing wrong?
Additionally I  do not use CONFIG_NEEDS_MANUAL_RELOC since i do not need it
(or i think I do not need).

Regards,
Marcin

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

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)

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

[mar.krzeminski]

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

[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@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