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:
signature.asc
Description: PGP signature
