[U-Boot] u-boot hang after we changed the flash chip
Hi, everyone I have a AMCC PowerPC 405EX based board. The u-boot version is U-Boot 1.3.2-RELEASE_11. It works fine until we have to change the NOR-Flash chip from JS28F128P33B85 to JS28F128P33BF70 since the JS28F128P33B85 is obsolete. I checked the datasheet of these two flash chips, they all support CFI and we enabled CFI in u-boot. The different is the write buffer size: the old one has 32 bytes and the new one has 256 bytes. I tracked into the u-boot with BDI3000. The code fly away in the function i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE), which is called in init_func_i2c:
static int init_func_i2c (void) { puts ("I2C: "); i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); puts ("ready\n"); return (0); } In debug console: I actually see the out put I2C: . The codes fly away inside i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); and never come back to put("ready\n");
Another interesting thing is when I am in function init_func_i2c, I used bt full in GDB to check the stack. I get the following: (gdb) bt full #0 <signal handler called> No locals. #1 0x00000000 in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. Previous frame inner to this frame (corrupt stack?)
Does this mean the stack is corrupted? There should have a stack already in this moment, right?
Does anyone has any idea which direction I should go?
Thanks a lot,
Raymond
Dear raymond zhao,
In message AANLkTik9PHqAAvvE1fpGVMh5EYVBb=LitaxA2dG7Y_SA@mail.gmail.com you wrote:
I have a AMCC PowerPC 405EX based board. The u-boot version is U-Boot 1.3.2-RELEASE_11. It works fine until we have to change the NOR-Flash chip
There has never been any such release. There was v1.3.2, followed by v1.3.3. Note that these are more than 2.5 years old, so I strongly recommend to update to current code instead.
static int init_func_i2c (void) { puts ("I2C: "); i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); puts ("ready\n"); return (0); } In debug console: I actually see the out put I2C: . The codes fly away inside i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); and never come back to put("ready\n");
This does not really look like a flash related issue to me.
Another interesting thing is when I am in function init_func_i2c, I used bt full in GDB to check the stack. I get the following: (gdb) bt full #0 <signal handler called> No locals. #1 0x00000000 in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. Previous frame inner to this frame (corrupt stack?)
Neither does this.
Does this mean the stack is corrupted? There should have a stack already in this moment, right?
Does anyone has any idea which direction I should go?
Check your voltages, as close to the flash chips as possible. The new ones may draw higher currents (especially higher and steeper peaks). If your voltages are not clean you may see data corruption, which would explain the effects you describe (and a lot more).
Best regards,
Wolfgang Denk
Just FYI. It is not the hardware problem. I update the u-boot to latest version and port all the configuration files. It just works. Must be something improved (or fixed) in the new u-boot version. So I learned the lesson, always use latest stable u-boot version. :-)
Thanks for the help.
Raymond
On Mon, Dec 13, 2010 at 6:11 PM, Wolfgang Denk wd@denx.de wrote:
Dear raymond zhao,
In message AANLkTik9PHqAAvvE1fpGVMh5EYVBb=LitaxA2dG7Y_SA@mail.gmail.com you wrote:
I have a AMCC PowerPC 405EX based board. The u-boot version is U-Boot 1.3.2-RELEASE_11. It works fine until we have to change the NOR-Flash
chip
There has never been any such release. There was v1.3.2, followed by v1.3.3. Note that these are more than 2.5 years old, so I strongly recommend to update to current code instead.
static int init_func_i2c (void) { puts ("I2C: "); i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); puts ("ready\n"); return (0); } In debug console: I actually see the out put I2C: . The codes fly away inside i2c_init (CFG_I2C_SPEED, CFG_I2C_SLAVE); and never come back to put("ready\n");
This does not really look like a flash related issue to me.
Another interesting thing is when I am in function init_func_i2c, I used
bt
full in GDB to check the stack. I get the following: (gdb) bt full #0 <signal handler called> No locals. #1 0x00000000 in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. Previous frame inner to this frame (corrupt stack?)
Neither does this.
Does this mean the stack is corrupted? There should have a stack already
in
this moment, right?
Does anyone has any idea which direction I should go?
Check your voltages, as close to the flash chips as possible. The new ones may draw higher currents (especially higher and steeper peaks). If your voltages are not clean you may see data corruption, which would explain the effects you describe (and a lot more).
Best regards,
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 On the subject of C program indentation: "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." - Blair P. Houghton
Hi Raymond,
On Friday 17 December 2010 17:12:00 raymond zhao wrote:
It is not the hardware problem. I update the u-boot to latest version and port all the configuration files. It just works. Must be something improved (or fixed) in the new u-boot version. So I learned the lesson, always use latest stable u-boot version. :-)
Yes. And another lesson would be to push your board support upstream, so that you save yourself the trouble of maintaining a non-mainlined version. ;)
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
participants (3)
-
raymond zhao -
Stefan Roese -
Wolfgang Denk