>>>> 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. Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
