[U-Boot] [RFC] Supporting multiple variants of an SoC
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?
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.
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?
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.
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.
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
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
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!
participants (4)
-
Lukasz Majewski -
Stephen Warren -
Tom Rini -
Wolfgang Denk