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

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

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130702/96c2c5ed/attachment.pgp>

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

[Stephen Warren]

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.

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

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130702/1b6c8cda/attachment.pgp>

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

[Wolfgang Denk]

Dear Tom Rini,

In message <20130702162829.GG16630@bill-the-cat> you wrote:
> 
> 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?

You can always add extra defines on the make command line...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Small is beautiful.

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

[Wolfgang Denk]

Dear Stephen Warren,

In message <51D314DB.2010702@wwwdotorg.org> you wrote:
>
> 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.

One problem here is that - so far - we cannot support multiple storage
devices for the environment at the same time, so a single bbinary
cannot work with environment in NAND or on SDCard.  This is a pity,
but I feel the best way to fix this includes fixing the device driver
model first.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Either one of us, by himself, is expendable.  Both of us are not.
	-- Kirk, "The Devil in the Dark", stardate 3196.1

[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

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

[Tom Rini]

On Tue, Jul 02, 2013 at 11:45:46PM +0200, Wolfgang Denk wrote:
> Dear Tom Rini,
> 
> In message <20130702162829.GG16630@bill-the-cat> you wrote:
> > 
> > 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?
> 
> You can always add extra defines on the make command line...

OK, I'm not spotting the easy way to do that.  Hint?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130703/62dadb8c/attachment.pgp>

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

[Stephen Warren]

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.