On 08/15/17 17:42, Tom Rini wrote: > On Tue, Aug 15, 2017 at 04:50:40PM -0700, Frank Rowand wrote: >> 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. >>> >>> Cc: Rob Herring <robh+dt@xxxxxxxxxx> >>> Cc: Frank Rowand <frowand.list@xxxxxxxxx> >>> Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> >>> Cc: Michal Marek <mmarek@xxxxxxxx> >>> Cc: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >>> Cc: devicetree@xxxxxxxxxxxxxxx >>> Cc: linux-kernel@xxxxxxxxxxxxxxx >>> CC: linux-kbuild@xxxxxxxxxxxxxxx >>> Signed-off-by: Tom Rini <trini@xxxxxxxxxxxx> >>> --- >>> In order for a dtb file to be useful with all types of overlays, it >>> needs to be generated with the -@ flag passed to dtc so that __symbols__ >>> are generated. This however is not free, and increases the resulting >>> dtb file by up to approximately 50% today. In the current worst case >>> this is moving from 88KiB to 133KiB. In talking with Frank about this, >>> he outlined 3 possible ways (with the 4th option of something else >>> entirely). >>> >>> 1. Make passing -@ to dtc be dependent upon some CONFIG symbol. >>> 2. In the kernel, if the kernel does not have overlay support, discard >>> the __symbols__ information that we've been passed. >>> 3. Have the bootloader pass in, or not, __symbols__ information. >> >> I also was hoping that other people might have ideas for additional >> approaches. > > Yes, please. > >>> This patch is an attempt to implement something between the 3rd option >>> and a different, 4th option. Frank was thinking that we might introduce >>> a new symbol to control generation of __symbol__ information for option >>> 1. I think this gets the usage backwards and will lead to confusion >>> among users and developers. >>> >>> My proposal is that we do not want __symbols__ existence to be dependent >>> on some part of the kernel configuration for a number of reasons. >>> First, this is out of step with the rest of how dtbs are created today >>> and more importantly, thought about. Today, all dtb content is >>> independent of CONFIG options. If you build a dtb from a given kernel >>> tree, everyone will agree on the result. This is part of the "contract" >>> on passing old kernels and new dtb files even. >> >> I hope that dtb contents are independent of CONFIG options, but I don't >> feel confident is stating that there is not such dependency. (Of course, >> whether to build a dtb can be dependent on a CONFIG option in the Makefile, >> but that is not the same concept.) >> >> The only existing rule that I am aware of that helps avoid a dts dependency >> on kernel CONFIG options is that included files can not be from general kernel >> header files; they must be in include/dt-bindings/. > > I'm fairly certain for in-kernel stuff at least, the assumption is > correct. > >> Should we add text to Documentation/devicetree/bindings/submitting-patches.txt >> that explicitly states that dts files are not allowed to contain any >> dependency on kernel CONFIG options? > > Certainly can't hurt. > >>> Second, I think this is out of step with how a lot of overlay usage will >>> occur. My thinking is that with maximally useful overlays being >>> available in mainline, lots of use-cases that we have today that result >>> in a number of DTS files being included can become just overlays. This >> >> I disagree with this. My _opinion_ is that overlays should be the exception, >> not the common case. Overlays require extra complexity in the various >> subsystems that interact with device trees. For an overlay to work, these >> subsystems must be able to react to changes made to the device tree by >> an overlay. The current mechanism is via notifiers, which only exist >> for a few subsystems. > > Ah. Now, I can't blame you for thinking with your kernel hat on, but, > you're thinking with your kernel hat on :) (And taking mine off for a > minute is why I changed my mind between when we talked on IRC, and what > I posted). Kernel run-time apply an overlay has various use cases that > I don't want to discount, but don't want to try and go in detail on > either. > > At heart, one of the issues here is that the Linux kernel is the > authoritative source of dts and dtb files. Assembling a dtb and N > overlays at some point prior to booting Linux, in order to give it a > complete and valid system is going to be a common case. Even setting Yes. When discussing overlay issues and technologies we should be very clear about whether the context is post-boot run time loading of an overlay or using overlays applied on top of a base dtb to create a dtb to be fed to the kernel for booting. These are very different domains. For the case of constructing a boot time dtb from a base dtb and one or more overlays my primary concerns are related to the complexity (and again fragility) of the approach. It is already quite difficult to read source dts files and dts include files and determine what the final dtb will contain. This has been the motivation for several of my debugging tools. Adding overlays to the mix will increase the complexity of understanding the final product (dtb), where the individual items originated, and what component to modify to result in a change to the final product. It will add the further challenge that applying overlays in different orders may result in different final dtbs (depending on how strict the rules for applying an overlay are). I agree that this technology has some valuable upsides and use cases, but I also fear the negative impacts. The trick lies in finding a way to meet the technology needs in a manner that successfully balances the costs and the benefits. I mentioned my concerns about the robustness of overlays applied to a running Linux system in another reply. It seems to me that applying overlays pre-boot is more robust as far as the driver and subsystem initialization is concerned, because the normal boot path will be used to process the resulting dtb instead of using an overlay loading path in the kernel. > aside all of the hobbyist board families out there, SoMs are a big > thing. Eval modules are a big thing. This turns not just enabling > these as a vendor but using them as a developer into a much less error > prone system. If I understand the eval modules concept, then using overlays to develop and test device tree changes is somewhat analogous to using kernel modules to develop and test drivers. Yes, this may make some device tree source development more efficient. And in other cases may actually make it less efficient. I don't see the impact as being very large one direction or the other. > To try and re-state my rational, if the Linux kernel needs some > safe-guards or other mechanisms to restrict what can be done on top of > OF_OVERLAY (which is not widely enabled in mainline), OK, that's > certainly a discussion to have and think about implications of. But, > the Linux kernel is the producer of most dtbs that will be consumed by a > variety of platforms. I feel it needs to generate the dtb that can be > used for all consumers, since it is the source of these resources. This has gone far off topic from the original issue you brought up, which is how, in the context of the Linux kernel build environment, to enable building a base dtb that contains the symbols that are needed to load an overlay. Can we return to the base topic? And if anyone wants to discuss the other issues start a new thread? -- 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
