When creating a tree with the sequential write functions, certain things
have to be done in a certain order. You must create the memory reserve map
and only then can you create the actual tree structure.
The -FDT_ERR_BADSTATE return code is for if you try to do things out of
order. However, we weren't checking that very thoroughly, so it was
possible to generate a corrupted blob if, for example, you started calling
fdt_begin_node() etc. before calling fdt_finish_reservemap().
This makes the state checking more thorough disallow that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Simon Glass <sjg@chromium.org>
Many of the libfdt entry points call some sort of sanity check function
before doing anything else. These need to do slightly different things for
the various classes of functions.
The read-only version is shared with the exported fdt_check_header(), which
limits us a bit in how we can improve it. For that reason split the two
functions apart (though the exported one just calls the ro one for now).
We also rename the functions for more consistency - they're all named
fdt_XX_probe_() where the XX indicates which class of functions they're
for. "probe" is a better "term" than the previous check, since they really
only do minimal validation.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The current code throws away all the data type and grouping information
when parsing the DTS source file, which makes it difficult to
reconstruct the data format when emitting a format that can express data
types (ie. dts and yaml). Use the marker structure to mark the beginning
of each integer array block (<> and []), and the datatype contained in
each (8, 16, 32 & 64 bit widths).
Signed-off-by: Grant Likely <grant.likely@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[robh: s/MARKER_/TYPE_/]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
It is annoying to have to add .value when we want the value of a Property.
Make Property a subclass of bytearray so that it can be used directly when
the value is required.
Fix the Property class comment while we are here.
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When calling libfdt functions which are not supported by the Fdt class it
is necessary to get direct access to the device tree data. At present this
requries using the internal _fdt member. Add a new method to provide
public access to this, without allowing the data to be changed.
Note that a bytearray type is returned rather than str, since the swig
types are set up for bytearray to map correctly to const void *.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The newly introduced /omit-if-no-ref/ needs a few test cases, make
sure to test them.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A number of platforms have a need to reduce the number of DT nodes,
mostly because of two similar constraints: the size of the DT blob, and
the time it takes to parse it.
As the DT is used in more and more SoCs, and by more projects, some
constraints start to appear in bootloaders running from SRAM with an
order of magnitude of 10kB. A typical DT is in the same order of
magnitude, so any effort to reduce the blob size is welcome in such an
environment.
Some platforms also want to reach very fast boot time, and the time it
takes to parse a typical DT starts to be noticeable.
Both of these issues can be mitigated by reducing the number of nodes in
the DT. The biggest provider of nodes is usually the pin controller and
its subnodes, usually one for each valid pin configuration in a given
SoC.
Obviously, a single, fixed, set of these nodes will be used by a given
board, so we can introduce a node property that will tell the DT
compiler to drop the nodes when they are not referenced in the tree, and
as such wouldn't be useful in the targetted system.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Having a 'bus-range' property for PCI bridges should not be required,
so remove the warning when missing. There was some confusion with the
Linux kernel printing a message that no property is present and the OS
assigned the bus number. This message was intended to be informational
rather than a warning.
When the firmware doesn't enumerate the PCI bus and leaves it up to the
OS to do, then it is perfectly fine for the OS to assign bus numbers
and bus-range is not necessary.
There are a few cases where bus-range is needed or useful as Arnd
Bergmann summarized:
- Traditionally Linux avoided using multiple PCI domains, but instead
configured separate PCI host bridges to have non-overlapping
bus ranges so we can present them to user space as a single
domain, and run the kernel without CONFIG_PCI_DOMAINS.
Specifying the bus ranges this way would and give stable bus
numbers across boots when the probe order is not fixed.
- On certain ARM64 systems, we must only use the first
128 bus numbers based on the way the IOMMU identifies
the device with truncated bus/dev/fn number. There are probably
others like this, with various limitations.
- To leave some room for hotplugged devices, each slot on
a host bridge can in theory get a range of bus numbers
that are available when assigning bus numbers at boot time
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When refactoring node path printing, the code checking for duplicate
node names was accidentally changed to print the name of the parent
node, instead of the name of the duplicated child node.
Fixes: 88960e3989 ("checks: centralize printing of node path in check_msg")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This test builds a tree in a previously uninitialized buffer, then writes
the whole buffer out to a file to be used by other tests. Because part of
the buffer may be uninitialized this causes a valgrind error.
Pre-initializing the buffer would remove the error, however it would make
valgrind not notice any accesses to the uninitialized portion *before* the
write out, and those would be genuine errors.
So, instead we use a valgrind suppressions file - however it has a couple
of problems. First it unnecessarily lists the same call path twice.
Second, the call path is only right for some C library versions. Change
the second copy to cover possible path that occurs with a different glibc
version.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In the case where fdt_get_path() returns an error, a debug print will
attempt to display a poisoned buffer, running over the end and accessing
uninitialized memory.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add checks for DT graph bindings. These checks check node names,
unit-addresses and link connections on ports, port, and endpoint nodes.
The graph nodes are matched by finding nodes named 'endpoint' or with a
'remote-endpoint' property. We can't match on 'ports' or 'port' nodes
because those names are used for non-graph nodes. While the graph nodes
aren't really buses, using the bus pointer to tag matched nodes is
convenient.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Child nodes with the same unit-address (and different node names) are
either an error or just bad DT design. Typical errors are the unit-address
is just wrong (i.e. doesn't match reg value) or multiple children using the
same overlapping area. Overlapping regions are considered an error in new
bindings, but do exist in some existing trees. This check should flag
most but not all of those errors. Finding all cases would require doing
address translations and creating a full map of address spaces.
Mixing more than one address/number space at a level is bad design. It only
works if both spaces can use the same #address-cells and #size-cells sizes.
It also complicates parsing have a mixture of types of child nodes. The
best practice in this case is adding child container nodes for each
address/number space or using additional address bits/cells to encode
different address spaces.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
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>
Overlay fragments are traditionally named "fragment@NNN" but don't have
have a 'reg' property, amongst other differences from normal nodes. Really
we should treat overlay fragments fundamentally differently, but for the
moment, suppress the common warnings about the fragment names with this
simple hack.
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 failure messages apply to a specific property. Add a FAIL_PROP()
macro for failure messages which are specific to a property. With that,
failure messages can print the property name in a standard way. Once
source line numbers are supported, then the file and line number of the
property can be used instead of the node file and line number.
Convert the existing messages related to properties to use the FAIL_PROP
macro and reword the messages as necessary.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Most error/warning messages print the node path as part of their error
message. Move printing of the node path into check_msg() so the
formatting can be standardized to the form:
<output file>: (ERROR|warning) (<check name>): <full node name>: <check message>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This can be useful in particular in the kernel when booting on systems
with FDT-emitting firmware that is out of date. Releases of kexec-tools
on ppc64 prior to the end of 2014 are notable examples of such.
Signed-off-by: Nathan Whitehorn <nwhitehorn@freebsd.org>
[dwg: Some whitespace cleanups]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Align column number with those reported by gcc. Thus, do not make a tab
count as 8 spaces.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The overlay support has been introduced, but the copyright and license
header was missing. Make sure that this is no longer the case.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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>
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>
alloca entails a complicated header situation when using other platforms, where
some split it out in alloca.h while others include it as a standard part of
stdlib.h.
The cons don't seem to outweigh the pros, so switch it to malloc.
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 checks for aliases node that all properties follow alias naming
convention and the values are a valid path.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a check for unnecessary "#{size,address}-cells" when there's neither
a 'ranges' property nor child nodes with a 'reg' property.
An exception may be an overlay that adds nodes, but this case would need
"#{size,address}-cells" in the overlay to properly compile already.
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>
The property is named "sound-dai", not "sound-dais".
Fixes: b3bbac02d5 ("checks: add phandle with arg property checks")
Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 737b2df3, "overlay: Add syntactic sugar version of overlays"
introduced an empty rule for "devicetree" that created ambiguities in
the grammar and causes the following warning:
BISON dtc-parser.tab.c
dtc-parser.y: warning: 3 shift/reduce conflicts [-Wconflicts-sr]
Fix the grammar by explicitly testing for the condition the
new overlay grammar wants to use. This means duplicating a very small
amount of grammar processing code, but the alternative seems to be a
more invasive reorganization of the devicetree rule. Better to fix it
this way now and save the reorg for a separate patch.
Signed-off-by: Grant Likely <grant.likely@arm.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
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>
Every remaining usage of strneq() is, in fact, incorrect. They're trying
to check that the first n characters of one string exactly match another
string. But, they fall into the classic trap of strncmp() on which
strneq() is based. If n is less than the length of the second string, they
only check that the first string matches the start of the second, not the
whole of it.
To fix this, remove strneq() and replace it with a strprefixeq() function
which does what we want here.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
nodename_from_path() in flattree.c uses strneq() to test that one
string starts with another. This is, in fact, the only correct usage
of strneq() in the entire tree. To make things harder to confuse, add
a strstarts() function for this purpose.
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>
Right now, check_interrupts_property fails with overlays, as the phandle
for the interrupt-parent can be orphan. Avoid this by allowing the orphan
node to pass the assert check.
The process_checks() call is also moved later during init sequence,
so that we can use the global variable generate_fixups to check if
we are compiling an overlay.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[dwg: Shortcut handling of invalid phandles]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Prior the Mac OS 10.7, the function strnlen() was not available. This patch
implements strnlen() on Mac OS X versions that are below 10.7.
Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In a lot of places libfdt uses a leading _ character to mark an identifier
as "internal" (not part of the published libfdt API). This is a bad idea,
because identifiers with a leading _ are generally reserved by the C
library or system. It's particularly dangerous for libfdt, because it's
designed to be able to be integrated into lots of different environments.
In some cases the leading _ has no purpose, so we simply drop it. In most
cases we move it to the end, as our new convention for marking internal
identifiers.
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>
The FDT_VERSION() and _FDT_VERSION() macros don't really have anything
specific to do with the fdt version. Rather, they're the common CPP
"stringify" idiom. Move to util.h and rename to stringify() to
reflect this.
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>
In dts plugins, it is valid to have unresolved phandle values. The
check_property_phandle_args and check_interrupts_property checks failed to
account for this resulting in spurious warnings or asserts, respectively.
Fix this by bailing from the checks if we're checking a dts plugin as
there is no way to further validate the properties.
Fixes: ee3d26f696 ("checks: add interrupts property check")
Fixes: b3bbac02d5 ("checks: add phandle with arg property checks")
Reported-by: Alan Tull <atull@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
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>
