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>
Add a check for nodes with interrupts property that they have a valid
parent, the parent has #interrupt-cells property, and the size is a
valid multiple of #interrupt-cells.
This may not handle every possible case and doesn't deal with
translation thru interrupt-map properties, but should be enough for
modern dts files.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The GPIO binding is different compared to other phandle plus args
properties in that the property name has a variable, optional prefix.
The format of the property name is [<name>-]gpio{s} where <name> can
be any legal property string. Therefore, custom matching of property
names is needed, but the common check_property_phandle_args() function
can still be used.
It's possible that there are property names matching which are not GPIO
binding specifiers. There's only been one case found in testing which is
"[<vendor>,]nr-gpio{s}". This property has been blacklisted and the same
should be done to any others we find. This check will prevent getting
any more of these, too.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Many common bindings follow the same pattern of client properties
containing a phandle and N arg cells where N is defined in the provider
with a '#<specifier>-cells' property such as:
intc0: interrupt-controller@0 {
#interrupt-cells = <3>;
};
intc1: interrupt-controller@1 {
#interrupt-cells = <2>;
};
node {
interrupts-extended = <&intc0 1 2 3>, <&intc1 4 5>;
};
Add checks for properties following this pattern.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The show_data() function is quite long. Split out the part that loops
through the values. This makes it easier to add new features.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a little note in the README about something which confused me.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add this into the class to simplify use of this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add this into the class to simplify use of this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add this into the class to simplify use of this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add this into the class to simplify use of this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present 'make check' succeeds even if some tests fail. Adjust this so
that we can use things like 'git bisect run make check' to find a failure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some systems may have the Python libfdt.py library installed. Adjust the
tests to prepend the local libfdt path so that we test the local version
instead of the system version.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Using the libfdt function without going through the Python Fdt class
requires use of the uint32_t type. Add a test that this works correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some types used by libfdt.h are not understood the Python module since
they are defined outside it. An example is an attempt to do this:
import libfdt
result = libfdt.fdt_node_offset_by_phandle(fdt, phandle)
This results in:
TypeError: in method 'fdt_node_offset_by_phandle', argument 2 of
type 'uint32_t'
Include the standard integer header file to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a stacked overlay unit test, piggybacking on fdtoverlay.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In some cases you need to add a property but the contents of it
are not known at creation time, merely the extend of it.
This method allows you to create a property of a given size (filled
with garbage) while a pointer to the property data will be provided.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
[dwg: Corrected commit message]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently, both legacy (linux,phandle) and ePAPR (phandle) properties
are inserted into dtbs by default. The newer ePAPR style has been
supported in dtc and Linux kernel for 7 years. That should be a long
enough transition period. We can save a little space by not putting both
into the dtb.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add an fdtoverlay unit test. Applies applies overlay(s) and then
retrieves an inserted property to verify.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
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 -d and -s options were undocumented. Add an entry in the manual.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2a42b14 "dtc: check.c fix compile error" changed a format string using
%lx which wasn't correct for all platforms. Unfortunately it changed it to
%zx, which is wrong for a different set of platforms (and only right on
the others by accident). The parameter we're formatting here is uint64_t,
not size_t, so we need to use the PRIx64 macro from <inttypes.h> to get
this right.
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>
Since 548aea2 "fdtdump: Discourage use of fdtdump", fdtdump unconditionally
prints a message discouraging its own use except for debugging purposes.
This shows up messily in the "make check" output, so suppress it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fix the following compile error found on odroid-xu4:
checks.c: In function ‘check_simple_bus_reg’:
checks.c:876:41: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 4 has type
‘uint64_t{aka long long unsigned int}’ [-Werror=format=]
snprintf(unit_addr, sizeof(unit_addr), "%lx", reg);
^
checks.c:876:41: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 4 has type
‘uint64_t {aka long long unsigned int}’ [-Werror=format=]
cc1: all warnings being treated as errors
Makefile:304: recipe for target 'checks.o' failed
make: *** [checks.o] Error 1
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
[dwg: Correct new format to be correct in general]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When determining if to recurse into a node, get_node_by_path does not
check if the length of each node name is equal. If searching for
/foo/baz, this can result in recursing into /foobar because
strneq("foo", "foobar", 3) is true.
This can result in a reference to /foo/baz to be incorrectly set to
/foobar/baz. A test for this was added.
Signed-off-by: Tim Montague <tmontague@ghs.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
fdtdump is, and always has been, a quick-and-dirty debugging tool. However
I keep getting reports of people using it for real work. For production
decompiling of a dtb, dtc in -I dtb -O dts mode is the right tool. In the
hopes of getting that message out there, add a warning message to fdtdump
to discourage its use.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
It's perfectly valid for a dtb to have version and last compat version set
to the same value, and that value can be 17 (the latest defined version).
However, since 0931cea "dtc: fdtdump: check fdt if not in scanning mode"
fdtdump will refuse to process such a dtb. We get away with this in many
cases because dtc's typical output has last compat version equal to 16,
rather than 17, but it's still a bug.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
These were noticed when synching with U-Boot's downstream tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since we are using the standard .i extension for the swig file, we can use
setup.py to build the wrapper. Drop the existing build code since it is
not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
I've recently signed up dtc for Coverity Scan coverage. This adds magic
to the .travis.yml file to submit builds to Coverity for analysis.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We should follow PEP8 even for our setup() call.
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>
The .i extension allows Python distutils to automatically handle the swig
file. Rename it.
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>
The existing function to add a new property to a tree being built requires
that the entire contents of the new property be passed in. For some
applications it is more convenient to be able to add the property contents
later, perhaps by reading from a file. This avoids double-buffering of the
contents.
Add a new function to support this and adjust the existing fdt_property() to
use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This is in a separate patch since I not sure if GNU make features
are permitted in the Makefile.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use the same version number in the module as with the rest of libfdt. This
can be examined with:
import pkg_resources
print pkg_resources.require('libfdt')[0].version
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>
To make sure the Makefile behaves in both cases, make Travis matrix builds
with and without swig installed.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present we manually move _libfdt.so into the correct place. Provide a
package directory so we can avoid needing to do this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present setup.py adjusts its command line when running, so that the
C flags and file list can be passed as arguments. Pass them in environment
variables instead, so we can avoid this messiness. It also allows us to
support the 'install' command.
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>
There are a few places where libfdt.h cannot be used as is with swig:
- macros like fdt_totalsize() have to be defined as C declarations
- fdt_offset_ptr() and fdt_getprop_namelen() need special treatment due to
a TODO in the wrapper for fdt_getprop(). However they are not useful to
Python so can be removed
Add #ifdefs to work around these problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a note about pylibfdt in the README.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a set of tests to cover the functionality in pylibfdt.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
David Gibson