Red Hat Bugzilla – Bug 23380
SH: Obscure CPU erratas
Last modified: 2007-04-18 12:30:32 EDT
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
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
Description: Changing the FRQCR should be done from non-cachable
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
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.
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.
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=23380