Dear Albert ARIBAUD,
In message 4D286F58.9010605@free.fr you wrote:
I know we consider multi-board u-boot binaries when boards are variant of a given SoC, that's one reason why we wanted relocation. I'm not sure about multi-SoC when SoC is a variant of a given cpu, though. Wolfgang, your opinion?
Unless we see a specific example which uses this feature, we should not add provisions that make the code more complicated than needed.
And when we start supporting such a feature, we should probably do this based on a device tree approach.
Although this function is non-empty, flush_dcache_range() is in turn empty. Effect will be the same, right?
Yes the effect is the same, but your patch results in a non-trivially empty function; I'd prefer it to be visibly empty when we compile without cache support.
Yes, that's my opinion, too.
Just because Linux uses armv7-a for a v7 arch does not mean we must have it for u-boot. For starters, U-boot does not always boot Linux. :)
As for out-dated compilers, that's the question I'm asking: do we consider e.g. ELDK 4.2 as outdated or not? It won't accept armv7-a.
That's a catch question.
Yes, ELDK 4.2 is outdated. But it is still one of the most stable versions of a tool chain known to me, especially when it comes to using the very same tool versions across several architectures.
I cannot see any benefits of this code change that would justiify such a breakage.
Best regards,
Wolfgang Denk