On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobin...@gmail.com> wrote: >> On 21 June 2017 at 01:07, Peter Robinson <pbrobin...@gmail.com> wrote: >>>>>>> Simon, do you have some suggestions on what to do here? Thanks! >>>>>>> >>>>>>> -- >>>>>>> Tom >>>>>> >>>>>> My guess is that there is already a libfdt.py in the system. Someone >>>>>> else reported this too. >>>>>> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is >>>>>> first. >>>>> >>>>> No, I'm not sure that's completely the case because I first saw a >>>>> related issue before my dtc had the python patch set added to it, I >>>>> would actually prefer to build with the distro dtc rather than a fork >>>>> of upstream like we use to. >>>> >>>> OK I think I see what is happening then. It seems to be picking up >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that >>>> seems like a bad idea at the best of times. >>>> >>>> Despite upstreaming efforts we still have local libfdt changes in >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back >>>> but failed. I've been thinking of trying again but have not mustered >>>> the energy. >>>> >>>> This particular error could probably be worked around in the short >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this >>>> sort of thing? I think we should either use one libfdt module or the >>>> other, not a mixture of the two >>> >>> I suspect your right but I don't want to get into a situation where >>> something might work in the kernel and and not in u-boot or >>> vice-versa, and as things like overlays come into play where they >>> could be applied to either the possible differences get greater and >>> from a distro PoV that increased the requirements of support and debug >>> and believe me people will do weird shit that they expect you to >>> magically fix with little information hence my reluctance to diverge. >> >> I'm not sure what to do about this other than what I suggested. I >> wonder it if is possible to detect the case where there is a mismatch >> with the installation? > > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on > this, what does it do? Maybe provide an option to specify whether to > use external dtc or bundled?
So dropping dtc from our deps to try and get anything on 2017.07 built I get for a bunch of devices I get this: /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line 18: dtc: command not found rm -f .tmp_quiet_recordmcount *** Your dtc is too old, please upgrade to dtc 1.4 or newer Can we please have some level of resolution for 2017.07 GA? Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot