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?