On 11/09/17 09:09, Alexander.Steffen@xxxxxxxxxxxx wrote: >> On 10/20/17 05:11, Alexander.Steffen@xxxxxxxxxxxx wrote: >>>> Hi Alexander, >>>> >>>> On 10/19/17 10:06, Alexander.Steffen@xxxxxxxxxxxx wrote: >>>>> Hi Frank, Rob, >>>>> >>>>> I ran some tests with kernel v4.14-rc2, where I came across an issue >>>>> with your commit "of: overlay: add overlay symbols to live device >>>>> tree" (d1651b03c2df75db8eda3fbcd3a07adb337ee8b0, >>>>> >>>> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/d >>>> rivers/of?h=v4.14- >> rc5&id=d1651b03c2df75db8eda3fbcd3a07adb337ee8b0). >>>>> I am not sure whether this is a problem with your change or whether I >>>>> made a mistake somewhere. >>>>> >>>>> Without this commit, the following device tree overlay works fine on >>>>> a Raspberry Pi: >>>>> >>>>> /dts-v1/; >>>>> /plugin/; >>>>> >>>>> / { >>>>> fragment@0 { >>>>> target-path = "/soc/spi@7e204000"; >>>>> __overlay__ { >>>>> #address-cells = <1>; >>>>> #size-cells = <0>; >>>>> status = "okay"; >>>>> >>>>> spidev1: spi@1 { >>>>> compatible = "spidev"; >>>>> reg = <1>; >>>>> spi-max-frequency = <5000000>; >>>>> }; >>>>> }; >>>>> }; >>>>> }; >>>>> >>>>> But with the commit, it is rejected: >>>>> >>>>> OF: overlay: no symbols in root of device tree. >>>>> OF: overlay: of_build_overlay_info() failed for tree@/ >>>>> create_overlay: Failed to create overlay (err=-22) >>>>> >>>>> Only if I remove the spidev1 label, it continues to work with the >>>>> commit (but this is not always possible in more complex overlays). >>>>> >>>>> I hope this does not make a difference, but I use the configfs >>>>> interface to load the overlay, that is not part of mainline, but >>>>> shipped by several distributions nonetheless (for example in the >>>>> Raspberry Pi kernel, >>>>> >>>> >> https://github.com/raspberrypi/linux/commit/cccc24635da69799335566eb46 >>>> 4a4c9e1fb4a8ad). >>>>> >>>>> >>>>> Could you tell me whether this change in behavior is intentional and >>>>> whether I have to fix something in my usage? >>>> >>>> Yes, the change is intentional. >>>> >>>> If you are using overlays, the expectation is that the device tree >>>> that was used to boot contains symbols (the paths of nodes that >>>> have phandles) so that phandle references in the overlay can be >>>> fixed up to match the values in the base devicetree. Symbols >>>> will be added to the device tree if if is compiled with the >>>> "@" option. This is the first method to avoid the overlay >>>> load error. >>> >>> Ah, thanks, this does solve the problem. I use nothing special to >>> generate the base devicetree, just "make dtbs". Would it make sense >>> to add the "@" option to the kernel Makefile, so that symbols are >>> added by default? Or does this have any downside? I'd suspect that >> >> Yes, there is a large downside. Compiling with the "@" option will >> increase the size of the DTB. Most boards will not use overlays, >> and in those cases this overhead has no value. So "@" should be >> opt-in, not default. > > I see. Is there a way (a config option maybe?) that I can use to get this behavior without patching the Makefile? To compile a DTB with -@, you can specify the value of DTC_FLAGS on the make command line. For example: DTC_FLAGS="-@" make qcom-apq8074-dragonboard.dtb This will work for arm. For some other architectures, you may want to add additional flags to DTC_FLAGS, and for microblaze this will not work with the current makefile (the arch makefiles should probably be changed to be: DTC_FLAGS += ... or to remove the "-p 1024" if no longer needed): $ git grep DTC_FLAGS | grep Makefile: | grep arch arch/c6x/boot/dts/Makefile:DTC_FLAGS ?= -p 1024 arch/microblaze/boot/dts/Makefile:DTC_FLAGS := -p 1024 arch/openrisc/boot/dts/Makefile:#DTC_FLAGS ?= -p 1024 arch/powerpc/boot/Makefile:DTC_FLAGS ?= -p 1024 >>> many more people will be hit by this change, since most tutorials for >>> overlays that I have seen include the "@" option for the dtc calls.> >>>> If you compile the overlay with the "@" option then symbols >>>> will be added to the overlay DTB. Previous to commit >>>> d1651b03c2df, these symbols would be ignored when an overlay >>>> was loaded. If you remove the "@" from the compile of >>>> overlays, then everything should work the same way it did >>>> before the commit. This is the second way to avoid the >>>> load overlay error. > > Do I understand that correctly, that when I remove the "@" option > from the dtc calls, the same call should work both with an old > (pre-d1651b03c2df) and a new kernel? If the old kernel just ignored > the symbols, they were not used for anything, so it should not matter > whether they were contained in the overlay DTB or not, right? I just mentioned that workaround as another temporary way to work around your specific case. You should probably just forget I even mentioned it. >>>> >>>> >>>>> Thanks >>>>> Alexander >>>>> -- >>>>> 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 >>> >> > > -- 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
