[U-Boot-Users] Freescale MPC8349EMDS hang on boot

[David Hawkins]

Hi guys,

As noted in Ira's previous posts, he'd managed to get the
MPC8349E and MPC8349EA boards to fail consistently.

Starting with the U-Boot head, and applying Ira's minimal
BCSR access plus linker 32-byte alignment patch, we used a
BDI2000 to set break-points until we identified the flash
address at which the board died. The BDI could break
consistently at FE00_9B90, but stepping past that point
would result in failure.

FE00_9B90 is in the drivers/i2c/fsl_i2c.c code, which
explains why Ira would see the 'I2C: ' line before lockup.

I put a logic analyzer on the local bus and triggered
at the access to FE00_9B90, and found something weird ...

Right before the access to FE00_9B90 was a *write* to
FE03_03C8. This location is in the .data section, but
in *read-only* Flash.

The data following that write is then *not* the same as
the data shown in the ELF file (or binary file written
to flash).

My hypothesis is that this write-access to the flash triggers
an undocumented Flash command code, that causes further reads
from the  Flash to return manufacturer data *not code*. Hence,
following the write to Flash, the processor loads garbage
instructions and goes off into nowhere land.

Ira's alignment patch to the linker code causes the
write-address to change, so I suspect that the address for
the Flash write was critical in triggering the Flash code.

The offending write shown in the logic analyzer trace was
the value 0005_FE99 to address FE03_03C8, which results
in 16-bits writes of 0005 then FE99 to address FE03_03C8
and FE03_03CA.

On the MPC8349E board, which uses Micron Q-Flash, the Flash
reads after this write return 0, while on the MPC8349EA board,
which uses Spansion Flash, the reads return non-zero data, but
still invalid data.

We tried writing the offending command code to Flash and
then reading from FE00_9B90 to see if we could reproduce
what the logic analyzer shows. However, we could not reproduce
the problem; the write waveforms would match, but the
reads returned valid Flash data. So, its a pretty subtle
Flash command code sequence!

How's that for a 'trial by fire'?!

The offending line that produces the write to Flash, involves
the use of a

static unsigned int i2c_bus_speed[2]

on line 48 of drivers/i2c/fsl_i2c.c, which is written to in
the function i2c_init(). This code is running from Flash still,
so there should be no writes to .data section code.

git log d8c82db4

shows Timur added this code. So, Timur, you owe Ira a
beer for the stress this change caused :)

We haven't looked into the intent of the I2C speed tracking
variable, so can't provide a patch. However, I'm sure Timur
will come up with a nice solution.

Thanks for all the valuable feedback everyone supplied to Ira.

Kudos to Ira for debugging this issue.

Cheers,
Dave Hawkins.