Add support for structured tags and v18 dtb version

The basenamelen member in the node structure is set in all cases to a positive value, the length of the basename string. Also it is used as parameters on function expecting a size_t type.

Further more an implicit cast of strspn() returned value from size_t to int is needed in checks.c to avoid a signed/unsigned compilation warning when this value is checked.

This member has no reason to be a signed integer and its obvious type is size_t.

Be consistent and fix its type.

Signed-off-by Herve Codina <[email protected]>

---
 checks.c | 2 +-
 dtc.h    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

checks.c +1 -1

index 45d0213..946c142 100644
@@ -324,7 +324,7 @@ ERROR(node_name_chars, check_node_name_chars, NODECHARS);
 static void check_node_name_chars_strict(struct check *c, struct dt_info *dti,
 					 struct node *node)
 {
-	int n = strspn(node->name, c->data);
+	size_t n = strspn(node->name, c->data);
 
 	if (n < node->basenamelen)
 		FAIL(c, dti, node, "Character '%c' not recommended in node name",

dtc.h +1 -1

index 7231200..473552e 100644
@@ -227,7 +227,7 @@ struct node {
 	struct node *next_sibling;
 
 	char *fullpath;
-	int basenamelen;
+	size_t basenamelen;
 
 	cell_t phandle;
 	int addr_cells, size_cells;

Signature · 1 line

2.52.0

fdtdump checks the dtb version and simply failed if the dtb version is newer than the last version supported by fdtdump.

This check is not needed and too restrictive. Indeed, fdtdump does read-only operations on the dtb provided and should rely only the last_comp_version header field to know whether or not it can read the dtb.

The current check also avoid the use of fdtdump in tests checking for the libfdt behavior when an new (future) dtb version is used.

Relax fdtdump checks removing the check of the dtb version header field.

Signed-off-by Herve Codina <[email protected]>

fdtdump prints a message on stderr when it encounters a wrong tag and stop its processing without returning an error code.

Having a wrong tag is really a failure. Indeed, the processing cannot continue.

Be more strict. Stop the processing, print a message and return an error code. In other words, call die().

Signed-off-by Herve Codina <[email protected]>

---
 fdtdump.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

fdtdump.c +1 -2

index 6c9ad90..0e7a265 100644
@@ -146,8 +146,7 @@ static void dump_blob(void *blob, bool debug)
 			continue;
 		}
 
-		fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
-		break;
+		die("** Unknown tag 0x%08"PRIx32"\n", tag);
 	}
 }
 

Signature · 1 line

2.52.0

Quoted 9 lines · Herve Codina

fdtdump prints a message on stderr when it encounters a wrong tag and stop its processing without returning an error code.

Having a wrong tag is really a failure. Indeed, the processing cannot continue.

Be more strict. Stop the processing, print a message and return an error code. In other words, call die().

Quoted 1 line

Signed-off-by Herve Codina <[email protected]>

The intention of fdtdump is that it's a fairly crude debugging tool - it will generally attempt to produce at least partial output even on a bad dtb file. If you want a polished tool for use on good dtbs, use :dtc -I dtb -O dts".

That's why this didn't die() initially - the idea is if there's some bogus stuff in the dtb, it might print a bunch of these warnings, but eventually resynchronize on another valid tag.

Hi David,

Quoted 12 lines · On Mon, 23 Feb 2026 16:38:09 +1100 David Gibson <[email protected]>…

Quoted 10 lines · Herve Codina

fdtdump prints a message on stderr when it encounters a wrong tag and stop its processing without returning an error code.

Having a wrong tag is really a failure. Indeed, the processing cannot continue.

Be more strict. Stop the processing, print a message and return an error code. In other words, call die().

Signed-off-by Herve Codina <[email protected]>

Quoted 4 lines

The intention of fdtdump is that it's a fairly crude debugging tool - it will generally attempt to produce at least partial output even on a bad dtb file. If you want a polished tool for use on good dtbs, use :dtc -I dtb -O dts".

fdtdump is also interesting for tests purpose.
I use it to check dtb outputs during tests. Those outputs are either generated by dtc or by libfdt.

Having an error code returned by fdtdump when it cannot parse the given dtb allows to have this test (patch 10):
--- 8< ---

(quoted diff) +7 -1

+
+    base_run_test wrap_fdtdump unknown_tags_can_skip.dtb unknown_tags_can_skip.dtb.out
+    # Remove unneeded comments
+    sed -i '/^\/\/ /d' unknown_tags_can_skip.dtb.out
+    base_run_test check_diff unknown_tags_can_skip.dtb.out "$SRCDIR/unknown_tags_can_skip.dtb.expect"
+
+    run_wrap_error_test $FDTDUMP unknown_tags_no_skip.dtb
--- 8< ---

