From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 25 Apr 2016 13:25:17 -0600 Subject: [U-Boot] [PATCH 38/60] ARM: tegra: remove tegra_get_chip() In-Reply-To: References: <1461099580-3866-1-git-send-email-swarren@wwwdotorg.org> <1461099580-3866-39-git-send-email-swarren@wwwdotorg.org> Message-ID: <571E6F1D.3040405@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/23/2016 11:14 AM, Simon Glass wrote: > Hi Stephen, > > On 19 April 2016 at 14:59, Stephen Warren wrote: >> From: Stephen Warren >> >> 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 >> --- >> 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.