22 Nov, 2017

2 commits


01 Oct, 2017

1 commit


13 Aug, 2017

1 commit


11 Jul, 2017

1 commit


23 Jun, 2017

2 commits


12 Jun, 2017

1 commit

  • Assigning a variable to itself is not necessary. Drop this and also add a
    check for malloc() failure.

    Signed-off-by: Simon Glass
    Reported-by: Coverity (CID: 161418)
    Fixes: 111bcc4 (rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399)

    Simon Glass
     

07 Jun, 2017

3 commits

  • Add support to mkimage for rv1108 soc, the max
    spl code size for rv1108 is 6kb, and the spl
    code should be packed by rksd, wether boot from
    emmc or spi nor flash.

    Signed-off-by: Andy Yan
    Reviewed-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Andy Yan
     
  • This change restores the earlier setting of init_boot_size to include
    the maximum area covered by the the boot ROM of each chip for resolve
    issues with back-to-bootrom functionality reported by Kever and Heiko.

    To ensure that we don't run into the same issue again in the future,
    I have updated the comments accordingly and added a reference to the
    mailing list archive (there's some very helpful info from Andy Yan
    that provides background on the BootROM requirements regarding these
    fields).

    See https://lists.denx.de/pipermail/u-boot/2017-May/293267.html for
    some background (by Andy Yan) of how the BootROM processes this field.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass

    Philipp Tomsich
     
  • The rockchip image generation was previously missing the ability to
    verify the generated header (and dump the image-type) without having
    to resort to hexdump or od. Experience in our testing has showed it
    to be very easy to get the rkspi and rksd images mixed up and the
    lab... so we add the necessary support to have dumpimage tell us
    what image type we're dealing with.

    This change set adds the verify_header and print_header capability
    to the rksd/rkspi image drivers (through shared code in rkcommon).

    As of now, we only support images fully that are not RC4-encoded for
    the SPL payload (i.e. header1 and payload). For RC4-encoded payloads,
    the outer header (header0) is checked, but no detection of whether
    this is a SD/MMC or SPI formatted payload takes place.

    The output of dumpsys now prints the image type (spl_hdr), whether it
    is a SD/MMC or SPI image, and the (padded) size of the image:
    $ ./tools/dumpimage -l ./spl.img
    Image Type: Rockchip RK33 (SD/MMC) boot image
    ^^^^^^ SD/MMC vs. SPI indication
    ^^^^ spl_hdr indicated by the image
    Data Size: 79872 bytes

    Signed-off-by: Philipp Tomsich
    Acked-by: Simon Glass

    Philipp Tomsich
     

11 May, 2017

5 commits

  • Dumpimage (it invoked with "-T rkspi" or "-T rksd") would not work due
    to check_params failing. These changes ensure that we can both be called
    with an empty imagename.

    Signed-off-by: Philipp Tomsich
    Acked-by: Simon Glass

    Philipp Tomsich
     
  • This change set adds documentation to the header0 initialisation and
    improves readability for the calculations of various offsets/lengths.

    As the U-Boot SPL stage doesn't use any payload beyond what is covered
    by init_size, we no longer add RK_MAX_BOOT_SIZE to init_boot_size.

    Signed-off-by: Philipp Tomsich
    Acked-by: Simon Glass

    Philipp Tomsich
     
  • The calculation of the variable header size in rkcommon_vrec_header
    had been update twice in the earlier series (introducing boot0-style
    images to deal with the alignment of the first instruction in 64bit
    binaries). Unfortunately, I didn't update the comment twice (so it
    remained out-of-date).

    This change brings the comment back in-sync with what the code is
    doing.

    Signed-off-by: Philipp Tomsich
    Acked-by: Simon Glass

    Philipp Tomsich
     
  • In (first) breaking and (then) fixing the rkspi tool, I realised that
    the calculation of the required padding (for the header-size and the
    2K-in-every-4K SPI layout) was not as self-explainatory as it could
    have been. This change rewrites the code (using new, common functions
    in rkcommon.c) and adds verbose in-line comments to ensure that we
    won't fall into the same pit in the future...

    Tested on the RK3399 (with has a boot0-style payload) with SD/MMC and SPI.

    Signed-off-by: Philipp Tomsich
    Acked-by: Simon Glass

    Philipp Tomsich
     
  • Add support for rk3328 package header in mkimage tool.

    Signed-off-by: Kever Yang
    Reviewed-by: Simon Glass

    Kever Yang
     

