New MPC5200 Eratta/ATA Bugs

Stephen Warren SWarren at
Tue Apr 26 08:13:54 EST 2005

From: Eric N. Johnson (ACD) [mailto:ejohnson at] 
> At 02:35 PM 4/25/2005, Stephen Warren wrote:
> >Freescale have been working with us on a board work-around for the
> >problem. This basically involves deriving a substitute ATA_ISOLATION
> >signal from the regular ATA control signals, in some cases.
> Are you able to share the circuit they've recommended?  Is it as
simple as:
>    ISOLATION = ((ATA_CS1 or ATA_IOR) and (ATA_CS0 or ATA_IOR))
> This seems like it would be in violation of the setup and hold time 
> requirements for the data bus.

This was suggested:

>>> 2. ... beleives that to fix the ATA_ISOLATION with logic would be
>>>  something like this:

The idea is that the errata only causes a problem for UDMA (not MDMA or
PIO). So, the kernel is modified to set a GPIO whenever UDMA is in
progress. This triggers the external logic to use ATA_DMA_ACK# to
trigger the bus drivers. ATA_DMA_ACK# is the signal that means an actual
DMA data transfer is in progress.

That said, various people are in the process of trying the above logic,
and the more explicit:


(possibly with the extra ~'s in there to fix high v.s. low true...)

And neither of these approaches actually works for us.

If I recall correctly, one of the other errata means MDMA can't work

> I've been told there's a new silicon revision of the MPC5200 due
> later in the year, but the date keeps getting pushed back.

We were told this too. Sounds like maybe sometime in the middle of the
year at the earliest.

Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren at
swarren at

More information about the Linuxppc-embedded mailing list