[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/24/2012 01:32 PM, Tom Rini wrote:
> On Wed, Oct 24, 2012 at 01:05:16PM -0600, Stephen Warren wrote:
>> On 10/24/2012 12:41 PM, Tom Rini wrote:
...
>>> Doing something to derive this also means that custom
>>> development can be a bit easier too since you can just set
>>> fdtfile directly and work out the logic for auto-detection
>>> later.
>> 
>> Hmm. So I can't really put the following into Tegra's default
>> environment:
>> 
>> "fdtfile=${soc}-${board}${boardrev}.dtb"
>> 
>> ... since that would require any use of "${fdtfile}" in a command
>> to first expand fdtfile itself, then expand it a second time to
>> pick up the actual soc/board/... values, and that's not how the
>> shell works.
>> 
>> That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON
>> in include/configs/tegra-common-post.h) would need to do
>> something like:
>> 
>> setenv fdtfile ${soc}-${board}${boardrev}.dtb
> 
> I hope that a longer term thing would be trying to share more of
> the bootcmd related magic between all our parts.  How we deal with
> this on TI stuff is that in uEnv.txt if we find the file, we load
> the file into the environment (so fdtfile=mylocalstuff.dtb will
> overwrite the default) and if uenvcmd is set execute that command.

Ah, so uEnv.txt is some user-managed file along the same lines as
boot.scr. I had thought it was the file behind CONFIG_ENV_IS_IN_FAT.

>> ... before executing the loaded boot.scr. But then, how would it
>> know whether to do that, or whether the user wanted to override
>> the fdtfile value?
>> 
>> In theory, I could do the following in Tegra's default
>> environment:
>> 
>> "fdtfile=" CONFIG_SYS_SOC "-" CONFIG_SYS_BOARD" ".dtb"
>> 
>> But then that wouldn't allow for the fdtfile value to vary at
>> run-time based on $boardrev.
> 
> It's not an imutable variable, so you could change it, if you do
> that early in the process.

Sure. My point was that would end up duplicating the method to
construct the value in two places; one in includes/configs/xxx.h for
the default, and one in code in U-Boot for the case where we override
the default to include some version number. That doesn't seem ideal.