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

Stephen Warren
2016-04-25T19:25:17Z

On 04/23/2016 11:14 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 19 April 2016 at 14:59, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@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@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.