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

[Simon Glass]

On 10 July 2017 at 02:26, Peter Robinson <pbrobinson at gmail.com> wrote:
> On Mon, Jul 10, 2017 at 4:31 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Tom,
>>
>> On 9 July 2017 at 16:36, Tom Rini <trini at 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 at 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 at 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 at gmail.com> wrote:
>>>> >> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson at 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/