[U-Boot-Users] Freescale MPC8349EMDS BCSR corruption

[David Hawkins <dwh@ovro.caltech.edu>]

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.

Cheers,
Dave

PS. The MDS board serial port is also driving the 3.3V
processor with 5V logic levels (4V measured) which is
bad-bad-bad, but thats not the cause of our current issue.