From: Eric N. Johnson (ACD) [mailto:[EMAIL PROTECTED]
> 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
