New MPC5200 Eratta/ATA Bugs

[Stephen Warren]

From: Eric N. Johnson (ACD) [mailto:ejohnson at acdstar.com] 
> 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:
>>>  ATA_ISOLATION_TO_BUFFERS = MPC's_ATA_ISOLATION or (GPIO_UDMA and
ATA_DMA_ACK#) 

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:

ATA_ISOLATION_TO_BUFFERS = \
    (~GPIO_UDMA and MPC's_ATA_ISOLATION) | \
    (GPIO_UDMA and ATA_DMA_ACK#)

(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
either...

> I've been told there's a new silicon revision of the MPC5200 due
sometime 
> 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 nvidia.com        http://www.nvidia.com/
swarren at wwwdotorg.org     http://www.wwwdotorg.org/pgp.html