[PATCH 2/3] env: set fdtfile environment variable from /chosen/fdtfile

[Casey Connolly]

On 6/11/25 15:55, Quentin Schulz wrote:
> Hi Casey,
> 
> On 6/10/25 6:23 PM, Casey Connolly wrote:
>> If /chosen/fdtfile exists in the devicetree and the fdtfile variable
>> isn't set in the default environment then populate it. This allows for
>> U-Boot to load the devicetree from the boot partition or ESP that should
>> more closely match the OS being booted.
>>
>> Signed-off-by: Casey Connolly <casey.connolly at linaro.org>
>> ---
>>   common/board_r.c | 35 +++++++++++++++++++++++++++++++++++
>>   1 file changed, 35 insertions(+)
>>
>> diff --git a/common/board_r.c b/common/board_r.c
>> index 
>> 41c8dec8d49ef21a12fd41272581dd94484dfa08..594c7827c39cfca5f4561b4699e5b66de54e11c2 100644
>> --- a/common/board_r.c
>> +++ b/common/board_r.c
>> @@ -448,8 +448,41 @@ static int should_load_env(void)
>>       return 1;
>>   }
>> +/**
>> + * fdtdec_setup_fdtfile - set fdtfile variable from /chosen/fdtfile
>> + *
>> + * This function will look for a string property named "fdtfile" under
>> + * the chosen node and if found set the "fdtfile" environment variable.
>> + *
>> + * This devicetree property is used to identify the path to the FDT in
>> + * use so that the same path can be checked in the dtbs directory on
>> + * the boot partition or ESP.
>> + */
>> +int setup_fdtfile(void)
>> +{
>> +    ofnode node;
>> +    const char *path;
>> +
>> +    if (env_get("fdtfile"))
> 
> How do we guarantee that fdtfile variable is read from the default 
> environment (I assume here you're talking about the environment stored 
> in the U-Boot binary?) with env_get?

I'm not sure tbh, I don't have much familiarity with the env_ api.

> 
>> +        return -EINVAL;
>> +
>> +    node = ofnode_path("/chosen");
>> +    if (!ofnode_valid(node))
>> +        return -ENOENT;
>> +
>> +    path = ofnode_read_string(node, "fdtfile");
>> +    if (!path)
>> +        return -ENOENT;
>> +
> 
> Please add this to the DT spec (and schema) before it lands in U-Boot so 
> we can have some sort of standard here (e.g. Barebox may want to use 
> that as well? The earlier stage setting this variable needs to know the 
> location, name and expected content of the property).
> 
> Additionally, you say this property is a string array, I assume of the 
> form:
> 
> fdtfile = "myboard.dts", "myboard-overlay.dtso";
> 
> ?
> 
> Which seems to be hinted at by the cover letter.
> 
> In that case, I don't think ofnode_read_string is the right way to go. 
> We should
> 
> 1) enforce the location of the dts in the array (I assume 0?)
> 2) look only at that location to get fdtfile, e.g. with 
> ofnode_read_string_index?
> 
> Otherwise we'll have incompatibility with old U-Boot being unable to 
> parse a string array and new Device Tree providing an actual string array.

I don't think this is an issue since a string array in DT is just null 
separated strings, but yeah it would probably make things clearer 
regardless.

thanks

> 
> Cheers,
> Quentin

-- 
Casey (she/they)