upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
u-boot/tools/rkcommon.h

116 lines
3.6 KiB

/* SPDX-License-Identifier: GPL-2.0+ */
/*
* (C) Copyright 2015 Google, Inc
* Written by Simon Glass <sjg@chromium.org>
*/
#ifndef _RKCOMMON_H
#define _RKCOMMON_H
enum {
RK_BLK_SIZE = 512,
RK_INIT_SIZE_ALIGN = 2048,
RK_INIT_OFFSET = 4,
RK_MAX_BOOT_SIZE = 512 << 10,
RK_SPL_HDR_START = RK_INIT_OFFSET * RK_BLK_SIZE,
RK_SPL_HDR_SIZE = 4,
RK_SPL_START = RK_SPL_HDR_START + RK_SPL_HDR_SIZE,
RK_IMAGE_HEADER_LEN = RK_SPL_START,
};
/**
* rkcommon_check_params() - check params
*
* @return 0 if OK, -1 if ERROR.
*/
int rkcommon_check_params(struct image_tool_params *params);
/**
* rkcommon_get_spl_hdr() - get 4-bytes spl hdr for a Rockchip boot image
*
* Rockchip's bootrom requires the spl loader to start with a 4-bytes
* header. The content of this header depends on the chip type.
*/
const char *rkcommon_get_spl_hdr(struct image_tool_params *params);
/**
* rkcommon_get_spl_size() - get spl size for a Rockchip boot image
*
* Different chip may have different sram size. And if we want to jump
* back to the bootrom after spl, we may need to reserve some sram space
* for the bootrom.
* The spl loader size should be sram size minus reserved size(if needed)
*/
int rkcommon_get_spl_size(struct image_tool_params *params);
/**
* rkcommon_set_header() - set up the header for a Rockchip boot image
*
* This sets up a 2KB header which can be interpreted by the Rockchip boot ROM.
*
* @buf: Pointer to header place (must be at least 2KB in size)
* @file_size: Size of the file we want the boot ROM to load, in bytes
* @return 0 if OK, -ENOSPC if too large
*/
int rkcommon_set_header(void *buf, uint file_size,
struct image_tool_params *params);
/**
* rkcommon_verify_header() - verify the header for a Rockchip boot image
*
* @buf: Pointer to the image file
* @file_size: Size of entire bootable image file (incl. all padding)
* @return 0 if OK
*/
int rkcommon_verify_header(unsigned char *buf, int size,
struct image_tool_params *params);
/**
* rkcommon_print_header() - print the header for a Rockchip boot image
*
* This prints the header, spl_name and whether this is a SD/MMC or SPI image.
*
* @buf: Pointer to the image (can be a read-only file-mapping)
*/
void rkcommon_print_header(const void *buf);
/**
* rkcommon_need_rc4_spl() - check if rc4 encoded spl is required
*
* Some socs cannot disable the rc4-encryption of the spl binary.
* rc4 encryption is disabled normally except on socs that cannot
* handle unencrypted binaries.
* @return true or false depending on rc4 being required.
*/
bool rkcommon_need_rc4_spl(struct image_tool_params *params);
/**
* rkcommon_rc4_encode_spl() - encode the spl binary
*
* Encrypts the SPL binary using the generic rc4 key as required
* by some socs.
*
* @buf: Pointer to the SPL data (header and SPL binary)
* @offset: offset inside buf to start at
* @size: number of bytes to encode
*/
void rkcommon_rc4_encode_spl(void *buf, unsigned int offset, unsigned int size);
rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399 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 <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
7 years ago
/**
* rkcommon_vrec_header() - allocate memory for the header
*
* @params: Pointer to the tool params structure
* @tparams: Pointer tot the image type structure (for setting
* the header and header_size)
* @alignment: Alignment (a power of two) that the image should be
* padded to (e.g. 512 if we want to align with SD/MMC
* blocksizes or 2048 for the SPI format)
*
* @return bytes of padding required/added (does not include the header_size)
rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399 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 <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
7 years ago
*/
int rkcommon_vrec_header(struct image_tool_params *params,
struct image_type_params *tparams,
unsigned int alignment);
rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399 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 <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
7 years ago
#endif