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

[Simon Glass]

Hi Peter,

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?

Regards,
Simon