From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 02 Jul 2013 11:58:51 -0600 Subject: [U-Boot] [RFC] Supporting multiple variants of an SoC In-Reply-To: <20130702162829.GG16630@bill-the-cat> References: <20130702162829.GG16630@bill-the-cat> Message-ID: <51D314DB.2010702@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 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.