Bug 23380 - SH: Obscure CPU erratas
Summary: SH: Obscure CPU erratas
Alias: None
Product: eCos
Classification: Retired
Component: HAL   
(Show other bugs)
Version: CVS
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: ecc-bugs-int
QA Contact: ecc-bugs-int
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-05 08:44 UTC by Jesper Skov
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-20 15:53:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jesper Skov 2001-01-05 08:44:28 UTC
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

   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
                system initialization.

   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.

Comment 1 Alex Schuilenburg 2003-06-20 15:53:07 UTC
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=23380

Note You need to log in before you can comment on or make changes to this bug.