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.conno...@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)
