Re: Fix potential stall with Coldfire Ethernet

[Bart Veer <bartv@ecoscentric.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

>>>>> "Tarmo" == Tarmo Kuuse <tarmo.kuuse@mail.ee> writes:

    Tarmo> While struggling with eCos on Coldfire 5208 I stumbled on a
    Tarmo> nasty bug. The fast ethernet controller often stalls if
    Tarmo> transmission is flagged immediately after copying data to
    Tarmo> buffer.

    Tarmo> I have no idea why this happens. Maybe my compiler (from
    Tarmo> CodeSourcery, not eCos) does something to confuse the FEC.
    Tarmo> Maybe the 5208 hardware is buggy.

    Tarmo> Hopefully the currently supported devices (5282 and 532x)
    Tarmo> are safe when built with eCos toolchain (I cannot test it).
    Tarmo> The patch could save a few neurons for someone.

    Tarmo> Patch adds a NOP between filling the buffer and flagging
    Tarmo> the transmitter.

This is not the right fix, and the problem is nothing to do with the
toolchain.

FreeScale have redefined the nop instruction for ColdFires to act as a
barrier instruction. When the cpu executes nop it stalls the
instruction pipeline until all previous instructions have completed.
Also, if the processor has some kind of write buffer between the cache
and external memory then nop will stall until the write buffer has
been emptied. Most of the time you do not need to worry about pipeline
effects like this, but DMA engines and cache interactions nearly
always need very special care.

The operation immediately before starting the transmit is a
HAL_DCACHE_STORE(). Without the nop that macro may not have finished
executing, so the cache store is still happening at the point that the
ethernet engine fetches the buffer descriptors. Hence the ethernet
engine may see bogus buffer descriptors, and confusion results.

The correct solution is to incorporate the nop into your processor's
HAL_DCACHE_STORE() macro, thus making the macro do precisely what it
is supposed to do. That will fix any other uses of HAL_DCACHE_STORE(),
not just the ethernet driver. It also avoids adding an unnecessary nop
instruction on processors which do not need it, e.g. the mcf5272 which
does not have a data cache at all.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300
Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300