Hi Tom,
On 9 July 2017 at 16:36, Tom Rini trini@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 trini@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 trini@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 pbrobinson@gmail.com wrote: >> On 21 June 2017 at 01:07, Peter Robinson pbrobinson@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?
Regards, Simon