[U-Boot] [PATCH 38/60] ARM: tegra: remove tegra_get_chip()

[Stephen Warren]

On 04/23/2016 11:14 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 19 April 2016 at 14:59, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> U-Boot is compiled for a single board, which in turn uses a specific SoC.
>> There's no need to make runtime decisions based on SoC ID. While there's
>> certainly an argument for making the code support different SoCs at
>> run-time, the Tegra code is so far from that possible ideal that the
>> existing runtime code is an anomaly. If this changes in the future, all
>> runtime decisions should likely be based on DT anyway.
>>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> ---
>>   arch/arm/mach-tegra/ap.c               | 106 ++++++++++-----------------------
>>   arch/arm/mach-tegra/cache.c            |  20 +++----
>>   arch/arm/mach-tegra/cpu.c              |  16 ++---
>>   arch/arm/mach-tegra/cpu.h              |   6 --
>>   arch/arm/mach-tegra/tegra20/warmboot.c |  20 ++-----
>>   5 files changed, 51 insertions(+), 117 deletions(-)
>
> What exactly is missing to prevent multi-arch support?

In a word: everything:-)

Pretty much all decisions in core architecture code, core Tegra code, 
drivers, and even board files are currently made at compile time. For 
example, consider drivers where the register layouts are different 
between different SoCs; not just new fields added, but existing fields 
moved to different offsets. Right now, we handle this by changing the 
register struct definition at compile time. To support multiple chips, 
we'd have to either (a) link in n copies of the driver, one per register 
layout, or (b) rework the driver to use #defines and runtime 
calculations for register offsets, like the Linux kernel drivers do. 
Tegra USB is one example. The pinmux and clock drivers have a 
significantly different sets of pins/clocks/resets/... per SoC, and 
enums/tables describing those sets are currently configured at compile 
time. Some PMIC constants (e.g. vdd_cpu voltage) are configured at 
compile-time, and even differ per board.

> Shouldn't we head towards that rather than making it harder?

I don't see any need for that, no.

U-Boot is built for a specific board (or in some cases a set of 
extremely closely related set of boards, such as the RPI A/B/A+/B+). 
There's no need to determine almost anything at run-time since almost 
all information is known at compile time, with exceptions such as 
standardized enumerable buses such as USB, PCIe. If we support multiple 
HW in a single binary, it gets bloated with code that simply isn't going 
to be used, since all the extra code is either for a platform that the 
build won't be installed on (e.g. clock/pinmux tables), or is overhead 
to add runtime detection of which block of code to use, which simply 
isn't needed in the current model.

In my opinion, firmware/bootloaders run on a single specific board, 
whereas full-featured operating systems support multiple systems.

As an aside, I've wondered whether U-Boot should be split into multiple 
parts; one HW-specific binary providing various drivers (e.g. via 
DM-related APIs?) and the other containing just high-level 
user-interface code such as the shell, high-level USB/... protocols, 
which would only call into those APIs. Still, I don't think we're 
anywhere close to that, and I'm not aware that it's a goal of the 
project at the moment.