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. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
