On Tue, 02 Jul 2013 16:40:08 -0400, Tom Rini wrote: Hi Tom, > 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?
If I can vote here for something - I would like to first move toward device model + Kconfig implementation. I think that those changes are more important now. > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
