Hi Chen-Yu, On Wed, 5 Jun 2024 at 03:48, Chen-Yu Tsai <wenst@xxxxxxxxxxxx> wrote: > > The kernel tree builds some "composite" DTBs, where the final DTB is the > result of applying one or more DTB overlays on top of a base DTB with > fdtoverlay. > > The FIT image specification already supports configurations having one > base DTB and overlays applied on top. It is then up to the bootloader to > apply said overlays and either use or pass on the final result. This > allows the FIT image builder to reuse the same FDT images for multiple > configurations, if such cases exist. > > The decomposition function depends on the kernel build system, reading > back the .cmd files for the to-be-packaged DTB files to check for the > fdtoverlay command being called. This will not work outside the kernel > tree. The function is off by default to keep compatibility with possible > existing users. > > To facilitate the decomposition and keep the code clean, the model and > compatitble string extraction have been moved out of the output_dtb > function. The FDT image description is replaced with the base file name > of the included image. > > Signed-off-by: Chen-Yu Tsai <wenst@xxxxxxxxxxxx> > --- > This is a feature I alluded to in my replies to Simon's original > submission of the make_fit.py script [1]. > > This is again made a runtime argument as not all firmware out there > that boot FIT images support applying overlays. Like my previous > submission for disabling compression for included FDT images, the > bootloader found in RK3399 and MT8173 Chromebooks do not support > applying overlays. Another case of this is U-boot shipped by development > board vendors in binary form (without upstream) in an image or in > SPI flash on the board that were built with OF_LIBFDT_OVERLAY=n. > These would fail to boot FIT images with DT overlays. One such > example is my Hummingboard Pulse. In these cases the firmware is > either not upgradable or very hard to upgrade. > > I believe there is value in supporting these cases. A common script > shipped with the kernel source that can be shared by distros means > the distro people don't have to reimplement this in their downstream > repos or meta-packages. For ChromeOS this means reducing the amount > of package code we have in shell script. > > [1] https://lore.kernel.org/linux-kbuild/20231207142723.GA3187877@xxxxxxxxxx/ > [2] > > scripts/Makefile.lib | 1 + > scripts/make_fit.py | 70 ++++++++++++++++++++++++++++++-------------- > 2 files changed, 49 insertions(+), 22 deletions(-) This is a clever way to discover the included files. Does it need to rely on the Linux build information, or could this information somehow be in the .dtb files? I had expected some sort of overlay scheme in the source, but perhaps people have given up on that? Regards, Simon
