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

[Simon Glass]

Hi Allen,

On Thu, Apr 19, 2012 at 12:22 PM, Allen Martin <amartin at nvidia.com> wrote:

> On Thu, Apr 19, 2012 at 11:27:05AM -0700, Simon Glass wrote:
> > >
> > > This is part of an upcoming patch set to move all armv4t code out of
> > > tegra2 u-boot and put it into an SPL, but I wanted to get some early
> > > feedback on this patch.  This moves most of the tegra2 SoC code from
> > > arch/arm/cpu/armv7 to a new directory arch/arm/cpu/tegra2-common.
> > > This code will be shared between the armv7 and armv4t builds of
> > > tegra2.
> >
> > I am not sure whether moving things up a level is OK. It makes some
> > sense to me but is different from what other boards do.
>
> Agreed I couldn't find any other examples, but AFAIK no other board is
> trying to do what we do (sharing code between 2 different CPU
> models).  The other options I contemplated were:
>
> -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'.


>
> > Secondly, you will at some point add Tegra 3 support I suppose. In
> > that case much of this code will become common anyway. Should you do
> > that split (tegra-common, tegra2-common) now or later?
>
> I'd like to keep the tegra3 changes separate since that will involve
> refactoring of much of this code.  For the SPL build it's mostly
> hidden in the config and Makefiles.
>
> I thought about doing exactly what you said to reduce the amount of
> code I needed to pull into the SPL build, but what I found was that
> because the SPL needs to initialize some regulators, clocks, and
> pinmux to bring up the A9 and UART it ends up needing much of the
> tegra2 SoC code, so there's not a lot of opportunity to minize the
> code set for the SPL build beyond the CONFIG options to disable
> drivers that area already there.
>

OK. Please note that we do have a refactor in the Chromium tree to move
things into tegra-common and add T30 support. We hope to get this upstream
once the T20 stuff is there (NAND, keyboard and LCD are still pending).

Regards,
Simon


>
> -Allen
> nvpublic
>