[U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Stefano,

On Wed, 15 May 2013 14:24:33 +0200, Stefano Babic <sbabic@denx.de>
wrote:

> On 15/05/2013 14:09, Albert ARIBAUD wrote:
> >>
> >> Albert, what do you think about ? Should these files be moved away from
> >> armv7 ?
> > 
> > If the SoC is ARMv5, then yes, its arch/arm/cpu files should not go in
> > armv7 -- and then, we may have to discuss whether, and how, to factorize
> > ISA-level code. Maybe we need an arch/arm/isa/armv{4,5,6,7...} beside
> > arch/cpu, and move wherever is isa-specific there.
> 
> Agree. I think adding armv{4,5,6,7...} is the most clean solution.

This is a clean solution, but do we have the problem? IOW, do we have a
substantial quantity of code that is common to a given ISA but neither
generic to ARM (if it were, it would go to arch/arm or arch/arm/lib) nor
specific to a CPU (if it were, then it should stay under arch/arm/cpu/)?
If we do then moving this code under an isa tree makes sense; if we
don't, then arch/arm/cpu/<cpu>/<soc> is enough, and mvf600 just jas to
move under arch/arm/cpu/ and copy the few ARMv5 snippets it needs from
another ARMv5-based cpu.

IMO, the proof is in the pudding: if I see a patch that creates e.g.
arch/arm/isa/armv5 and factorizes isa code there from cpu subdirs, and
if this results in a smaller codebase (apart from doc) and no binary
size increase, then I'll ack it and apply it [albeit on next as the
merge window is now closed].

> > Regarding errata, I don't understand your point: if they are specific
> > to armv7, then arch/arm/cpu/armv7/start.S seems to be the place to put
> > them (assuming they affect execution before board_init_f() of course).
> 
> I was not able to express my point, sorry. Of course, the right place
> for them is arch/arm/cpu/armv7/start.S. My concern was related to this
> SOC, as it seems it steals armv7 code but it is not armv7. Then changes
> in start.S, that fixes real problems for armv7, can break this Vybrid.
> But the reason is that Vybrid initialization should not be taken from
> arch/arm/cpu/armv7/start.S.

I understand now, and this is a valid point -- all the more a reason to
move mvf600 under arch/cpu/, with or without factorizing armv5 code.

> Best regards,
> Stefano

Amicalement,
-- 
Albert.