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

> Dear raymond zhao,
>
> In message <AANLkTik9PHqAAvvE1fpGVMh5EYVBb=LitaxA2dG7Y_SA at 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
>