On Tue, Jun 11, 2024 at 5:52 PM Chen-Yu Tsai <wenst@xxxxxxxxxxxx> wrote: > > On Mon, Jun 10, 2024 at 11:16 PM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > 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 > > (+CC DT folks and mailing list) > > I suppose we could make the `fdtoverlay` program embed this data during > the kernel build. That would keep the information together, while also > having one source of truth (the kernel Makefiles). Whether it belongs > in the DTB or not is a separate matter. Some time ago, I asked a similar question with a similar motivation. https://lore.kernel.org/devicetree-compiler/CAK7LNARV8Bo-tBXMdOu55Wg9uZRXvNiRdkDJ4LH8PwVMnMp4cA@xxxxxxxxxxxxxx/ > > > the source, but perhaps people have given up on that? > > I wouldn't say given up, since we haven't agreed on anything either. > Elliot had some concerns when I brought this up earlier [1] though. > > ChenYu > > [1] https://lore.kernel.org/linux-mediatek/20240314113908471-0700.eberman@xxxxxxxxxxxxxxxxxxxxxxxxxx/ > -- Best Regards Masahiro Yamada
