On Mon, 01 Dec 2014 14:55:48 +0100 , Michal Marek <mmarek@xxxxxxx> wrote: > On 2014-11-28 15:10, Linus Walleij wrote: > > On Wed, Nov 26, 2014 at 3:41 PM, Russell King - ARM Linux > > <linux@xxxxxxxxxxxxxxxx> wrote: > >> On Wed, Nov 26, 2014 at 02:57:42PM +0100, Linus Walleij wrote: > >>> make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >>> KBUILD_OUTPUT=build-u300 u300_defconfig > >>> make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >>> KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y > >>> make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >>> KBUILD_OUTPUT=build-u300 dtbs > >>> make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >>> KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y > >>> > >>> -> Rebuilds everything. > >>> > >>> This doesn't occur before the offending commit. So it only happens > >>> when specifying extra environment variables on the command line. > >> > >> I suspect if you also provide the CONFIG_DEBUG_SECTION_MISMATCH=y on the > >> dtbs line, everything will work properly. > > > > Yay, it works! :) > > > >> The problem is that dtbs line executes a prepare, which I guess rebuilds > >> the bounds stuff. So, the dtbs target results in it being rebuilt without > >> the section mismatch, and then you re-execute a make with it, causing > >> the bounds stuff to be rebuilt again. > > > > Yep. Not very intuitive to require passing section mismatch debug > > flags to DTB rebuilding but whatever, it's not so bad I can't live with > > it. > > Still, the dependency on the 'prepare' target is superfluous, if the > only requirement is that $(KERNELRELEASE) be set properly. So, I've lost track of where things stand on this issue. What is the current proposed fix? Make dtbs depend on 'scripts' and dtbs_install depend on 'prepare scripts'? Or is there a better way to make sure KERNELRELEASE is set for the dtbs_install target? g. -- 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
