New MPC5200 Eratta/ATA Bugs
SWarren at nvidia.com
Tue Apr 26 08:13:54 EST 2005
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
> 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
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
> 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 nvidia.com http://www.nvidia.com/
swarren at wwwdotorg.org http://www.wwwdotorg.org/pgp.html
More information about the Linuxppc-embedded