Re: [PATCH v3 06/15] Introduce structured tag value definition

[Herve Codina <herve.codina@bootlin.com>]

Hi David,

On Sat, 12 Sep 2026 12:34:24 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

...

> > Do you mean that we should avoid the DATA_LEN_ENCODING and always have the
> > 32-bit value right after the tag to give the size for all "skippable" tags?  
> 
> Yes.
> 

I did a test using a dts file available in kernel sources. I used (arbitrary
choice) juno.dts [0].

Without any new tags, the size of the compiled dtb is 27067 bytes.

With new metadata tags identifying phandles in properties (FDT_PROPDATA_PHANDLE),
the size of the dtb becomes 29027 bytes and so 29027 - 27067 = 1960 bytes for
those FDT_PROPDATA_PHANDLE tags (+7.2%).

The tags used are composed of:
32-bit: FDT_PROPDATA_PHANDLE value encoding 1 x 32-bit for data
32-bit: offset in the property where a phandle is present.

Removing the '1 x 32-bit' information from the tag value and adding a 32-bit
'length' in all cases will lead 3 x 32-bit values for a FDT_PROPDATA_PHANDLE
tag (tag + length + offset) instead of the 2 x 32-bit (tag + offset).

Back to juno.dts instead of 1960 bytes, the FDT_PROPDATA_PHANDLE will need
1960 * 3 / 2 = 2640 bytes (+9.7%). This leads to around +2.5% of the whole
dtb just to have the 32-bit for length. This +2.5% can be easily avoided.

Also, I will not be surprised to see more tags in the future adding some more
metadata information and so increasing dtb sizes.

Quite often you have mentioned memory constraints system where libfdt should
be as small as possible. On those system, the dtb itself is embedded in the
binary close to libfdt. The size of dtb should be taken into account.

If the SAFE_SKIP bit is removed, I even plan to use this now free bit in the
length encoding part:
  0b000: No data
  0b001: 1 fdt32
  0b010: 2 fdt32
  ...
  0b110: 6 fdt32
  0b111: On additional fdt32 to encode the length of data.

IHMO, length encoding bits in tag value definition should be kept and used
for all tags where the length is fixed and can be encoded using these bits.


[0] https://elixir.bootlin.com/linux/v7.2.5/source/arch/arm64/boot/dts/arm/juno.dts

Best regards,
Hervé