Distributions packaging dtc may need to set extra flags. Currently when
they do that it overrides the ones set by the makefile. This is
particularly problematic when compiling without yaml, as the yaml
detection is ignored.
ld: dtc.o: in function `main':
dtc.c:(.text.startup+0x718): undefined reference to `dt_to_yaml'
This patch provides a EXTRA_CFLAGS variable that is added to the list of
CFLAGS, and can be set on the command line when packaging.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20190722030244.9580-1-joel@jms.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A couple of dtc files are missing licenses. Add GPL-2.0-or-later SPDX
tag to them.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20190620211944.9378-7-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently if a file is touched requiring libfdt.so rebuild, it will fail
because the ln -s command will attempt to replace an already existing link
an error. Correct this by using ln -sf.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently the libfdt based tools (fdtput, fdtget, etc.) and all the
test binaries using libfdt are linked against the static version of libfdt.
That's made it very easy in the past to forget to properly update the
version.lds file which is needed to make functions publicaly accessible
from the shared library.
To avoid problems like that in future, alter the build so that we link and
run the tests against the shared library version of libfdt.
That immediately points out several important symbols that are still
missing from the version.lds, so fix those as well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We currently set LDLIBS to include libyaml globally if we're using it.
However only dtc itself actually needs to link with libyaml - the other
tool binaries don't. Avoid that unnecessary inclusion by making LDLIBS
handling per-target.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The usable content of the shared library varies depending on the symbol
versions given in the version.lds linker script, however it's not currently
in the make dependencies. Correct that, and move the libfdt rules together
for consistency while we're at it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Python2 is deprecated upstream, lets try to move forwards. Along with it
generalize the .gitignore file so we ignore the .pyc files in the new
location that Python3 uses.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We've accumulated several new features as well as a number of bugfixes,
so prepare for another release.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The dtc makefiles have support for building into a separate directory from
the sources... except that it's broken and probably always has been.
Remove the pretense.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Move it to the subdir Makefile, generalize some of the patterns, remove
the 'build' directory made by setup.py and __pycache__ directory made by
Python3.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Move it to the libfdt Makefile piece, use neater make syntax, and remove
redundant command (already included in STD_CLEANFILES).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Python 2 is still the default but it can be changed by
setting environment variable PYTHON before build/test.
Signed-off-by: Lumir Balhar <lbalhar@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
YAML encoded DT is useful for validation of DTs using binding schemas.
The YAML encoding is an intermediate format used for validation and
is therefore subject to change as needed. The YAML output is dependent
on DTS input with type information preserved.
Signed-off-by: Grant Likely <grant.likely@arm.com>
[robh: make YAML support optional, build fixes, Travis CI test,
preserve type information in paths and phandles]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some platforms don't have valgrind support, and sometimes you simply might
not want to use valgrind. But at present, dtc, or more specifically its
testsuite, won't compile without valgrind because we use the valgrind
client interface in some places to improve our testing and suppress false
positives.
This adds some Makefile detection to correctly handle the case where
valgrind is not available.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We've accumulated a bunch of bugfixes, including considerable improvements
to libfdt's memory safety, so get ready for another release.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present we have a build check that python-dev and swig are available.
If they are not, we print a message and skip building pylibfdt.
However this check is not currently present with 'make install'. The
install is attempted, and fails. See crbug.com/789189
Split the check out into a separate script and use it twice, once for the
build and once for the install. This corrects the error.
Reported-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For adoption into systems that may have additional arguments to be passed into
install(1) upon install, split out INSTALL into the different types of files to
be installed and use them appropriately. This allows, for instance, passing -s
to strip binaries and libs while not botching directory installs or data/script
installations.
Signed-off-by: Kyle Evans <kevans@FreeBSD.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Preparing for another release. No particular trigger for this, just a
number of accumulated enhancements since v1.4.4.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The pylibfdt code is written for Python2, not Python3. So, it's safer to
explicitly request Python2 in our scripts and when checking pkg-config.
On Arch Linux at least, there isn't actually a plain "python" link, just
"python2" and "python3", so the current setup won't work at all.
According to https://www.python.org/dev/peps/pep-0394/ using "python2"
should work, and is preferred.
Updating pylibfdt to work with Python3 would be nice, but is a problem for
another day.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since libfdt support overlay application on FDT blobs, provide
a command line tool that applies an arbitrary number of
overlays, one after another to a base fdt blob and output
the result in the given file.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The host compiler on MSYS2 and Cygwin does not allow the -fPIC option,
issuing a warning that is treated as an error and stops the build.
Detect whether we're running under MSYS2 or Cygwin and avoid adding
-fPIC to prevent the error from happening.
Tested on Linux, MSYS2 and Cygwin.
Signed-off-by: Carles Cufi <carles.cufi@gmail.com>
[dwg: Added explicit empty CFLAGS for clarity]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
- Allow overriding of shared library compile time flags for platforms whic
need it
- Include -fPIC in the link flags variable instead of including it raw
in the target rule
- Cosmetic formatting tweaks
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The current mechanism uses a shell construct, but it seems better to use
a Makefile approach.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present we require that setup.py is executed from the Makefile, which
sets up various important things like the list of files to build and the
version number.
However many installation systems expect to be able to change to the
directory containing setup.py and run it. This allows them to support (for
example) building/installing for multiple Python versions, varying
installation paths, particular C flags, etc.
The problem in implementing this is that we don't want to duplicate the
information in the Makefile. A common solution (so I am told) is to parse
the Makefile to obtain the required information.
Update the setup.py script to read a few Makefiles when it does not see
the required information in its environment. This allows installation
using:
./pylibfdt/setup.py install
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Adjust the setup script to support installation, and call it from the
Makefile if enabled. It will be disabled if we were unable to build the
module (e.g. due to swig being missing), or the NO_PYTHON environment
variable is set.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some build systems want to build python libraries separately from the
rest of the build.
Add a NO_PYTHON option to enable this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some build systems have their own version of the pkg-config tool.
Use a variable for this instead of hard-coding it, to allow for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If swig and the Python are available, build pylibfdt automatically.
Adjust the tests to run Python tests too in this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
[dwg: Make error message clearer that missing swig or python-dev isn't
fatal to the whole build]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add Python bindings for a bare-bones set of libfdt functions. These allow
navigating the tree and reading node names and properties.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
It's useful to have some tags to jump around sources. We don't
include test sources in the toplevel Makefile because they
probably aren't useful to main program development.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This has some fixes to the make dist target, and a new make kup target for
maintainer convenience uploading new releases.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The "-Werror" compiler flag is currently declared twice in the
Makefile, one time in WARNINGS, and one time in CFLAGS. Let's
remove one of them.
Signed-off-by: Thomas Huth <thuth@redhat.com>
[Moved remaining -Werror from WARNINGS to CFLAGS --dwg]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This patch adds scripts/kup-dtc which builds a tarball from a specified git
tag, signs it and uploads to kernel.org with kup. This is useful only for
dtc maintainers.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We can test fdtdump by comparing its output with the source file that was
compiled by dtc. Add a simple test that should at least catch regressions
in basic functionality.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
make dist can be used to produce tarballs directly from the git
repository, which can be useful to automate the release process as well
as shipping custom releases.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that all -Wshadow build warnings/errors are fixed, turn on -Wshadow
by default to make sure we would catch new potential shadow warnings.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Currently `make install` will install the binaries, libraries and
includes.
This change separates the install target into install-bin, install-lib
and install-includes, so we have more flexibility, particularly when
we're just using libfdt.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This simple utility allows writing of values into a device tree from the
command line. It aimes to be the opposite of fdtget.
What is it for:
- Updating fdt values when a binary blob already exists
(even though source may be available it might be easier to use this
utility rather than sed, etc.)
- Writing machine-specific fdt values within a build system
To use it, specify the fdt binary file on command line followed by the node
and property to set. Then, provide a list of values to put into that
property. Often there will be just one, but fdtput also supports arrays and
string lists.
fdtput does not try to guess the type of the property based on looking at
the arguments. Instead it always assumes that an integer is provided. To
indicate that you want to write a string, use -ts. You can also provide
hex values with -tx.
The command line arguments are joined together into a single value. For
strings, a nul terminator is placed between each string when it is packed
into the property. To avoid this, pass the string as a single argument.
Usage:
fdtput <options> <dt file> <<node> <property> [<value>...]
Options:
-t <type> Type of data
-v Verbose: display each value decoded from command line
-h Print this help
<type> s=string, i=int, u=unsigned, x=hex
Optional modifier prefix:
hh or b=byte, h=2 byte, l=4 byte (default)
To read from stdin and write to stdout, use - as the file. So you can do:
cat somefile.dtb | fdtput -ts - /node prop "My string value" > newfile.dtb
This commit also adds basic tests to verify the major features.
Signed-off-by: Simon Glass <sjg@chromium.org>
This simply utility makes it easy for scripts to read values from the device
tree. It is written in C and uses the same libfdt as the rest of the dtc
package.
What is it for:
- Reading fdt values from scripts
- Extracting fdt information within build systems
- Looking at particular values without having to dump the entire tree
To use it, specify the fdt binary file on command line followed by a list of
node, property pairs. The utility then looks up each node, finds the property
and displays the value.
Each value is printed on a new line.
fdtget tries to guess the type of each property based on its contents. This
is not always reliable, so you can use the -t option to force fdtget to decode
the value as a string, or byte, etc.
To read from stdin, use - as the file.
Usage:
fdtget <options> <dt file> [<node> <property>]...
Options:
-t <type> Type of data
-h Print this help
<type> s=string, i=int, u=unsigned, x=hex
Optional modifier prefix:
hh or b=byte, h=2 byte, l=4 byte (default)
Signed-off-by: Simon Glass <sjg@chromium.org>
The freetype package already installs a binary named "ftdump", so the dtc
package conflicts with that. So rename the newer dtc tool to "fdtdump".
This even makes a bit more sense:
ftdump: [F]lat device [T]ree [dump]
fdtdump: [F]lat [D]evice [T]ree [dump]
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This adds higher-level libfdt operations for reading/writing an fdt
blob from/to a file, as well as a function to decode a data type string
as will be used by fdtget, fdtput.
This also adds a few tests for the simple type argument supported by
utilfdt_decode_type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
We want to avoid a separate Makefile include for each utility, so this sets
up a general one for utilities.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Simon Glass <sjg@chromium.org>
Joel Stanley