On 05/27/2016 04:54 PM, Paul Burton wrote:
On Fri, May 27, 2016 at 04:40:07PM +0200, Marek Vasut wrote:
Hi Marek,
Hi!
Hi again Marek :)
Hi!
We're already using the cache size auto-detection on Malta, and on 2 other FPGA-based boards internally. I've submitted v2 which preserves CONFIG_SYS_CACHELINE_SIZE as a synonym of ARCH_DMA_MINALIGN for the drivers that are still using it.
That's a good workaround for now. Would you be interested in fixing this runtime cache configuration properly ?
We use the runtime cache size detection on Malta, on SEAD3 & on Boston. The latter 2 aren't upstream yet of course, but all 3 are FPGA-based platforms used to develop, test & showcase new CPUs. As such the CPU (& by association the cache) can change just by flashing a new bitfile to the board, and it's very convenient for a single build of U-Boot to work regardless of the bitfile in use.
Right, this much I understand.
It all works fine so long as drivers are well behaved, and nothing on any of those platforms uses CONFIG_SYS_CACHELINE_SIZE. I'm not sure there's anything to fix really apart from drivers should possibly move to use ARCH_DMA_MINALIGN, but I wouldn't feel comfortable doing a global replacement as I don't have a way to test many boards for other architectures.
I went through the u-boot sources again and it's mostly USB to blame, but I don't think USB should use ARCH_DMA_MINALIGN. USB controllers usually have their own DMA engine which might have different alignment requirements from the one in the CPU. This would imply that the entire concept of ARCH_DMA_MINALIGN is becoming increasingly inapplicable to modern CPUs and we might need some sort of DMA API to deal with that.
But ok, that would be a lot of work far beyond the scope of this patchset. I suspect setting CONFIG_SYS_CACHELINE_SIZE to sensible default so it wouldn't break USB would be a good start. 128 might be a good pick, since I don't think there are systems with cache line size longer than that and so flushing/invalidating that much would assure it works on whole cacheline at least.
Off-topic: Is malta that mipsfpga or is that something else ? Can I synthesise that mipsfpga into some altera FPGA ? If so, which one is a good pick ?
I don't know much about the MIPSfpga project to be honest, but I can forward your question to someone who does.
That's OK, I will poke myself into it before bothering you with it, thanks!
Thanks, Paul