There are a few erratas we may want to support at some time if customers
want or if problems can actually be attributed to these hardware bugs.
Btw, the below are only the ones found to be relevant for the MPC
port - there were quite a few others, for various modules not in use on
the MPC.


I've just gone through the long list of SH erratas [for SH7709A and
SH7729]. Frightening stuff!  But I think, software wise, the MPC (and
GMX320) targets should only be susceptible to the below erratas.

From what I understood, you may end up using the next silicon rev
which may fix some of these. So I will not take any action (other than
the comment suggested for the first errata) without further info from
you:


 SH7-184
   Description: Changing the FRQCR should be done from non-cachable
                memory.

   Action:      I will add some comments to the HAL to make sure we
                don't get bitten by this. No other changes necessary,
                since the cache is always disabled during eCos early
                system initialization.

 SH7-191
   Description: Hardware flow control may cause bytes to get lost if
                CTS is asserted while the SCIF is preparing to send
                the last character in the FIFO.

   Action:      [take a minute to laugh frantically: enabling HW flow
                control may cause bytes to get lost. Funniest HW bug I
                ever came across ;]

                There are some suggested workarounds:

                  1: don't use HW flow control (duh!)

                  2: wire CTS to an interrupt and throttle/unthrottle
                     the flow from the interrupt handler [yuck! Also
                     requires HW changes]

                  3: pad all sent data with a dummy byte.

                3 is probably best. You control the protocol used to
                talk to the other CPU, right? If so, just add a dummy
                char that does not contain data to the packets.

  SH7-221
    Description: Don't flush a write-back enabled cache while the DMA
                 engine is running.


    Action:      Ouch! This is a bad one. We want write-back for
                 performance reasons, we want DMA for performance
                 reasons, and the combination require us to flush
                 memory areas used for DMA actions.

                 There's a suggested workaround: simply disabling the
                 DMA engine before starting a flush, re-enabling it
                 after the flush has completed.

                 That's _probably_ an acceptable solution. But I don't
                 like it much - I can't help feeling disabling the DMA
                 while it's running full steam is asking for
                 trouble. But that's probably just me. It's a fairly
                 simple fix to add, if necessary.