2015-10-07 20:25 GMT+02:00 mar.krzeminski <mar.krzemin...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot