[U-Boot] [RFC] Supporting multiple variants of an SoC

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/02/2013 02:40 PM, Tom Rini wrote:
> On Tue, Jul 02, 2013 at 11:58:51AM -0600, Stephen Warren wrote:
>> On 07/02/2013 10:28 AM, Tom Rini wrote:
>>> Hey guys,
>>> 
>>> I'm wondering about something and looking for input.  As has
>>> come up a few times now, we have the ability for a single
>>> binary to run on a few systems (there's both i.MX examples and
>>> AM335x examples), but what we don't have is agreement on the
>>> best way to handle things that must (today) be done at build
>>> time.  For example, am335x_evm supports both the "kitchen sink"
>>> style EVM which includes NAND, and Beaglebone White/Black,
>>> which do not.  But we default to env on NAND as that was the
>>> first board up.  What might provide the best end-user
>>> experience (in their binary) would be adding a build target of
>>> am335x_evm_bbb that: - Uses eMMC for environment - Uses GPIO
>>> (since we have a button available) for skipping Falcon Mode and
>>> then adding am335x_evm_sd_only that: - Uses a file on FAT for
>>> environment - Uses a character (c) for skipping Falcon Mode and
>>> maybe even adding am335x_evm_nand that: - Uses NAND for
>>> environment (still default) - Checks environment for skipping
>>> Falcon Mode
>>> 
>>> That said, when others have suggested something like this
>>> before, Wolfgang has pointed out and NAK'd the idea of adding N
>>> different configuration as that adds (potentially) a lot of
>>> build time for custodians/etc that tend to build --soc or
>>> --arch or other group targets.  So, what do we want to do here?
>>> I guess longer term, if we are able to focus on switching to
>>> Kconfig, it would become we provide a generic defconfig for
>>> am335x (or imx6 or ...) with a best-fit-for-all set and
>>> communities can provide tweaked binaries as needed.  But do we
>>> want to think about any stop-gap solutions here?
>> 
>> Can there be a single generic binary, which is configured at
>> run-time by device-tree? Tegra and at least some Samsung Exynos
>> boards (snow I guess) seem headed that way, although the
>> conversion is nowhere near complete and hasn't yet covered the
>> specific differences you listed above.
> 
> We don't, today, support switching where environment comes from at 
> run-time, but we kind of could add that.  Same with the SPL
> related changes.  But, is it worth doing the effort now vs device
> model (which would lead to easier run time environment backing
> switching) and Kconfig and so on?

I don't think device model or Kconfig alone solve the issue. To
support the different boards, you can:

a) Build different binaries using different configuration files,
whether those config files are include/config/*.h, or Kconfig doesn't
really matter.

b) Parameterize everything at run-time, either using a DT or some
HW-specific probing method, etc.

For (a) above, I believe the main U-Boot source tree should provide
configs for all the useful board configurations. Otherwise, we get
into a situation where the build process for some boards is:

1) clone source
2) MAKEALL boardname

and the build process for other boards is:

1) clone source
2) Either manually edit include/config/*.h, or a .config file, or
download one of those from some other source.
3) Edit boards.cfg to add the board
4) MAKEALL boardname

That seems like a really bad user-experience for the poor people whose
board configuration is deemed not acceptable in the main source tree.

Also, if (2) and (3) above require someone to maintain the
instructions/diffs or alternate copies of the config files. That means
maintaining part of U-Boot out-of-tree rather than in-tree. That seems
like a bad idea; the out-of-tree code will never manage to keep fully
up-to-date with upstream.

So, my assertion is that if we do (a) above not (b) above, we simply
have to allow the U-Boot source tree to include all the config files
necessary to support all boards.