Hi Stefano, On Wed, 15 May 2013 14:24:33 +0200, Stefano Babic <sba...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot