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

[Tom Rini <trini@ti.com>]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130702/1b6c8cda/attachment.pgp>