[U-Boot] [PATCH 1/3] MIPS: Move cache sizes to Kconfig

[Marek Vasut <marex@denx.de>]

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
> 


-- 
Best regards,
Marek Vasut