From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Mon, 10 Jan 2011 10:26:04 +0530 Subject: [U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7 In-Reply-To: <20110109224143.0E98E150A44@gemini.denx.de> References: <1293018898-13253-1-git-send-email-aneesh@ti.com> <1293018898-13253-3-git-send-email-aneesh@ti.com> <4D2805FC.7070200@free.fr> <4D2863D0.2050005@ti.com> <4D286F58.9010605@free.fr> <20110109224143.0E98E150A44@gemini.denx.de> Message-ID: <4D2A9164.5020107@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Wolfgang, On Monday 10 January 2011 04:11 AM, Wolfgang Denk wrote: > 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. 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 >