It's more appropriate than off_t since it is, after all, a size not an
offset.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
There are no less than _four_ variants on utilfdt_read() which is a bit
excessive. The _len() variants are particularly pointless, since we can
achieve the same thing with very little extra verbosity by using the usual
convention of ignoring return parameters if they're NULL. So, get rid of
them (we keep the shorter names without _len, but add now-optional len
parameters).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
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>
We have a number of explicit __GNUC__ conditionals to tell if we want to
use some gcc extensions for extra warnings. This cleans this up to use
a single conditional, defining convenience macros for those attributes.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When compiling with gcc, we already include the attribute on check_msg()
to give compiler warnings about mismatches between printf() like format
strings and the corresponding arguments. This patch adds similar
attributes for lexical_error() and die().
Suggested-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fix two places where a printf()-style format string does not match the
arguments passed.
Reported-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Include a portable asprintf variant that works on any C99
conforming platform.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Although on some systems va_end is a no-op, it is good practice
to use va_end, especially since the manual states:
"Each invocation of va_start() must be matched by a corresponding
invocation of va_end() in the same function."
Signed-off-by: Colin Ian King <colin.king@canonical.com>
We already use the C99 bool type from stdbool.h in a few places. However
there are many other places we represent boolean values as plain ints.
This patch changes that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
I want to use this in more places, so put it in util.h rather than
copying & pasting it into another file.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that all utils have converted to the new usage framework, we can
rename to just plain "usage()" and avoid naming conflicts.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This helps standardize the flag processing and the usage screens.
Only lightly tested; would be great if someone who uses these utils
could double check.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This starts a new usage framework and then cuts fdtdump over to it.
Now we can do `fdtdump -h` and get something useful back.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For a follow up commit, we want to be able to scan the buffer that was
returned to us. In order to do that safely, we need to know how big
the buffer actually is, so create a new set of funcs to pass that back.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This is so all utilities can have this flag and not just dtc.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We only display this string, so there's no need for it to be writable.
Constify away!
Acked-by: David Gibson <David@gibson.dropbear.id.au>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
For a follow up commit, we want to be able to scan the buffer that was
returned to us. In order to do that safely, we need to know how big
the buffer actually is, so pass that back if requested.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The function that prints a property can be useful to other programs,
so move it into util.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This commit which changed the behaviour of this function broke one
of the tests. Also the comment should be updated to reflect its new
behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
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>
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>
Move the parsing of hex, octal and escaped characters from data.c
to util.c where it can be used for character literal parsing within
strings as well as for stand alone C style character literals.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This useful function is split out so it will be available to programs
other than ftdump.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This patch cleans up our handling of input files, particularly dts
source files, but also (to an extent) other input files such as those
used by /incbin/ and those used in -I dtb and -I fs modes.
We eliminate the current clunky mechanism which combines search paths
(which we don't actually use at present) with the open relative to
current source file behaviour, which we do.
Instead there's a single srcfile_relative_open() entry point for
callers which opens a new input file relative to the current source
file (which the srcpos code tracks internally). It doesn't currently
do search paths, but we can add that later without messing with the
callers, by drawing the search path from a global (which makes sense
anyway, rather than shuffling it around the rest of the processing
code).
That suffices for non-dts input files. For the actual dts files,
srcfile_push() and srcfile_pop() wrappers open the file while also
keeping track of it as the current source file for future opens.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that we have a util.[ch] file shared between dtc and
convert-dtsv0, move some functions which are currently duplicated in
the two to util files. Specifically we move the die(), xmalloc() and
xrealloc() functions.
While we're at it, add standard double-include protection to util.h
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Many places in dtc use strdup(), but none of them actually check the
return value to see if the implied allocation succeeded. This is a
potential bug, which we fix in the patch below by replacing strdup()
with an xstrdup() which in analogy to xmalloc() will quit with a fatal
error if the allocation fails.
I felt the introduciton of util.[ch] was a better choice
for utility oriented code than directly using srcpos.c
for the new string function.
This patch is a re-factoring of Dave Gibson's similar patch.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
David Gibson