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.