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

[Tom Rini <trini@ti.com>]

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?

-- 
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/96c2c5ed/attachment.pgp>