[U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7

[Aneesh V]

Dear Wolfgang,

On Monday 10 January 2011 04:11 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4D286F58.9010605 at 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
>