[U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...)

Hello,
browsing through some code searching for a reason why an u-boot compiled with gcc 4.5.1 fails to boot on a beagleboard, I've come through another place where bss is used before relocation: gpmc_init (gpmc_cfg) in arch/arm/cpu/armv7/omap3/mem.c.
I haven't fixed it up to now, but I want to inform the people actually working with that board (currently I don't have any to do with that board and just touching at from time to time for fun), that there might be other places than the already mentioned timer_init() and that gpmc_init().
All candidates for such problems could be found in board_init_f() in arch/arm/lib/board.c, escpecially all functions which appear in init_sequence in board.c.
Someone should take the time and check them all. ;)
Regards,
Alexander

-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Alexander Holler Sent: Tuesday, November 30, 2010 9:59 PM To: u-boot@lists.denx.de Subject: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...)
Hello,
browsing through some code searching for a reason why an u-boot compiled with gcc 4.5.1 fails to boot on a beagleboard, I've come through another place where bss is used before relocation: gpmc_init (gpmc_cfg) in arch/arm/cpu/armv7/omap3/mem.c.
I haven't fixed it up to now, but I want to inform the people actually working with that board (currently I don't have any to do with that board and just touching at from time to time for fun), that there might be other places than the already mentioned timer_init() and that gpmc_init().
All candidates for such problems could be found in board_init_f() in arch/arm/lib/board.c, escpecially all functions which appear in init_sequence in board.c.
For omap3evm - I was getting multiple errors during compilation. Most for undefined symbols - which existed in the compiled objects but, I suspect, not in right sequence.
Haven't still been able to look back at these errors; still surprised to find that you had the code running on beagle.
~sanjeev
Someone should take the time and check them all. ;)
Regards,
Alexander _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Hello,
Am 30.11.2010 19:21, schrieb Premi, Sanjeev:
For omap3evm - I was getting multiple errors during compilation. Most for undefined symbols - which existed in the compiled objects but, I suspect, not in right sequence.
Haven't still been able to look back at these errors; still surprised to find that you had the code running on beagle.
When I'm compiling the current master with gcc 4.3.5 (using binutils 2.20.1) u.boot currently works (at least it loads and starts the kernel from mmc). But I assume that is just some lucky condition because 4.3.5 does some things different than 4.5.1 which causes some sill existent bugs to not appear.
Browsing the source to search those problems (which arise when I'm using gcc 4.5.1) is just some freetime activity I'm doing when I feel bored, without spending much time. For actually working on those problems I would have to build a TI<->ARM JTAG cable, which is still on my list of low priority todos. ;)
Regards,
Alexander

Maybe in init sequens asm func, i used turn on led to check which func faild.

Am 02.12.2010 14:33, schrieb zfsdk:
Maybe in init sequens asm func, i used turn on led to check which func faild.
Using a LED for debugging is time consuming. And you won't see which code still uses BSS before relocation as such code does not have to fail (it still might work). I prefer reading source. Using JTAG should help too, but I think, using JTAG and a debugger might got somewhat harder, at least after the code got relocated. Anyway, a JTAG-debugger could help a lot searching the stuff which currently goes wrong before relocation. I assume single stepping the few dozen lines which are executed before relocation could be done in a few hours and it should reveal most of the code which accesses BSS before relocation.
Regards,
Alexander
participants (3)
-
Alexander Holler
-
Premi, Sanjeev
-
zfsdk