Re: [RFC] devicetree: new FDT format version

From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Frank Rowand
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Devicetree Compiler
	<devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Pantelis Antoniou
	<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
	"Pantelis
	Antomarek.vasut-Re5JQEeQqe/2sr8fMPgRzw@public.gmane.org"
	<panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
	Kyle Evans <kevans-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
Subject: Re: [RFC] devicetree: new FDT format version
Date: Thu, 25 Jan 2018 23:37:34 +1100	[thread overview]
Message-ID: <20180125123734.GC2099@umbus> (raw)
In-Reply-To: <90983180-ae3b-5a31-9dc0-b62b978a0fba-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On Thu, Jan 25, 2018 at 10:14:38AM +0100, Marek Vasut wrote:
> On 01/23/2018 10:17 PM, Frank Rowand wrote:
> [...]
> > My knowledge of bootloader use of the FDT is nearly non-existent, so
> > I'm on thin ice here.  But I am guessing that a lot of bootloader
> > processing of FDT data could be removed if the kernel would unflatten
> > a chained FDT and overlay FDT(s).
> > 
> > Comments from the bootloader folks on this topic would be much
> > appreciated.
> 
> U-Boot, when using DT as a hardware-description (rather than just
> passing it to Linux) usually operates on the FDT, unless explicitly
> configured to unflatten the tree. That later option is not enabled by
> default.
> 
> The reason for that is so that the DT can be accessed very early on, at
> which point there may not be any other memory available than a very
> limited stack and the FDT blob can still be located in some read-only
> memory.

Right, this is exactly the reason that the fdt format is designed so
you can read thing from it directly.  If you're doing more than very
minor modifications, however, it does become worth unflattening.

Note that while unflatenning requires an allocator of sorts, it can be
a trivial one.  A bump allocator in a fixed buffer of reasonable size
would do fine.  You don't realy need a free(), since the bootloader
has limited lifetime you can just leak nodes until you throw the lot
away.  You can also use pointers into the flattened tree blob to avoid
allocating space for the actual property values (except for ones you
add later, obviously).  And if you make extensive enough changes that
leaked pieces really do become a problem, you could do a
flatten/unflatten pass to recompact everything.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]