On Fri, 13 Feb 2026 06:33:46 +0100 "H. Nikolaus Schaller" <[email protected]> wrote:
> Hi, > > > Am 12.02.2026 um 23:19 schrieb Andreas Kemnade <[email protected]>: > > > > On Thu, 12 Feb 2026 17:55:43 +0100 > > "H. Nikolaus Schaller" <[email protected]> wrote: > > > >>> Am 12.02.2026 um 17:47 schrieb Andreas Kemnade <[email protected]>: > >>> > >>> On Thu, 12 Feb 2026 16:49:43 +0100 > >>> "H. Nikolaus Schaller" <[email protected]> wrote: > >>> > >>>>> Am 12.02.2026 um 16:26 schrieb Kory Maincent (TI) > >>>>> <[email protected]>: > >>>>> > >>>>> Allow overlays to be applied to any DTB. This adds around ~40% to the > >>>>> total size of the DTB files on average. > >>>> > >>>> Is this unconditionally enabled or can it be turned off by some CONFIG? > >>>> We have > >>>> our own defconfig so I would not worry if if is enabled in > >>>> omap2plus_defconfig > >>>> and disabled in ours. > >>>> > >>>> We have several devices where the boot loader can't handle overlays > >>>> (never touch > >>>> a working boot-loader :) So this seems to only contribute to build and > >>>> load time > >>>> without benefit. > >>>> > >>> As long as you do not add overlays, the bootloader does not care. I would > >>> like to simply carry around the 1-bit mmc overlay for one broken board. > >>> That would help me. So I think there is a benefit but nobody forces > >>> you to use it. > >> > >> Well, it does not force to use the really good feature, but it forces to > >> add > >> ~40% more file size and some more compile time, if I understand it > >> correctly. > >> > > Compile time, hardly measurable even if you just do make dtbs. > > > > Size on disk: > > a) if it lives around in a /boot partitions with kernels and initrams in it, > > then we are around 1% more space needed. > > Ah, I see. I was too focussed on the "adds around ~40% to the total size of > the DTB files". > > For the Letux arm distro all DTBs are around 8.1 MB at the moment so it will > grow not that much > (there are non-TI devices included). > > So you are right, it is ~1% of the total if the kernel image is counted. > > Therefore, space should not be something we should be too concerned about > (although I remember > discussions for driver code where every single byte did count). > > On the other hand this increases load time from (sometimes slow) µSD for a > specific DTB by 40%. > That should at least be discussed. > so also 1% of total loading time. And symbols can be stripped away during e.g. deployment. fdtput -r some_board.dtb /__symbols__ I am not strongly against it. It is just we are doing something unusual here. Are there reasons why it is unusual I do not understand? I think it can be useful for every board in some situations. For the ones with can carry a head, they are the most useful. What was the reasoning to have it enabled for k3 for every board? K3 and Broadcom-64bit seem to be the only arch doing that. Broadcom mostly many RPis, some routers. Regards, Andreas
