On Tue, Apr 18, 2017 at 10:48:07AM -0600, Simon Glass wrote: > Hi Tom, > > On 18 April 2017 at 10:33, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Apr 18, 2017 at 10:27:37AM -0600, Simon Glass wrote: > >> Hi Tom, > >> > >> On 18 April 2017 at 10:25, Tom Rini <tr...@konsulko.com> wrote: > >> > > >> > On Sun, Apr 16, 2017 at 08:22:14PM -0600, Simon Glass wrote: > >> > > >> > > Python libfdt bindings have recently been accepted upstream. While the > >> > > internals have changed a fair bit most of the API remains the same. > >> > > Still, > >> > > a few functions are different from how they are used in U-Boot so > >> > > changes > >> > > are needed to make this work. > >> > > > >> > > At present in U-Boot there are two libraries for accessing a device > >> > > tree > >> > > file: > >> > > > >> > > - FdtNormal which uses U-Boot's own Python bindings > >> > > - FdtFallback which uses the fdtget command-line utility > >> > > > >> > > The latter is not a great solution: it is fairly slow since the DT is > >> > > re-read for every access and it cannot provide DT offsets or packing of > >> > > the DT. > >> > > > >> > > In addition, U-Boot now builds the libfdt module if swig is available, > >> > > meaning that the fallback module is not used in that case. > >> > > > >> > > Finally, at some point in the future distributions may start packaging > >> > > the > >> > > libfdt Python module and it will be available without U-Boot needing to > >> > > build it itself. > >> > > > >> > > Therefore it seems like a good idea to take this opportunity to drop > >> > > the > >> > > fallback module and just require that the Python libfdt bindings be > >> > > present (at least if need by the build). > >> > > > >> > > The bindings are needed in two situations: > >> > > - When dtoc is used to convert a device tree into C code. This is > >> > > enabled > >> > > by CONFIG_SPL_OF_PLATDATA > >> > > - When binman is used to produce a firmware image. This is used on all > >> > > x86 > >> > > and sunxi boards at present > >> > > > >> > > This series: > >> > > - Plumbs in building the Python libfdt module to the U-Boot build > >> > > system > >> > > - Ensures that the module is always built if needed, print an error if > >> > > swig is not available (and thus the module cannot be built) > >> > > - Allows use of a libfdt.py module already installed on the machine > >> > > - Drops the FdtFallback support > >> > > - Moves fdt.h and libfdt.h into lib/libfdt to aid with syncing with > >> > > upstream, building the Python bindings and to keep the code > >> > > together > >> > > - Merges Fdt and FdtNormal to simplify the code > >> > > - Adjusts the Fdt library to work with the new libfdt module > >> > > - Adds a few more tests to check access to properties in the DT > >> > > - Adjusts binman and dtoc to work with the new approach > >> > > > >> > > It should be possible to easily sync libfdt's Python bindings with > >> > > U-Boot > >> > > in the future, as development there proceeds. > >> > > >> > While this came in late, my gut feeling is that it would be best to have > >> > this change in the next release (so that various upstreams can get used > >> > to the idea of basically always needing python installed to build). > >> > >> I'm a little worried that it might cause problems. I made it so that > >> it only *requires* python if is it actually needed, though it always > >> builds libfdt.py if it can. Or perhaps that is what you are saying, > >> that the only way to flush out upstream issues is to apply it? > > > > What I'm saying is that distros (Fedora, openSUSE, OpenEmbedded) are > > going to make a blanket change (if they haven't already) to say that > > building U-Boot requires python to be installed (since they aren't > > likely to try and optimize it on a board-by-board basis when it's "easy" > > to just say it's an always dependency). If you think there's risk with > > the change itself, we can wait a release, that's fine too. Thanks! > > I see. I'm not sure what is best. I checked for build errors and added > some more tests so I'm fairly confident. But it is late (sorry, it was > more work than I expected). I'll leave this up to you.
Alright, lets just have this queued up for early next window. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot