Hi Allen,
On Thu, Apr 19, 2012 at 12:22 PM, Allen Martin amartin@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