[U-Boot] U-Boot malloc implementation on arm - problem after relocation
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
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
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
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
participants (3)
-
Andreas Färber -
mar.krzeminski -
Marcin Krzemiński