03 Dec, 2019

1 commit


08 Oct, 2019

3 commits

  • The default CSF_SIZE defined in Kconfig is too high and SPL cannot
    fit into the OCRAM in certain cases.

    The CSF cannot achieve 0x2000 length when using RSA 4K key which is
    the largest key size supported by HABv4.

    According to AN12056 "Encrypted Boot on HABv4 and CAAM Enabled Devices"
    it's recommended to pad CSF binary to 0x2000 and append DEK blob to
    deploy encrypted boot images.

    As the maximum DEK blob size is 0x58 we can reduce CSF_SIZE to 0x2060
    which should cover both CSF and DEK blob length.

    Update default_image.c and image.c to align with this change and avoid
    a U-Boot proper authentication failure in HAB closed devices:

    Authenticate image from DDR location 0x877fffc0...
    bad magic magic=0x32 length=0x6131 version=0x38
    bad length magic=0x32 length=0x6131 version=0x38
    bad version magic=0x32 length=0x6131 version=0x38
    spl: ERROR: image authentication fail

    Fixes: 96d27fb218 (Revert "habv4: tools: Avoid hardcoded CSF size for SPL targets")

    Reported-by: Jagan Teki
    Signed-off-by: Breno Lima

    Breno Matheus Lima
     
  • This reverts commit 62a52f3f85bf33e286632e99f0d39b2c166af0c4.

    Stefano Babic
     
  • Currently it's not possible to authenticate the U-Boot proper of
    mx6ul_14x14_evk_defconfig target:

    Authenticate image from DDR location 0x877fffc0...
    bad magic magic=0x0 length=0x00 version=0x3
    bad length magic=0x0 length=0x00 version=0x3
    bad version magic=0x0 length=0x00 version=0x3
    spl: ERROR: image authentication fail

    Commit 0633e134784a ("imx: hab: Increase CSF_SIZE for i.MX6 and
    i.MX7 devices") has increased CSF_SIZE to avoid a possible issue
    when booting encrypted boot images.

    Commit d21bd69b6e95 ("tools: mkimage: add firmware-ivt image type
    for HAB verification") is hardcoding the CSF and IVT sizes, the
    new CSF size is not being considered and u-boot-ivt.img fails to
    boot.

    Avoid hardcoded CSF and IVT size to fix this issue.

    Signed-off-by: Breno Lima
    Reviewed-by: Fabio Estevam

    Breno Matheus Lima
     

11 Jul, 2018

1 commit


07 May, 2018

1 commit

  • 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

    Tom Rini
     

20 Mar, 2018

1 commit

  • This patch adds a new type IH_OS_TEE. This new OS type will be used for
    chain-loading to Linux via a TEE.

    With this patch in-place you can generate a bootable OPTEE image like this:

    mkimage -A arm -T kernel -O tee -C none -d tee.bin uTee.optee

    where "tee.bin" is the input binary prefixed with an OPTEE header and
    uTee.optee is the output prefixed with a u-boot wrapper header.

    This image type "-T kernel -O tee" is differentiated from the existing
    IH_TYPE_TEE "-T tee" in that the IH_TYPE is installed by u-boot (flow
    control returns to u-boot) whereas for the new IH_OS_TEE control passes to
    the OPTEE firmware and the firmware chainloads onto Linux.

    Andrew Davis gave the following ASCII diagram:

    IH_OS_TEE: (mkimage -T kernel -O tee)
    Non-Secure Secure

    BootROM
    |
    -------------
    |
    v
    SPL
    |
    v
    U-Boot ------>


    Suggested-by: Andrew F. Davis
    Cc: Harinarayan Bhatta
    Cc: Andrew F. Davis
    Cc: Tom Rini
    Cc: Kever Yang
    Cc: Philipp Tomsich
    Cc: Peng Fan
    Link: http://mrvan.github.io/optee-imx6ul

    Bryan O'Donoghue
     

03 Jan, 2017

1 commit

  • When we want to use Secure Boot with HAB from SPL over U-Boot.img,
    we need to append the IVT to the image and leave space for the CSF.
    Images generated as firmware_ivt can directly be signed using the
    Freescale code signing tool. For creation of a CSF, mkimage outputs
    the correct HAB Blocks for the image.
    The changes to the usual firmware image class are quite small,
    that is why I implemented that directly into the default_image.

    Cc: sbabic@denx.de

    v2-Changes: None

    Signed-off-by: Sven Ebenfeld
    Reviewed-by: George McCollister
    Tested-by: George McCollister

    Sven Ebenfeld
     

25 Jun, 2016

1 commit

  • Embedding timestamps in FIT images results in unreproducible builds
    for targets that generate a fit image, such as dra7xx_evm.

    This patch uses the SOURCE_DATE_EPOCH environment variable, when set,
    to use specified value for the date.

    Thanks to HW42 for debugging the issue and providing the patch:

    https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20160606/005722.html

    For more information about reproducible builds and the
    SOURCE_DATE_EPOCH specification:

    https://reproducible-builds.org/specs/source-date-epoch/
    https://reproducible-builds.org/

    Signed-off-by: Vagrant Cascadian
    Reviewed-by: Simon Glass

    Vagrant Cascadian
     

12 Oct, 2015

1 commit


28 Jul, 2015

1 commit

  • In order to achieve reproducible builds in U-Boot, timestamps that are defined
    at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment
    variable allows setting a fixed value for those timestamps.

    Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be
    built reproducibly. This is the case for e.g. sunxi devices.

    However, some other devices might need some more tweaks, especially regarding
    the image generation tools.

    Signed-off-by: Paul Kocialkowski

    Paul Kocialkowski
     

30 Jan, 2015

4 commits


13 Dec, 2013

2 commits

  • Given a multi-file image created through the mkimage's -d option:

    $ mkimage -A x86 -O linux -T multi -n x86 -d vmlinuz:initrd.img:System.map \
    multi.img

    Image Name: x86
    Created: Thu Jul 25 10:29:13 2013
    Image Type: Intel x86 Linux Multi-File Image (gzip compressed)
    Data Size: 13722956 Bytes = 13401.32 kB = 13.09 MB
    Load Address: 00000000
    Entry Point: 00000000
    Contents:
    Image 0: 4040128 Bytes = 3945.44 kB = 3.85 MB
    Image 1: 7991719 Bytes = 7804.41 kB = 7.62 MB
    Image 2: 1691092 Bytes = 1651.46 kB = 1.61 MB

    It is possible to perform the innverse operation -- extracting any file from
    the image -- by using the dumpimage's -i option:

    $ dumpimage -i multi.img -p 2 System.map

    Although it's feasible to retrieve "data files" from image through scripting,
    the requirement to embed tools such 'dd', 'awk' and 'sed' for this sole purpose
    is cumbersome and unreliable -- once you must keep track of file sizes inside
    the image. Furthermore, extracting data files using "dumpimage" tool is faster
    than through scripting.

    Signed-off-by: Guilherme Maciel Ferreira
    Signed-off-by: Simon Glass

    Guilherme Maciel Ferreira
     
  • In order to avoid duplicating code and keep only one point of modification,
    the functions, structs and defines useful for "dumpimage" were moved from
    "mkimage" to a common module called "imagetool".

    This modification also weakens the coupling between image types (FIT, IMX, MXS,
    and so on) and image tools (mkimage and dumpimage). Any tool may initialize the
    "imagetool" through register_image_tool() function, while the image types
    register themselves within an image tool using the register_image_type()
    function:

    +---------------+
    +------| fit_image |
    +--------------+ +-----------+ | +---------------+
    | mkimage |--------> | | | |
    Signed-off-by: Simon Glass

    Guilherme Maciel Ferreira
     

24 Jul, 2013

1 commit


01 Dec, 2011

1 commit

  • The legacy uImage format includes an absolute load and entry-point
    address. When bootm operates on a kernel uImage in memory that isn't
    loaded at the address in the image's load address, U-Boot will copy
    the image to its address in the header.

    Some kernel images can actually be loaded and used at any arbitrary
    address. An example is an ARM Linux kernel zImage file. To represent
    this capability, IH_TYPE_KERNEL_NOLOAD is implemented, which operates
    just like IH_TYPE_KERNEL, except that the load address header is
    ignored, and U-Boot does not copy the image to its load address, but
    rather uses it in-place.

    This is useful when sharing a single (uImage-wrapped) zImage across
    multiple boards with different memory layouts; in this case, a specific
    load address need not be picked when creating the uImage, but instead
    is selected by the board-specific U-Boot environment used to load and
    boot that image.

    v2: Rename from IH_TYPE_KERNEL_ANYLOAD to IH_TYPE_KERNEL_NOLOAD.

    Signed-off-by: Stephen Warren
    Signed-off-by: Stefan Roese

    Stephen Warren
     

22 Oct, 2011

1 commit

  • This avoids the following checkpatch warning in later patches:

    ERROR: "(foo*)" should be "(foo *)"
    ERROR: space required before the open brace '{'
    ERROR: space prohibited before that close parenthesis ')'
    ERROR: spaces required around that '||' (ctx:WxV)
    WARNING: space prohibited between function name and open parenthesis '('
    WARNING: line over 80 characters

    This fixes all the white-space warnings/errors in my subsequent patch,
    and within this current patch. A number of other checkpatch warnings
    and errors are still present in this patch itself, but are beyond simple
    whitespace fixes, so are not solved by this patch.

    v2: New patch

    Signed-off-by: Stephen Warren
    Tested-by: Simon Glass
    Tested-by: Simon Glass

    Stephen Warren
     

11 Sep, 2009

1 commit

  • This is a first step towards reorganizing the mkimage code to make it
    easier to add support for additional images types. Current mkimage
    code is specific to generating uImage and FIT image files, but the
    same framework can be used to generate other image types like
    Kirkwood boot images (kwbimage-TBD). For this, the mkimage code gets
    reworked:

    Here is the brief plan for the same:-
    a) Split mkimage code into core and image specific support
    b) Implement callback functions for image specific code
    c) Move image type specific code to respective C files
    Currently there are two types of file generation/list
    supported (i.e uImage, FIT), the code is abstracted from
    mkimage.c/.h and put in default_image.c and fit_image.c;
    all code in these file is static except init function call
    d) mkimage_register API is added to add new image type support
    All above is addressed in this patch
    e) Add kwbimage type support to this new framework (TBD)
    This will be implemented in a following commit.

    Signed-off-by: Prafulla Wadaskar
    Edit commit message, fix coding style and typos.
    Signed-off-by: Wolfgang Denk

    Prafulla Wadaskar