[U-Boot] [PATCH] tegra2: move tegra2 SoC code to arch/arm/cpu/tegra2-common

[Allen Martin]

On Mon, Apr 30, 2012 at 11:31:44AM -0700, Simon Glass wrote:
> 
> -Have the armv4t build reach up and over into armv7
> -Move the code out to board/nvidia
> 
> Both of these seemed worse
> 
> I've thought about this a bit more. To me you have a bit of a unique problem in that you need to build the code as both ARMv4T and ARMv7. The way it works at the moment is pretty simple - we just mark a few files that must be build with ARMv4T and ARMv7 is happy with that also.
> 
> I believe the point of the 'cpu' directory is to separate out common code between different architectures. It seems you want a chip which uses two different architectures. That might be unique in the U-Boot world - I note that other SOCs with different chips use ARMv7 for all of them.
> 
> But really, who cares what architecture you actually use? The code clearly doesn't include ARMv7-isms otherwise it wouldn't build with current compile options. It does work...
> 
> So my suggestion is that you just continue as now, and build the relevant code for ARMv4T. I don't see a compelling reason to move it, least of all into a no-man's land at the same level as 'cpu'.
> 

The problem that pushed me over the edge on this was the patch series
to add thumb support for ARM.  The linker has to insert interworking
code for the cross ARM/thumb calls.  If it is linking armv4t and armv7
objects together it will promote them all to armv7 style interworking
which uses instructions that are illegal on armv4t.  The only fix for
this is to link armv4t objects separately or not support thumb, and we
would really like to support thumb.

Also it's not true that the code in arch/arm/cpu/armv7 doesn't include
any armv7'isms, we're just #ifdef around them for the tegra and call
them later in the boot sequence when we know we're running on the A9.
We also have to code the init sequence extremely carefully to make
sure we don't call any armv7 code on the armv4t.  It's extremely
fragile as any changes to start.S or the ordering of the init sequence
can (and have) broken us.

-Allen
--
nvpublic