On Wed, Sep 09, 2020 at 10:17:56AM -0700, Gurbir Arora wrote: > Hello Upstream Team, > > This is the second upstream attempt for the fdtoverlay changes and the first attempt can > be found here: https://www.spinics.net/lists/devicetree-compiler/msg01949.html. All of the > issues/comments from the first attempt have been addressed and fixed in this patch. Sorry I've taken so long to look at this. Before delving into the code, I think I need to understand your use case a bit better. There's some confusion here, because there's at least 2 things that "merging overlays" could mean. 1) Combining 2 overlays into one which will have the same effect as both applied sequentially. This is almost trivial, since you can just list all the fragments of the first, followed by all the fragments of the second, with only the fixups nodes needing to be actually "merged". The question is, does this alone provide any tangible benefit over just processing a list of overlays in order. 2) "Partially resolving" an overlay. That is finding cases where we can determine enough about the targets of 2 fragments that we can combine the fragments together. It's entirely possible - both in theory and in practice with dtc - for a single overlay to have multiple fragments targetting the same node (or one targetting a subnode of the first). Thus, this is something that makes logical sense on a single overlay. If you really need both of these operations, I'd suggest separate entry points for them, so that your "merge" would be (1) followed by (2) on the result. > Changelog: > > v1 -> v2: > - Introduction of new entry point, fdt_overlay_merge(), to handles merging > overlay blobs (rather than overload that in fdt_overlay_apply()). > - Removed use of printf() in libfdt. snprintf() is still used to help with string > manipulation. > - Changed the logic to identify fragment nodes. > - Removed use of malloc/calloc and global variables. > - Incorporated a function that copies a node in the overlay tree along with its children and their > properties. > > fdt_overlay_apply() API currently allows for an overlay DT blob to be merged > with a base blob. It assumes that all external symbols specified in overlay > blob's __fixups__ section are found in base blob's __symbols__ section and > aborts on the first instance where a symbol could not be found in base blob. > > This is mostly fine as the primary use of overlay is on a target for its > bootloader to merge various overlay blobs based on h/w configuration detected? > > We are exploring an extended use of fdt_overlay_apply() for offline use, i.e on > the host (build machine) side, which requires merging two overlay DT blobs i.e > the base (overlay) blob will not resolve all the external node references found > in overlay blob. > > Currently all the device-tree (DT) code for a given soc is maintained in a > common kernel repository. For example, this common DT code will have code for > audio, video, fingerprint, bluetooth etc. Further this DT code is typically > split into a base (soc-common) code and board specific code, with the soc code > being compiled as soc.dtb and board specific code being compiled as respective > overlay blobs (board1.dtbo, board2.dtbo etc). soc.dtb represents hardware configuration > of a given SOC while boardX.dtbo represents configuration of a board/platform > designed using that soc.soc.dtb and boardX.dtbo files are flashed separately on > target (besides improving the overall size of DT blobs flashed on target, Android > Treble also requires separation of soc and board DT bits). Bootloader will pick > one of the board overlay blobs and merge it with soc.dtb, before booting kernel > which is presented a unified DT blob (soc + board overlay). > > For ease of code maintenance and better control over release management, we are > exploring allowing some of the tech teams (audio/fingerprint sensor etc) to > maintain their kernel code (including their DT code) outside a common kernel > repository. In our experience, this simplifies number of branches maintained in > core kernel repo. New/experimental features in fingerprint sensor driver for > example that needs to be on a separate branch will not result in unnecessary > branching in core kenrel repo, affecting all other drivers. > > In addition to compiling DT code outside core kernel tree, we also want to merge > the blobs back to respective blobs found in kernel build tree (soc.dtb or > boardX.dtbo), as otherwise relying on bootloader to do all the overlay impacts > boot-time. > > This brings up the need to merge two overlay blobs (fingerprint-overlay.dtbo + > boardX.dtbo), which currently doesn't seem to be supported and which this patch > series aims to support. Can you connect the dots a bit more as to why your neeed overlay merging? If the concern is boot time, then it seems like you want to merge everything into the base tree before boot time, in which case you can just apply all the overlays in order. -- 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
