Hi Allen, On Thu, Apr 19, 2012 at 12:22 PM, Allen Martin <amar...@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 >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot