On 10 July 2017 at 02:26, Peter Robinson <pbrobin...@gmail.com> wrote: > On Mon, Jul 10, 2017 at 4:31 AM, Simon Glass <s...@chromium.org> wrote: >> Hi Tom, >> >> On 9 July 2017 at 16:36, Tom Rini <tr...@konsulko.com> wrote: >>> On Sun, Jul 09, 2017 at 12:38:19PM -0600, Simon Glass wrote: >>>> Hi, >>>> >>>> On 9 July 2017 at 06:49, Tom Rini <tr...@konsulko.com> wrote: >>>> > On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote: >>>> >> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <tr...@konsulko.com> wrote: >>>> >> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote: >>>> >> >> 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? >>>> >> > >>>> >> > Can we short term do the thing where I guess it was PYTHONPATH gets >>>> >> > modified so that you only pick up U-Boot provided parts here? >>>> >> >>>> >> Sure, as long as we have a commitment to a read fix for 2017.09 >>>> > >>>> > The "real" fix is to get upstream libfdt stuff in sync with us again, >>>> > yes? If so, yes, I think we can agree that we need to sync up with them >>>> > and get on the same page. >>>> >>>> It would be easy enough to drop the new error. I think that would fix >>>> the current problem. I synced libfdt after the Python library was >>>> applied upstream, so it may be possible to mix and match dtc now. >>>> >>>> Re fdtgrep I did send fdtgrep patches to the list a long time ago but >>>> it did not go anywhere. For v3 there was a long delay and then this >>>> comment: >>>> >>>> https://www.spinics.net/lists/devicetree-compiler/msg00108.html >>>> >>>> I have been meaning to try again with something smaller as I think it >>>> is a useful tool. >>> >>> OK, so I need a patch for the moment then please, thanks! >> >> OK I just sent something that might help. Peter can you please test and >> advise? > > Testing it now.
Just for reference this is: http://patchwork.ozlabs.org/patch/786042/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot