• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 839 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

another bug? u-boot's vsprintf() overrun on DM355?

YJ Liu
Expert 1675 points


gays:

I encounter strange things again on DM355 when using u-boot 1.3.4.

I use the UART boot mode ,and download uboot to ddr, finally found it ran to printf() and not respond anymore.(sometimes reboot and show BOOTME string).

To debug it ,i define a function writing string directly to UART register "u_sendstring(char *s)".

here are some code for debugging printf():

void printf(const char *fmt, ...) //console.c Line402

{

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);

/* Print the string */

puts(printbuffer);

}

here are 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

///////////////// well, the first strings may output correctly, such as "128","MB". BUT,when it run to nand_scan()->nand_get_flash_type(), it overrun.

static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd, struct nand_chip *chip, int busw, int *maf_id)

{

.......

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;

}

//// you can see that when involving printf() in nand_get_flash_type(), the printf() had no response.
Two years ago, I had found if I added more printf() in misc_init_r(), u-boot would not boot again.
am i wrong? or We are just the men helping to find out TI's BUG?

  • 0
    Expert 1675 points

    I am also going to crash now, Is there anyone had met this situation before?

  • 0 in reply to YJ Liu
    Expert 1675 points

    well ,the printf function is very strange.I had never met this before.!!!

    when printf("%s") as string output ,it will operate ok.

    but "%d" "%u" as digital output ,it will crash, what's the strange reason?

    had no emulator,it's very hard for me.

  • 0 in reply to YJ Liu
    TI__Intellectual 1910 points

      I'm guessing it might be because %d and %u probably call a divide function in the math run-time library, but %s does not.  What are the numerical values for %d?  Are they large values or small?  Can you also try "%X" and "%o"?  These hexadecimal and octal cases may not call the divide function.

    Regards, Clay

  • 0 in reply to Clay Montgomery
    Expert 1675 points

    well, "%x" will also  crash, as i describe before:

    static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd, struct nand_chip *chip, int busw, int *maf_id)

    {

    .......

     

    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;

    }

    the most important is , if I cannot resolve printf, then uboot cannot be used anymore. because many many cmd will use printf to output digital string.

     

  • 0 in reply to YJ Liu
    Expert 1675 points

    It seems gcc optimizing option cause printf() and others crash.

    I use arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.gz to compile uboot1.3.4 (from  arago project. ), 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?

  • 0 in reply to YJ Liu
    Expert 1675 points

    I have figured it out ,haha.

  • 0 in reply to YJ Liu
    TI__Intellectual 1910 points

    Liu,

       Can you please share what you learned about this problem?  Was the optimization level of the CodeSourcery gcc compiler the only issue, or was there another issue?

    Regards, Clay

  • 0 in reply to Clay Montgomery
    Expert 1675 points

    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 :(

  • 0 in reply to YJ Liu
    Expert 1675 points

    set a low ddr2 speed, and it work file. thank everyone.