This series from Marek Vasut <marek.vasut@mailbox.org> cleans up some of
the FIT pytests we have and then extends mkimage to support including
the TEE in FIT images when using "-f auto" to create the resulting FIT.
Link: https://lore.kernel.org/r/20251125154324.51940-1-marek.vasut@mailbox.org
Introduce two new parameters to be used with mkimage -f auto to bundle
TEE image into fitImage, using auto-generated fitImage. Add -z to specify
TEE file name and -Z to specify TEE load and entry point address. This is
meant to be used with systems which boot all of TEE, Linux and its DT from
a single fitImage, all booted by U-Boot.
Example invocation:
"
$ mkimage -E -A arm -C none -e 0xc0008000 -a 0xc0008000 -f auto \
-d arch/arm/boot/zImage \
-b arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dtb \
-z ../optee_os/out/arm-plat-stm32mp1/core/tee-raw.bin \
-Z 0xde000000 \
/path/to/output/fitImage
"
Documentation update and test are also included, the test validates
both positive and negative test cases, where fitImage does not include
TEE and does include TEE blobs.
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Quentin Schulz <foss+uboot@0leil.net> says:
I have a couple of products whose U-Boot FIT is signed via a proprietary
OpenSSL engine which only expects the name of a "slot" to select the key
to sign data with.
Currently mkimage fit support expects either a key-dir (-k) or a
key-file (-G) as a toggle for signing, however this doesn't apply to our
usecase because we use an OpenSSL engine (so no key-file to provide)
which doesn't mimic a directory layout like key-dir implies. Moreover,
binman really expects private keys (.key extension) to be available in
this key-dir directory, which we of course cannot provide.
This series allows to sign a FIT image with mkimage (and binman) with
an OpenSSL engine, including PKCS11 and custom engines. If a key-dir
needs to be passed (which is typical for PKCS11), one can do so by using
fit,engine-keydir.
Note that the public key (.crt extension) still needs to be available if
one wants to embed it for signature verification (which is probably what
one wants to do :) ). It is probably possible to use the engine for
getting the public key instead of storing it on disk, but this needs to
be added to fdt_add_pubkey and then binman, through a mechanism
different from fit,engine*.
One issue though is that since binman resolves key paths absolutely and
that I don't believe an OpenSSL engine would happen to have the exact
same key_id value than a local absolute path, fit,encrypt and
fit,engine cannot cohabit. An issue for the next person who wants
an OpenSSL engine AND encrypt the same FIT image, I don't.
Note that LibreSSL supports neither engines nor providers as far as I
could tell (engine support has been explicitly removed).
Note that OpenSSL engines have been deprecated since 3.0 (Q3-2021),
however note that OpenSSL 3.5 still seems to support engines (git grep)
and is EOL end of Q1 2030.
If anyone has an idea on how to test PKCS11 with SOftHSMv2 with id=
passed in fit,engine-keydir, I'm all ears.
I'm also wondering if the explanation around fit,engine-keydir aren't
too much. After all, they are passed verbatim to mkimage as -k argument
and the special cases are all specific to mkimage and not binman.
Link: https://lore.kernel.org/r/20251121-binman-engine-v3-0-b80180aaa783@cherry.de
This adds a test that signs a FIT and verifies the signature with
fit_check_sign.
OpenSSL engines are typically for signing with external HW so it's not
that straight-forward to simulate.
For a simple RSA OpenSSL engine, a dummy engine with a hardcoded RSA
4096 private key is made available. It can be selected by setting the
OpenSSL engine argument to dummy-rsa-engine. This can only be done if
the engine is detected by OpenSSL, which works by setting the
OPENSSL_ENGINES environment variable. I have no clue if dummy-rsa-engine
is properly implementing what is expected from an RSA engine, but it
seems to be enough for testing.
For a simple PKCS11 engine, SoftHSMv2 is used, which allows to do PKCS11
without specific hardware. The keypairs and tokens are generated on the
fly. The "prod" token is generated with a different PIN (1234 instead of
1111) to also test MKIMAGE_SIGN_PIN env variable while we're at it.
Binman will not mess with the local SoftHSMv2 setup as it will only use
tokens from a per-test temporary directory enforced via the temporary
configuration file set via SOFTHSM2_CONF env variable in the tests. The
files created in the input dir should NOT be named the same as it is
shared between all tests in the same process (which is all tests when
running binman with -P 1 or with -T).
Once signed, it's checked with fit_check_sign with the associated
certificate.
Finally, a new softhsm2_util bintool is added so that we can initialize
the token and import keypairs. On Debian, the package also brings
libsofthsm2 which is required for OpenSSL to interact with SoftHSMv2. It
is not the only package required though, as it also needs p11-kit and
libengine-pkcs11-openssl (the latter bringing the former). We can detect
if it's properly installed by running openssl engine dynamic -c pkcs11.
If that fails, we simply skip the test.
The package is installed in the CI container by default.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This adds support for using an OpenSSL engine for signing a FIT image.
To use it, one should set the fit,engine property at the FIT node level
with the engine to use. This will in turn call mkimage with the -N
option.
The -k argument to mkimage can be specified via fit,engine-keydir. If
not specified, -k is not passed to mkimage. This property is especially
useful for pkcs11 engine to specify slots, token label, etc...
As far as I could tell, mkimage encrypts and signs a FIT in one go, thus
the -k argument applies to both signing and encrypting. Considering we
reuse the -k argument for two different meanings (info to pass to the
engine when using an engine otherwise the directory where keys are
stored), we cannot reasonably encrypt using local keys and signing with
an engine, hence the enforced check. I believe it should be possible to
support encrypting and signing with the same engine (using different
key pairs of course, via different key-name-hint likely), but this is
left for the next person to implement.
This is why the property is named fit,engine and not fit,sign-engine.
Ditto for fit,engine-keydir.
The public key (with .crt extension) is still required if it needs to be
embedded in the SPL DTB for example. We could probably support
retrieving the public key from an engine, but this is a change to make
to fdt_add_pubkey.c.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
mkimage has support for OpenSSL engines but binman currently doesn't for
direct callers of mkimage (e.g. the fit etype). This prepares for adding
support for OpenSSL engines for signing elements of a FIT image, which
will done in the next commit.
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Currently, when one wants to use an OpenSSL engine to sign a FIT image,
one needs to pass a keydir (via -k) to mkimage which will then be
prepended to the value of the key-name-hint before being passed as
key_id argument to the OpenSSL Engine API, or pass a keyfile (via -G) to
mkimage.
My OpenSSL engine only has "slots" which are not mapped like
directories, so using keydir is not proper, though I could simply have
-k '' I guess but this won't work currently with binman anyway.
Additionally, passing a keyfile (-G) when using an engine doesn't make
sense as the key is stored in the engine.
Let simply allow FIT images be signed if both keydir and keyfile are
missing but an engine is to be used.
The keyname member is already filled by looking at key-name-hint
property in the FIT and passed to the engine, which is exactly what is
needed here.
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
- Bump to noble-20251013
- Include tools for sage lab, build TF-A for platforms there.
- Switch to distro provided trace-cmd, add libengine-pkcs11-openssl
- Use mirrors for GNU projects
- Switch to QEMU 10.1.x
Signed-off-by: Tom Rini <trini@konsulko.com>
Quentin Schulz <foss+uboot@0leil.net> says:
I have to add one (1) package to the Dockerfile as a new dependency and
wanted to build the image to verify it works. I wasn't able to because
GNU servers are just not reliable at all.
The git server URL we're using doesn't seem to be a mirrored one, and
switching to mirror URLs seem to make fetching possible again.
Unfortunately, we don't have the option to do that for coreboot's
dependencies, though we can ask coreboot to download the dependencies
through its own mirror, which we do in this series.
Link: https://lore.kernel.org/r/20251127-gnu-mirror-v2-0-c86fa2e8d464@cherry.de
In the future, we'll need proper pkcs11 support so that we can validate
mkimage/binman works well with pkcs11 OpenSSL engine/provider via
softhsm2-util (already installed).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Now that we have moved to Ubuntu 24.04 the distribution provided
trace-cmd is new enough for our needs. Switch to installing that and
stop building it from source.
Signed-off-by: Tom Rini <trini@konsulko.com>
The current release of QEMU is 10.1.2 and we should be tracking at least
that new currently, to help find and fix emulation problems. This will
make it smaller of a change when we move to 10.1.3 which will re-enable
sifive_unleashed_sdcard testing again.
Signed-off-by: Tom Rini <trini@konsulko.com>
This series adds support for Gitlab pipelines to run our pytest suite on
a limited number of hardware platforms. While better documentation and
some further enhancements will be coming soon, this can be triggered by
passing '-o ci.variable="SAGE_LAB=1"' to git push, or adding
'pushOption = ci.variable="SAGE_LAB=1"' to the .git/config file for the
project. It can also be invoked manually from the pipeline webpage on a
an existing pipeline.
Link: https://lore.kernel.org/r/20251118210015.624758-1-trini@konsulko.com
Add snmp and rsync to the normal docker image. While these tools are
only required for the lab on sage, I think it's a small enough addition
to be worth always including at this point. A higher level TODO I think
may be to see if we can / should split the resulting container up, or
if there's host tooling we can remove at a later step, after building
all the software we require.
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to add pine64_plus to the sage lab we will need to have a build
of TF-A available for it as bl31.bin. Add this to the existing build
loop of TF-A targets.
Signed-off-by: Tom Rini <trini@konsulko.com>
coreboot buildgcc script downloads GNU dependencies from GNU FTP server.
For some reason, this is also as unreliable as their git main server.
There's no option to use a GNU mirror (and I'm not even sure if there's
one for FTP), so we simply pass --mirror to the buildgcc script via the
BUILDGCC_OPTIONS variable so that it makes use of coreboot's mirror.
Hopefully, this proves more reliable than GNU original FTP server.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
grub bootstrap script downloads gnulib from a non-mirror URL and thus is
unreliable.
One can specify the URL to fetch from with GNULIB_URL environment
variable, so let's make this variable point at a mirror URL.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
GNU announced they activated mirrors for git servers[1] in May this
year.
The main git server keeps being very unreliable and switching to those
mirrors seems to improve reliability (albeit somewhat slow).
Yes, the URL in this patch has nothing in common with the URL in the
linked mail, it was extracted from the Clone section in the mirrored
cgit page[2].
While at it, switch to the HTTPS clone which is "more secure" than git
protocol.
[1] https://lists.gnu.org/archive/html/savannah-users/2025-05/msg00002.html
[2] https://cgit.git.savannah.gnu.org/cgit/grub.git/
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The Dockerfile is using linux/arm64 without the /v8 suffix.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Quentin Schulz <foss+uboot@0leil.net> says:
While historically signature verification is mostly done for FIT such
FIT_SIGNATURE dependency for signature algorithm makes sense, it isn't
the only kind of file we can verify signatures of. It can also be done
manually with rsa_verify_hash() with an embedded public key.
Considering the impacted code is guarded by RSA_VERIFY, let's make the
symbol depend on that otherwise selecting it without RSA_VERIFY won't do
anything. The FIT_SIGNATURE dependency wasn't also enough before as it
only implied RSA_VERIFY.
Then, simply relocate the RSA SSA PSS padding with the other RSA symbols
in lib/rsa instead of in boot/ and rename it to remove the mention to
FIT.
Finally, add the PSS padding wherever PKCS1.5 padding is specified as
one or the other can be used.
Link: https://lore.kernel.org/r/20251031-rsa-pss-always-v2-0-a29184ea064d@cherry.de
This renames FIT_RSASSA_PSS symbols to drop the FIT_ prefix to avoid
potential confusion since there's nothing FIT specific to those symbols.
It also isn't really related to booting, so boot/Kconfig is an odd place
for them to live. Since they make sense only in relation with RSA,
simply move them to lib/rsa where it makes more sense for them to
reside.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The changes here are that we need to ensure python setuptools are
in our build virtual environments as they will no longer come in via
python even in a virtual environment. As part of this ensure setuptools
is in our cache and also include pytest-azurepipelines as we should have
been doing. Next, we move away from using apt-key directly and move that
stanza towards the rest of the apt work. This also lets us drop
directly installing gnupg2. These steps are not strictly required for
24.04 but will be for later releases and are valid now. Finally, we drop
the unused PTYHONPATH ENV line.
In order to use these containers however, we need to stop running the
event_dump test as the 'addr2line' tool provided by binutils no longer
is able to decode those specific events in most cases. As this is a
problem with binutils and present for some time now, disabling the test
until someone has time to work with upstream this seems reasonable.
Signed-off-by: Tom Rini <trini@konsulko.com>
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
Signed-off-by: Tom Rini <trini@konsulko.com>
Align the implementation to rsa_add_verify_data() by writing the modulus
and r-squared properties with the same length as the key itself. This
fixes signature verification issues when one of the parameters has
leading zeros.
Reported-by: Hans Gfirtner (Nokia) <hans.gfirtner@nokia.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This also incorporates the following commits to the Dockerfile:
da7942de29f7 Dockerfile: remove Python 2.7
183299d9a400 docker: add OP-TEE and TF-A build for testing Firmware Handoff
Signed-off-by: Tom Rini <trini@konsulko.com>
We don't use Python 2 anywhere. Remove the package from our Docker image.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Raymond Mao <raymond.mao@linaro.org> says:
This patch series enable Firmware Handoff [1] CI tests on qemu_arm64 by:
1. fetch MbedTLS (v3.6), OP-TEE (v4.7.0) and TF-A (v2.13.0);
2. build bl1 and fip with both Firmware Handoff and Measured Boot
enabled;
3. pytest to validate the Firmware Handoff feature via bloblist by
checking the existence of expected FDT nodes and TPM events generated
and handed over from TF-A/OP-TEE.
[1] https://github.com/FirmwareHandoff/firmware_handoff
Link: https://lore.kernel.org/r/20251021181703.598342-1-raymond.mao@linaro.org
Fetch OP-TEE (4.7.0), TF-A (v2.13.0), MbedTLS (v3.6) and build
bl1 and fip with both Firmware Handoff and Measured Boot enabled.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Commit 65e2c14d5a5a ("binman: btool: mkimage: use Bintool.version")
removed the version argument from the run method but forgot to remove it
from the method docstring, so let's fix this oversight.
Fixes: 65e2c14d5a5a ("binman: btool: mkimage: use Bintool.version")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Change the formatting of binman.rst so that the compiled HTML output
becomes more readable. Changes include enumerations and the escaping of
arguments starting with a double dash (e.g. --debug).
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
When importing data, the data-offset property is removed and the data
content is imported inside the data property of the node.
When mkimage is run twice on the same FIT, data-size property is already
set in the second run, from the first run (via the fit_export_data
function). If we don't remove the data-size property, nothing guarantees
it matches the actual size of data within the data property. To avoid
possible mistakes when handling the data property, let's simply remove
the data-size property as well.
This also fixes an ordering issue of the data-size and data-offset
properties in FIT when comparing the FIT after one run of mkimage and a
second run. This is due to fit_export_data setting data-offset property
first (it doesn't exist so it's added) and then data-size (it doesn't
exist so it's added) for the first run, while it sets data-offset
property first (removed in fit_import_data, so it doesn't exist so it's
added) and then data-size (it exists already from the first run, so it's
simply modified) for the second run.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
All explicit calls to fdt_setprop* in tools/ are checked except those
three. Let's add a check for the return code of fdt_setprop_u32() calls.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The return code of fdt_setprop is overwritten by the one from
fdt_delprop meaning we could very well have an issue when setting the
property that would be ignored if the deletion of the property that
comes right after passes.
Let's add a separate check for each.
Fixes: 4860ee9b09e0 ("mkimage: allow internalization of data-position")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Add missing help text for the -y and -Y parameters of mkimage.
Fixes: 6dfd14e1228e ("mkimage: Add support for bundling TFA BL31 in mkimage -f auto")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This reverts commit 4d84fa1261eb27d57687f2e4c404a78b8653c183, reversing
changes made to b82a1fa7ddc7f3be2f3b75898d5dc44c34420bdd.
I had missed some feedback on this series from earlier, and we have
since had reports of regressions due to this as well. For now, revert
this.
Signed-off-by: Tom Rini <trini@konsulko.com>
Aristo Chen <jj251510319013@gmail.com> says:
This patch series enhances FIT image robustness by adding **memory
region overlap detection** to `mkimage` and fixing existing overlaps
in DTS files and `binman` tests.
The primary goal is to prevent runtime memory corruption from
conflicting load addresses in FIT images.
Key Changes:
1. `mkimage` Overlap Detection: A new validation in
`tools/fit_image.c` checks for overlapping load addresses
within FIT configurations. `mkimage` now errors out with
detailed info on conflicts, preventing bad FIT image creation.
2. New Test Case: A Python test verifies the new detection.
It intentionally creates an overlap (kernel and FDT)
to confirm correct error handling.
3. Fixes for Existing Overlaps:
* Board DTS (k3-am6xx): Adjusted load addresses for TI
firmware stubs to prevent conflicts. This resolves
previously undetected overlaps.
* `binman` Tests: Fixed several tests. U-Boot load
addresses were shifted to avoid ATF conflicts. A new
linker script for TEE ELF sections ensures distinct
memory layouts.
4. Documentation: Added guidance for developers on how to
determine ELF load addresses using readelf, linker scripts,
and objdump when working with binman FIT images.
Impact:
This series improves FIT image reliability by catching overlaps
at build time, helping developers resolve issues before runtime
failures.
Link: https://lore.kernel.org/r/20250914110021.4103-1-aristo.chen@canonical.com
Add documentation to help users understand how to determine where ELF
files will be loaded when using binman's 'fit,load' property. This
addresses the common confusion about how load addresses are determined
from ELF files.
The documentation explains three methods:
1. Using readelf to examine program headers
2. Checking the linker script (.lds file)
3. Using objdump to see section addresses
Also includes a specific example from binman tests showing how
elf_sections.lds sets ATF load address to 0x00000010 and
elf_sections_tee.lds sets TEE load address to 0x00100010 to avoid
memory overlap conflicts.
This helps users debug memory layout conflicts more efficiently when
working with FIT images containing multiple ELF components.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
This patch adds a validation step in mkimage to detect memory region
overlaps between images specified in the same configuration of a
FIT image. If any overlaps are found, the tool prints an error and
aborts the build.
This helps prevent runtime memory corruption caused by conflicting
load addresses between images.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Fix one binman test that has memory region overlap issue, the test case
needed to be updated to use non-overlapping memory layouts.
* Tests fixed:
- testFitSplitElf
* Changes made:
1. ELF section layouts: added elf_sections_tee.lds with different
address for TEE to avoid overlap with ATF address defined in
elf_sections.lds
2. Makefile to properly build elf_sections_tee binary
3. Updat ftest.py to use separate ELF files for TEE vs ATF components
in split-elf operations.
An upcoming commit will validate if the memory region is overlapped
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Fix three binman tests that has memory region overlap issue, the test
cases needed to be updated to use non-overlapping memory layouts.
* Tests fixed:
- testFitFirmwareLoadables
- testFitSignSimple
- testFitSignNoSignatureNodes
* Changes made:
Updated DTB test files to change U-Boot load addresses from 0x0 to
0x2000 to avoid overlapping with ATF in the 0x10-0xfc range:
- 276_fit_firmware_loadables.dts
- 340_fit_signature.dts
- 342_fit_signature.dts
An upcoming commit will validate if the memory region is overlapped
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
To support passing specific commands defined in enum imx8image_cmd to
the imx8image_copy_image() function, this patch introduces a new entry
type nxp-imx9image. This entry generates a plain text data file
containing the relevant commands, enabling flexible configuration during
image creation.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Javier Tia <javier.tia@linaro.org> says:
This patch series modernizes U-Boot's code formatting infrastructure by
with current Linux kernel practices and providing a more robust and
comprehensive formatting solution.
Link: https://lore.kernel.org/r/20250905205349.127333-1-javier.tia@linaro.org
Replace the use of scripts/Lindent with clang-format in
zynqmp_psu_init_minimize.sh. This change is made to align with the rest
of the codebase that uses clang-format for code formatting. This ensures
consistency across all scripts in terms of code style and formatting.
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Javier Tia <javier.tia@linaro.org>
Introduce two new parameters to be used with mkimage -f auto to bundle
TFA BL31 image into fitImage, using auto-generated fitImage. Add -y to
specify TFA BL31 file name and -Y to specify TFA BL31 load and entry
point address. This is meant to be used with systems which boot all of
TFA BL31, Linux and its DT from a single fitImage, all booted by U-Boot.
Example invocation:
"
$ mkimage -E -A arm64 -C none -e 0x50200000 -a 0x50200000 -f auto \
-d arch/arm64/boot/Image \
-b arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dtb \
-y ../tfa/build/rcar_gen4/release/bl31.bin -Y 0x46400000 \
/path/to/output/fitImage
"
Documentation update and test are also included, the test validates
both positive and negative test cases, where fitImage does not include
TFA BL31 and does include TFA BL31 blobs.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This cannot work (unless qemu-user is registered in binfmt_misc) as the
tools will be for a different architecture.
Fixes "make cross_tools" in case CONFIG_VIDEO_LOGO is enabled.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
