[U-Boot] [PATCH 00/19] fdt: Move to the new upstream pylibfdt library

[Tom Rini <trini@konsulko.com>]

On Tue, Apr 18, 2017 at 10:48:07AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 18 April 2017 at 10:33, Tom Rini <trini@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 <trini@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
-------------- 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/20170419/dc901b4f/attachment.sig>