Currently -l option for mkimage and dumpimage ignores option -T and always
tries to autodetect image type.

With this change it is possible to tell mkimage and dumpimage to parse
image file as specific type (and not random autodetected type). This allows
to use mkimage -l or dumpimage -l as tool for validating image.

params.type for -l option is now by default initialized to zero
(IH_TYPE_INVALID) instead of IH_TYPE_KERNEL. imagetool_get_type() for
IH_TYPE_INVALID returns NULL, which is assigned to tparams. mkimage and
dumpimage code is extended to handle tparams with NULL for -l option. And
imagetool_verify_print_header() is extended to do validation via tparams if
is not NULL.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

This has the same result but some compilers will warn about this
fall-through if there are statements as part of the label block.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

The dumpimage utility errors out in a number of places without providing
sufficient feedback to allow the user to easily determine what has gone
wrong. Add additional error messages to make the cause of the failure
more obvious.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Help message isn't clear over the use of the "-T" option (it's to declare
the type of image that the tool is operating on), which also is optional
as it defaults to the default image type. It's also missing a description
of the "-o" option, so add it.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

The utility dumpimage has error paths that display the usage and others
that exit without displaying usage. Add an explicit help option to
dumpimage to display the usage and remove it's use in error paths to make
the error messages more obvious and errors paths more consistent.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

There are 3 supported modes of operation:

1) Show version
2) List image contents
3) Extract image component

Option (1) terminates early, so only options (2) and (3) remain. Remove
redundant check for these modes.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

The dump image utility has very confusing syntax. If called to list image
contents ("-l") it takes the image name as a positional argument. If the
utility is called to extract something from the image, the image must be
provided via the optional argument "-i" as well as the positional argument
but the value passed in the positional argument will be completely
ignored.

Simplify dumpimage by always providing the image as the first positional
argument. Assume we want to dump something from the image if we do not
provide the "-l" option for now.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

The dumpimage utility errors out in a number of places without providing
sufficient feedback to allow the user to easily determine what they have
done wrong. Add addtional error messages to make the cause of the failure
more obvious.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>