[U-Boot] i.MX51: FEC: Cache coherency problem?

[Aneesh V <aneesh@ti.com>]

Hi David,

On Wednesday 20 July 2011 02:51 PM, David Jander wrote:
> On Wed, 20 Jul 2011 10:56:07 +0200

[snip ..]

>>> Any ideas?
>>
>> Yes, one: I had issues with the Marvell Ethernet adapter, which has DMA
>> as well, not because of cache (it was not active at the time) but
>> because of instruction reordering done by the compiler when optimizing,
>> which resulted in out-of-order accesses to the descritpors and DMA
>> registered, so that the DMA start was written before the descriptors
>> were set up. The (proper and clean) solution was to introduce memory
>> barriers at strategic points of the driver to ensure that specific DMA
>> starts were done only after all writes to the descriptors (and possibly
>> buffers).
>
> Hmmm. I know that issue, but AFAICS, the driver already uses readX() and
> writeX() macros when accessing register and DMA memory. Those macros have
> compiler barriers included.... and armv7 is still in-order execution ;-)

1. armv7 is not necessarily in-order. Cortex-A8 is in-order while
Cortex-A9 is out-of-order.
2. I am not sure if in-order execution guarantees memory ordering. My
understanding is that it doesn't.
3. In u-boot's implementation of MMU for ARM, the register
space(everything other than SDRAM) is 'strongly-ordered' memory.
Strongly ordered accesses will be correctly ordered w.r.to all other
accesses in program order.
4. Compiler barriers prevent the compiler from doing certain
optimizations, but doesn't help in these situations.

In short, I think you don't need to worry about ordering, but not
because of compiler barriers or armv7 being in-order.

br,
Aneesh