Hi Tim, > Thank you very much. > I'm using ELDK4.2. I just defined my global variable in lib_ppc/board.c, > here we have three functions: board_init_f(), board_init_r(), > Reset_Watchdog(). > Reset_Watchdog() will be called in board_init_f(), board_init_r(). > > here as below is my code, > /***************************************************************************/ > /*board.c*/ > unsigned char g_debug = 0; > void Reset_Watchdog() > { > if(g_debug) > {printf("hello world\n");} > ..... > } > > void board_init_f(...) > { > Reset_Watchdog(); > ..... > > relocate_code(); > } > > void board_init_r(...) > { > g_debug = 1; > /*Reset_Watchdog can print as g_debug=1*/ > Reset_Watchdog(); > ..... > } > /***************************************************************************************/ > > I firstly defined "unsigned char g_debug=0" in board.c, I thought this > global variable would be in data section, so there was no problem > for my code in Reset_Watchdog(), because g_debug=0, "printf("hello > world\n")" wouldn't be executed until to the board_init_r() where > the variable g_debug=1. > > but in fact, the g_debug is in bss section, before relocate_code() which > move the code from flash to RAM, g_debug=0xff. > relocate_code doesn't move bss section, it just clear 0 the same bss size in > RAM. so after relocate_code, g_debug=0x0. > > thus, in board_init_f(), reset_watchdog() will be problem because serial > port haven't initialized at that point. > > I don't know why compiler make g_debug initialized as 0 in bss section. it > makes me confused!
Well this is standard behaviour. If the compiler places such a variable into the .data segment, it would a) use space in the executable and b) need time to copy into memory on execution. If the compiler instead puts the variable into .bss, we have neither of those problems and from a program perspective everything is ok. Now inside of U-Boot of course, we are "working below the hoods" and actually the definitions used in the previous paragraph have somewhat unclear meanings before relocation. So currently as U-Boot is its own loader, we accept the fact that .bss will be cleared on relocation. Actually I don't even know if it is correct at all to use .bss variables before then (if you look around, you'll find the "global_data" structure (include/asm/global-data.h) that we use in this early phase by keeping a reference to it in a register) On the whole, this is not an ELDK issue, but rather an U-Boot property so I include that mailing list also. Cheers Detlev -- Wenn ein Kopf und ein Buch zusammenstossen und es klingt hohl; ist denn das allemal im Buche? - Lichtenberg -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot