We've recently added "syntactic sugar" support to generate runtime dtb
overlays using similar syntax to the compile time overlays we've had for
a while. This worked with the &label { ... } syntax, adjusting an existing
labelled node, but would fail with the &{/path} { ... } syntax attempting
to adjust an existing node referenced by its path.
The previous code would always try to use the "target" property in the
output overlay, which needs to be fixed up, and __fixups__ can only encode
symbols, not paths, so the result could never work properly.
This adds support for the &{/path} syntax for overlays, translating it into
the "target-path" encoding in the output. It also changes existing
behaviour a little because we now unconditionally one fragment for each
overlay section in the source. Previously we would only create a fragment
if we couldn't locally resolve the node referenced. We need this for
path references, because the path is supposed to be referencing something
in the (not yet known) base tree, rather than the overlay tree we are
working with now. In particular one useful case for path based overlays
is using &{/} - but the constructed overlay tree will always have a root
node, meaning that without the change that would attempt to resolve the
fragment locally, which is not what we want.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
So far, the tests for generating runtime overlays with dtc weren't checking
the syntactic sugar. This adds such a test.
Furthermore the existing tests were only minimally testing dtc's output
for the overlay. This adds a test comparing the dtc output with the
more or less manually constructed overlays we already have for testing
libfdt's overlay application code. This does require some minor changes
to that manually constructed overlay which don't change the sematics but
re-order / rename things to match the way dtc does it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some platforms (many, if not all, of the *BSD projects) do not provide a libdl,
and instead provide the same functionality in libc. Instead of forcing these
platforms to patch out the link against libdl, add a LIBDL make(1) variable to
allow the -ldl argument to be excluded easily via make(1) arguments.
Signed-off-by: Kyle Evans <kevans@FreeBSD.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
GNU stat(1) uses '-c "%s"' as the proper invocation to print filesize of the
file in question, while BSD stat(1) uses '-f "%Uz"'. Do some trivial
autodetection to check if we're using GNU stat(1) and assume we're using BSD
stat(1) if we don't detect otherwise.
This should allow the test suite to run properly out-of-the-box on *BSDs and
MacOS in addition to the current Linux support.
Signed-off-by: Kyle Evans <kevans@FreeBSD.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
stat -c %s's equivalent on FreeBSD is stat -f %Uz; these differ enough, allow
STATSZ in the environment to specify local replacement for a stat that outputs
size in bytes of an argument.
Signed-off-by: Kyle Evans <kevans@FreeBSD.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add some checks for /chosen node. These check that chosen is located at
the root level and that bootargs and stdout-path properties are strings.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a string list check for common properties ending in "-names" such as
reg-names or interrupt-names.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a check for string list properties with compatible being the first
check.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a string property check for 'label' property. 'label' is a human
readable string typically used to identify connectors or ports on devices.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This adds some simple tests for the checks of correctly formatted PCI
bridge nodes. Doesn't test all that much, but it's a start.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The current tests for fdt_node_check_compatible() test that it returns true
on several matching cases, but don't test that it actually returns false on
some non-matching cases, which isn't great coverage. Add some basic tests
to address that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In a number of places, dtc and associated tools and test code use
leading _ characters on identifiers to flag them as "internal", an
idiom taken from the Linux kernel. This is a bad idea in a userspace
program, because identifiers with a leading _ are reserved for the C
library / system.
In some cases, the extra _ served no real purpose, so simply drop it. In
others move to the end of the identifier, which is a convention we're free
to use for our own purposes.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A comment in tests/stringlist.c refers to fdt_get_string(), which is not a
function that exists. From the content, it's supposed to be referring to
fdt_getprop_string().
A comment in libfdt.h has an extraneous space in a function name.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At least some clang versions (correctly) warn that 'size' is used
unititialized, if sw_tree1 is invoked with argc > 2. This corrects the
warning.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For testing we (ab)use the assembler to build us a sample dtb, independent
of the other tools (dtc and libfdt) that we're trying to test. In a few
places this uses 64-bit arithmetic to decompose 64-bit constants into
the individual bytes in the blob.
Unfortunately, it seems that some builds of GNU as don't support >32 bit
arithmetic, though it's not entirely clear to me which do and which don't
(Fedora i386 does support 64-bit, Debian arm32 doesn't).
Anyway, to be safe, this avoids 64-bit arithmetic in assembler at the cost
of some extra awkwardness because we have to define the values in 32-bit
halves.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a single test makeing sure the &foo { }; syntax works.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
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>
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>
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>
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 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>
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>
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>
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>
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 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>
Node name unit-addresses should generally never begin with 0x or leading
0s. Add warnings to check for these cases, but only for nodes without a
known bus type as there should be better bus specific checks of the
unit address in those cases. Any unit addresses that don't follow the
general rule will need to add a new bus type. There aren't any known
ones ATM.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This bug has been found by using clang Static Analyzer: it reported that
the value stored to fdt was never read.
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This fixes a great many sparse warnings on the fdt and libfdt sources.
These are mostly due to incorrect mixing of endian annotated and native
integer types.
This includes fixing a couple of quasi-bugs where we had endian conversions
the wrong way around (this will have the right effect in practice, but is
certainly conceptually incorrect).
This doesn't make the whole tree sparse clean: there are many warnings in
bison and lex generated code, and there are a handful of other remaining
warnings that are (for now) more trouble than they're worth to fix (and
are not genuine bugs).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Device trees can contain empty (zero length) properties, which are often
used as boolean flags. These can already be created using fdt_setprop()
passing a length of zero and a pointer which is ignored. It is safe to
pass NULL, but that may not be obvious from the interface. To make it
clearer, add an fdt_setprop_empty() helper macro.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If we have a construct like this:
label: &handle {
...
};
Running dtc on it will cause a segfault, because we use 'target'
when it could be NULL. Move the add_label() call into the if
statement to fix this potentially bad use of a NULL pointer.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At the moment we generate a __symbols__ node if -@ is specified OR if the
dts has the /plugin/ tag. That difference in behaviour from handling base
trees is unnecessary and slightly confusing. It also means it's impossible
to create a plugin without symbols. Since symbols in a plugin are only
useful in the case of stacked plugins - and libfdt doesn't even support
merging plugin symbols as part of overlay application yet - that's a thing
that might be useful.
So make __symbols__ generation depend only on -@. We also remove remove
the testcases that checked explicitly for this not very useful behaviour.
Instead we don't use -@ for our basic overlay testcase, and check that
symbols are not generated.
At some point in the future we should add support for symbol merging to
libfdt and add testcases for stacked overlay application.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Using -@ again here obscures what's going on, because at the end we can't
know which run actually generated the symbols node. We should just
generate the symbols on the first run and leave it at that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
I think these were for an additional command line option which got dropped
during development. At this point all they're testing is that fixups don't
get generated for a non /plugin/ tree, which is already tested with one of
the simpler cases previously.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This changes the names of the testfiles for a number of the testcases of
the dtc overlay generation functionality to make them shorter and a bit
cleaerer what's going on. In addition we move some of the check_path
sanity checks closer to the dtc commands they verify.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At the moment we have some rudimentary tests of the fdt_overlay_apply()
function which don't rely on overlay generation support in dtc. This is
done by avoiding any external references in the sample overlay, in
particularly using the 'target-path' syntax instead of 'target' to avoid
needing external references in the fragment targets. Thus this test case
doesn't exercise libfdt's processing of the __fixups__ node at all.
We do test that somewhat in combination with dtc's overlay support.
However, in the interests of being able to quickly determine which side a
bug is on, it would be nice to exercise this without requiring the dtc
support.
This adds testcases to do so, by making some examples with manually
constructed __symbols__ and __fixups__ nodes. In addition we rename some
of the test data files and add some extra check_path tests to make it a bit
clearer what's going on here.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Two test programs - check_path and overlay - define a CHECK() helper macro
in such a way that in the case of an error it will re-execute the checked
code fragment, instead of using the return value from the initial call.
This can lead to misreporting errors, because the code may fail in a
different way the second time around due to changes made during the first
failing call.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The various tests for overlay/plugin support are currently lumped together
in the overlay_tests shell function, which is executed by libfdt_tests.
However, this includes both tests designed primarily to exercise libfdt's
overlay application, and tests designed to exercise dtc's overlay
generation. Split these up for improved clarity.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The current testcases for the -A "auto alias generation" option operate on
a "plugin" tree. Although not technically wrong, this is an odd approach,
since a plugin will almost certainly need the __symbols__ and/or __fixups__
syntax instead of aliases. On the other hand -A may be useful simply for
generating aliases on a tree which is not using the overlay / plugin
mechanism at all.
Therefore change the tests to operate on a base tree example instead of a
plugin.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When overlay apply supprt was added to libfdt the testcases included some
which could only be executed with the (then) out of tree dtc with overlay
output support. So, the test script automatically skipped those tests if
it wasn't available.
Now that the overlay support is merged into dtc mainline there's no reason
to keep this logic. Instead run all the overlay tests unconditionally.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a number of tests for dynamic objects/overlays.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
David Gibson