Generalize the existing 'ranges' check to also work for 'dma-ranges'
which has the same parsing requirements.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20200303193931.1653-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This error indicates a logic bug in the code calling libfdt, so VALID_DTB
is not really the right check. Update it to use VALID_INPUT instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-4-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If libfdt returns -FDT_ERR_INTERNAL that generally indicates a bug in the
library. Add a new assumption for these cases since it should be save to
disable these checks regardless of the input.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-3-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a little more detail in a few of these comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-2-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fix 'saftey' and 'additional' typos noticed in the assumption series.
Reword the ASSUME_NO_ROLLBACK slightly to improve clarity.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-1-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This function is used to perform a full check of the device tree. Allow
it to be excluded if all assumptions are enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-9-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a way to remove this check and the reordering code, which is
unnecessary if the dtb is known to be correctly ordered.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-8-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allow enabling FDT_ASSUME_LATEST to disable version checks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-7-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allow enabling FDT_ASSUME_NO_ROLLBACK to disable rolling back after a
failed operation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-6-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allow enabling ASSUME_VALID_INPUT to disable sanity checks on the device
tree and the parameters to libfdt. This assumption covers that cases where
the problem could be with either.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-5-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Support ASSUME_VALID_DTB to disable some sanity checks
If we assume that the DTB itself is valid then we can skip some checks and
save code space. Add various conditions to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-4-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a new ASSUME_MASK option, which allows for some control over the
checks used in libfdt. With all assumptions enabled, libfdt assumes that
the input data and parameters are all correct and that internal errors
cannot happen.
By default no assumptions are made and all checks are enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-3-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There does not seem to be a strong reason to inline this function. Also
we are about to add some extra code to it which will increase its size.
Move it into fdt.c and use a simple declaration in libfdt.h
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-2-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This reverts commit 18d7b2f4ee.
This doesn't work for properties such as 'interrupt-map' that has
phandle in the middle of an entry. It would also not work for a 0 or -1
phandle value that acts as a NULL.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20200124144657.29749-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
gcc 10 will default to -fno-common, which causes this error at link
time:
(.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here
This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern",
however that leads to:
dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
26 | extern YYLTYPE yylloc;
| ^~~~~~
In file included from dtc-lexer.l:24:
dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
127 | extern YYLTYPE yylloc;
| ^~~~~~
cc1: all warnings being treated as errors
which means the declaration is completely redundant and can just be
dropped.
Signed-off-by: Dirk Mueller <dmueller@suse.com>
Message-Id: <20200114175341.2994-1-dmueller@suse.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since -D sets preprocessor directives, it applies for the preprocessor not
just the C compiler proper and so belongs in CPPFLAGS rather than CFLAGS.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When Valgrind is not available NO_VALGRIND is set in CFLAGS, and this
is needed during dependency generation as well as compilation.
Message-Id: <20191210163033.9888-1-emaste@freefall.freebsd.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Travis recently added the possibility to compile on aarch64, ppc64le
and s390x hosts, so let's add this possibility to the dtc CI, too.
Unfortunately, there are some weird valgrind errors when running
on ppc64le (which rather look like a problem on the valgrind side to
me, and not in dtc), so we can not use "checkm" on ppc64le yet.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20191203122020.14442-1-thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Right now this is just a build test for FreeBSD, along with a Linux build
and "make check." A later change will add "gmake check" for FreeBSD.
Signed-off-by: Ed Maste <emaste@freebsd.org>
Message-Id: <20191120211133.69281-1-emaste@freefall.freebsd.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Clang does not support gnu_printf, so just use printf when using it to
compile.
Signed-off-by: Ed Maste <emaste@freebsd.org>
Message-Id: <20191120210422.61327-1-emaste@freefall.freebsd.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
By default FreeBSD does not have 'gcc' in the PATH (on common platforms).
As on Linux 'cc' is available as a link to the default compiler (Clang or
GCC), so just use 'cc'.
Signed-off-by: Ed Maste <emaste@freebsd.org>
Message-Id: <20191115155108.39488-1-emaste@freefall.freebsd.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If there is trailing zero, fdtget adds extra chacarter to the
property value. Thus comparing the expected with the actual
value, an error is emitted.
Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
Message-Id: <20191111080444.9819-3-stefan@olimex.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The overlay path ends with trailing zero. When adding this path
as property value, this character should be removed. This is the case
when the overlay adds a node with an alias.
Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
Message-Id: <20191111080444.9819-2-stefan@olimex.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Python recently deprecated some test methods in favour of others. Adjust
the code to avoid warnings.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20191113012410.62550-1-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
BSD sed requires that an extension is provided to the -i (in-place edit)
flag, which may immediately follow the -i or may be separated by a space -
sed -i .bak and sed -i.bak are equivalent. The extension is optional with
GNU sed, but if provided must immediately follow the -i. Thus, sed -i.bak
behaves identically with both GNU and BSD sed.
Signed-off-by: Ed Maste <emaste@freebsd.org>
Message-Id: <20191114203615.2866-1-emaste@freefall.freebsd.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This function returns an int32_t, however the prototype in
libfdt_internal.h shows it returning an int. We haven't caught this before
because they're the same type on nearly all platforms this gets built on.
Apparently it's not the case on FreeRTOS, so someone hit this mismatch
building for that platform.
Reported-by: dharani kumar <dharanikumarsrvn@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The type here is uint32_t which should use PRIx32, not plain %x which is
for an int, we've just gotten away with it so far.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use -b to explicitly set file prefix, so that byacc generates files with
the same names as bison.
Add %locations to dtc-parser.y to explicitly enable location tracking
for byacc, and define YYERROR_CALL to prevent byacc from defining it to
call yyerror with 2 parameters because of the locations directive,
because dtc-parser.y defines yyerror to accept one parameter.
Signed-off-by: Ethan Sommer <e5ten.arch@gmail.com>
Message-Id: <20191029162619.32561-1-e5ten.arch@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This function should use a void * type, not char *. This causes an error:
TypeError: in method 'fdt_property_stub', argument 3 of type 'char const *'
Fix it and update the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20191025010226.34378-1-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
dtc uses non-portable formats. Using gnu_printf attributes (for
warnings) in combination with __USE_MINGW_ANSI_STDIO allows to build
for win32.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191009102025.10179-8-marcandre.lureau@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fixes mingw cross-compilation. lstat() doesn't exist on win32.
It seems to me that stat() is the right function there, to return
informations about the file it refers to.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191009102025.10179-7-marcandre.lureau@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Instead of outputing files to current directory, allow to specificy an
output directory. This helps with meson build system out-of-tree support.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191009102025.10179-4-marcandre.lureau@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present the tool terminates its execution if one of the overlays passed
as command-line arguments can't be successfully read or applied, but the exit
code of the process is zero, making failures hard to detect inside scripts.
Signed-off-by: Valter Minute <valter.minute@toradex.com>
Message-Id: <20191009123256.14248-1-valter.minute@toradex.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Set code style for various editors.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191009102025.10179-2-marcandre.lureau@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The dts syntax allows for '<>' around phandles and arg cells or not
which it didn't matter until adding type information. However, the YAML
encoding expects each phandle + args to be bracketed.
If TYPE_UINT32 markers are not present before each REF_PHANDLE, fix up
the markers and add the TYPE_UINT32 markers. This allows the subsequent
YAML emitting code to work as-is.
Adding the markers at an earlier stage doesn't work because of
possible labels in dts output. We'd have to define the ordering of
labels and brackets. Also, it is probably best to have dts output match
the input.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20190918183534.24205-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Including libfdt.h in a C++ project fails during compilation with recent
version of GCC or Clang.
This simple example:
extern "C" {
#include <libfdt.h>
}
int main(void) { return 0; }
leads to the following errors with GCC 9.1.0:
/usr/include/libfdt.h: In function ‘void fdt32_st(void*, uint32_t)’:
/usr/include/libfdt.h:139:16: error: invalid conversion from ‘void*’ to ‘uint8_t*’ {aka ‘unsigned char*’} [-fpermissive]
139 | uint8_t *bp = property;
| ^~~~~~~~
| |
| void*
/usr/include/libfdt.h: In function ‘void fdt64_st(void*, uint64_t)’:
/usr/include/libfdt.h:163:16: error: invalid conversion from ‘void*’ to ‘uint8_t*’ {aka ‘unsigned char*’} [-fpermissive]
163 | uint8_t *bp = property;
| ^~~~~~~~
| |
| void*
This commit adds an explicit cast to uint8_t* to fix this issue.
Signed-off-by: Luc Michel <luc.michel@greensocs.com>
Message-Id: <20190910104824.1321594-1-luc.michel@greensocs.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The default Python version for pylibfdt is already Python 3 but if
called without specifiying an interpreter, the setup.py script gets
called with Python 2.
It's of course still possible to call setup.py with python2 directly.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Message-Id: <20190907152530.25102-1-luca@z3ntu.xyz>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The 'alias_paths' check verifies that each property in /aliases is a valid
path to another node. However this can cans false positives trees where
the /aliases node has a phandle property, which isn't in this format but
is allowed. In particular this situation can be common with trees dumped
from some real OF systems (which typically generate a phandle for every
node).
Special case this to avoid the spurious error.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Convert the usage to be compatible with Python 3 and the current API.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Message-Id: <20190817212532.15661-2-luca@z3ntu.xyz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The "strlen && strprefixeq" check in get_node_by_path is
excessive, since strlen is checked in strprefixeq macro
internally. Thus, "strlen(child->name) == p-path"
conjunct duplicates after macro expansion and could
be removed.
Signed-off-by: Denis Efremov <efremov@linux.com>
Message-Id: <20190827204148.20604-1-efremov@linux.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
c12b2b0c20 "libfdt: fdt_address_cells() and fdt_size_cells()" introduced
a bug as it consolidated code between the helpers for getting
#address-cells and #size-cells. Specifically #size-cells is allowed to
be 0, and is frequently found so in practice for /cpus. IEEE1275 only
requires implementations to handle 1..4 for #address-cells, although one
could make a case for #address-cells == #size-cells == 0 being used to
represent a bridge with a single port.
While we're there, it's not totally obvious that the existing implicit
cast of a u32 to int will give the correct results according to strict C,
although it does work in practice. Straighten that up to cast only after
we've made our range checks.
Reported-by: yonghuhaige via https://github.com/dgibson/dtc/issues/28
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
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>
In libfdt we often sanity test fdt_totalsize(fdt) fairly early, then
trust it (but *only* that header field) for the remainder of our work.
However, Coverity gets confused by this - it sees the byteswap in
fdt32_ld() and assumes that means it is coming from an untrusted source
everytime, resulting in many tainted data warnings.
Most of these end up with logic in fdt_get_string() as the unsafe
destination for this tainted data, so let's tweak the logic there to make
it clearer to Coverity that this is ok.
We add a sanity test on fdt_totalsize() to fdt_probe_ro_(). Because the
interface allows bare ints to be used for offsets, we already have the
assumption that totalsize must be 31-bits or less (2GiB would be a
ludicrously large fdt). This makes this more explicit.
We also make fdt_probe_ro() return the size for convenience, and change the
logic in fdt_get_string() to keep it in a local so that Coverity can see
that it has already been bounds-checked.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Symbols from overlays are merged into the target tree, and are required to
have the form:
/fragment@XXX/__overlay__/...
If any symbols don't have this form, the overlay is rejected.
But there's not really anything wrong with an overlay having "local"
labels referring to a fragment node or some other metadata, that's not
expected to end up in a target tree.
So change our overlay application to simply ignore such symbols rather than
fail.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When applying overlays, we merge symbols from the overlay into the target
tree. At the moment the logic for this assumes all symbols in the overlay
are attached to a node of the form:
/fragment@XXX/__overlay__/relative/path
And will end up applied to the relative/path node under the fragment's
target.
However, this disallows the case of a symbol in the form just:
/fragment@XXX/__overlay__
This does have a pretty obvious sensible meaning: attach the new symbol
directly to the fragment's target, but we don't currently do that.
It's pretty easy to workaround this limitation in one's overlays, but it's
also easy to handle in the overlay applying code, so we might as well
extend it to cover this case.
Reported-by: Christophe Braillon
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add this into the class to simplify use of this function.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Message-Id: <1562130487-27028-1-git-send-email-appana.durga.rao@xilinx.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present this example is incorrect since it is missing the call to
finish_reservemap() and does not add a root node. Fix these problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20190703000815.102459-1-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This adds a test case to demonstrate some issue seen when applying
overlays using 'fdtoverlay'. It fails with FDT_ERR_NOSPACE:
- with long target path
- symbols in order to use these nodes in possible subsequent overlay.
This is seen with this patch, by running:
$ make check # Reports a failed test
$ ./fdtoverlay -i tests/overlay_base.test.dtb -o out.dtb \
tests/overlay_overlay_long_path.fdoverlay.test.dtb
Failed to apply tests/overlay_overlay_long_path.fdoverlay.test.dtb (-3)
This overlay fails to apply, because dtb size is close to modulo 1024
bytes chunk: utilfdt_read() -> utilfdt_read_err() -> bufsize = 1024.
As there is not much extra space in the blob to resolve symbols (long
target path), it fails with FDT_ERR_NOSPACE. In fdtoverlay, size is :
/* grow the blob to worst case */
blob_len = fdt_totalsize(blob) + total_len;
I can see assumption is made that result should be lower than:
- base fdt size + overlay size. Is there a simple way to find to know
what the final size is?
I'm not sure what the correct fix might be, for such (worst) case?
Similar issue is also seen in u-boot/common/image-fit.c that implements
similar approach (e.g. base fdt size + overlay size).
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Message-Id: <1538553302-1353-1-git-send-email-fabrice.gasnier@st.com>
[dwg: To avoid breaking bisection, I committed this after a fix, so
the "failed" description is no longer accurate]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rob Herring