Re: [PATCH v3 15/15] Introduce v18 dtb version

[Ayush Singh <ayush@beagleboard.org>]

Herve Codina <herve.codina@bootlin.com> writes:

> Hi Ajush,
>
> On Tue, 13 Oct 2026 22:34:57 +0530
> Ayush Singh <ayush@beagleboard.org> wrote:
>
>> David Gibson <david@gibson.dropbear.id.au> writes:
>> 
>> > On Fri, Sep 25, 2026 at 03:21:57PM +0200, Herve Codina wrote:  
>> >> Hi David,
>> >> 
>> >> On Mon, 21 Sep 2026 16:20:02 +1000
>> >> David Gibson <david@gibson.dropbear.id.au> wrote:
>> >>   
>> >> > On Wed, Aug 26, 2026 at 10:31:46AM +0200, Herve Codina wrote:  
>> >> > > 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.
>> >> > > 
>> >> > >     libfdt, dtc and other tools implementing version v18 will be able to
>> >> > >     skip unknown tags available in dtbd generated with later version of
>> >> > >     dtc.
>> >> > > 
>> >> > >   - 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. For instance, the future addons format will
>> >> > >     use this field to clearly identify that the dtb is an addon 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
>> >> > > apply:    
>> >> > 
>> >> > "last_comp_version_w allows modifications" is a bit hard to
>> >> > understand.  What exactly is the version number against which we're
>> >> > comparing that value?  
>> >> 
>> >> We had one last_comp_version.
>> >> 
>> >> Now we have two last_comp_version, one for reading and one for writing.
>> >> We compare again the dtb version supported by our libfdt version.
>> >> 
>> >> This comes from the discussion [1]
>> >> 
>> >> [1] https://lore.kernel.org/all/CAL_JsqLRrbZje_gGZPBDni6StFa+6rdiECtk49on8VfkP7CDvw@mail.gmail.com/  
>> >
>> > Ok, I now see that the logic is you simply fail to proceed with writes
>> > if the library's latest understood version is < last_comp_version_w.
>> >
>> > As I said elsewhere, this approach doesn't particularly make sense to
>> > me.  If lib_version >= last_comp_version you *can* write, even if it
>> > means stripping everything that's not understood at lib_version.
>> >
>> > So the real question here is how do we know, for any given structured
>> > tag, what write operations require the version to be downgraded (which
>> > might in turn require this and/or other structured tags to be stripped
>> > entirely).
>> >
>> > This is related to (though not the same as) the question of whether
>> > introducing a new structured tags requires a bump to the dtb version
>> > (though not to last_comp_version, of course).
>> >
>> > Here's the simplest model I can think of.  It's what I'd suggest,
>> > unless one of it's limitations is a showstopper for what you have in mind:
>> >
>> >  - version and last_comp_version retain their meanings.  No new header
>> >    version.
>> >  - New structured tags *do* require a new version.  If a dtb wants to
>> >    include a specific tag, it must label itself with a version that
>> >    defines that tag.  To enforce that:
>> >     - For read operations, if we encounter a (known) tag that
>> >       doesn't belong in the header version, we throw an error (either
>> >       BADSTRUCTURE, or a new error for the purpose).
>> >        - If version <= FDT_LAST_SUPPORTED_VERSION and we encounter an
>> >          unknown tag that also trips the error (since if it was
>> > 	 defined in this version, we should know about it).
>> >     - For write operations (including in-place), we always error if
>> >       version > FDT_LAST_SUPPORTED_VERSION (done in fdt_rw_probe_()).
>> >     - fdt_open_into() _is_ permitted if version > FDT_LAST_SUPPORTED_VERSION.
>> >       It will strip all unknown structured tags from the entire tree
>> >       and downgrade the version to FDT_LAST_SUPPORTED_VERSION.
>> >
>> > This does mean that every new tag does require a new version, which
>> > may make experimenting with new tags more awkward.  More
>> > significantly, it also means that any change requires a version
>> > downgrade, even if it's just updating a handful of properties.
>> >
>> > On the plus side, it's fairly simple, retains as much as possible
>> > current version semantics.  Most especially there's no tricky
>> > questions about what sorts of writes might invalidate an unknown tag
>> > (they'll all be stripped by the time we permit a write operation).
>> >
>> > If those limitations really are a showstopper, I do have a few other
>> > models that might work, though.  
>> 
>> The limitations do not sound too bad. And it feels easier to implement than
>> keeping track of read and write versions separately for each new tag.
>
> But it doesn't handle the use case I mentioned in a previous reply :(
>
> bootloader knows about version 2.0
> kernel knowns about version 3.0
>
> dtb 3.0 we want the bootloader to skip tags it doesn't know about but this same
> bootloader has to handle 'unknown' tags on some modification. We want to have 
> possibilities to let this bootloader perform those modifications (under precise
> known rules) and pass this dtb to the kernel.
>
> Best regards,
> Hervé

Apologies, I guess your email with the bootloader case came while I was
composing, hence missed it.

Anyway, that is an interesting case, and well, it does happen rather
frequently in embedded devices. I just did not consider it in the earlier
reply. If I remember correctly, U-boot does some dt fixups after detecting
things like GPU in case of TI AM62 (used in BeaglePlay and PocketBeagle 2).

Best Regards,
Ayush Singh

-- 
BeagleBoard.org Foundation
https://www.beagleboard.org