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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
