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