On Tue, 2008-07-22 at 16:14 -0700, David Hawkins wrote:
Hi all,
We're having a rough week with our Freescale MDS boards. I've just submitted a service request through Freescale's online system. However, I figured others (eg. Kim, and Timur) might be interested in the following problem:
We have an MPC8349E-MDS-PB and an MPC8349EA-MDS-PB that we are using to develop PCI agent mode software. After debugging the I2C flash write issue, we found that the serial port would stop receiving shortly after boot (we could see the U-Boot boot messages). We traced the issue to the RS232 receiver enable bit in the BCSR register 0 being written to; disabling the serial port receiver tri-state outputs.
The RS232 receiver enable bit is not being changed by a write to the BCSR, but by a write to the *flash*.
Yikes!!
We were adding print statements that showed the value of the BCSR code in U-Boot. We found the error occurred during the Flash CFI code. I don't think the problem is related to CFI code - thats just where the corruption is triggered.
Starting with U-Boot head, we applied Timur's I2C patch, and then added the following code sequence to __flash_detect_cfi in U-boot:
- write 0x2F (the reset value) to the BCSR[0] register at 0xE2400000
- read BCSR[0] (to confirm the write)
- write 0xCC to Flash (0xFE000000)
- read BCSR[0] (to show the value changed)
(If you would like to repeat this test, please ask and Ira can send a patch file).
The board was operated in stand-alone host-mode on the bench.
The following logic analyzer traces show:
a) the case where this sequence did nothing,
http://www.ovro.caltech.edu/~dwh/mpc8349e_bcsr_read_ok.pdf
and
(b) the case where the sequence changed the value read back from the BCSR base address to 0xCC.
http://www.ovro.caltech.edu/~dwh/mpc8349e_bcsr_read_bad.pdf
We were able to trigger the error on both the E and EA board, but it would not fail every single reset - it occurred about 1-in-3 tries - hence it seems like a timing issue. It could be that the BCSR CPLD code has a decoding bug, or a timing issue. Another possibility is that the CPLD code that monitors CS#[0] for RCW access on boot is screwy and is allowing a write to CS#[1] to occur.
We have had several other weird issues with the ethernet interfaces failing too, and their enable registers are in BCSR[0], so this would explain that too.
I figured that this may help others explain weird issues they may be seeing on their development boards.
I believe it is timing issue. The BCSR read(#LOE) has not enough setup time. You may try the two solutions: (a) slow down local bus clock If you are using default configuration, the local bus clock is 66MHz. change the LCRR from div 4 to div 8 to make the local bus clock as 33MHz. you can find it in the MPC8349EMDS.h
(b) Tuning the #CS1 timing, such as change the OR1 from 0xFFFFE8F0 to 0xFFFFE9F7
Let us know the result.
Thanks, Dave