[U-Boot] u-boot hang after we changed the flash chip

[U-Boot] u-boot hang after we changed the flash chip

[raymond zhao]

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

[U-Boot] u-boot hang after we changed the flash chip

[Wolfgang Denk]

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 at 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

[U-Boot] u-boot hang after we changed the flash chip

[raymond zhao]

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 at 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
>

[U-Boot] u-boot hang after we changed the flash chip

[Stefan Roese]

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 at denx.de