On 08/15/17 14:15, Tom Rini wrote: > With support for stacked overlays being part of libfdt it is now > possible and likely that overlays which require __symbols__ will be > applied to the dtb files generated by the kernel. This is done by > passing -@ to dtc. This does increase the filesize (and resident memory > usage) based on the number of __symbol__ entries added to match the > contents of the dts. < snip > And for some background, for those who were not on the irc channel, here is the conversation that Tom and I had: <Tartarus> frowand: So, dtc knows -@, but the kernel doesn't globally use -@ yet due to increased memory usage, in the dtb? <frowand> yes <frowand> It is available via the pattern that you can see in drivers/of/unittest-data/Makefile <Tartarus> Is there an opt-in way to get the extra symbols? <frowand> # enable creation of __symbols__ node <frowand> DTC_FLAGS_overlay := -@ <Tartarus> ah, hm <frowand> The problem is that it is always on, once the flags are added <frowand> there are a few ways I have thought of making it optional <frowand> 1) DTC_FLAGS_overlay := CONFIG_OVERLAY_ENABLED_IN_BASE <Tartarus> OK. There's at least a few vendors that are eagerly awaiting overlays Just Working, is why I'm asking <Tartarus> How much extra memory usage are we talking about, on a 'big' platform for example? <frowand> where CONFIG_OVERLAY_ENABLED_IN_BASE is a string of either empty or "-@". I don't know if the kconfig allows that, but I'm guessing there is some way to do it <frowand> Not sure of size penalty. <Tartarus> CONFIG_USE_xxx as a bool, CONFIG_xxx as the string <Tartarus> I would kind of assume wanting overlays to just work would be the common case, at least in terms of in-kernel users <frowand> 2) When instantiating the device tree from the FDT, do not keep the __SYMBOLS__ node if overlays are not enabled in the kernel <Tartarus> ie if it's a CONFIG opt-in, multi_v7_defconfig, etc, would want it on <frowand> the issue with 2, is that the boot image still has the size penalty <frowand> 3) the bootloader could choose whether to pass the __SYMBOLS__ node to the kernel or not <Tartarus> I'm not sure about 3 honestly <frowand> Yep, 3 is my least favorite. <Tartarus> If one has a case where there's a desire for no overlay support, for whatever reason, that's a feature of the kernel <frowand> There is probably also option 4, 5, etc. But I haven't thought it through too deeply yet. <Tartarus> I can see some sort of CONFIG option, default y, being a reasonable option here <frowand> I'm not sure about the common case. There are some boards where overlays would almost always be used, but there may also be boards where there are rarely used. <frowand> But the common case is a bikeshed issue to me. <Tartarus> heh <Tartarus> Well, here's why I was thinking that <frowand> As long as the users and distros have a way to control it. <Tartarus> Lots of proprietary boards I've dealt with could just be an EVM + overlay <Tartarus> wrt dtb <frowand> what is EVM? <Tartarus> Today it's take the evm dts, start hacking <Tartarus> evaluation platform <Tartarus> The second, similar, example would be custom platforms based on SoMs <frowand> Are you saying to use an overlay to add onto the base EVM dts kinda sorta the way that some driver writers use kernel modules to add drivers? <Tartarus> A reasonable analogy, yes <frowand> ok, just wanted to verify I understood the model <frowand> I see that as a reasonable development technique <frowand> I have some time critical errands to run, so I'll be gone for a few hours. It would be good to share what we just said with the mail list, and see if anyone else has some brilliant ideas. Start with what the objectives/issues are, some possible solutions... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
