[U-Boot] gcc optimizing option cause printf() and others crash.why?

I use arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.gz to compile uboot1.3.4, and found that if I set OPTFLAGS to -O1,or O2, uboot will crash, usually in printf(). when i set to O3, it runs to prompt, but after several seconds(or minutes), the code is dead,and the console has no response. Os also has the problem,usually cannot run to main_loop(). How should i resolve this problem?
2010/7/29 yaojin liu lanmanck@gmail.com
hi,all: I encounter strange thing again. :(
it seems the vsprintf will overrun. have someone met before?
To debug it ,I define a function writing character directly to the register: "u_sendstring()"
Here is the code for debugging printf:
void printf(const char *fmt, ...)
{
va_list args;
uint i;
char printbuffer[CONFIG_SYS_PBSIZE];
va_start(args, fmt);
/* For this to work, printbuffer must be larger than
- anything we ever want to print.
*/
u_sendstring("printf2\n");
i = vsprintf(printbuffer, fmt, args);
u_sendstring("printf3\n");
va_end(args);
puts(printbuffer);
}
and here is the output:
DM3xx=>>: DONEprintf2
DM3xx=>>: printf3
DM3xx=>>: U-Boot 2009.03 ( 2010 - 23:14:17)
DM3xx=>>: I2C: ready
DM3xx=>>: DRAM: printf2
DM3xx=>>: printf3
DM3xx=>>: 128printf2
DM3xx=>>: printf3
DM3xx=>>: MB
DM3xx=>>: NAND: board_nand_init end
DM3xx=>>: nand_scan1
DM3xx=>>: nand_scan_ident1
DM3xx=>>: nand_scan_ident2
DM3xx=>>: nand_get_flash_type1
DM3xx=>>: nand_get_flash_type2
DM3xx=>>: nand_get_flash_type4
DM3xx=>>: printf2n BOOTME
DM3xx=>>: BOOTME
DM3xx=>>: BOOTME
DM3xx=>>: BOOTME
/////////////////////// weill, you can see that the first string will output correctly,such as "128" "MB", but when it ran to nand_get_flash_type(), the chip reboot.
static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd, struct nand_chip *chip, int busw, int *maf_id)
{
struct nand_flash_dev *type = NULL;
int i, dev_id, maf_idx;
int tmp_id, tmp_manf;
/* Select the device */
chip->select_chip(mtd, 0);
u_sendstring("nand_get_flash_type1\n");
.....
u_sendstring("nand_get_flash_type4\n");
printk("NAND device: Manufacturer ID:"
" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, dev_id, nand_manuf_ids[maf_idx].name, type->name);
u_sendstring("nand_get_flash_type5\n");
return type;
}
printk is just printf. So as i describe above, the code ran to vsprintf and no respond anymore. How could this happen? Is it another hardware bug?

Hi yaojin liu lanmanck@gmail.com writes:
I use arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.gz to compile uboot1.3.4, and found that if I set OPTFLAGS to -O1,or O2, uboot will crash, usually in printf().
<faq>
What board do you use? Why do you use U-Boot 1.3.4 and not current code?
</faq>
when i set to O3, it runs to prompt, but after several seconds(or minutes), the code is dead,and the console has no response. Os also has the problem,usually cannot run to main_loop(). How should i resolve this problem?
Actually I presume that somebody tested U-Boot on the board you use. Probably there is a running version on it - so the most obvious problem seems to be your toolchain. So my advise is:
Find a working starting point, i.e. a known to work U-Boot version for your board (latest?) together with a known-to-work toolchain (eldk-4.2 for arm?).
Then use your toolchain, compare results, find problem and post answer :)
Cheers Detlev

I have figured it out,haha!!
2010/7/30 Detlev Zundel dzu@denx.de
Hi yaojin liu lanmanck@gmail.com writes:
I use arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.gz to compile uboot1.3.4, and found that if I set OPTFLAGS to -O1,or O2, uboot will crash, usually in printf().
<faq>
What board do you use? Why do you use U-Boot 1.3.4 and not current code?
</faq>
when i set to O3, it runs to prompt, but after several seconds(or
minutes),
the code is dead,and the console has no response. Os also has the problem,usually cannot run to main_loop(). How should i resolve this problem?
Actually I presume that somebody tested U-Boot on the board you use. Probably there is a running version on it - so the most obvious problem seems to be your toolchain. So my advise is:
Find a working starting point, i.e. a known to work U-Boot version for your board (latest?) together with a known-to-work toolchain (eldk-4.2 for arm?).
Then use your toolchain, compare results, find problem and post answer :)
Cheers Detlev
-- There are three kinds of people in the world; those who can count and those who can't. -- 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: dzu@denx.de

Dear yaojin liu,
In message AANLkTik2N941wFtVXDJdCi4Dp9C2_HxbAm909UsujGEx@mail.gmail.com you wrote:
I have figured it out,haha!!
And would you care to share your wisdom with the rest of the comunity?
Wolfgang Denk

well, actually i smile too early. I have ported to version 1.1.6(using gcc3.3.2 instead !!), and the result remain the same. the board is designed by myself. when i run TI test code on IRAM or DDR,it has no problem. but uboot, crash. don't know why yet. it has past 2 weeks :(
2010/8/1 Wolfgang Denk wd@denx.de
Dear yaojin liu,
In message AANLkTik2N941wFtVXDJdCi4Dp9C2_HxbAm909UsujGEx@mail.gmail.com you wrote:
I have figured it out,haha!!
And would you care to share your wisdom with the rest of the comunity?
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Es sind überhaupt nur die Dummköpfe, die sich den Befehlen der Mäch- tigen widersetzen. Um sie zu ruinieren ist es genug, ihre Befehle treu zu erfüllen. - Peter Hacks: "Die schöne Helena"
participants (3)
-
Detlev Zundel
-
Wolfgang Denk
-
yaojin liu