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
-------------------------------------------------------------------------
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
