On Sat, Jan 27, 2018 at 09:30:11PM +0100, Marek Vasut wrote:
> On 01/25/2018 01:37 PM, David Gibson wrote:
> > 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.
> 
> Right
> 
> > 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.
> 
> There's a regular mallocator in later stages of u-boot and a small
> allocator for the early stages if needed. It's only the early one that
> doesn't implement free() and it's only used for a very short time when
> the system is still running from flash.
> 
> Thus far, I don't see a usecase for unflattening the tree that early,
> but maybe one will come in the future.In the later stages, the design is
> that you do unflatten only if you have a system which benefits from it
> and has the resources to do that. Modern systems usually do, but there
> are systems with weird limitations.
> 
> Since you can do a lot more than just booting with u-boot, leaking any
> memory is a really bad idea.

"Leaking" might not have been the right word.  Essentially you want to
use a pool allocator, where you can't free individual small
allocations, but you can free the entire pool of "dt associated
allocations".  If your program lifetime is small enough, you can just
treat the entire program as one pool.  Otherwise it's not too
complicated to have explicit pools.  Basically you,
	1. Create a pool
	2. Unflatten, allocating from that pool
	3. Manipulate tree
	4. Reflatten (to a buffer outside the pool)
	5. Discard pool

> > 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