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

[Lukasz Majewski]

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