ratp: new md and mw commands ...

This commit introduces support for running the md and mw commands
using the binary interface provided by RATP. This allows clients to
read and write memory files without needing to do custom string
parsing on the data returned by the console 'md' and 'mw' operations.

The request and response messages used for these new operations are
structured in the same way:

 * An initial fixed-sized section includes the fixed-sized
   variables (e.g. integers), as well as the size and offset of the
   variable-length variables.

 * After the initial fixed-sized section, the buffer is given, which
   contains the variable-length variables in the offsets previously
   defined and with the size previously defined.

The message also defines separately the offset of the buffer
w.r.t. the start of the message. The endpoint reading the message will
use this information to decide where the buffer starts. This allows to
extend the message format in the future without needing to break the
message API, as new fields can be appended to the fixed-sized section
as long as the buffer offset is also updated to report the new
position of the buffer.

E.g.:
    $ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5
    0000000000

    $ ./bbremote --port /dev/ttyUSB2 mw /dev/pic_eeprom_rdu 0x107 0102030405
    5 bytes written

    $ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5
    0102030405

    $ ./bbremote --port /dev/ttyUSB2 mw /dev/pic_eeprom_rdu 0x107 0000000000
    5 bytes written

    $ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5
    0000000000

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: use xstrndup() instead of a custom xmemdup_add_zero() ...

The console operations done via RATP expect strings, so just use
xstrndup() instead of defining a custom method.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: implement getenv as a standard ratp command ...

Also, use xstrndup() instead of the custom xmemdup_add_zero() as we're
working with strings anyway.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: implement ping as a standard ratp command ...

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: allow building without full console support ...

Make CONFIG_RATP a selectable config option, so that the user can
enable RATP support without explicitly needing to enable the full
console support over RATP (e.g. only for RATP FS or built-in command
support).

The full console can still be explicitly enabled with
CONFIG_CONSOLE_RATP.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: moved logic to its own subdirectory ...

We are going to add new RATP command implementations in separate files
within this subdirectory.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: implement generic command support ...

The RATP implementation now allows executing generic commands with a
binary interface: binary requests are received and binary responses
are returned.

Each command can define its own RATP request contents (e.g. to specify
command-specific options) as well as its own RATP response contents
(if any data is to be returned).

Each command is associated with a pair of numeric unique request and
response IDs, and for easy reference these IDs are maintained in the
common ratp_bb header. Modules may override generic implemented
commands or include their own new ones (as long as the numeric IDs
introduced are unique).

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

state: find backend node with its reproducible name ...

When fixing up the kernels state nodes we depended on the full node path
of the input device tree. This does not work when the kernel device tree
has different names. This has happened lately when the i.MX6 device
trees got their leading zeroes removed from the node names.

Use of_find_node_by_reproducible_name() to find the node corresponding
to the storage backend node in the kernel device tree.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

state: remove unused arguments from state_new_from_node() ...

state_new_from_node() has arguments describing the backend path. These
are never used in barebox, the backend path is always derived from the
device nodes backend description. Remove these arguments.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts/compiler.h: inline functions in headers must be static ...

Without this building bareboxenv-target with gcc 7.3 fails with:

  CC      scripts/bareboxenv-target
/tmp/cc9G2oOY.o: In function `file_action':
bareboxenv.c:(.text+0x14): undefined reference to `xzalloc'
/tmp/cc9G2oOY.o: In function `concat_path_file':
bareboxenv.c:(.text+0xf4): undefined reference to `xmalloc'
/tmp/cc9G2oOY.o: In function `envfs_save':
bareboxenv.c:(.text+0x5b4): undefined reference to `xzalloc'
/tmp/cc9G2oOY.o: In function `envfs_load':
bareboxenv.c:(.text+0x7d8): undefined reference to `xmalloc'
collect2: error: ld returned 1 exit status

Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

i2c: i2c_master_send(): don't leave flags uninitialized ...

Leaving the flags field unitialized can lead to performing
read operation instead of write operation.

Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: Use const dtb unflatten variant ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/zstd'

Merge branch 'for-next/tftp-workaround'

Merge branch 'for-next/sandbox-libftdi'

Merge branch 'for-next/ratp'

Merge branch 'for-next/of'

Merge branch 'for-next/misc'

Merge branch 'for-next/e1000'

Merge branch 'for-next/constify'

Merge branch 'for-next/at91'

Merge branch 'for-next/FIT'

env: Add more context to error message ...

When setenv complains that it can't set a device parameter, then print
which parameter it tried to set.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: Allow to open buffer as FIT image ...

This adds fit_open_buf() which can open a buffer as FIT image.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: Implement opening images with no configuration ...

different images can be grouped together to build a FIT configuration.
So far we only supported opening images as parts of configurations.
This patch adds support for opening images that are not part of a
configuration. This mode is used when the configuration parameter of
fit_open_image is NULL.

The main difference is in the way the RSA signature is checked. When
being part of a configuration all involved nodes (including the hash
nodes of the images, but not the image itself) are covered by the
signature, thus during opening an image only the validity of the image
data hash has to be checked. When not being part of a configuration,
the image data itself is signed and must be checked.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: factor out some helper functions ...

Create and use fit_alloc_digest() and fit_read_rsa_public_key()
which we can use a second time in the next step.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: move handle->verify check to fit_verify_hash() ...

Preparation for the next step which will allow to open
images which are not part of a configuration.

This has one change inside: We used to iterate over all
subnodes of a image expecting all of them containing a hash,
so it could happen that we check multiple hashes if more exist
or that we falsely interpret some unrelated subnode as hash node.
With this patch we expect the hash in a subnode named "hash@1"
as required by the FIT image format description.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: store device_nodes in fit_handle ...

We need the /images and /configurations nodes more than once,
so store them in the fit_handle rather than searching for them
each time again.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: Let user specify the configuration to use ...

The images in FIT images can be opened in two different ways. They
can be either opened directly based on their names in the images/
node or as part of a configuration based on their names in the
corresponding /configuration/ node.

So far we only supported the latter. To prepare supporting the former
we return a cookie belonging to the configuration from
fit_open_configuration() which we use in fit_open_image() to refer
to the desired configuration.

While at it document fit_open_configuration().

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

FIT: Do not pre-open images ...

Only do what fit_open_configuration() suggests: open the configuration,
but not the images in it.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>