[U-Boot] i.MX51: FEC: Cache coherency problem?
Albert ARIBAUD
albert.u.boot at aribaud.net
Sat Jul 23 15:04:21 CEST 2011
Le 21/07/2011 08:48, David Jander a écrit :
>> However, it is still correct that copying from an non-cached area is
>> slower than from cached areas, because of burst reads vs. individual
>> reads. However, I doubt that the u-boot user can tell the difference, as
>> the network latency will far exceed the difference in copy time.
That's assuming cache is only for networking. There can be DMA engines
in a lot of other peripherals which do not have the same latency as
network (and then, even for networking, TFTP can be done from a very
nearby server, possibly even on the same Ethernet segment).
>> The
>> question is, which is easier to do, and that is probably a matter of
>> opinion. However, it is safe to say that so far a cached solution has
>> eluded us. That may be changing, but it would still be nice to know how
>> to allocate a section of un-cached RAM in the ARM processor, in so far
>> as the question has a single answer! That would allow easy portability
>> of drivers that do not know about caches, of which there seems to be many.
That is one approach, which I think prevents cache from being used
beyond caching pure CPU-used DRAM.
> I agree. Unfortunately, my time is up for now, and I can't go on with trying
> to fix this driver. Maybe I'll pick up after my vacation.
> As for now I settled for the ugly solution of keeping dcache disabled while
> ethernet is being used :-(
Make sure you flush before disabling. :)
> IMHO, doing cache maintenance all over the driver is not an easy or nice
> solution. Implementing a non-cached memory pool in the MMU and a corresponding
> dma_malloc() sounds like much more universally applicable to any driver.
I think cache maintenance is feasible if one makes sure the cached areas
used by the driver are properly aligned, which simplifies things a lot:
you don't have to care for flush-invalidate or just-in-time invalidate,
you just have to flush before sending and invalidate before reading.
> Best regards,
Amicalement,
--
Albert.
More information about the U-Boot
mailing list