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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
