This most likely doesn't fix any real bugs, but it's the
right thing to do and reduces the noise level with static
checkers.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We have to use strtoul to run the tool working on 32bit systems.
Otherwise it will generate signed numbers for strings representing
values with the 32nd bit set.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Image payload size should always be a multiple of 4 bytes. This fixes
mis-sized image payload by allocating payload buffer as multiple of 4
but load true filesize into the payload buffer.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The v0 header, used on Kirkwood, has some fields to indicate the type
of the NAND ECC, and the page size of the NAND. This commit adds
support for such fields, which are needed to support the Kirkwood
Guruplug platform.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The function image_boot_mode_id() converts the name of a boot media
into the corresponding Marvell specific code. However, 0 that we
currently used to indicate that the boot media name wasn't found,
could potentially be a valid value. So instead we use -1 to indicate a
failure.
This is also done in preparation to the introduction of
image_nand_ecc_mode_id(), which will convert a NAND ECC mode name into
the corresponding identifier. And in this case 0 is a valid identifier
of a NAND ECC mode, so we cannot use it to indicate a failure. Since
we want image_boot_mode_id() and image_nand_ecc_mode_id() to have a
consistent behavior, we change the former in this commit. The latter
is introduced in the next commit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We now assume that at most one binary header can be added, so we no
longer need to loop for all configuration options to find the binary
blobs. We simply find the binary blob configuration option in
'binarye' and use that when we need to generate the corresponding
header.
Also, just like we did for the v0 image creation, use
image_find_option() to find the value of the different options needed
to create the main header.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Until now, the v0 image creation function was expecting the
configuration parameters to be ordered with first the configuration
parameters affecting the main header, then the DATA configuration
parameters that affect the extended header, then the payload.
However, with the recently added ability to override the destination
address or execution address, the configuration options corresponding
to those values may now appear at the end of the configuration
options. This commit allows to handle that by making the image
creation more flexible:
- The configuration options for the main header are just searched
amongst all options, the first match is used.
- When building the extension header with the DATA options, all DATA
options from the configuration file are used, in the order in which
they appear in the kwbimage.cfg file.
This will for example allow a kwbimage.cfg for a v0 image to not
specify any destination or execution address, and simply override it
from the command line.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This commit uses the newly introduced image_count_options() function
to:
- See if there is any DATA option that require the creation of an
extended header for v0 header.
- Verify that no more than one payload has been provided when
creating a v0 header.
- Verify that no more than one binary payload has been provided when
creating a v1 header. Technically speaking, it is possible to
support several payloads, but in real life, only one gets used, so
we will only support that to make the code simpler for now. It can
always be extended later on if needed.
- Verify that no more than one payload has been provided when
creating a v1 header.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This function returns the number of configuration elements that match
a given type. Will be used to do some sanity checking of the number of
options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This adds some references to Marvell Dove as it is also supported by
kwbimage.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
that understand a specific image format, composed of a main header,
several extension headers and a paylod. This image can be booted from
NAND, SPI, SATA, UART, NOR, etc.
This patch adds a tool that allows to extract the components and
configuration of existing images, and to create new images.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Lucas Stach
Alexander Shiyan
Michael Grzeschik
Sebastian Hesselbarth
Thomas Petazzoni