From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Sat, 8 Jul 2017 08:21:40 -0400 Subject: [U-Boot] [ANN] U-Boot v2017.07-rc2 released In-Reply-To: References: <20170620004736.GB10782@bill-the-cat> <20170620111947.GE10782@bill-the-cat> Message-ID: <20170708122140.GT22707@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote: > On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson wrote: > >> On 21 June 2017 at 01:07, Peter Robinson 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: