[U-Boot-Users] Freescale MPC8349EMDS BCSR corruption

[Dave Liu <r63238@freescale.com>]

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