28 Apr, 2017

1 commit


05 Apr, 2017

2 commits

  • To simplify the creation of AArch64 SPL images for the RK3399, we
    use the ENABLE_ARM_SOC_BOOT0_HOOK option and prepend 4 bytes of
    padding at the start of the text section. This makes it easy for
    mkimage to rewrite this word with the 'RK33' boot magic.

    This change brings logic to calculate the header size and allocate
    the header back in sync. For the RK3399 we now limit the header to
    before the payload (i.e. the 'header0' and the padding up to the
    actual image) and overwrite the first word (inserted by the
    boot0-hook for this purpose) with the 'RK33' magic in-place.

    X-AffectedPlatforms: RK3399-Q7
    Signed-off-by: Philipp Tomsich
    Tested-by: Klaus Goger

    Philipp Tomsich
     
  • The RK3399 boot code (running as AArch64) poses a bit of a challenge
    for SPL image generation:
    * The BootROM will start execution right after the 4-byte header (at
    the odd instruction word loaded into SRAM at 0xff8c2004, with the
    'RK33' boot magic residing at 0xff8c2000).
    * The default padding (during ELF generation) for AArch64 is 0x0,
    which is an illegal instruction and the .text section needs to be
    naturally aligned (someone might locate a 64bit constant relative
    to the section start and unaligned loads trigger a fault for all
    privileged modes of an ARMv8)... so we can't simply define the
    CONFIG_SPL_TEXT_BASE option to the odd address (0xff8c2004).
    * Finally, we don't want to change the values used for padding of
    the SPL .text section for all ARMv8 targets to the instruction
    word encoding 'nop', as this would affect all padding in this
    section and might hide errors that would otherwise quickly trigger
    an illegal insn exception.

    To deal with this situation, we modify the rkimage generation to
    - understand the fact that the RK3399 needs to pad the header to an
    8 byte boundary using an AArch64 'nop'
    - the necessary logic to adjust the header_size (which controls the
    location where the payload is copied into the image) and to insert
    this padding (AArch64 insn words are always little-endian) into
    the image following the 4-byte header magic.

    X-AffectedPlatforms: RK3399-Q7
    Signed-off-by: Philipp Tomsich
    Tested-by: Klaus Goger

    Philipp Tomsich
     

17 Mar, 2017

2 commits


26 Jul, 2016

2 commits


14 Dec, 2015

2 commits


01 Dec, 2015

2 commits

  • The Rockchip boot ROM could load & run an initial spl loader,
    and continue to load a second level boot-loader(which stored
    right after the initial loader) when it returns.
    Modify idblock generation code to support it.

    Signed-off-by: Jeffy Chen
    Acked-by: Simon Glass

    Jeffy Chen
     
  • Our chips may have different max spl size and spl header, so
    we need to add configs for that.

    Signed-off-by: Jeffy Chen
    Acked-by: Simon Glass
    Dropped CONFIG_ROCKCHIP_MAX_SPL_SIZE from rk3288_common.h,
    Added $(if...) to tools/Makefile to fix widespread build breakage
    Signed-off-by: Simon Glass

    Series-changes: 8
    - Drop CONFIG_ROCKCHIP_MAX_SPL_SIZE from rk3288_common.h,
    - Add $(if...) to tools/Makefile to fix widespread build breakage

    Jeffy Chen
     

03 Sep, 2015

1 commit