Quoted 2 lines

Quoted 3 lines

That's why this didn't die() initially - the idea is if there's some bogus stuff in the dtb, it might print a bunch of these warnings, but eventually resynchronize on another valid tag.

Current implementation cannot resynchronize. The parsing loop is exited
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/fdtdump.c#n150
and the program just returns 0.

Instead of just print and exit the loop, the idea was to have a program error code set. Calling die() allows to print, exit the loop and exit the program with an error code.

With that in mind, I can do what you prefer. Either:
- keep the die() call
or
- discard this patch and update the test in patch 10 (i.e. remove the 'run_wrap_error_test $FDTDUMP unknown_tags_no_skip.dtb' line)

Current code perform a version downgrade at one place only, the end of fdt_rw_probe_().

In order to offer a finer grain and choose to downgrade or not depending on the exact writes done, introduce fdt_downgrade_version() to perform the downgrade operation.

The modification doesn't introduce any functional changes.

Signed-off-by Herve Codina <[email protected]>

---
 libfdt/fdt_rw.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

libfdt/fdt_rw.c +7 -2

index 7475caf..90ea14e 100644
@@ -22,6 +22,12 @@ static int fdt_blocks_misordered_(const void *fdt,
 		    (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)));
 }
 
+static void fdt_downgrade_version(void *fdt)
+{
+	if (!can_assume(LATEST) && fdt_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
+		fdt_set_version(fdt, FDT_LAST_SUPPORTED_VERSION);
+}
+
 static int fdt_rw_probe_(void *fdt)
 {
 	if (can_assume(VALID_DTB))

@@ -33,9 +39,8 @@ static int fdt_rw_probe_(void *fdt)
 	if (fdt_blocks_misordered_(fdt, sizeof(struct fdt_reserve_entry),
 				   fdt_size_dt_struct(fdt)))
 		return -FDT_ERR_BADLAYOUT;
-	if (!can_assume(LATEST) && fdt_version(fdt) > 17)
-		fdt_set_version(fdt, 17);
 
+	fdt_downgrade_version(fdt);
 	return 0;
 }
 

Signature · 1 line

2.52.0

In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present at the offset 0 of the structure block.

This assumption is not correct. Indeed, a FDT_NOP can be present at the offset 0 and this is a legit case.

Introduce fdt_first_node() in order to get the offset of the first node (first FDT_BEGIN_NODE tag) available in a fdt blob.

Signed-off-by Herve Codina <[email protected]>

---
 libfdt/fdt.c             | 25 +++++++++++++++++++++++++
 libfdt/libfdt_internal.h |  1 +
 2 files changed, 26 insertions(+)

libfdt/fdt.c +0 -0

index 56d4dcb..676c7d7 100644

libfdt/fdt.c +15 -0

+int fdt_first_node(const void *fdt)
+{
+	int nextoffset = 0;
+	int offset;
+	uint32_t tag;
+
+	do {
+		offset = nextoffset;
+		tag = fdt_next_tag(fdt, offset, &nextoffset);
+		switch (tag) {
+		case FDT_END_NODE:
+		case FDT_PROP:
+			return -FDT_ERR_BADSTRUCTURE;
+
+		case FDT_BEGIN_NODE:

Hi Hervé, David,

I'm trying to review the patches that have no feedback so far.

Being new to the dtc codebase I'm mostly pointing out things that are not clear from a newcomer point of view. I hope this helps anyway.

On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:

Quoted 5 lines

In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present at the offset 0 of the structure block.

This assumption is not correct. Indeed, a FDT_NOP can be present at the offset 0 and this is a legit case.

I wonder whether this can be proven by showing an example, or the specs, or whatever use case that makes sense.

Quoted 15 lines

Introduce fdt_first_node() in order to get the offset of the first node (first FDT_BEGIN_NODE tag) available in a fdt blob.

Signed-off-by Herve Codina <[email protected]>

---
 libfdt/fdt.c             | 25 +++++++++++++++++++++++++
 libfdt/libfdt_internal.h |  1 +
 2 files changed, 26 insertions(+)

libfdt/fdt.c +0 -0

index 56d4dcb..676c7d7 100644

libfdt/fdt.c int fdt_check_prop_offset_(const void *fdt, int offset) · line 254

Quoted 3 lines

libfdt/fdt.c +0 -0

@@ -252,6 +252,31 @@ int fdt_check_prop_offset_(const void *fdt, int offset)
 	return offset;
 }
 

Even though this seems to be quite uncommon in this repository, I think documenting new functions would be helpful, especially preconditions, postconditions and parameter values when not obvious.

What about:

Find the initial node with content (FDT_BEGIN_NODE) in a fdt, skipping FDT_NOP [and <other tags> is applicable].

*return: pointer to the first node into the fdt or e negative error value

In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present at the offset 0 of the structure block.

This assumption is not correct. Indeed, a FDT_NOP can be present at the offset 0 and this is a legit case.

fdt_first_node() has been introduce recently to get the offset of the

first node (first FDT_BEGIN_NODE) in a fdt blob.

Use this function to get the first node offset instead of looking for this node at offset 0.

Signed-off-by Herve Codina <[email protected]>

---
 libfdt/fdt.c    | 10 ++++++++--
 libfdt/fdt_ro.c | 16 +++++++++++++---
 libfdt/fdt_rw.c |  6 ++++++
 3 files changed, 27 insertions(+), 5 deletions(-)

libfdt/fdt.c +0 -0

index 676c7d7..ff2fa6c 100644

Quoted 7 lines · Herve Codina

In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present at the offset 0 of the structure block.

This assumption is not correct. Indeed, a FDT_NOP can be present at the offset 0 and this is a legit case.

fdt_first_node() has been introduce recently to get the offset of the

                            ^
			    introduced

libfdt/fdt.c int fdt_first_node(const void *fdt) · line 285

Quoted 7 lines

int fdt_next_node(const void *fdt, int offset, int *depth) {

libfdt/fdt.c +2 -1

-	int nextoffset = 0;
+	int nextoffset = offset;
 	uint32_t tag;
 
+	if (offset <= 0) {  

What is the difference between 0 and a engative value?

This is where the parameter value is not obvious to the newcomer and I'd love seeing it concisely documented.

fdt_check_full() makes the assumption that a FDT_END tag is present immediately after the FDT_END_NODE tag related to the root node.

This assumption is not correct. Indeed, FDT_NOP tags can be present between this FDT_END_NODE tag and the FDT_END tag.

Handle those possible FDT_NOP tags.

Signed-off-by Herve Codina <[email protected]>

---
 libfdt/fdt_check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

libfdt/fdt_check.c +1 -1

index a21ebbc..cca0523 100644
@@ -43,7 +43,7 @@ int fdt_check_full(const void *fdt, size_t bufsize)
 			return nextoffset;
 
 		/* If we see two root nodes, something is wrong */
-		if (expect_end && tag != FDT_END)
+		if (expect_end && tag != FDT_END && tag != FDT_NOP)
 			return -FDT_ERR_BADSTRUCTURE;
 
 		switch (tag) {

Signature · 1 line

2.52.0

The goal of structured tag values is to ease the introduction of new tags in future releases with the capability for an already existing release to ignore those structured tags. In order to do that data length related to the unknown tag needs to be identify.

Also a flag is present

to tell an old release if this tag can be simply skipped or must lead to an error.

Structured tag value is defined on 32bit and is defined as follow:

Bits | 31 | 30 | 29 28 | 27 0|
------+----+----------+-------------------+--------+
Fields| 1 | CAN_SKIP | DATA_LNG_ENCODING | TAG_ID |
------+----+----------+-------------------+--------+

Bit 31 is always set to 1 to identified a structured tag value.

Bit 30 (CAN_SKIP) is set to 1 if the tag can be safely ignore when its

TAG_ID value is not a known value (unknown tag). If the CAN_SKIP bit is set to 0 this tag must not be ignored and an error should be reported when its TAG_ID value is not a known value (unknown tag).

Bits 29..28 (DATA_LNG_ENCODING) indicates the length of the data related

to the tag. Following values are possible:
- 0b00: No data.
The tag is followed by the next tag value.

- 0b01: 1 cell data
The tag is followed by a 1 cell (u32) data. The next tag is available after this cell.

- 0b10: 2 cells data
The tag is followed by a 2 cells (2 * u32) data. The next tag is available after those two cells.

- 0b11: Data length encoding
The tag is followed by a cell (u32) indicating the size of the data. This size is given in bytes. Data are available right after this cell.

The next tag is available after the data. Padding is present after the data in order to have the next tag aligned on 32bits. This padding is not included in the size of the data.

Bits 27..0 (TAG_ID) is the tag identifier defining a specific tag.

Introduce the structured tag values definition and some specific tags reserved for tests based on this structure definition.

Signed-off-by Herve Codina <[email protected]>

---
 libfdt/fdt.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

libfdt/fdt.h +1 -0

index a07abfc..2e07599 100644
@@ -49,6 +49,7 @@ struct fdt_property {
 
 #define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
 #define FDT_TAGSIZE	sizeof(fdt32_t)
+#define FDT_CELLSIZE	sizeof(fdt32_t)
 
 #define FDT_BEGIN_NODE	0x1		/* Start node: full name */
 #define FDT_END_NODE	0x2		/* End node */

Quoted 4 lines · Herve Codina

The goal of structured tag values is to ease the introduction of new tags in future releases with the capability for an already existing release to ignore those structured tags. In order to do that data length related to the unknown tag needs to be identify.

                                         ^
					 identified

Quoted 2 lines

Also a flag is present

"Also add a flag"

Quoted 11 lines

to tell an old release if this tag can be simply skipped or must lead to an error.

Structured tag value is defined on 32bit and is defined as follow:

Bits | 31 | 30 | 29 28 | 27 0|
------+----+----------+-------------------+--------+
Fields| 1 | CAN_SKIP | DATA_LNG_ENCODING | TAG_ID |
------+----+----------+-------------------+--------+

Quoted 1 line

Bit 31 is always set to 1 to identified a structured tag value.

                               ^
			       identify

Quoted 1 line

Bit 30 (CAN_SKIP) is set to 1 if the tag can be safely ignore when its

                                                         ^
							 ignored

Quoted 7 lines

TAG_ID value is not a known value (unknown tag). If the CAN_SKIP bit is set to 0 this tag must not be ignored and an error should be reported when its TAG_ID value is not a known value (unknown tag).

Bits 29..28 (DATA_LNG_ENCODING) indicates the length of the data related

I think "LEN" is more common than "LNG".

libfdt/fdt.h struct fdt_property { · line 63

Quoted 4 lines

libfdt/fdt.h +3 -0

+/* Tag values flags */
+#define FDT_TAG_STRUCTURED	(1<<31)
+#define FDT_TAG_SKIP_SAFE	(1<<30)  

This is called CAN_SKIP in the commit message and SKIP_SAFE here. Using a consistent name would be better IMO.

libfdt/fdt.h struct fdt_property { · line 68

Quoted 6 lines

libfdt/fdt.h +5 -0

+#define FDT_TAG_DATA_MASK	(3<<28)
+#define FDT_TAG_DATA_NONE	(0<<28)
+#define FDT_TAG_DATA_1CELL	(1<<28)
+#define FDT_TAG_DATA_2CELLS	(2<<28)
+#define FDT_TAG_DATA_LNG	(3<<28)  

I find _LNG (or _LEN) misleading: this is not the length, but rather an enum value telling you the length is stored in the next cell. What about FDT_TAG_DATA_VARLEN?

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

Handle those structured tag.

fdtdump.c +10 -1

@@ -44,7 +44,7 @@ static const char *tagname(uint32_t tag)
 #define dumpf(fmt, args...) \
 	do { if (debug) printf("// " fmt, ## args); } while (0)
 
-static void dump_blob(void *blob, bool debug)
+static void dump_blob(void *blob, bool debug, int dump_unknown)
 {
 	uintptr_t blob_off = (uintptr_t)blob;
 	struct fdt_header *bph = blob;

@@ -146,20 +146,55 @@ static void dump_blob(void *blob, bool debug)
 			continue;
 		}
 
+		if ((tag & FDT_TAG_STRUCTURED) && (tag & FDT_TAG_SKIP_SAFE)) {
+			sz = 0;
+			switch (tag & FDT_TAG_DATA_MASK) {
+			case FDT_TAG_DATA_NONE:
+				break;
+			case FDT_TAG_DATA_1CELL:
+				sz = FDT_CELLSIZE;
+				break;
+			case FDT_TAG_DATA_2CELLS:

fdtdump.c +14 -1

+				       depth * shift, "", tag, sz);
+				if (dump_unknown > 1 && sz != 0) {
+					printf(" ");
+					for (i = 0; i < sz; i++)
+						printf("%02hhx", *(p + i));
+				}
+				printf("\n");
+			}
+
+			/* Skip the data bytes */
+			p = PALIGN(p + sz, 4);
+			continue;
+		}
+
 		die("** Unknown tag 0x%08"PRIx32"\n", tag);
 	}
 }
 
 /* Usage related data. */
 static const char usage_synopsis[] = "fdtdump [options] <file>";
-static const char usage_short_opts[] = "ds" USAGE_COMMON_SHORT_OPTS;

tests/trees.S +16 -0

@@ -328,3 +328,113 @@ named_root_strings:
 named_root_strings_end:
 
 named_root_end:
+
+
+	/* Tree with "unknown" tags that can be skipped
+	 * Use a really future dtb version to check version downgrade on
+	 * modification.
+	 */
+	treehdr_vers	unknown_tags_can_skip 0xffffffff 0x10
+	empty_rsvmap	unknown_tags_can_skip
+
+unknown_tags_can_skip_struct:
+	fdtlong	FDT_TEST_1CELL_CAN_SKIP
+	fdtlong	0x1
+
+	beginn	""
+		fdtlong	FDT_TEST_NONE_CAN_SKIP
+

tests/trees.S +14 -0

+
+		fdtlong	FDT_TEST_LNG_CAN_SKIP
+		fdtlong	3
+		.byte 0x13
+		.byte 0x13
+		.byte 0x13
+		.byte 0 /* padding */
+
+		beginn	"subnode1"
+			propu64	unknown_tags_can_skip, prop_int, 1, 2
+			fdtlong	FDT_TEST_NONE_CAN_SKIP
+		endn
+
+		beginn	"subnode2"

Quoted 4 lines · Herve Codina

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

Handle those structured tag.

How? This sentence is vague, what about:

Allow dumping the unknown tags or not based on a command line flag.

Quoted 29 lines

fdtdump.c +14 -1

@@ -44,7 +44,7 @@ static const char *tagname(uint32_t tag)
 #define dumpf(fmt, args...) \
 	do { if (debug) printf("// " fmt, ## args); } while (0)
 
-static void dump_blob(void *blob, bool debug)
+static void dump_blob(void *blob, bool debug, int dump_unknown)
 {
 	uintptr_t blob_off = (uintptr_t)blob;
 	struct fdt_header *bph = blob;

@@ -146,20 +146,55 @@ static void dump_blob(void *blob, bool debug)
 			continue;
 		}
 
+		if ((tag & FDT_TAG_STRUCTURED) && (tag & FDT_TAG_SKIP_SAFE)) {
+			sz = 0;
+			switch (tag & FDT_TAG_DATA_MASK) {
+			case FDT_TAG_DATA_NONE:
+				break;
+			case FDT_TAG_DATA_1CELL:
+				sz = FDT_CELLSIZE;
+				break;
+			case FDT_TAG_DATA_2CELLS:
+				sz = 2 * FDT_CELLSIZE;
+				break;
+			case FDT_TAG_DATA_LNG:
+				/* Get the length */

fdtdump.c static void dump_blob(void *blob, bool debug) · line 167

Quoted 6 lines

fdtdump.c +6 -0

+				sz = fdt32_to_cpu(GET_CELL(p));
+				break;
+			}
+
+			if (dump_unknown) {
+				printf("%*s// Unknown tag ignored: 0x%08"PRIx32", data lng %d",  

As before, I'd use "len" instead of "lng".

Quoted 19 lines

fdtdump.c +14 -0

+				       depth * shift, "", tag, sz);
+				if (dump_unknown > 1 && sz != 0) {
+					printf(" ");
+					for (i = 0; i < sz; i++)
+						printf("%02hhx", *(p + i));
+				}
+				printf("\n");
+			}
+
+			/* Skip the data bytes */
+			p = PALIGN(p + sz, 4);
+			continue;
+		}
+
 		die("** Unknown tag 0x%08"PRIx32"\n", tag);
 	}
 }
 

fdtdump.c static void dump_blob(void *blob, bool debug) · line 197

Quoted 13 lines

fdtdump.c +3 -1

 /* Usage related data. */
 static const char usage_synopsis[] = "fdtdump [options] <file>";
-static const char usage_short_opts[] = "ds" USAGE_COMMON_SHORT_OPTS;
+static const char usage_short_opts[] = "dus" USAGE_COMMON_SHORT_OPTS;
 static struct option const usage_long_opts[] = {
 	{"debug",            no_argument, NULL, 'd'},
+	{"unknown",          no_argument, NULL, 'u'},
 	{"scan",             no_argument, NULL, 's'},
 	USAGE_COMMON_LONG_OPTS
 };
 static const char * const usage_opts_help[] = {
 	"Dump debug information while decoding the file",
+	"Dump unknown tags information while decoding the file (-uu to have data)",  

                                                                       ^
								       dump

Quoted 29 lines

tests/trees.S +22 -0

@@ -328,3 +328,113 @@ named_root_strings:
 named_root_strings_end:
 
 named_root_end:
+
+
+	/* Tree with "unknown" tags that can be skipped
+	 * Use a really future dtb version to check version downgrade on
+	 * modification.
+	 */
+	treehdr_vers	unknown_tags_can_skip 0xffffffff 0x10
+	empty_rsvmap	unknown_tags_can_skip
+
+unknown_tags_can_skip_struct:
+	fdtlong	FDT_TEST_1CELL_CAN_SKIP
+	fdtlong	0x1
+
+	beginn	""
+		fdtlong	FDT_TEST_NONE_CAN_SKIP
+
+		propu32	unknown_tags_can_skip, prop_int, 1
+
+		fdtlong	FDT_TEST_1CELL_CAN_SKIP
+		fdtlong	0x11
+
+		propstr	unknown_tags_can_skip, prop_str, "abcd"

tests/trees.S named_root_strings: · line 356

Quoted 4 lines

tests/trees.S +4 -0

+
+		fdtlong	FDT_TEST_2CELLS_CAN_SKIP
+		fdtlong	0x12
+		fdtlong	0x12  

Can you use different values here, just to make the test slightly more robust? Just in case parsing ends up on the wrong cell, as unlikely as it can be.

Same in various places below.

Quoted 20 lines

tests/trees.S +20 -0

+
+		fdtlong	FDT_TEST_LNG_CAN_SKIP
+		fdtlong	3
+		.byte 0x13
+		.byte 0x13
+		.byte 0x13
+		.byte 0 /* padding */
+
+		beginn	"subnode1"
+			propu64	unknown_tags_can_skip, prop_int, 1, 2
+			fdtlong	FDT_TEST_NONE_CAN_SKIP
+		endn
+
+		beginn	"subnode2"
+			fdtlong	FDT_TEST_1CELL_CAN_SKIP
+			fdtlong	0x121
+			propu64	unknown_tags_can_skip, prop_int1, 1, 2
+			fdtlong	FDT_TEST_1CELL_CAN_SKIP
+			fdtlong	0x122
+			propu64	unknown_tags_can_skip, prop_int2, 1, 2

tests/trees.S named_root_strings: · line 380

Quoted 4 lines

tests/trees.S +4 -0

+			beginn	"subsubnode"
+				fdtlong	FDT_TEST_1CELL_CAN_SKIP
+				fdtlong	0x123
+				propu64	unknown_tags_can_skip, prop_int, 1, 2  

As before, you are using values 1 and 2 for all the properties, I'd use different values, and possibly even with different amounts of cells in properties.

Hi Luca,

Quoted 9 lines · On Wed, 01 Apr 2026 17:15:09 +0200 "Luca Ceresoli" <[email protected]>…

Quoted 4 lines · Herve Codina

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

Handle those structured tag.

How? This sentence is vague, what about:

Allow dumping the unknown tags or not based on a command line flag.

Hum indeed but I don't fully agree with your proposal.

The patch adds support for structured tag in fdtdump and introduce the '-u' option to dump unknown tags which can be safely ignored.

What do you think about:

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

Add support for those structured tags in fdtdump and introduce a command line option to dump unknown tags that should be ignored.

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

Handle those structured tag.

Signed-off-by Herve Codina <[email protected]>

+++ b/tests/unknown_tags_can_skip.dtb.dts.expect

tests/unknown_tags_can_skip.dtb.dts.expect new file +9 -0

@@ -0,0 +1,19 @@
+/dts-v1/;
+
+/ {
+	prop-int = <0x01>;
+	prop-str = "abcd";
+
+	subnode1 {
+		prop-int = <0x01 0x02>;
+	};

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

libfdt uses fdt_get_next() to get a tag.

Filtering out tags that should be ignored in fdt_get_next() allows to have the filtering done globally and allows, in future release, to have

a central place to add new known tags that should not be filtered out.

An already known tag exists with the meaning of "just ignore". This tag is FDT_NOP. fdt_get_next() callers already handle the FDT_NOP tag.

Avoid unneeded modification at callers side and use a fake FDT_NOP tag when an unknown tag that should be ignored is encountered.

Add also fdt_get_next_() internal function for callers who need to know

if the FDT_NOP tag returned is a real FDT_NOP or a fake FDT_NOP due to an unknown tag.

Signed-off-by Herve Codina <[email protected]>

Quoted 4 lines · Herve Codina

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error when they are read.

libfdt uses fdt_get_next() to get a tag.

I think you mean fdt_next_tag(), here and elsewhere in the commit message.

Quoted 3 lines

Filtering out tags that should be ignored in fdt_get_next() allows to have the filtering done globally and allows, in future release, to have

                                                         ^
							 releases

Quoted 5 lines

a central place to add new known tags that should not be filtered out.

An already known tag exists with the meaning of "just ignore". This tag is FDT_NOP. fdt_get_next() callers already handle the FDT_NOP tag.

Quoted 4 lines

Avoid unneeded modification at callers side and use a fake FDT_NOP tag when an unknown tag that should be ignored is encountered.

Add also fdt_get_next_() internal function for callers who need to know

And here fdt_next_tag_()?

libfdt provides internal used helpers to convert an offset to a pointer

but nothing to do the reverse operation.

Fill this lack and introduce the fdt_ptr_offset_() internal helper to

The structured tag value definition introduced recently gives the ability to ignore unknown tags without any error.

When the dtb is modified those unknown tags have to be taken into account.

First, depending on the unknown tag location, the item associated with the tag is identified:
- An unknown tag located just after a FDT_BEGIN_NODE is related to the node.

- An unknown tag located just after a FDT_PROP is related to the property.

- An unknown tag out of any node (i.e located before the first FDT_BEGIN_NODE or after the last FDT_END_NODE is a global tag

related to the dtb itself.

Then, if we are allowed to write a dtb containing unknown tags, the following rules are used:
- When a property is modified, tags related to this property are removed and the dtb version is downgraded.

- When a property is removed, tags related to this property are obviously removed. The dtb version is kept unchanged.

- When a property or a node is added, obviously no unknown tags are added and the dtb version is kept unchanged.

- When a node is removed, tags related to this node are obviously removed. The dtb version is kept unchanged.

- Adding, removing or modifying a property is not considered as a node modification and so, those operations have no impacts on unknown tags related to the node. Those node related tags are kept unchanged.

- The only modification considered as a node modification is setting its name. We consider that this operation has no impact on tags related to the node. Here also, those node related tags and the dtb version are kept unchanged.

- Global (dtb related) unknown tags are kept unchanged regardless the modification done.

Implement those rules when a dtb is modified.

Signed-off-by Herve Codina <[email protected]>

Quoted 2 lines

- An unknown tag out of any node (i.e located before the first FDT_BEGIN_NODE or after the last FDT_END_NODE is a global tag

                                                   ^
						   missing ')'

Quoted 1 line

related to the dtb itself.

Out of curiosity, is there a real use case for global tags after FDT_END_NODE?

This v18 version will add support for
- Structured tags.
Those tags value definition will allow old libfdt, dtc and other tools to skip unknown tags if encountered in future dtb version.

- dt_flags header field.
For now this flag field is set to 0. It is a placeholder for future dtb version and could be used to store some dtb related information such as the kind of dtb.

- last_comp_version_w header field.
This field is similar to last_comp_version but for writing. It contains the lowest version of the devicetree data structure with which the version used can safely perform modifications (taking into account following rules related to unknown tags).
If this lowest version is greater than the last known supported version, modification are simply forbidden and lead to a FDT_ERR_BADVERSION error.

For modification, when an unknown tag that can be skipped is involved and last_comp_version_w allows modifications, the following rules applies:

- When a property is modified, tags related to this property are removed and the dtb version is downgraded.

- When a property is removed, tags related to this property are obviously removed. The dtb version is kept unchanged.

- When a property or a node is added, obviously no unknown tags are added and the dtb version is kept unchanged.

- When a node is removed, tags related to this node are obviously removed. The dtb version is kept unchanged.

- Adding, removing or modifying a property is not considered as a node modification and so, those operations have no impacts on unknown tags related to the node. Those node related tags are kept unchanged.

- The only modification considered as a node modification is setting its name. We consider that this operation has no impact on tags related to the node. Here also, those node related tags and the dtb version are kept unchanged.

- Global (dtb related) unknown tags are kept unchanged regardless the modification done.

In all cases, if unknown tags are not involved in a modification, the dtb version is not downgraded when the modification is node.

Compared to previous version, it is worth noting that the dtb is not

downgrade for all modification but only when unknown tags are removed

due a property modification.

Signed-off-by Herve Codina <[email protected]>

Quoted 4 lines · Herve Codina

This v18 version will add support for
- Structured tags.
Those tags value definition will allow old libfdt, dtc and other tools to skip unknown tags if encountered in future dtb version.

"old" seems to imply that versions released before today will be able to wkip unknown tags. I think this should be clarified along the lines of:

libfdt, dtc and other tools implementing version v18 will be able to wkip unknown tags in dtbs generated with later versions of dtc

Quoted 5 lines

- dt_flags header field.
For now this flag field is set to 0. It is a placeholder for future dtb version and could be used to store some dtb related information such as the kind of dtb.

Is this intended for DT addons?

You may mention a realistiv use case here.

Quoted 2 lines

Compared to previous version, it is worth noting that the dtb is not

                                                               ^
				                        "dtb version"

Quoted 1 line

downgrade for all modification but only when unknown tags are removed

^
downgraded for any

Quoted 1 line

due a property modification.

^
"due to a ..."

I'm not sure I got what you mean by the initial "Compared to previous version". Version(s) of what?

If I just remove those 4 words the sentence seems OK to me BTW.

Hi Luca,

Quoted 11 lines · On Wed, 01 Apr 2026 17:19:09 +0200 "Luca Ceresoli" <[email protected]>…

Quoted 4 lines · Herve Codina

This v18 version will add support for
- Structured tags.
Those tags value definition will allow old libfdt, dtc and other tools to skip unknown tags if encountered in future dtb version.

"old" seems to imply that versions released before today will be able to wkip unknown tags. I think this should be clarified along the lines of:

libfdt, dtc and other tools implementing version v18 will be able to wkip unknown tags in dtbs generated with later versions of dtc

Yes, I will add this clarification in the next iteration.

Quoted 8 lines

Quoted 5 lines

- dt_flags header field.
For now this flag field is set to 0. It is a placeholder for future dtb version and could be used to store some dtb related information such as the kind of dtb.

Is this intended for DT addons?

Quoted 1 line

You may mention a realistiv use case here.

Intended, maybe not. Used by addons, yes, for sure.

What do you think if I add the following:
For instance, the future addons format will use this field to clearly identify that the dtb is an addon dtb.

Quoted 16 lines

Quoted 1 line

Compared to previous version, it is worth noting that the dtb is not

                                                               ^
				                        "dtb version"

Quoted 1 line

downgrade for all modification but only when unknown tags are removed

^
downgraded for any

Quoted 1 line

due a property modification.

^
"due to a ..."

I'm not sure I got what you mean by the initial "Compared to previous version". Version(s) of what?

Quoted 1 line

If I just remove those 4 words the sentence seems OK to me BTW.

Is the following clearer?

It is worth noting that with this v18 version, the dtb version is not downgraded for any modification but only when unknown tags are removed due to a property modification. In v17 or older version any modification led to a dtb version downgrade.

Recently, I sent a RFC series related to support for metadata and addon device-trees [1].

During the discussion the concept of structured tags and "unknown" tags emerged as well as the need to have them handled as a prerequisite of support for metadata and addon.

The conclusion was the need for a new dtb version (v18) with support for:
- Structured tags and based on them, "unknown" tags.
Those structured tags allow to have an standardized definition of tags with the capability of skipping a tag and its related data when a "unknown" tag is incountered by a given version of libfdt, dtc and tools. Those "unknown" tags are tags defined in future versions. Even if they exact meaning is unknown for an 'old' version, they structure is understood and the 'old' version can skip them without any errors if allowed.

- Flags in the dtb header (dt_flags).
The goal of this field is to have a placeholder to specify the type of dtb we are dealing with. For instance, addons dtb will set a flag in this placeholder

- A last compatible version for writing purpose.
The goal of the new dtb header field (last_comp_version_w) is to disable globally any modification. It works similarly to last_comp_version but for modification. It can be used to avoid any modification that could be done by an 'old' version and could lead to inconsistencies between the modification itself and some "unknown" tags.

This RFC series implements those features and leads to the v18 dtb version.

Hi David,

Quoted 31 lines · On Tue, 10 Feb 2026 18:33:28 +0100 Herve Codina <[email protected]>…

Recently, I sent a RFC series related to support for metadata and addon device-trees [1].

During the discussion the concept of structured tags and "unknown" tags emerged as well as the need to have them handled as a prerequisite of support for metadata and addon.

The conclusion was the need for a new dtb version (v18) with support for:
- Structured tags and based on them, "unknown" tags.
Those structured tags allow to have an standardized definition of tags with the capability of skipping a tag and its related data when a "unknown" tag is incountered by a given version of libfdt, dtc and tools. Those "unknown" tags are tags defined in future versions. Even if they exact meaning is unknown for an 'old' version, they structure is understood and the 'old' version can skip them without any errors if allowed.

- Flags in the dtb header (dt_flags).
The goal of this field is to have a placeholder to specify the type of dtb we are dealing with. For instance, addons dtb will set a flag in this placeholder

- A last compatible version for writing purpose.
The goal of the new dtb header field (last_comp_version_w) is to disable globally any modification. It works similarly to last_comp_version but for modification. It can be used to avoid any modification that could be done by an 'old' version and could lead to inconsistencies between the modification itself and some "unknown" tags.

Quoted 2 lines

This RFC series implements those features and leads to the v18 dtb version.

I sent this series a month ago.

I know some patches have been applied but what's the plan for the remaining ones?

Is there anything I can do to help move things forward?

Let me know if you want some rebase and/or modification and so a new version of the series or if you need anything else that can help in moving forward.

Quoted 3 lines

I know some patches have been applied but what's the plan for the remaining ones?

Get to them as time permits, which I do not expect to be soon.

Quoted 1 line

Is there anything I can do to help move things forward?

Usher forth a world where small projects get sufficient support to have apprentice maintainers? Other than that, not really.

Quoted 2 lines

Let me know if you want some rebase and/or modification and so a new version of the series or if you need anything else that can help in moving forward.

I will when I can.