Dear Wolfgang, On Monday 10 January 2011 04:11 AM, Wolfgang Denk wrote: > Dear Albert ARIBAUD, > > In message<4d286f58.9010...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
