Dear Wolfgang,
On Monday 10 January 2011 04:11 AM, Wolfgang Denk wrote:
Dear Albert ARIBAUD,
In message4D286F58.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.
Agree. But do you think the pointer based approach makes it overly complex?
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.
Agree.
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.
Agree. The only benefit is that I can use some memory barrier instructions without hand-coding the respective machine instructions. But that can be done if it helps avoiding compiler breakage.
Best regards,
Wolfgang Denk