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. > 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. -- Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
