FT is sometimes used for storing raw data. That is quite common for
U-Boot FIT images.
Extracting such data is not trivial currently. Using type 's' (string)
will replace every 0x00 (NUL) with 0x20 (space). Using type 'x' will
print bytes but in xxd incompatible format.
This commit adds support for 'r' (raw) format. Example usage:
fdtget -t r firmware.itb /images/foo data > image.raw
Support for encoding isn't added as there isn't any clean way of passing
binary data as command line argument.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Message-Id: <20211209061420.29466-1-zajec5@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Replace instances of GPLv2 or later boilerplate with SPDX tags.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20190620211944.9378-2-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
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>
When clang checks the documentation tags (with -Wdocumentation flag), it
reports the following warning:
fdtput.c:70:11: error: parameter '*value_len' not found in the
function declaration [-Werror,-Wdocumentation]
* @param *value_len Returns length of value encoded
^~~~~~~~~~
fdtput.c:70:11: note: did you mean 'value_len'?
* @param *value_len Returns length of value encoded
^~~~~~~~~~
value_len
As this sounds reasonable, remove the star from the documentation tag.
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>
CID 132821 (#1 of 1): Resource leak (RESOURCE_LEAK)
12. leaked_storage: Variable value going out of scope leaks the storage it points to.
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
fdtput.c:
Replace the remaining call to realloc by xrealloc.
Some redundant lines in encode_value can be saved.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
If you try to insert a new node or extend a property with large value,
using fdtput you will notice that it always fails.
example:
fdtput -v -p -ts ./tst.dtb "/node-1" "property-1" "value-1
Error at 'node-1': FDT_ERR_NOSPACE
or
fdtput -v -c ./tst.dtb "/node-1"
Error at 'node-1': FDT_ERR_NOSPACE
or
fdtput -v -ts ./tst.dtb "/node" "property" "very big value"
Decoding value:
string: 'very big value'
Value size 15
Error at 'property': FDT_ERR_NOSPACE
All these error are returned from libfdt, as the size of the fdt passed
has no space to accomdate these new properties.
This patch adds realloc functions in fdtput to allocate new space in fdt
when it detects a shortage in space for new value or node. With this
patch, fdtput can insert a new node or property or extend a property
with new value greater than original size. Also it packs the final blob
to clean up any extra padding.
Without this patch fdtput tool complains with FDT_ERR_NOSPACE when we
try to add a node/property or extend the value of a property.
Testcases for the new behaviour added by David Gibson.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
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>
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>
This option mimics mkdir's -p option. It automatically creates nodes
as needed along the path provided. If the node already exists, no
error is given.
Signed-off-by: Simon Glass <sjg@chromium.org>
As with many fdt functions, report_error() should permit a namelen to
be specified, thus obviating the need for nul termination in strings
passed to it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This option allows the creation of new nodes in a dtb file. The syntax
is:
fdtput -c <dtb_file> <node_path>
The node_path contains the path of the node to be created. All path
components up to the final one must exist already. The final one must
not exist already.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
We want to add new options to this tool. In preparation for this, add
the concept of a current operation.
Signed-off-by: Simon Glass <sjg@chromium.org>
There was an extra < in the help message, so fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This simple utility allows writing of values into a device tree from the
command line. It aimes to be the opposite of fdtget.
What is it for:
- Updating fdt values when a binary blob already exists
(even though source may be available it might be easier to use this
utility rather than sed, etc.)
- Writing machine-specific fdt values within a build system
To use it, specify the fdt binary file on command line followed by the node
and property to set. Then, provide a list of values to put into that
property. Often there will be just one, but fdtput also supports arrays and
string lists.
fdtput does not try to guess the type of the property based on looking at
the arguments. Instead it always assumes that an integer is provided. To
indicate that you want to write a string, use -ts. You can also provide
hex values with -tx.
The command line arguments are joined together into a single value. For
strings, a nul terminator is placed between each string when it is packed
into the property. To avoid this, pass the string as a single argument.
Usage:
fdtput <options> <dt file> <<node> <property> [<value>...]
Options:
-t <type> Type of data
-v Verbose: display each value decoded from command line
-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)
To read from stdin and write to stdout, use - as the file. So you can do:
cat somefile.dtb | fdtput -ts - /node prop "My string value" > newfile.dtb
This commit also adds basic tests to verify the major features.
Signed-off-by: Simon Glass <sjg@chromium.org>
