[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini <trini@konsulko.com>]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170708/0203bfc5/attachment.sig>