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/rkspi.c

110 lines
2.4 KiB

/*
* (C) Copyright 2015 Google, Inc
* Written by Simon Glass <sjg@chromium.org>
*
* SPDX-License-Identifier: GPL-2.0+
*
* See README.rockchip for details of the rkspi format
*/
#include "imagetool.h"
#include <image.h>
#include <rc4.h>
#include "mkimage.h"
#include "rkcommon.h"
enum {
RKSPI_SECT_LEN = RK_BLK_SIZE * 4,
};
static int rkspi_verify_header(unsigned char *buf, int size,
struct image_tool_params *params)
{
return 0;
}
static void rkspi_print_header(const void *buf)
{
}
static void rkspi_set_header(void *buf, struct stat *sbuf, int ifd,
struct image_tool_params *params)
{
int sector;
unsigned int size;
int ret;
size = params->orig_file_size;
ret = rkcommon_set_header(buf, size, params);
debug("size %x\n", size);
if (ret) {
/* TODO(sjg@chromium.org): This method should return an error */
printf("Warning: SPL image is too large (size %#x) and will not boot\n",
size);
}
/*
* Spread the image out so we only use the first 2KB of each 4KB
* region. This is a feature of the SPI format required by the Rockchip
* boot ROM. Its rationale is unknown.
*/
for (sector = size / RKSPI_SECT_LEN - 1; sector >= 0; sector--) {
debug("sector %u\n", sector);
memmove(buf + sector * RKSPI_SECT_LEN * 2,
buf + sector * RKSPI_SECT_LEN,
RKSPI_SECT_LEN);
memset(buf + sector * RKSPI_SECT_LEN * 2 + RKSPI_SECT_LEN,
'\0', RKSPI_SECT_LEN);
}
}
static int rkspi_extract_subimage(void *buf, struct image_tool_params *params)
{
return 0;
}
static int rkspi_check_image_type(uint8_t type)
{
if (type == IH_TYPE_RKSPI)
return EXIT_SUCCESS;
else
return EXIT_FAILURE;
}
/* We pad the file out to a fixed size - this method returns that size */
static int rkspi_vrec_header(struct image_tool_params *params,
struct image_type_params *tparams)
{
int pad_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(params, tparams);
pad_size = ROUND(rkcommon_get_spl_size(params), 0x800);
params->orig_file_size = pad_size;
/* We will double the image size due to the SPI format */
pad_size += RK_SPL_HDR_START;
pad_size *= 2;
debug("pad_size %x\n", pad_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
return pad_size - params->file_size - tparams->header_size;
}
/*
* rk_spi parameters
*/
U_BOOT_IMAGE_TYPE(
rkspi,
"Rockchip SPI Boot Image support",
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
0,
NULL,
rkcommon_check_params,
rkspi_verify_header,
rkspi_print_header,
rkspi_set_header,
rkspi_extract_subimage,
rkspi_check_image_type,
NULL,
rkspi_vrec_header
);