Prepare v2023.07-rc6

-----BEGIN PGP SIGNATURE-----
 
 iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmSjExsACgkQFHw5/5Y0
 tywJ3gwAsTbr9mCmCzaKs2F/Jh6H47WEUMEz96wE8eXwuS57pfNJhml4v2rEhYpQ
 MlBjz6vTOyHDrtinRlvempJWVZEuoflMb6M2OTqVFqZPuPT3cLLuSdM4pgb5SdKS
 jNDWcxr12LqiDS0Mz+QOHdps3H8mzsCnOXeOTT+VaSeYHPOLQ+M9OV2o/aY2BsNi
 JLAGX+8i7FuZnVYZzSv6PQYYGZZV+Kvl5oLlPPJttsA7bGu4m2k8zRQQdzd+PIbu
 owAh3CHSKCy1g+y7ASn1Nd2VE06huvqGG7Qo2sj+Ypf/wbNy16qbMc2C7HDwDcul
 nrnf6BZ+MTelwxyPHBOR52ERgY6H8rgpvsCNL0arxaCHJOVddXtrUY1591vE71aB
 nGxhnyLnHwOXXdDGsPsR7p4SF16e6RzaINKmDorQ37nidRnTFLlFCxidnR8ztscR
 aUpLraqYUquGJf7lejYX2OZg2f36lvpYKy1lwuJfd9fUSgK8iyUKrE9wOJhWnTK8
 cIOnS/A+
 =DNor
 -----END PGP SIGNATURE-----

Merge tag 'v2023.07-rc6' into next

Prepare v2023.07-rc6

.azure-pipelines.yml

@@ -492,7 +492,7 @@ stages:
         nxp_ls101x:
           BUILDMAN: "freescale&ls101"
         nxp_ls102x:
-          BUILDMAN: "freescale&ls102"
+          BUILDMAN: "freescale&ls102 -x keymile"
         nxp_ls104x:
           BUILDMAN: "freescale&ls104"
         nxp_ls108x:
@@ -507,6 +507,8 @@ stages:
           BUILDMAN: "mx -x mx6,imx8,freescale,technexion,toradex"
         imx8_imx9:
           BUILDMAN: "imx8 imx9"
+        keymile:
+          BUILDMAN: "keymile"
         keystone2_keystone3:
           BUILDMAN: "k2 k3"
         sandbox_asan:
@@ -548,7 +550,7 @@ stages:
         mips:
           BUILDMAN: "mips"
         powerpc:
-          BUILDMAN: "powerpc"
+          BUILDMAN: "powerpc -x keymile"
         siemens:
           BUILDMAN: "siemens"
         tegra:

Makefile

@@ -3,7 +3,7 @@
 VERSION = 2023
 PATCHLEVEL = 07
 SUBLEVEL =
-EXTRAVERSION = -rc4
+EXTRAVERSION = -rc6
 NAME =
 
 # *DOCUMENTATION*
@@ -2164,7 +2164,7 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h \
 	       mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
 	       itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
 	       mkimage.rom.mkimage rom.map simple-bin.map simple-bin-spi.map \
-	       idbloader-spi.img
+	       idbloader-spi.img lib/efi_loader/helloworld_efi.S
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl \

arch/arm/cpu/arm11/cpu.c

@@ -20,6 +20,7 @@
 #include <irq_func.h>
 #include <asm/cache.h>
 #include <asm/system.h>
+#include <asm/arm11.h>
 
 static void cache_flush(void);
 
@@ -43,6 +44,11 @@ int cleanup_before_linux (void)
 	return 0;
 }
 
+void allow_unaligned(void)
+{
+	arm11_arch_cp15_allow_unaligned();
+}
+
 static void cache_flush(void)
 {
 	unsigned long i = 0;

arch/arm/cpu/arm11/sctlr.S

@@ -8,7 +8,7 @@
 #include <linux/linkage.h>
 
 /*
- * void allow_unaligned(void) - allow unaligned access
+ * void arm11_arch_cp15_allow_unaligned(void) - allow unaligned access
  *
  * This routine sets the enable unaligned data support flag and clears the
  * aligned flag in the system control register.
@@ -16,10 +16,10 @@
  * data abort or undefined behavior but is handled by the CPU.
  * For details see the "ARM Architecture Reference Manual" for ARMv6.
  */
-ENTRY(allow_unaligned)
+ENTRY(arm11_arch_cp15_allow_unaligned)
 	mrc	p15, 0, r0, c1, c0, 0	@ load system control register
 	orr	r0, r0, #1 << 22	@ set unaligned data support flag
 	bic	r0, r0, #2		@ clear aligned flag
 	mcr	p15, 0, r0, c1, c0, 0	@ write system control register
 	bx	lr			@ return
-ENDPROC(allow_unaligned)
+ENDPROC(arm11_arch_cp15_allow_unaligned)

arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds

@@ -36,6 +36,7 @@ SECTIONS
 	. = ALIGN(4);
 	__image_copy_end = .;
 	_end = .;
+	_image_binary_end = .;
 
 	.bss :
 	{

arch/arm/cpu/armv7/cpu.c

@@ -83,3 +83,8 @@ int cleanup_before_linux(void)
 {
 	return cleanup_before_linux_select(CBL_ALL);
 }
+
+void allow_unaligned(void)
+{
+	v7_arch_cp15_allow_unaligned();
+}

arch/arm/cpu/armv7/sctlr.S

@@ -8,15 +8,15 @@
 #include <linux/linkage.h>
 
 /*
- * void allow_unaligned(void) - allow unaligned access
+ * void v7_arch_cp15_allow_unaligned(void) - allow unaligned access
  *
  * This routine clears the aligned flag in the system control register.
  * After calling this routine unaligned access does no longer lead to a
  * data abort but is handled by the CPU.
  */
-ENTRY(allow_unaligned)
+ENTRY(v7_arch_cp15_allow_unaligned)
 	mrc	p15, 0, r0, c1, c0, 0	@ load system control register
 	bic	r0, r0, #2		@ clear aligned flag
 	mcr	p15, 0, r0, c1, c0, 0	@ write system control register
 	bx	lr			@ return
-ENDPROC(allow_unaligned)
+ENDPROC(v7_arch_cp15_allow_unaligned)

arch/arm/cpu/armv7/sunxi/u-boot-spl.lds

@@ -45,6 +45,7 @@ SECTIONS
 	. = ALIGN(4);
 	__image_copy_end = .;
 	_end = .;
+	_image_binary_end = .;
 
 	.bss :
 	{

arch/arm/dts/imx8mm-u-boot.dtsi

@@ -81,7 +81,9 @@
 
 		fit {
 			description = "Configuration to load ATF before U-Boot";
+#ifndef CONFIG_IMX_HAB
 			fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
+#endif
 			fit,fdt-list = "of-list";
 			#address-cells = <1>;
 

arch/arm/dts/imx8mn-u-boot.dtsi

@@ -145,7 +145,9 @@
 
 		fit {
 			description = "Configuration to load ATF before U-Boot";
+#ifndef CONFIG_IMX_HAB
 			fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
+#endif
 			fit,fdt-list = "of-list";
 			#address-cells = <1>;
 

arch/arm/dts/imx8mp-u-boot.dtsi

@@ -103,7 +103,9 @@
 
 		fit {
 			description = "Configuration to load ATF before U-Boot";
+#ifndef CONFIG_IMX_HAB
 			fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
+#endif
 			fit,fdt-list = "of-list";
 			#address-cells = <1>;
 

arch/arm/dts/imx8mq-u-boot.dtsi

@@ -97,7 +97,9 @@
 
 		fit {
 			description = "Configuration to load ATF before U-Boot";
+#ifndef CONFIG_IMX_HAB
 			fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
+#endif
 			#address-cells = <1>;
 
 			images {

arch/arm/include/asm/arm11.h

@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2023 Marek Vasut <marex@denx.de>
+ */
+#ifndef ARM11_H
+#define ARM11_H
+
+#ifndef __ASSEMBLY__
+void arm11_arch_cp15_allow_unaligned(void);
+#endif /* ! __ASSEMBLY__ */
+
+#endif	/* ARM11_H */

arch/arm/include/asm/armv7.h

@@ -156,6 +156,7 @@ void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
 				 u32 cpu_rev);
 void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
 			  u32 cpu_variant, u32 cpu_rev);
+void v7_arch_cp15_allow_unaligned(void);
 #endif /* ! __ASSEMBLY__ */
 
 #endif

arch/arm/mach-at91/armv7/cpu.c

@@ -24,7 +24,7 @@
 
 int arch_cpu_init(void)
 {
-#if defined(CONFIG_CLK_CCF)
+#if defined(CONFIG_CLK_CCF) || defined(CONFIG_CLK_SCMI)
 	return 0;
 #else
 	return at91_clock_init(CFG_SYS_AT91_MAIN_CLOCK);

arch/arm/mach-imx/cpu.c

@@ -510,3 +510,7 @@ char nxp_board_rev_string(void)
 	return (*rev + nxp_board_rev() - 1);
 }
 #endif
+
+__weak void reset_cpu(void)
+{
+}

arch/arm/mach-imx/hab.c

@@ -932,10 +932,10 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
 	printf("ivt entry = 0x%08x, dcd = 0x%08x, csf = 0x%08x\n", ivt->entry,
 	       ivt->dcd, ivt->csf);
 	puts("Dumping IVT\n");
-	print_buffer(ivt_addr, (void *)(ivt_addr), 4, 0x8, 0);
+	print_buffer(ivt_addr, (void *)(uintptr_t)(ivt_addr), 4, 0x8, 0);
 
 	puts("Dumping CSF Header\n");
-	print_buffer(ivt->csf, (void *)(ivt->csf), 4, 0x10, 0);
+	print_buffer(ivt->csf, (void *)(uintptr_t)(ivt->csf), 4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
 	get_hab_status();
@@ -944,7 +944,7 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
 	puts("\nCalling authenticate_image in ROM\n");
 	printf("\tivt_offset = 0x%x\n", ivt_offset);
 	printf("\tstart = 0x%08lx\n", start);
-	printf("\tbytes = 0x%x\n", bytes);
+	printf("\tbytes = 0x%lx\n", (ulong)bytes);
 #endif
 
 #ifndef CONFIG_ARM64

arch/arm/mach-imx/spl.c

@@ -20,6 +20,7 @@
 #include <asm/mach-imx/boot_mode.h>
 #include <g_dnl.h>
 #include <linux/libfdt.h>
+#include <memalign.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -315,36 +316,49 @@ ulong board_spl_fit_size_align(ulong size)
 	size = ALIGN(size, 0x1000);
 	size += CONFIG_CSF_SIZE;
 
+	if (size > CONFIG_SYS_BOOTM_LEN)
+		panic("spl: ERROR: image too big\n");
+
 	return size;
 }
-
-void board_spl_fit_post_load(const void *fit)
-{
-	u32 offset = ALIGN(fdt_totalsize(fit), 0x1000);
-
-	if (imx_hab_authenticate_image((uintptr_t)fit,
-				       offset + IVT_SIZE + CSF_PAD_SIZE,
-				       offset)) {
-		panic("spl: ERROR:  image authentication unsuccessful\n");
-	}
-}
 #endif
 
 void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
 {
-	int align_len = ARCH_DMA_MINALIGN - 1;
+#if defined(CONFIG_SPL_LOAD_FIT_ADDRESS)
-
+	return (void *)CONFIG_SPL_LOAD_FIT_ADDRESS;
-	/* Some devices like SDP, NOR, NAND, SPI are using bl_len =1, so their fit address
+#else
-	 * is different with SD/MMC, this cause mismatch with signed address. Thus, adjust
+	return (void *)(CONFIG_TEXT_BASE + CONFIG_SYS_BOOTM_LEN);
-	 * the bl_len to align with SD/MMC.
-	 */
-	if (bl_len < 512)
-		bl_len = 512;
-
-	return  (void *)((CONFIG_TEXT_BASE - fit_size - bl_len -
-			align_len) & ~align_len);
-}
 #endif
+}
+/*
+ * read the address where the IVT header must sit
+ * from IVT image header, loaded from SPL into
+ * an malloced buffer and copy the IVT header
+ * to this address
+ */
+void *spl_load_simple_fit_fix_load(const void *fit)
+{
+	struct ivt *ivt;
+	unsigned long offset;
+	unsigned long size;
+	u8 *tmp = (u8 *)fit;
+
+	offset = ALIGN(fdt_totalsize(fit), 0x1000);
+	size = ALIGN(fdt_totalsize(fit), 4);
+	size = board_spl_fit_size_align(size);
+	tmp += offset;
+	ivt = (struct ivt *)tmp;
+
+	debug("%s: ivt: %p offset: %lx size: %lx\n", __func__, ivt, offset, size);
+	debug("%s: ivt self: %x\n", __func__, ivt->self);
+
+	if (imx_hab_authenticate_image((uintptr_t)fit, (uintptr_t)ivt, offset))
+		panic("spl: ERROR: image authentication unsuccessful\n");
+
+	return (void *)fit;
+}
+#endif /* CONFIG_IMX_HAB */
 
 #if defined(CONFIG_MX6) && defined(CONFIG_SPL_OS_BOOT)
 int dram_init_banksize(void)
@@ -355,36 +369,3 @@ int dram_init_banksize(void)
 	return 0;
 }
 #endif
-
-/*
- * read the address where the IVT header must sit
- * from IVT image header, loaded from SPL into
- * an malloced buffer and copy the IVT header
- * to this address
- */
-void *spl_load_simple_fit_fix_load(const void *fit)
-{
-	struct ivt *ivt;
-	unsigned long new;
-	unsigned long offset;
-	unsigned long size;
-	u8 *tmp = (u8 *)fit;
-
-	offset = ALIGN(fdt_totalsize(fit), 0x1000);
-	size = ALIGN(fdt_totalsize(fit), 4);
-	size = board_spl_fit_size_align(size);
-	tmp += offset;
-	ivt = (struct ivt *)tmp;
-	if (ivt->hdr.magic != IVT_HEADER_MAGIC) {
-		debug("no IVT header found\n");
-		return (void *)fit;
-	}
-	debug("%s: ivt: %p offset: %lx size: %lx\n", __func__, ivt, offset, size);
-	debug("%s: ivt self: %x\n", __func__, ivt->self);
-	new = ivt->self;
-	new -= offset;
-	debug("%s: new %lx\n", __func__, new);
-	memcpy((void *)new, fit, size);
-
-	return (void *)new;
-}

arch/arm/mach-rockchip/rk3588/Kconfig

@@ -34,15 +34,15 @@ config TARGET_ROCK5B_RK3588
 	  4x ARM Cortex-A76, 4x ARM Cortex-A55
 	  4/8/16GB memory LPDDR4x
 	  Mali G610MC4 GPU
-	  MIPI CSI 2 multiple lanes connector
+	  2x MIPI CSI 2 multiple lanes connector
 	  eMMC module connector
 	  uSD slot (up to 128GB)
-	  2x USB 2.0, 2x USB 3.0
+	  2x USB 2.0 Type-A, 2x USB 3.0 Type-A, 1x USB 3.0 Type-C
-	  2x HDMI output, 1x HDMI input
+	  2x HDMI 2.1 output, 1x micro HDMI input
-	  Ethernet port
+	  2.5 Gbps Ethernet port
 	  40-pin IO header including UART, SPI, I2C and 5V DC power in
 	  USB PD over USB Type-C
-	  Size: 85mm x 54mm
+	  Size: 100mm x 72mm (Pico-ITX form factor)
 
 config ROCKCHIP_BOOT_MODE_REG
 	default 0xfd588080

arch/microblaze/cpu/u-boot-spl.lds

@@ -54,6 +54,7 @@ SECTIONS
 		__bss_end = .;
 	}
 	_end = . ;
+	_image_binary_end = .;
 }
 
 #if defined(CONFIG_SPL_MAX_FOOTPRINT)

arch/mips/cpu/cpu.c

@@ -15,7 +15,7 @@
 #if !CONFIG_IS_ENABLED(SYSRESET)
 void __weak _machine_restart(void)
 {
-	fprintf(stderr, "*** reset failed ***\n");
+	puts("*** reset failed ***\n");
 
 	while (1)
 		/* NOP */;

arch/riscv/cpu/u-boot.lds

@@ -48,7 +48,7 @@ SECTIONS
 		KEEP(*(SORT(__u_boot_list*)));
 	}
 
-	. = ALIGN(4);
+	. = ALIGN(8);
 
 	.efi_runtime_rel : {
 		__efi_runtime_rel_start = .;
@@ -57,8 +57,6 @@ SECTIONS
 		__efi_runtime_rel_stop = .;
 	}
 
-	. = ALIGN(8);
-
 	/DISCARD/ : { *(.rela.plt*) }
 	.rela.dyn : {
 		__rel_dyn_start = .;

board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c

@@ -15,7 +15,8 @@
 #include <asm/arch-rockchip/misc.h>
 #include <power/regulator.h>
 
-#define GRF_IO_VSEL_BT565_SHIFT 0
+#define GRF_IO_VSEL_BT565_GPIO2AB 1
+#define GRF_IO_VSEL_AUDIO_GPIO3D4A 2
 #define PMUGRF_CON0_VSEL_SHIFT 8
 
 #ifndef CONFIG_SPL_BUILD
@@ -48,7 +49,8 @@ static void setup_iodomain(void)
 	   syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
 
 	/* BT565 is in 1.8v domain */
-	rk_setreg(&grf->io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT);
+	rk_setreg(&grf->io_vsel,
+		  GRF_IO_VSEL_BT565_GPIO2AB | GRF_IO_VSEL_AUDIO_GPIO3D4A);
 
 	/* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */
 	rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);

board/ronetix/pm9g45/pm9g45.c

@@ -67,10 +67,12 @@ static void pm9g45_nand_hw_init(void)
 
 #ifdef CFG_SYS_NAND_READY_PIN
 	/* Configure RDY/BSY */
+	gpio_request(CFG_SYS_NAND_READY_PIN, "NAND RDY/BSY");
 	gpio_direction_input(CFG_SYS_NAND_READY_PIN);
 #endif
 
 	/* Enable NandFlash */
+	gpio_request(CFG_SYS_NAND_ENABLE_PIN, "NAND enable");
 	gpio_direction_output(CFG_SYS_NAND_ENABLE_PIN, 1);
 }
 #endif

board/sifive/unmatched/MAINTAINERS

@@ -1,6 +1,5 @@
 SiFive HiFive Unmatched FU740 BOARD
 M:	Paul Walmsley <paul.walmsley@sifive.com>
-M:	Pragnesh Patel <pragnesh.patel@sifive.com>
 M:	Green Wan <green.wan@sifive.com>
 S:	Maintained
 F:	board/sifive/unmatched/

board/starfive/visionfive2/MAINTAINERS

@@ -1,5 +1,5 @@
 STARFIVE JH7110 VISIONFIVE2 BOARD
-M: startfive
+M:	Yanhong Wang <yanhong.wang@starfivetech.com>
 S:	Maintained
 F:	arch/riscv/include/asm/arch-jh7110/
 F:	board/starfive/visionfive2/

board/storopack/smegw01/smegw01.c

@@ -102,7 +102,7 @@ int board_late_init(void)
 	return 0;
 }
 
-uint board_mmc_get_env_part(struct mmc *mmc)
+uint mmc_get_env_part(struct mmc *mmc)
 {
 	uint part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
 

board/storopack/smegw01/smegw01.env

@@ -29,7 +29,16 @@ altbootcmd=
 	run bootcmd;
 boot_emmc=setenv mmcdev_wanted 1; run persist_mmcdev; run bootcmd;
 boot_sd=setenv mmcdev_wanted 0; run persist_mmcdev; run bootcmd;
-bootcmd=run finduuid; run distro_bootcmd
+bootcmd=
+	if test "${bootcount}" -gt "${bootlimit}"; then
+		run altbootcmd;
+	else
+		if test "${ustate}" = 1; then
+			setenv upgrade_available 1;
+			saveenv;
+		fi;
+		run mmcboot;
+	fi;
 bootdelay=2
 bootlimit=3
 bootm_size=0x10000000

boot/Kconfig

@@ -397,19 +397,6 @@ config BOOTSTD
 	        U-Boot)
 	    - bootflow - a description of how to boot (owned by the distro)
 
-config BOOTSTD_FULL
-	bool "Enhanced features for standard boot"
-	default y if SANDBOX
-	help
-	  This enables various useful features for standard boot, which are not
-	  essential for operation:
-
-	  - bootdev, bootmeth commands
-	  - extra features in the bootflow command
-	  - support for selecting the ordering of bootmeths ("bootmeth order")
-	  - support for selecting the ordering of bootdevs using the devicetree
-	    as well as the "boot_targets" environment variable
-
 config SPL_BOOTSTD
 	bool "Standard boot support in SPL"
 	depends on SPL && SPL_DM && SPL_OF_CONTROL && SPL_BLK
@@ -432,6 +419,19 @@ config VPL_BOOTSTD
 
 if BOOTSTD
 
+config BOOTSTD_FULL
+	bool "Enhanced features for standard boot"
+	default y if SANDBOX
+	help
+	  This enables various useful features for standard boot, which are not
+	  essential for operation:
+
+	  - bootdev, bootmeth commands
+	  - extra features in the bootflow command
+	  - support for selecting the ordering of bootmeths ("bootmeth order")
+	  - support for selecting the ordering of bootdevs using the devicetree
+	    as well as the "boot_targets" environment variable
+
 config BOOTSTD_DEFAULTS
 	bool "Select some common defaults for standard boot"
 	depends on BOOTSTD

boot/bootm.c

@@ -240,7 +240,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
 
 	if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
 		if (IS_ENABLED(CONFIG_CMD_BOOTI) &&
-		    images.os.arch == IH_ARCH_ARM64) {
+		    images.os.arch == IH_ARCH_ARM64 &&
+		    images.os.os == IH_OS_LINUX) {
 			ulong image_addr;
 			ulong image_size;
 

boot/bootmeth_extlinux.c

@@ -150,7 +150,7 @@ static int extlinux_boot(struct udevice *dev, struct bootflow *bflow)
 	info.dev = dev;
 	info.bflow = bflow;
 	ret = pxe_setup_ctx(&ctx, &cmdtp, extlinux_getfile, &info, true,
-			    bflow->subdir, false);
+			    bflow->fname, false);
 	if (ret)
 		return log_msg_ret("ctx", -EINVAL);
 

cmd/Kconfig

@@ -362,7 +362,8 @@ config BOOTM_VXWORKS
 
 config SYS_BOOTM_LEN
 	hex "Maximum size of a decompresed OS image"
-	depends on CMD_BOOTM || CMD_BOOTI || CMD_BOOTZ
+	depends on CMD_BOOTM || CMD_BOOTI || CMD_BOOTZ || \
+		   LEGACY_IMAGE_FORMAT || SPL_LEGACY_IMAGE_FORMAT
 	default 0x4000000 if PPC || ARM64
 	default 0x1000000 if X86 || ARCH_MX6 || ARCH_MX7
 	default 0x800000

cmd/net.c

@@ -210,7 +210,7 @@ U_BOOT_CMD(
 
 static void netboot_update_env(void)
 {
-	char tmp[44];
+	char tmp[46];
 
 	if (net_gateway.s_addr) {
 		ip_to_string(net_gateway, tmp);
@@ -275,20 +275,20 @@ static void netboot_update_env(void)
 	if (IS_ENABLED(CONFIG_IPV6)) {
 		if (!ip6_is_unspecified_addr(&net_ip6) ||
 		    net_prefix_length != 0) {
-			sprintf(tmp, "%pI6c", &net_ip6);
 			if (net_prefix_length != 0)
-				sprintf(tmp, "%s/%d", tmp, net_prefix_length);
+				snprintf(tmp, sizeof(tmp), "%pI6c/%d", &net_ip6, net_prefix_length);
-
+			else
+				snprintf(tmp, sizeof(tmp), "%pI6c", &net_ip6);
 			env_set("ip6addr", tmp);
 		}
 
 		if (!ip6_is_unspecified_addr(&net_server_ip6)) {
-			sprintf(tmp, "%pI6c", &net_server_ip6);
+			snprintf(tmp, sizeof(tmp), "%pI6c", &net_server_ip6);
 			env_set("serverip6", tmp);
 		}
 
 		if (!ip6_is_unspecified_addr(&net_gateway6)) {
-			sprintf(tmp, "%pI6c", &net_gateway6);
+			snprintf(tmp, sizeof(tmp), "%pI6c", &net_gateway6);
 			env_set("gatewayip6", tmp);
 		}
 	}

cmd/usb.c

@@ -421,7 +421,9 @@ static void usb_show_tree_graph(struct usb_device *dev, char *pre)
 		 * Ignore emulators and block child devices, we only want
 		 * real devices
 		 */
-		if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+		if (udev &&
+		    (device_get_uclass_id(child) != UCLASS_BOOTDEV) &&
+		    (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
 		    (device_get_uclass_id(child) != UCLASS_BLK)) {
 			usb_show_tree_graph(udev, pre);
 			pre[index] = 0;
@@ -604,9 +606,11 @@ static void usb_show_info(struct usb_device *udev)
 	     child;
 	     device_find_next_child(&child)) {
 		if (device_active(child) &&
+		    (device_get_uclass_id(child) != UCLASS_BOOTDEV) &&
 		    (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
 		    (device_get_uclass_id(child) != UCLASS_BLK)) {
 			udev = dev_get_parent_priv(child);
+			if (udev)
 				usb_show_info(udev);
 		}
 	}

common/menu.c

@@ -15,7 +15,7 @@
 
 #include "menu.h"
 
-#define ansi 0
+#define ansi 1
 
 /*
  * Internally, each item in a menu is represented by a struct menu_item.

common/spl/spl_ext.c

@@ -28,7 +28,7 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
 
 	ext4fs_set_blk_dev(block_dev, &part_info);
 
-	err = ext4fs_mount(0);
+	err = ext4fs_mount(part_info.size);
 	if (!err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 		printf("%s: ext4fs mount err - %d\n", __func__, err);
@@ -82,7 +82,7 @@ int spl_load_image_ext_os(struct spl_image_info *spl_image,
 
 	ext4fs_set_blk_dev(block_dev, &part_info);
 
-	err = ext4fs_mount(0);
+	err = ext4fs_mount(part_info.size);
 	if (!err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 		printf("%s: ext4fs mount err - %d\n", __func__, err);

common/spl/spl_fit.c

@@ -27,10 +27,6 @@ struct spl_fit_info {
 	int conf_node;		/* FDT offset to selected configuration node */
 };
 
-__weak void board_spl_fit_post_load(const void *fit)
-{
-}
-
 __weak ulong board_spl_fit_size_align(ulong size)
 {
 	return size;
@@ -829,8 +825,5 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 
 	spl_image->flags |= SPL_FIT_FOUND;
 
-	if (IS_ENABLED(CONFIG_IMX_HAB))
-		board_spl_fit_post_load(ctx.fit);
-
 	return 0;
 }

common/spl/spl_legacy.c

@@ -7,6 +7,7 @@
 #include <image.h>
 #include <log.h>
 #include <malloc.h>
+#include <asm/sections.h>
 #include <spl.h>
 
 #include <lzma/LzmaTypes.h>
@@ -15,6 +16,22 @@
 
 #define LZMA_LEN	(1 << 20)
 
+static void spl_parse_legacy_validate(uintptr_t start, uintptr_t size)
+{
+	uintptr_t spl_start = (uintptr_t)_start;
+	uintptr_t spl_end = (uintptr_t)_image_binary_end;
+	uintptr_t end = start + size;
+
+	if ((start >= spl_start && start < spl_end) ||
+	    (end > spl_start && end <= spl_end) ||
+	    (start < spl_start && end >= spl_end) ||
+	    (start > end && end > spl_start))
+		panic("SPL: Image overlaps SPL\n");
+
+	if (size > CONFIG_SYS_BOOTM_LEN)
+		panic("SPL: Image too large\n");
+}
+
 int spl_parse_legacy_header(struct spl_image_info *spl_image,
 			    const struct legacy_img_hdr *header)
 {
@@ -58,6 +75,9 @@ int spl_parse_legacy_header(struct spl_image_info *spl_image,
 	      "payload image: %32s load addr: 0x%lx size: %d\n",
 	      spl_image->name, spl_image->load_addr, spl_image->size);
 
+	spl_parse_legacy_validate(spl_image->load_addr, spl_image->size);
+	spl_parse_legacy_validate(spl_image->entry_point, 0);
+
 	return 0;
 }
 

configs/evb-rk3568_defconfig

@@ -22,6 +22,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y

configs/evb-rk3588_defconfig

@@ -23,6 +23,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-evb1-v10.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set

configs/imx93_11x11_evk_defconfig

@@ -7,7 +7,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_ENV_SIZE=0x4000
-CONFIG_ENV_OFFSET=0x400000
+CONFIG_ENV_OFFSET=0x700000
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="imx93-11x11-evk"
 CONFIG_SPL_TEXT_BASE=0x2049A000

configs/j721e_evm_r5_defconfig

@@ -10,7 +10,7 @@ CONFIG_SOC_K3_J721E=y
 CONFIG_K3_EARLY_CONS=y
 CONFIG_TARGET_J721E_R5_EVM=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf5bfc
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf59f0
 CONFIG_ENV_SIZE=0x20000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
@@ -22,22 +22,19 @@ CONFIG_SPL_SERIAL=y
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL_SIZE_LIMIT=0xf59f0
-CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
-CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
 CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf59f0
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000
-CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_BOOTCOMMAND=y
 # CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
 CONFIG_SPL_MAX_SIZE=0xf59f0
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x41cf59f0

configs/pinephone-pro-rk3399_defconfig

@@ -73,6 +73,7 @@ CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM_ROCKCHIP_LPDDR4=y
 CONFIG_DM_RNG=y
 CONFIG_RNG_ROCKCHIP=y
 CONFIG_BAUDRATE=1500000

configs/radxa-cm3-io-rk3566_defconfig

@@ -22,6 +22,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3566-radxa-cm3-io.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y

configs/rock-3a-rk3568_defconfig

@@ -27,6 +27,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-rock-3a.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y

configs/rock-pi-4-rk3399_defconfig

@@ -20,6 +20,7 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 # CONFIG_ANDROID_BOOT_IMAGE is not set
 CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4a.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_MISC_INIT_R=y

configs/rock5b-rk3588_defconfig

@@ -29,6 +29,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_FIT_SIGNATURE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set

configs/rockpro64-rk3399_defconfig

@@ -23,6 +23,7 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_LTO=y
 CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_USE_PREBOOT=y

configs/sama5d2_icp_mmc_defconfig

@@ -41,6 +41,7 @@ CONFIG_SPL_MAX_SIZE=0x10000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x20000000
 CONFIG_SPL_BSS_MAX_SIZE=0x80000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SYS_SPL_MALLOC=y
 CONFIG_SYS_SPL_MALLOC_SIZE=0x80000

configs/smegw01_defconfig

@@ -21,8 +21,6 @@ CONFIG_FIT_VERBOSE=y
 # CONFIG_BOOTSTD is not set
 CONFIG_AUTOBOOT_MENU_SHOW=y
 CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE=y
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="if test \"${bootcount}\" -gt \"${bootlimit}\"; then run altbootcmd; else if test \"${ustate}\" = 1; then setenv upgrade_available 1; saveenv; fi; run mmcboot; fi;"
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run setup_boot_menu;"
 CONFIG_HUSH_PARSER=y

doc/develop/event.rst

@@ -28,8 +28,8 @@ To declare a spy, use something like this::
     }
     EVENT_SPY(EVT_DM_POST_INIT_F, snow_setup_cpus);
 
-Your function is called when EVT_DM_POST_INIT_F is emitted, i.e. after driver
+This function is called when EVT_DM_POST_INIT_F is emitted, i.e. after the
-model is inited (in SPL, or in U-Boot proper before and after relocation).
+driver model is initialized (in U-Boot proper before and after relocation).
 
 
 Debugging

doc/develop/release_cycle.rst

@@ -54,7 +54,7 @@ Current Status
 
 * The next branch is now **open**.
 
-* Release "v2023.07" is scheduled for 03 July 2023.
+* Release "v2023.07" is scheduled for 10 July 2023.
 
 Future Releases
 ---------------
@@ -72,12 +72,14 @@ For the next scheduled release, release candidates were made on::
 
 * U-Boot v2023.07-rc4 was released on Mon 12 June 2023.
 
-.. * U-Boot v2023.07-rc5 was released on Mon 19 June 2023.
+* U-Boot v2023.07-rc5 was released on Mon 26 June 2023.
+
+* U-Boot v2023.07-rc6 was released on Mon 03 July 2023.
 
 Please note that the following dates are planned only and may be deviated from
 as needed.
 
-* "v2023.07": end of MW = Mon, Apr 24, 2023; release = Mon, Jul 03, 2023 
+* "v2023.07": end of MW = Mon, Apr 24, 2023; release = Mon, Jul 10, 2023
 
 * "v2023.10": end of MW = Mon, Jul 24, 2023; release = Mon, Oct 02, 2023
 

doc/develop/statistics/u-boot-stats-v2022.10.rst

@@ -607,20 +607,21 @@ Release Statistics for U-Boot v2022.10
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             590 (38.8%)
+   (Unknown)                             584 (38.4%)
    Konsulko Group                        265 (17.4%)
    Google, Inc.                          141 (9.3%)
    NXP                                   77 (5.1%)
+   AMD                                   70 (4.6%)
    ST Microelectronics                   67 (4.4%)
    Linaro                                60 (3.9%)
    Texas Instruments                     56 (3.7%)
-   AMD                                   53 (3.5%)
    DENX Software Engineering             45 (3.0%)
    Toradex                               45 (3.0%)
    Weidmüller Interface GmbH & Co. KG    41 (2.7%)
-   Xilinx                                29 (1.9%)
    Amarula Solutions                     18 (1.2%)
+   Xilinx                                12 (0.8%)
    ARM                                   11 (0.7%)
+   Collabora Ltd.                        7 (0.5%)
    BayLibre SAS                          5 (0.3%)
    SUSE                                  4 (0.3%)
    Socionext Inc.                        3 (0.2%)
@@ -628,7 +629,6 @@ Release Statistics for U-Boot v2022.10
    IBM                                   2 (0.1%)
    Siemens                               2 (0.1%)
    Broadcom                              1 (0.1%)
-   Collabora Ltd.                        1 (0.1%)
    Debian.org                            1 (0.1%)
    Marvell                               1 (0.1%)
    Samsung                               1 (0.1%)
@@ -642,7 +642,7 @@ Release Statistics for U-Boot v2022.10
    Name                                  Count
    ====================================  =====
    Konsulko Group                        98915 (47.3%)
-   (Unknown)                             36773 (17.6%)
+   (Unknown)                             36630 (17.5%)
    Toradex                               20197 (9.7%)
    NXP                                   11759 (5.6%)
    Google, Inc.                          8739 (4.2%)
@@ -651,12 +651,13 @@ Release Statistics for U-Boot v2022.10
    Texas Instruments                     5930 (2.8%)
    ST Microelectronics                   3803 (1.8%)
    DENX Software Engineering             3551 (1.7%)
-   AMD                                   2343 (1.1%)
+   AMD                                   2591 (1.2%)
    Amarula Solutions                     1360 (0.7%)
-   Xilinx                                1016 (0.5%)
+   Xilinx                                768 (0.4%)
    Broadcom                              315 (0.2%)
    ARM                                   298 (0.1%)
    BayLibre SAS                          197 (0.1%)
+   Collabora Ltd.                        144 (0.1%)
    SUSE                                  79 (0.0%)
    IBM                                   34 (0.0%)
    Bootlin                               32 (0.0%)
@@ -665,7 +666,6 @@ Release Statistics for U-Boot v2022.10
    Debian.org                            4 (0.0%)
    Marvell                               3 (0.0%)
    Samsung                               2 (0.0%)
-   Collabora Ltd.                        1 (0.0%)
    ====================================  =====
 
 
@@ -677,13 +677,14 @@ Release Statistics for U-Boot v2022.10
    ====================================  =====
    AMD                                   81 (30.5%)
    NXP                                   51 (19.2%)
-   (Unknown)                             33 (12.4%)
+   (Unknown)                             28 (10.5%)
    Texas Instruments                     19 (7.1%)
    Linaro                                16 (6.0%)
    ARM                                   16 (6.0%)
    Amarula Solutions                     14 (5.3%)
    Xilinx                                13 (4.9%)
    Konsulko Group                        6 (2.3%)
+   Canonical                             5 (1.9%)
    Toradex                               4 (1.5%)
    Google, Inc.                          4 (1.5%)
    Socionext Inc.                        4 (1.5%)
@@ -699,19 +700,20 @@ Release Statistics for U-Boot v2022.10
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             78 (51.0%)
+   (Unknown)                             77 (50.3%)
    Linaro                                12 (7.8%)
    Texas Instruments                     11 (7.2%)
    NXP                                   7 (4.6%)
+   AMD                                   6 (3.9%)
    Google, Inc.                          5 (3.3%)
    DENX Software Engineering             5 (3.3%)
-   Xilinx                                4 (2.6%)
    Toradex                               4 (2.6%)
    ST Microelectronics                   4 (2.6%)
-   AMD                                   3 (2.0%)
    ARM                                   3 (2.0%)
    BayLibre SAS                          3 (2.0%)
    Amarula Solutions                     2 (1.3%)
+   Collabora Ltd.                        2 (1.3%)
+   Xilinx                                1 (0.7%)
    Konsulko Group                        1 (0.7%)
    Socionext Inc.                        1 (0.7%)
    Broadcom                              1 (0.7%)
@@ -723,5 +725,4 @@ Release Statistics for U-Boot v2022.10
    Debian.org                            1 (0.7%)
    Marvell                               1 (0.7%)
    Samsung                               1 (0.7%)
-   Collabora Ltd.                        1 (0.7%)
    ====================================  =====

doc/develop/statistics/u-boot-stats-v2023.01.rst

@@ -5,7 +5,7 @@ Release Statistics for U-Boot v2023.01
 
 * Processed 1396 changesets from 152 developers
 
-* 23 employers found
+* 24 employers found
 
 * A total of 91252 lines added, 42422 removed (delta 48830)
 
@@ -603,11 +603,11 @@ Release Statistics for U-Boot v2023.01
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             557 (39.9%)
+   (Unknown)                             556 (39.8%)
    Google, Inc.                          270 (19.3%)
+   AMD                                   90 (6.4%)
    DENX Software Engineering             86 (6.2%)
    Linaro                                85 (6.1%)
-   AMD                                   80 (5.7%)
    Konsulko Group                        48 (3.4%)
    ST Microelectronics                   47 (3.4%)
    SUSE                                  36 (2.6%)
@@ -616,16 +616,17 @@ Release Statistics for U-Boot v2023.01
    Broadcom                              27 (1.9%)
    Texas Instruments                     26 (1.9%)
    Amarula Solutions                     24 (1.7%)
-   Xilinx                                13 (0.9%)
    NXP                                   8 (0.6%)
    BayLibre SAS                          6 (0.4%)
    Collabora Ltd.                        6 (0.4%)
    Weidmüller Interface GmbH & Co. KG    6 (0.4%)
    Socionext Inc.                        4 (0.3%)
+   Xilinx                                3 (0.2%)
    Edgeble AI Technologies Pvt. Ltd.     1 (0.1%)
    Marvell                               1 (0.1%)
    Rockchip                              1 (0.1%)
    Siemens                               1 (0.1%)
+   Canonical                             1 (0.1%)
    ====================================  =====
 
 
@@ -635,7 +636,7 @@ Release Statistics for U-Boot v2023.01
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             41561 (37.8%)
+   (Unknown)                             41551 (37.8%)
    Google, Inc.                          19204 (17.5%)
    Linaro                                11194 (10.2%)
    Toradex                               6724 (6.1%)
@@ -644,18 +645,19 @@ Release Statistics for U-Boot v2023.01
    Collabora Ltd.                        3312 (3.0%)
    Amarula Solutions                     3308 (3.0%)
    ST Microelectronics                   3303 (3.0%)
+   AMD                                   2379 (2.2%)
    Texas Instruments                     2174 (2.0%)
    DENX Software Engineering             2105 (1.9%)
-   AMD                                   2105 (1.9%)
    ARM                                   1569 (1.4%)
    SUSE                                  478 (0.4%)
    Weidmüller Interface GmbH & Co. KG    448 (0.4%)
    NXP                                   446 (0.4%)
-   Xilinx                                280 (0.3%)
    Marvell                               200 (0.2%)
    Socionext Inc.                        76 (0.1%)
    BayLibre SAS                          65 (0.1%)
+   Canonical                             10 (0.0%)
    Siemens                               9 (0.0%)
+   Xilinx                                6 (0.0%)
    Edgeble AI Technologies Pvt. Ltd.     1 (0.0%)
    Rockchip                              1 (0.0%)
    ====================================  =====
@@ -669,47 +671,49 @@ Release Statistics for U-Boot v2023.01
    ====================================  =====
    AMD                                   79 (46.7%)
    Amarula Solutions                     27 (16.0%)
-   (Unknown)                             22 (13.0%)
+   (Unknown)                             18 (10.7%)
    DENX Software Engineering             10 (5.9%)
    NXP                                   7 (4.1%)
    Linaro                                5 (3.0%)
    Google, Inc.                          4 (2.4%)
    ST Microelectronics                   4 (2.4%)
    ARM                                   4 (2.4%)
+   Canonical                             4 (2.4%)
    Texas Instruments                     3 (1.8%)
    Konsulko Group                        2 (1.2%)
    BayLibre SAS                          2 (1.2%)
    ====================================  =====
 
 
-.. table:: Employers with the most hackers (total 154)
+.. table:: Employers with the most hackers (total 153)
    :widths: auto
 
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             81 (52.6%)
+   (Unknown)                             80 (52.3%)
-   Linaro                                9 (5.8%)
+   AMD                                   9 (5.9%)
+   Linaro                                9 (5.9%)
    Texas Instruments                     8 (5.2%)
-   AMD                                   7 (4.5%)
    ST Microelectronics                   6 (3.9%)
-   DENX Software Engineering             5 (3.2%)
+   DENX Software Engineering             5 (3.3%)
    Amarula Solutions                     4 (2.6%)
    Toradex                               4 (2.6%)
-   Xilinx                                4 (2.6%)
+   NXP                                   3 (2.0%)
-   NXP                                   3 (1.9%)
+   Google, Inc.                          3 (2.0%)
-   Google, Inc.                          3 (1.9%)
+   ARM                                   3 (2.0%)
-   ARM                                   3 (1.9%)
+   BayLibre SAS                          3 (2.0%)
-   BayLibre SAS                          3 (1.9%)
    Collabora Ltd.                        2 (1.3%)
    SUSE                                  2 (1.3%)
    Weidmüller Interface GmbH & Co. KG    2 (1.3%)
    Socionext Inc.                        2 (1.3%)
-   Konsulko Group                        1 (0.6%)
+   Canonical                             1 (0.7%)
-   Broadcom                              1 (0.6%)
+   Konsulko Group                        1 (0.7%)
-   Marvell                               1 (0.6%)
+   Broadcom                              1 (0.7%)
-   Siemens                               1 (0.6%)
+   Marvell                               1 (0.7%)
-   Edgeble AI Technologies Pvt. Ltd.     1 (0.6%)
+   Siemens                               1 (0.7%)
-   Rockchip                              1 (0.6%)
+   Xilinx                                1 (0.7%)
+   Edgeble AI Technologies Pvt. Ltd.     1 (0.7%)
+   Rockchip                              1 (0.7%)
    ====================================  =====
 

doc/develop/statistics/u-boot-stats-v2023.04.rst

@@ -5,7 +5,7 @@ Release Statistics for U-Boot v2023.04
 
 * Processed 1691 changesets from 157 developers
 
-* 29 employers found
+* 28 employers found
 
 * A total of 174471 lines added, 78380 removed (delta 96091)
 
@@ -631,17 +631,17 @@ Release Statistics for U-Boot v2023.04
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             524 (31.0%)
+   (Unknown)                             464 (27.4%)
    Google, Inc.                          381 (22.5%)
    Konsulko Group                        333 (19.7%)
+   Renesas Electronics                   84 (5.0%)
    DENX Software Engineering             72 (4.3%)
    Texas Instruments                     49 (2.9%)
    Linaro                                47 (2.8%)
    Edgeble AI Technologies Pvt. Ltd.     46 (2.7%)
    ST Microelectronics                   40 (2.4%)
-   AMD                                   34 (2.0%)
+   AMD                                   35 (2.1%)
    NXP                                   25 (1.5%)
-   Renesas Electronics                   24 (1.4%)
    Toradex                               24 (1.4%)
    Amarula Solutions                     20 (1.2%)
    Collabora Ltd.                        20 (1.2%)
@@ -659,7 +659,6 @@ Release Statistics for U-Boot v2023.04
    Intel                                 1 (0.1%)
    linutronix                            1 (0.1%)
    Samsung                               1 (0.1%)
-   Xilinx                                1 (0.1%)
    ====================================  =====
 
 
@@ -669,18 +668,18 @@ Release Statistics for U-Boot v2023.04
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             64681 (30.1%)
+   (Unknown)                             51007 (23.8%)
    Texas Instruments                     42105 (19.6%)
    Konsulko Group                        36464 (17.0%)
    Google, Inc.                          30090 (14.0%)
    Edgeble AI Technologies Pvt. Ltd.     23070 (10.7%)
+   Renesas Electronics                   14449 (6.7%)
    Linaro                                4601 (2.1%)
    DENX Software Engineering             4582 (2.1%)
-   AMD                                   1741 (0.8%)
+   AMD                                   1744 (0.8%)
    Amarula Solutions                     1649 (0.8%)
    ST Microelectronics                   882 (0.4%)
    Bootlin                               860 (0.4%)
-   Renesas Electronics                   775 (0.4%)
    Socionext Inc.                        760 (0.4%)
    ARM                                   724 (0.3%)
    Collabora Ltd.                        413 (0.2%)
@@ -695,7 +694,6 @@ Release Statistics for U-Boot v2023.04
    Pengutronix                           13 (0.0%)
    Samsung                               9 (0.0%)
    Ronetix                               4 (0.0%)
-   Xilinx                                3 (0.0%)
    Intel                                 1 (0.0%)
    linutronix                            1 (0.0%)
    ====================================  =====
@@ -707,14 +705,14 @@ Release Statistics for U-Boot v2023.04
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             48 (22.3%)
+   Renesas Electronics                   30 (14.0%)
    Rockchip                              29 (13.5%)
    Toradex                               28 (13.0%)
+   (Unknown)                             27 (12.6%)
    Amarula Solutions                     24 (11.2%)
    AMD                                   23 (10.7%)
    NVidia                                19 (8.8%)
    Linaro                                9 (4.2%)
-   Renesas Electronics                   9 (4.2%)
    Texas Instruments                     5 (2.3%)
    Konsulko Group                        5 (2.3%)
    NXP                                   4 (1.9%)
@@ -734,18 +732,18 @@ Release Statistics for U-Boot v2023.04
    ====================================  =====
    Name                                  Count
    ====================================  =====
-   (Unknown)                             86 (53.8%)
+   (Unknown)                             85 (53.1%)
    Linaro                                9 (5.6%)
    Texas Instruments                     8 (5.0%)
-   AMD                                   6 (3.8%)
+   AMD                                   7 (4.4%)
    Collabora Ltd.                        6 (3.8%)
    Toradex                               5 (3.1%)
    DENX Software Engineering             5 (3.1%)
    Amarula Solutions                     4 (2.5%)
    NXP                                   4 (2.5%)
+   Renesas Electronics                   3 (1.9%)
    ARM                                   3 (1.9%)
    ST Microelectronics                   3 (1.9%)
-   Renesas Electronics                   2 (1.2%)
    SUSE                                  2 (1.2%)
    Socionext Inc.                        2 (1.2%)
    Konsulko Group                        1 (0.6%)
@@ -761,7 +759,6 @@ Release Statistics for U-Boot v2023.04
    Pengutronix                           1 (0.6%)
    Samsung                               1 (0.6%)
    Ronetix                               1 (0.6%)
-   Xilinx                                1 (0.6%)
    linutronix                            1 (0.6%)
    ====================================  =====
 

doc/imx/habv4/csf_examples/mx8m/csf.sh

@@ -37,29 +37,11 @@ dd if=csf_spl.bin of=flash.bin bs=1 seek=${spl_dd_offset} conv=notrunc
 
 # 3) Sign u-boot.itb
 
-# fitImage tree
+# fitImage
-fit_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_TEXT_BASE=/ s@.*=@@p" .config) - $(sed -n "/CONFIG_FIT_EXTERNAL_OFFSET=/ s@.*=@@p" .config) - 0x200 - 0x40)) )
+fit_block_base=$(printf "0x%x" $(sed -n "/CONFIG_SPL_LOAD_FIT_ADDRESS=/ s@.*=@@p" .config) )
 fit_block_offset=$(printf "0x%s" $(fdtget -t x u-boot.dtb /binman/imx-boot/uboot offset))
-fit_block_size=$(printf "0x%x" $(( ( ($(fdtdump u-boot.itb 2>/dev/null | sed -n "/^...totalsize:/ s@.*\(0x[0-9a-f]\+\).*@\1@p") + 0x1000 - 0x1 ) & ~(0x1000 - 0x1)) + 0x20 )) )
+fit_block_size=$(printf "0x%x" $(( ( ( $(stat -tc %s u-boot.itb) + 0x1000 - 0x1 ) & ~(0x1000 - 0x1)) + 0x20 )) )
-sed -i "/Blocks = / s@.*@  Blocks = $fit_block_base $fit_block_offset $fit_block_size \"flash.bin\", \\\\@" csf_fit.tmp
+sed -i "/Blocks = / s@.*@  Blocks = $fit_block_base $fit_block_offset $fit_block_size \"flash.bin\"@" csf_fit.tmp
-
-# U-Boot
-uboot_block_base=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot load))
-uboot_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot data-position)) + ${fit_block_offset} )))
-uboot_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot data-size))
-sed -i "/0xuuuu/ s@.*@           $uboot_block_base $uboot_block_offset $uboot_block_size \"flash.bin\", \\\\@" csf_fit.tmp
-
-# ATF
-atf_block_base=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf load))
-atf_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf data-position)) + ${fit_block_offset} )))
-atf_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf data-size))
-sed -i "/0xaaaa/ s@.*@           $atf_block_base $atf_block_offset $atf_block_size \"flash.bin\", \\\\@" csf_fit.tmp
-
-# DTB
-dtb_block_base=$(printf "0x%x" $(( ${uboot_block_base} + ${uboot_block_size} )))
-dtb_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t x u-boot.itb /images/fdt-1 data-position)) + ${fit_block_offset} )))
-dtb_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/fdt-1 data-size))
-sed -i "/0xdddd/ s@.*@           $dtb_block_base $dtb_block_offset $dtb_block_size \"flash.bin\"@" csf_fit.tmp
 
 # IVT
 ivt_ptr_base=$(printf "%08x" ${fit_block_base} | sed "s@\(..\)\(..\)\(..\)\(..\)@0x\4\3\2\1@")
@@ -68,7 +50,7 @@ csf_block_base=$(printf "%08x" $(( ${fit_block_base} + ${fit_block_size} )) | se
 ivt_block_offset=$((${fit_block_offset} + ${fit_block_size} - 0x20))
 csf_block_offset=$((${ivt_block_offset} + 0x20))
 
-echo "0xd1002041 ${ivt_ptr_base} 0x00000000 0x00000000 0x00000000 ${ivt_block_base} ${csf_block_base} 0x00000000" | xxd -r -p > ivt.bin
+echo "0xd1002041 ${ivt_block_base} 0x00000000 0x00000000 0x00000000 ${ivt_block_base} ${csf_block_base} 0x00000000" | xxd -r -p > ivt.bin
 dd if=ivt.bin of=flash.bin bs=1 seek=${ivt_block_offset} conv=notrunc
 
 # Generate CSF blob

doc/imx/habv4/csf_examples/mx8m/csf_fit.txt

@@ -26,11 +26,5 @@
 [Authenticate Data]
   Verification index = 2
   # FIXME:
-  # Line 1 -- fitImage tree
+  # Line 1 -- fitImage
-  # Line 2 -- U-Boot u-boot-nodtb.bin blob
+  Blocks = 0x401fcdc0 0x57c00 0xffff "flash.bin"
-  # Line 3 -- ATF BL31 blob
-  # Line 4 -- DT blob
-  Blocks = 0x401fcdc0 0x57c00 0xffff "flash.bin", \
-           0x40200000 0x62c00 0xuuuu "flash.bin", \
-	   0x920000   0x00000 0xaaaa "flash.bin", \
-	   0x40200000 0x00000 0xdddd "flash.bin"

doc/imx/habv4/guides/mx6_mx7_secure_boot.txt

@@ -113,7 +113,7 @@ the U-Boot build, the example below is a log for mx7dsabresd_defconfig target:
 1.4 Signing the U-Boot binary
 ------------------------------
 
-The CST tool is used for singing the U-Boot binary and generating a CSF binary,
+The CST tool is used for signing the U-Boot binary and generating a CSF binary,
 users should input the CSF description file created in the step above and
 should receive a CSF binary, which contains the CSF commands, SRK table,
 signatures and certificates.

doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt

@@ -145,7 +145,7 @@ addresses, the csf_uboot.txt can be used as example:
 1.4 Signing the images
 -----------------------
 
-The CST tool is used for singing the U-Boot binary and generating a CSF binary,
+The CST tool is used for signing the U-Boot binary and generating a CSF binary,
 users should input the CSF description file created in the step above and
 receive a CSF binary, which contains the CSF commands, SRK table, signatures
 and certificates.

doc/imx/habv4/guides/mx8m_spl_secure_boot.txt

@@ -79,18 +79,16 @@ code within it:
 
 The diagram below illustrate a signed U-Boot binary, DT blob and external
 ATF BL31 blob combined to form fitImage part of flash.bin container layout.
-The *load_address is derived from CONFIG_TEXT_BASE such that the U-Boot
+The *load_address is CONFIG_SPL_LOAD_FIT_ADDRESS, the fitImage is loaded
-binary *start is placed exactly at CONFIG_SPL_TEXT_BASE in DRAM, however the
+including all of its embedded data, authenticated using IVT+CSF concatenated
-SPL moves the fitImage tree further to location:
+at the end of the fitImage at offset aligned to 4 kiB. The fitImage with
- *load_address = CONFIG_SPL_TEXT_BASE - CONFIG_FIT_EXTERNAL_OFFSET (=12kiB) -
+external data is not supported.
-                 512 Byte sector - sizeof(mkimage header)
 
             ------- +-----------------------------+ <-- *load_address
                 ^   |                             |
                 |   |        fitImage tree        |
-                |   |    with external data at    |
+                |   |      with embedded data     |
-                |   |   offset 12 kiB from tree   |
+                |   |        (cca. 1 MiB)         |
-                |   |        (cca. 1 kiB)         |
          Signed |   |                             |
   .-----  Tree  |   +-----------------------------+
   |       Data  |   | Padding to next 4k aligned  |
@@ -101,34 +99,9 @@ SPL moves the fitImage tree further to location:
   |         ------- +-----------------------------+ <-- *csf
   |                 | Command Sequence File (CSF) |
   |                 |  for all signed entries in  |
-   >--------------->| the fitImage, tree and data |
+  '---------------->| the fitImage, tree and data |
-  |                 |        (cca 6-7 kiB)        |
+                    |        (cca 6-7 kiB)        |
-  |                 +-----------------------------+
+                    +-----------------------------+
-  |                 |  Padding to 12 kiB offset   |
-  |                 |     from *load_address      |
-  |         ------- +-----------------------------+ <-- *start
-  |             ^   |                             |
-  |      Signed |   |                             |
-  |---- Payload |   |  U-Boot external data blob  |
-  |       Data  |   |                             |
-  |             v   |                             |
-  |         ------- +-----------------------------+
-  |                 |     Padding to 4 Bytes      |
-  |         ------- +-----------------------------+
-  |             ^   |                             |
-  |      Signed |   |                             |
-  |---- Payload |   |    ATF external data blob   |
-  |       Data  |   |                             |
-  |             v   |                             |
-  |         ------- +-----------------------------+
-  |                 |     Padding to 4 Bytes      |
-  |         ------- +-----------------------------+
-  |             ^   |                             |
-  |      Signed |   |                             |
-  '---- Payload |   |    DTB external data blob   |
-          Data  |   |                             |
-                v   |                             |
-            ------- +-----------------------------+
 
 The diagram below illustrate a combined flash.bin container layout:
 
@@ -202,29 +175,11 @@ dd if=csf_spl.bin of=flash.bin bs=1 seek=${spl_dd_offset} conv=notrunc
 
 CSF "Blocks" line for csf_fit.txt can be generated as follows:
 ```
-# fitImage tree
+# fitImage
-fit_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_TEXT_BASE=/ s@.*=@@p" .config) - $(sed -n "/CONFIG_FIT_EXTERNAL_OFFSET=/ s@.*=@@p" .config) - 0x200 - 0x40)) )
+fit_block_base=$(printf "0x%x" $(sed -n "/CONFIG_SPL_LOAD_FIT_ADDRESS=/ s@.*=@@p" .config) )
 fit_block_offset=$(printf "0x%s" $(fdtget -t x u-boot.dtb /binman/imx-boot/uboot offset))
-fit_block_size=$(printf "0x%x" $(( ( $(fdtdump u-boot.itb 2>/dev/null | sed -n "/^...totalsize:/ s@.*\(0x[0-9a-f]\+\).*@\1@p") + 0x1000 - 0x1 ) & ~(0x1000 - 0x1) + 0x20 )) )
+fit_block_size=$(printf "0x%x" $(( ( ( $(stat -tc %s u-boot.itb) + 0x1000 - 0x1 ) & ~(0x1000 - 0x1)) + 0x20 )) )
-sed -i "/Blocks = / s@.*@  Blocks = $fit_block_base $fit_block_offset $fit_block_size \"flash.bin\", \\\\@" csf_fit.tmp
+sed -i "/Blocks = / s@.*@  Blocks = $fit_block_base $fit_block_offset $fit_block_size \"flash.bin\"@" csf_fit.tmp
-
-# U-Boot
-uboot_block_base=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot load))
-uboot_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot data-position)) + ${fit_block_offset} )))
-uboot_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot data-size))
-sed -i "/0xuuuu/ s@.*@           $uboot_block_base $uboot_block_offset $uboot_block_size \"flash.bin\", \\\\@" csf_fit.tmp
-
-# ATF
-atf_block_base=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf load))
-atf_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf data-position)) + ${fit_block_offset} )))
-atf_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf data-size))
-sed -i "/0xaaaa/ s@.*@           $atf_block_base $atf_block_offset $atf_block_size \"flash.bin\", \\\\@" csf_fit.tmp
-
-# DTB
-dtb_block_base=$(printf "0x%x" $(( ${uboot_block_base} + ${uboot_block_size} )))
-dtb_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t x u-boot.itb /images/fdt-1 data-position)) + ${fit_block_offset} )))
-dtb_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/fdt-1 data-size))
-sed -i "/0xdddd/ s@.*@           $dtb_block_base $dtb_block_offset $dtb_block_size \"flash.bin\"@" csf_fit.tmp
 ```
 
 The fitImage part of flash.bin requires separate IVT. Generate the IVT and
@@ -237,8 +192,9 @@ csf_block_base=$(printf "%08x" $(( ${fit_block_base} + ${fit_block_size} )) | se
 ivt_block_offset=$((${fit_block_offset} + ${fit_block_size} - 0x20))
 csf_block_offset=$((${ivt_block_offset} + 0x20))
 
-echo "0xd1002041 ${ivt_ptr_base} 0x00000000 0x00000000 0x00000000 ${ivt_block_base} ${csf_block_base} 0x00000000" | xxd -r -p > ivt.bin
+echo "0xd1002041 ${ivt_block_base} 0x00000000 0x00000000 0x00000000 ${ivt_block_base} ${csf_block_base} 0x00000000" | xxd -r -p > ivt.bin
 dd if=ivt.bin of=flash.bin bs=1 seek=${ivt_block_offset} conv=notrunc
+```
 
 To generate CSF signature for the fitImage part of flash.bin container, use CST:
 ```

doc/uImage.FIT/beaglebone_vboot.txt

@@ -1,607 +0,0 @@
-Verified Boot on the Beaglebone Black
-=====================================
-
-Introduction
-------------
-
-Before reading this, please read verified-boot.txt and signature.txt. These
-instructions are for mainline U-Boot from v2014.07 onwards.
-
-There is quite a bit of documentation in this directory describing how
-verified boot works in U-Boot. There is also a test which runs through the
-entire process of signing an image and running U-Boot (sandbox) to check it.
-However, it might be useful to also have an example on a real board.
-
-Beaglebone Black is a fairly common board so seems to be a reasonable choice
-for an example of how to enable verified boot using U-Boot.
-
-First a note that may to help avoid confusion. U-Boot and Linux both use
-device tree. They may use the same device tree source, but it is seldom useful
-for them to use the exact same binary from the same place. More typically,
-U-Boot has its device tree packaged wtih it, and the kernel's device tree is
-packaged with the kernel. In particular this is important with verified boot,
-since U-Boot's device tree must be immutable. If it can be changed then the
-public keys can be changed and verified boot is useless. An attacker can
-simply generate a new key and put his public key into U-Boot so that
-everything verifies. On the other hand the kernel's device tree typically
-changes when the kernel changes, so it is useful to package an updated device
-tree with the kernel binary. U-Boot supports the latter with its flexible FIT
-format (Flat Image Tree).
-
-
-Overview
---------
-
-The steps are roughly as follows:
-
-1. Build U-Boot for the board, with the verified boot options enabled.
-
-2. Obtain a suitable Linux kernel
-
-3. Create a Image Tree Source file (ITS) file describing how you want the
-kernel to be packaged, compressed and signed.
-
-4. Create a key pair
-
-5. Sign the kernel
-
-6. Put the public key into U-Boot's image
-
-7. Put U-Boot and the kernel onto the board
-
-8. Try it
-
-
-Step 1: Build U-Boot
---------------------
-
-a. Set up the environment variable to point to your toolchain. You will need
-this for U-Boot and also for the kernel if you build it. For example if you
-installed a Linaro version manually it might be something like:
-
-   export CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-
-
-or if you just installed gcc-arm-linux-gnueabi then it might be
-
-   export CROSS_COMPILE=arm-linux-gnueabi-
-
-b. Configure and build U-Boot with verified boot enabled:
-
-   export UBOOT=/path/to/u-boot
-   cd $UBOOT
-   # You can add -j10 if you have 10 CPUs to make it faster
-   make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all
-   export UOUT=$UBOOT/b/am335x_boneblack_vboot
-
-c. You will now have a U-Boot image:
-
-   file b/am335x_boneblack_vboot/u-boot-dtb.img
-b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage, U-Boot 2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image (Not compressed), 395375 bytes, Sat May 31 16:19:04 2014, Load Address: 0x80800000, Entry Point: 0x00000000, Header CRC: 0x0ABD6ACA, Data CRC: 0x36DEF7E4
-
-
-Step 2: Build Linux
---------------------
-
-a. Find the kernel image ('Image') and device tree (.dtb) file you plan to
-use. In our case it is am335x-boneblack.dtb and it is built with the kernel.
-At the time of writing an SD Boot image can be obtained from here:
-
-   http://www.elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD
-
-You can write this to an SD card and then mount it to extract the kernel and
-device tree files.
-
-You can also build a kernel. Instructions for this are are here:
-
-   http://elinux.org/Building_BBB_Kernel
-
-or you can use your favourite search engine. Following these instructions
-produces a kernel Image and device tree files. For the record the steps were:
-
-   export KERNEL=/path/to/kernel
-   cd $KERNEL
-   git clone git://github.com/beagleboard/kernel.git .
-   git checkout v3.14
-   ./patch.sh
-   cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig
-   cd kernel
-   make beaglebone_defconfig
-   make uImage dtbs   # -j10 if you have 10 CPUs
-   export OKERNEL=$KERNEL/kernel/arch/arm/boot
-
-c. You now have the 'Image' and 'am335x-boneblack.dtb' files needed to boot.
-
-
-Step 3: Create the ITS
-----------------------
-
-Set up a directory for your work.
-
-   export WORK=/path/to/dir
-   cd $WORK
-
-Put this into a file in that directory called sign.its:
-
-/dts-v1/;
-
-/ {
-	description = "Beaglebone black";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			data = /incbin/("Image.lzo");
-			type = "kernel";
-			arch = "arm";
-			os = "linux";
-			compression = "lzo";
-			load = <0x80008000>;
-			entry = <0x80008000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-		fdt-1 {
-			description = "beaglebone-black";
-			data = /incbin/("am335x-boneblack.dtb");
-			type = "flat_dt";
-			arch = "arm";
-			compression = "none";
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-	};
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			kernel = "kernel";
-			fdt = "fdt-1";
-			signature-1 {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-				sign-images = "fdt", "kernel";
-			};
-		};
-	};
-};
-
-
-The explanation for this is all in the documentation you have already read.
-But briefly it packages a kernel and device tree, and provides a single
-configuration to be signed with a key named 'dev'. The kernel is compressed
-with LZO to make it smaller.
-
-
-Step 4: Create a key pair
--------------------------
-
-See signature.txt for details on this step.
-
-   cd $WORK
-   mkdir keys
-   openssl genrsa -F4 -out keys/dev.key 2048
-   openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
-
-Note: keys/dev.key contains your private key and is very secret. If anyone
-gets access to that file they can sign kernels with it. Keep it secure.
-
-
-Step 5: Sign the kernel
------------------------
-
-We need to use mkimage (which was built when you built U-Boot) to package the
-Linux kernel into a FIT (Flat Image Tree, a flexible file format that U-Boot
-can load) using the ITS file you just created.
-
-At the same time we must put the public key into U-Boot device tree, with the
-'required' property, which tells U-Boot that this key must be verified for the
-image to be valid. You will make this key available to U-Boot for booting in
-step 6.
-
-   ln -s $OKERNEL/dts/am335x-boneblack.dtb
-   ln -s $OKERNEL/Image
-   ln -s $UOUT/u-boot-dtb.img
-   cp $UOUT/arch/arm/dts/am335x-boneblack.dtb am335x-boneblack-pubkey.dtb
-   lzop Image
-   $UOUT/tools/mkimage -f sign.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit
-
-You should see something like this:
-
-FIT description: Beaglebone black
-Created:         Sun Jun  1 12:50:30 2014
- Image 0 (kernel)
-  Description:  unavailable
-  Created:      Sun Jun  1 12:50:30 2014
-  Type:         Kernel Image
-  Compression:  lzo compressed
-  Data Size:    7790938 Bytes = 7608.34 kB = 7.43 MB
-  Architecture: ARM
-  OS:           Linux
-  Load Address: 0x80008000
-  Entry Point:  0x80008000
-  Hash algo:    sha1
-  Hash value:   c94364646427e10f423837e559898ef02c97b988
- Image 1 (fdt-1)
-  Description:  beaglebone-black
-  Created:      Sun Jun  1 12:50:30 2014
-  Type:         Flat Device Tree
-  Compression:  uncompressed
-  Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
-  Architecture: ARM
-  Hash algo:    sha1
-  Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
- Default Configuration: 'conf-1'
- Configuration 0 (conf-1)
-  Description:  unavailable
-  Kernel:       kernel
-  FDT:          fdt-1
-
-
-Now am335x-boneblack-pubkey.dtb contains the public key and image.fit contains
-the signed kernel. Jump to step 6 if you like, or continue reading to increase
-your understanding.
-
-You can also run fit_check_sign to check it:
-
-   $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
-
-which results in:
-
-Verifying Hash Integrity ... sha1,rsa2048:dev+
-## Loading kernel from FIT Image at 7fc6ee469000 ...
-   Using 'conf-1' configuration
-   Verifying Hash Integrity ...
-sha1,rsa2048:dev+
-OK
-
-   Trying 'kernel' kernel subimage
-     Description:  unavailable
-     Created:      Sun Jun  1 12:50:30 2014
-     Type:         Kernel Image
-     Compression:  lzo compressed
-     Data Size:    7790938 Bytes = 7608.34 kB = 7.43 MB
-     Architecture: ARM
-     OS:           Linux
-     Load Address: 0x80008000
-     Entry Point:  0x80008000
-     Hash algo:    sha1
-     Hash value:   c94364646427e10f423837e559898ef02c97b988
-   Verifying Hash Integrity ...
-sha1+
-OK
-
-Unimplemented compression type 4
-## Loading fdt from FIT Image at 7fc6ee469000 ...
-   Using 'conf-1' configuration
-   Trying 'fdt-1' fdt subimage
-     Description:  beaglebone-black
-     Created:      Sun Jun  1 12:50:30 2014
-     Type:         Flat Device Tree
-     Compression:  uncompressed
-     Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
-     Architecture: ARM
-     Hash algo:    sha1
-     Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
-   Verifying Hash Integrity ...
-sha1+
-OK
-
-   Loading Flat Device Tree ... OK
-
-## Loading ramdisk from FIT Image at 7fc6ee469000 ...
-   Using 'conf-1' configuration
-Could not find subimage node
-
-Signature check OK
-
-
-At the top, you see "sha1,rsa2048:dev+". This means that it checked an RSA key
-of size 2048 bits using SHA1 as the hash algorithm. The key name checked was
-'dev' and the '+' means that it verified. If it showed '-' that would be bad.
-
-Once the configuration is verified it is then possible to rely on the hashes
-in each image referenced by that configuration. So fit_check_sign goes on to
-load each of the images. We have a kernel and an FDT but no ramkdisk. In each
-case fit_check_sign checks the hash and prints sha1+ meaning that the SHA1
-hash verified. This means that none of the images has been tampered with.
-
-There is a test in test/vboot which uses U-Boot's sandbox build to verify that
-the above flow works.
-
-But it is fun to do this by hand, so you can load image.fit into a hex editor
-like ghex, and change a byte in the kernel:
-
-   $UOUT/tools/fit_info -f image.fit -n /images/kernel -p data
-NAME: kernel
-LEN: 7790938
-OFF: 168
-
-This tells us that the kernel starts at byte offset 168 (decimal) in image.fit
-and extends for about 7MB. Try changing a byte at 0x2000 (say) and run
-fit_check_sign again. You should see something like:
-
-Verifying Hash Integrity ... sha1,rsa2048:dev+
-## Loading kernel from FIT Image at 7f5a39571000 ...
-   Using 'conf-1' configuration
-   Verifying Hash Integrity ...
-sha1,rsa2048:dev+
-OK
-
-   Trying 'kernel' kernel subimage
-     Description:  unavailable
-     Created:      Sun Jun  1 13:09:21 2014
-     Type:         Kernel Image
-     Compression:  lzo compressed
-     Data Size:    7790938 Bytes = 7608.34 kB = 7.43 MB
-     Architecture: ARM
-     OS:           Linux
-     Load Address: 0x80008000
-     Entry Point:  0x80008000
-     Hash algo:    sha1
-     Hash value:   c94364646427e10f423837e559898ef02c97b988
-   Verifying Hash Integrity ...
-sha1 error
-Bad hash value for 'hash-1' hash node in 'kernel' image node
-Bad Data Hash
-
-## Loading fdt from FIT Image at 7f5a39571000 ...
-   Using 'conf-1' configuration
-   Trying 'fdt-1' fdt subimage
-     Description:  beaglebone-black
-     Created:      Sun Jun  1 13:09:21 2014
-     Type:         Flat Device Tree
-     Compression:  uncompressed
-     Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
-     Architecture: ARM
-     Hash algo:    sha1
-     Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
-   Verifying Hash Integrity ...
-sha1+
-OK
-
-   Loading Flat Device Tree ... OK
-
-## Loading ramdisk from FIT Image at 7f5a39571000 ...
-   Using 'conf-1' configuration
-Could not find subimage node
-
-Signature check Bad (error 1)
-
-
-It has detected the change in the kernel.
-
-You can also be sneaky and try to switch images, using the libfdt utilities
-that come with dtc (package name is device-tree-compiler but you will need a
-recent version like 1.4:
-
-   dtc -v
-Version: DTC 1.4.0
-
-First we can check which nodes are actually hashed by the configuration:
-
-   fdtget -l image.fit /
-images
-configurations
-
-   fdtget -l image.fit /configurations
-conf-1
-fdtget -l image.fit /configurations/conf-1
-signature-1
-
-   fdtget -p image.fit /configurations/conf-1/signature-1
-hashed-strings
-hashed-nodes
-timestamp
-signer-version
-signer-name
-value
-algo
-key-name-hint
-sign-images
-
-   fdtget image.fit /configurations/conf-1/signature-1 hashed-nodes
-/ /configurations/conf-1 /images/fdt-1 /images/fdt-1/hash /images/kernel /images/kernel/hash-1
-
-This gives us a bit of a look into the signature that mkimage added. Note you
-can also use fdtdump to list the entire device tree.
-
-Say we want to change the kernel that this configuration uses
-(/images/kernel). We could just put a new kernel in the image, but we will
-need to change the hash to match. Let's simulate that by changing a byte of
-the hash:
-
-    fdtget -tx image.fit /images/kernel/hash-1 value
-c9436464 6427e10f 423837e5 59898ef0 2c97b988
-    fdtput -tx image.fit /images/kernel/hash-1 value c9436464 6427e10f 423837e5 59898ef0 2c97b981
-
-Now check it again:
-
-   $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
-Verifying Hash Integrity ... sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
-rsa_verify_with_keynode: RSA failed to verify: -13
--
-Failed to verify required signature 'key-dev'
-Signature check Bad (error 1)
-
-This time we don't even get as far as checking the images, since the
-configuration signature doesn't match. We can't change any hashes without the
-signature check noticing. The configuration is essentially locked. U-Boot has
-a public key for which it requires a match, and will not permit the use of any
-configuration that does not match that public key. The only way the
-configuration will match is if it was signed by the matching private key.
-
-It would also be possible to add a new signature node that does match your new
-configuration. But that won't work since you are not allowed to change the
-configuration in any way. Try it with a fresh (valid) image if you like by
-running the mkimage link again. Then:
-
-   fdtput -p image.fit /configurations/conf-1/signature-1 value fred
-   $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
-Verifying Hash Integrity ... -
-sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
-rsa_verify_with_keynode: RSA failed to verify: -13
--
-Failed to verify required signature 'key-dev'
-Signature check Bad (error 1)
-
-
-Of course it would be possible to add an entirely new configuration and boot
-with that, but it still needs to be signed, so it won't help.
-
-
-6. Put the public key into U-Boot's image
------------------------------------------
-
-Having confirmed that the signature is doing its job, let's try it out in
-U-Boot on the board. U-Boot needs access to the public key corresponding to
-the private key that you signed with so that it can verify any kernels that
-you sign.
-
-   cd $UBOOT
-   make O=b/am335x_boneblack_vboot EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb
-
-Here we are overriding the normal device tree file with our one, which
-contains the public key.
-
-Now you have a special U-Boot image with the public key. It can verify can
-kernel that you sign with the private key as in step 5.
-
-If you like you can take a look at the public key information that mkimage
-added to U-Boot's device tree:
-
-   fdtget -p am335x-boneblack-pubkey.dtb /signature/key-dev
-required
-algo
-rsa,r-squared
-rsa,modulus
-rsa,n0-inverse
-rsa,num-bits
-key-name-hint
-
-This has information about the key and some pre-processed values which U-Boot
-can use to verify against it. These values are obtained from the public key
-certificate by mkimage, but require quite a bit of code to generate. To save
-code space in U-Boot, the information is extracted and written in raw form for
-U-Boot to easily use. The same mechanism is used in Google's Chrome OS.
-
-Notice the 'required' property. This marks the key as required - U-Boot will
-not boot any image that does not verify against this key.
-
-
-7. Put U-Boot and the kernel onto the board
--------------------------------------------
-
-The method here varies depending on how you are booting. For this example we
-are booting from an micro-SD card with two partitions, one for U-Boot and one
-for Linux. Put it into your machine and write U-Boot and the kernel to it.
-Here the card is /dev/sde:
-
-   cd $WORK
-   export UDEV=/dev/sde1   # Change thes two lines to the correct device
-   export KDEV=/dev/sde2
-   sudo mount $UDEV /mnt/tmp && sudo cp $UOUT/u-boot-dtb.img /mnt/tmp/u-boot.img  && sleep 1 && sudo umount $UDEV
-   sudo mount $KDEV /mnt/tmp && sudo cp $WORK/image.fit /mnt/tmp/boot/image.fit && sleep 1 && sudo umount $KDEV
-
-
-8. Try it
----------
-
-Boot the board using the commands below:
-
-   setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
-   ext2load mmc 0:2 82000000 /boot/image.fit
-   bootm 82000000
-
-You should then see something like this:
-
-U-Boot# setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
-U-Boot# ext2load mmc 0:2 82000000 /boot/image.fit
-7824930 bytes read in 589 ms (12.7 MiB/s)
-U-Boot# bootm 82000000
-## Loading kernel from FIT Image at 82000000 ...
-   Using 'conf-1' configuration
-   Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
-   Trying 'kernel' kernel subimage
-     Description:  unavailable
-     Created:      2014-06-01  19:32:54 UTC
-     Type:         Kernel Image
-     Compression:  lzo compressed
-     Data Start:   0x820000a8
-     Data Size:    7790938 Bytes = 7.4 MiB
-     Architecture: ARM
-     OS:           Linux
-     Load Address: 0x80008000
-     Entry Point:  0x80008000
-     Hash algo:    sha1
-     Hash value:   c94364646427e10f423837e559898ef02c97b988
-   Verifying Hash Integrity ... sha1+ OK
-## Loading fdt from FIT Image at 82000000 ...
-   Using 'conf-1' configuration
-   Trying 'fdt-1' fdt subimage
-     Description:  beaglebone-black
-     Created:      2014-06-01  19:32:54 UTC
-     Type:         Flat Device Tree
-     Compression:  uncompressed
-     Data Start:   0x8276e2ec
-     Data Size:    31547 Bytes = 30.8 KiB
-     Architecture: ARM
-     Hash algo:    sha1
-     Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
-   Verifying Hash Integrity ... sha1+ OK
-   Booting using the fdt blob at 0x8276e2ec
-   Uncompressing Kernel Image ... OK
-   Loading Device Tree to 8fff5000, end 8ffffb3a ... OK
-
-Starting kernel ...
-
-[    0.582377] omap_init_mbox: hwmod doesn't have valid attrs
-[    2.589651] musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
-[    2.595830] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
-[    2.606470] musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
-[    2.612723] musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
-[    2.940808] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
-[    7.248889] libphy: PHY 4a101000.mdio:01 not found
-[    7.253995] net eth0: phy 4a101000.mdio:01 not found on slave 1
-systemd-fsck[83]: Angstrom: clean, 50607/218160 files, 306348/872448 blocks
-
-.---O---.
-|       |                  .-.           o o
-|   |   |-----.-----.-----.| |   .----..-----.-----.
-|       |     | __  |  ---'| '--.|  .-'|     |     |
-|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
-'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
-                -'  |
-                '---'
-
-The Angstrom Distribution beaglebone ttyO0
-
-Angstrom v2012.12 - Kernel 3.14.1+
-
-beaglebone login:
-
-At this point your kernel has been verified and you can be sure that it is one
-that you signed. As an exercise, try changing image.fit as in step 5 and see
-what happens.
-
-
-Further Improvements
---------------------
-
-Several of the steps here can be easily automated. In particular it would be
-capital if signing and packaging a kernel were easy, perhaps a simple make
-target in the kernel.
-
-Some mention of how to use multiple .dtb files in a FIT might be useful.
-
-U-Boot's verified boot mechanism has not had a robust and independent security
-review. Such a review should look at the implementation and its resistance to
-attacks.
-
-Perhaps the verified boot feature could could be integrated into the Amstrom
-distribution.
-
-
-Simon Glass
-sjg@chromium.org
-2-June-14

doc/uImage.FIT/command_syntax_extensions.txt

@@ -1,201 +0,0 @@
-Command syntax extensions for the new uImage format
-===================================================
-
-Author: Bartlomiej Sieka <tur@semihalf.com>
-
-With the introduction of the new uImage format, bootm command (and other
-commands as well) have to understand new syntax of the arguments. This is
-necessary in order to specify objects contained in the new uImage, on which
-bootm has to operate. This note attempts to first summarize bootm usage
-scenarios, and then introduces new argument syntax.
-
-
-bootm usage scenarios
----------------------
-
-Below is a summary of bootm usage scenarios, focused on booting a PowerPC
-Linux kernel. The purpose of the following list is to document a complete list
-of supported bootm usages.
-
-Note: U-Boot supports two methods of booting a PowerPC Linux kernel: old way,
-i.e., without passing the Flattened Device Tree (FDT), and new way, where the
-kernel is passed a pointer to the FDT. The boot method is indicated for each
-scenario.
-
-
-1.  bootm		boot image at the current address, equivalent to 2,3,8
-
-Old uImage:
-2.  bootm <addr1>		    /* single image at <addr1> */
-3.  bootm <addr1>		    /* multi-image at <addr1>  */
-4.  bootm <addr1> -		    /* multi-image at <addr1>  */
-5.  bootm <addr1> <addr2>	    /* single image at <addr1> */
-6.  bootm <addr1> <addr2> <addr3>   /* single image at <addr1> */
-7.  bootm <addr1> -	  <addr3>   /* single image at <addr1> */
-
-New uImage:
-8.  bootm <addr1>
-9.  bootm [<addr1>]:<subimg1>
-10. bootm [<addr1>]#<conf>[#<extra-conf[#...]]
-11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
-12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
-13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
-14. bootm [<addr1>]:<subimg1> -			  [<addr3>]:<subimg3>
-15. bootm [<addr1>]:<subimg1> -			  <addr3>
-
-
-Ad. 1. This is equivalent to cases 2,3,8, depending on the type of image at
-the current image address.
-- boot method: see cases 2,3,8
-
-Ad. 2. Boot kernel image located at <addr1>.
-- boot method: non-FDT
-
-Ad. 3. First and second components of the image at <addr1> are assumed to be a
-kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
-with the ramdisk from the image.
-- boot method: depends on the number of components at <addr1>, and on whether
-  U-Boot is compiled with OF support:
-
-		    |	       2 components |	       3 components |
-		    |	   (kernel, initrd) | (kernel, initrd, fdt) |
----------------------------------------------------------------------
-#ifdef CONFIG_OF_*  |		    non-FDT |			FDT |
-#ifndef CONFIG_OF_* |		    non-FDT |		    non-FDT |
-
-Ad. 4. Similar to case 3, but the kernel is booted without initrd.  Second
-component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
-- boot method: see case 3
-
-Ad. 5. Boot kernel image located at <addr1> with initrd loaded with ramdisk
-from the image at <addr2>.
-- boot method: non-FDT
-
-Ad. 6. <addr1> is the address of a kernel image, <addr2> is the address of a
-ramdisk image, and <addr3> is the address of a FDT binary blob.  Kernel is
-booted with initrd loaded with ramdisk from the image at <addr2>.
-- boot method: FDT
-
-Ad. 7. <addr1> is the address of a kernel image and <addr3> is the address of
-a FDT binary blob. Kernel is booted without initrd.
-- boot method: FDT
-
-Ad. 8. Image at <addr1> is assumed to contain a default configuration, which
-is booted.
-- boot method: FDT or non-FDT, depending on whether the default configuration
-  defines FDT
-
-Ad. 9. Similar to case 2: boot kernel stored in <subimg1> from the image at
-address <addr1>.
-- boot method: non-FDT
-
-Ad. 10. Boot configuration <conf> from the image at <addr1>.
-- boot method: FDT or non-FDT, depending on whether the configuration given
-  defines FDT
-
-Ad. 11. Equivalent to case 5: boot kernel stored in <subimg1> from the image
-at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
-<addr2>.
-- boot method: non-FDT
-
-Ad. 12. Equivalent to case 6: boot kernel stored in <subimg1> from the image
-at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
-<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
-- boot method: FDT
-
-Ad. 13. Similar to case 12, the difference being that <addr3> is the address
-of FDT binary blob that is to be passed to the kernel.
-- boot method: FDT
-
-Ad. 14. Equivalent to case 7: boot kernel stored in <subimg1> from the image
-at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
-<addr3>.
-- boot method: FDT
-
-Ad. 15. Similar to case 14, the difference being that <addr3> is the address
-of the FDT binary blob that is to be passed to the kernel.
-- boot method: FDT
-
-
-New uImage argument syntax
---------------------------
-
-New uImage support introduces two new forms for bootm arguments, with the
-following syntax:
-
-- new uImage sub-image specification
-<addr>:<sub-image unit_name>
-
-- new uImage configuration specification
-<addr>#<configuration unit_name>
-
-- new uImage configuration specification with extra configuration components
-<addr>#<configuration unit_name>[#<extra configuration unit_name>[#..]]
-
-The extra configuration currently is supported only for additional device tree
-overlays to apply on the base device tree supplied by the first configuration
-unit.
-
-Examples:
-
-- boot kernel "kernel-1" stored in a new uImage located at 200000:
-bootm 200000:kernel-1
-
-- boot configuration "cfg-1" from a new uImage located at 200000:
-bootm 200000#cfg-1
-
-- boot configuration "cfg-1" with extra "cfg-2" from a new uImage located
-  at 200000:
-bootm 200000#cfg-1#cfg-2
-
-- boot "kernel-1" from a new uImage at 200000 with initrd "ramdisk-2" found in
-  some other new uImage stored at address 800000:
-bootm 200000:kernel-1 800000:ramdisk-2
-
-- boot "kernel-2" from a new uImage at 200000, with initrd "ramdisk-1" and FDT
-  "fdt-1", both stored in some other new uImage located at 800000:
-bootm 200000:kernel-1 800000:ramdisk-1 800000:fdt-1
-
-- boot kernel "kernel-2" with initrd "ramdisk-2", both stored in a new uImage
-  at address 200000, with a raw FDT blob stored at address 600000:
-bootm 200000:kernel-2 200000:ramdisk-2 600000
-
-- boot kernel "kernel-2" from new uImage at 200000 with FDT "fdt-1" from the
-  same new uImage:
-bootm 200000:kernel-2 - 200000:fdt-1
-
-
-Note on current image address
------------------------------
-
-When bootm is called without arguments, the image at current image address is
-booted. The current image address is the address set most recently by a load
-command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example, consider
-the following commands:
-
-tftp 200000 /tftpboot/kernel
-bootm
-Last command is equivalent to:
-bootm 200000
-
-In case of the new uImage argument syntax, the address portion of any argument
-can be omitted. If <addr3> is omitted, then it is assumed that image at
-<addr2> should be used. Similarly, when <addr2> is omitted, it is assumed that
-image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
-current image address is to be used. For example, consider the following
-commands:
-
-tftp 200000 /tftpboot/uImage
-bootm :kernel-1
-Last command is equivalent to:
-bootm 200000:kernel-1
-
-tftp 200000 /tftpboot/uImage
-bootm 400000:kernel-1 :ramdisk-1
-Last command is equivalent to:
-bootm 400000:kernel-1 400000:ramdisk-1
-
-tftp 200000 /tftpboot/uImage
-bootm :kernel-1 400000:ramdisk-1 :fdt-1
-Last command is equivalent to:
-bootm 200000:kernel-1 400000:ramdisk-1 400000:fdt-1

doc/uImage.FIT/howto.txt

@@ -1,411 +0,0 @@
-How to use images in the new image format
-=========================================
-
-Author: Bartlomiej Sieka <tur@semihalf.com>
-
-
-Overview
---------
-
-The new uImage format allows more flexibility in handling images of various
-types (kernel, ramdisk, etc.), it also enhances integrity protection of images
-with sha1 and md5 checksums.
-
-Two auxiliary tools are needed on the development host system in order to
-create an uImage in the new format: mkimage and dtc, although only one
-(mkimage) is invoked directly. dtc is called from within mkimage and operates
-behind the scenes, but needs to be present in the $PATH nevertheless. It is
-important that the dtc used has support for binary includes -- refer to
-
-	git://git.kernel.org/pub/scm/utils/dtc/dtc.git
-
-for its latest version. mkimage (together with dtc) takes as input
-an image source file, which describes the contents of the image and defines
-its various properties used during booting. By convention, image source file
-has the ".its" extension, also, the details of its format are given in
-doc/uImage.FIT/source_file_format.txt. The actual data that is to be included in
-the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
-form of paths to appropriate data files. The outcome of the image creation
-process is a binary file (by convention with the ".itb" extension) that
-contains all the referenced data (kernel, ramdisk, etc.) and other information
-needed by U-Boot to handle the uImage properly. The uImage file is then
-transferred to the target (e.g., via tftp) and booted using the bootm command.
-
-To summarize the prerequisites needed for new uImage creation:
-- mkimage
-- dtc (with support for binary includes)
-- image source file (*.its)
-- image data file(s)
-
-
-Here's a graphical overview of the image creation and booting process:
-
-image source file     mkimage + dtc		  transfer to target
-	+	     ---------------> image file --------------------> bootm
-image data file(s)
-
-SPL usage
----------
-
-The SPL can make use of the new image format as well, this traditionally
-is used to ship multiple device tree files within one image. Code in the SPL
-will choose the one matching the current board and append this to the
-U-Boot proper binary to be automatically used up by it.
-Aside from U-Boot proper and one device tree blob the SPL can load multiple,
-arbitrary image files as well. These binaries should be specified in their
-own subnode under the /images node, which should then be referenced from one or
-multiple /configurations subnodes. The required images must be enumerated in
-the "loadables" property as a list of strings.
-
-If a platform specific image source file (.its) is shipped with the U-Boot
-source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol.
-In this case it will be automatically used by U-Boot's Makefile to generate
-the image.
-If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR
-can point to a script which generates this image source file during
-the build process. It gets passed a list of device tree files (taken from the
-CONFIG_OF_LIST symbol).
-
-The SPL also records to a DT all additional images (called loadables) which are
-loaded. The information about loadables locations is passed via the DT node with
-fit-images name.
-
-Finally, if there are multiple xPL phases (e.g. SPL, VPL), images can be marked
-as intended for a particular phase using the 'phase' property. For example, if
-fit_image_load() is called with image_ph(IH_PHASE_SPL, IH_TYPE_FIRMWARE), then
-only the image listed into the "firmware" property where phase is set to "spl"
-will be loaded.
-
-Loadables Example
------------------
-Consider the following case for an ARM64 platform where U-Boot runs in EL2
-started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware).
-
-/dts-v1/;
-
-/ {
-	description = "Configuration to load ATF before U-Boot";
-
-	images {
-		uboot {
-			description = "U-Boot (64-bit)";
-			data = /incbin/("u-boot-nodtb.bin");
-			type = "firmware";
-			os = "u-boot";
-			arch = "arm64";
-			compression = "none";
-			load = <0x8 0x8000000>;
-			entry = <0x8 0x8000000>;
-			hash {
-				algo = "md5";
-			};
-		};
-		atf {
-			description = "ARM Trusted Firmware";
-			data = /incbin/("bl31.bin");
-			type = "firmware";
-			os = "arm-trusted-firmware";
-			arch = "arm64";
-			compression = "none";
-			load = <0xfffea000>;
-			entry = <0xfffea000>;
-			hash {
-				algo = "md5";
-			};
-		};
-		fdt_1 {
-			description = "zynqmp-zcu102-revA";
-			data = /incbin/("arch/arm/dts/zynqmp-zcu102-revA.dtb");
-			type = "flat_dt";
-			arch = "arm64";
-			compression = "none";
-			load = <0x100000>;
-			hash {
-				algo = "md5";
-			};
-		};
-	};
-	configurations {
-		default = "config_1";
-
-		config_1 {
-			description = "zynqmp-zcu102-revA";
-			firmware = "atf";
-			loadables = "uboot";
-			fdt = "fdt_1";
-		};
-	};
-};
-
-In this case the SPL records via fit-images DT node the information about
-loadables U-Boot image.
-
-ZynqMP> fdt addr $fdtcontroladdr
-ZynqMP> fdt print /fit-images
-fit-images {
-	uboot {
-		os = "u-boot";
-		type = "firmware";
-		size = <0x001017c8>;
-		entry = <0x00000008 0x08000000>;
-		load = <0x00000008 0x08000000>;
-	};
-};
-
-As you can see entry and load properties are 64bit wide to support loading
-images above 4GB (in past entry and load properties where just 32bit).
-
-
-Example 1 -- old-style (non-FDT) kernel booting
------------------------------------------------
-
-Consider a simple scenario, where a PPC Linux kernel built from sources on the
-development host is to be booted old-style (non-FDT) by U-Boot on an embedded
-target. Assume that the outcome of the build is vmlinux.bin.gz, a file which
-contains a gzip-compressed PPC Linux kernel (the only data file in this case).
-The uImage can be produced using the image source file
-doc/uImage.FIT/kernel.its (note that kernel.its assumes that vmlinux.bin.gz is
-in the current working directory; if desired, an alternative path can be
-specified in the kernel.its file). Here's how to create the image and inspect
-its contents:
-
-[on the host system]
-$ mkimage -f kernel.its kernel.itb
-DTC: dts->dtb  on file "kernel.its"
-$
-$ mkimage -l kernel.itb
-FIT description: Simple image with single Linux kernel
-Created:	 Tue Mar 11 17:26:15 2008
- Image 0 (kernel)
-  Description:	Vanilla Linux kernel
-  Type:		Kernel Image
-  Compression:	gzip compressed
-  Data Size:	943347 Bytes = 921.24 kB = 0.90 MB
-  Architecture: PowerPC
-  OS:		Linux
-  Load Address: 0x00000000
-  Entry Point:	0x00000000
-  Hash algo:	crc32
-  Hash value:	2ae2bb40
-  Hash algo:	sha1
-  Hash value:	3c200f34e2c226ddc789240cca0c59fc54a67cf4
- Default Configuration: 'config-1'
- Configuration 0 (config-1)
-  Description:	Boot Linux kernel
-  Kernel:	kernel
-
-
-The resulting image file kernel.itb can be now transferred to the target,
-inspected and booted (note that first three U-Boot commands below are shown
-for completeness -- they are part of the standard booting procedure and not
-specific to the new image format).
-
-[on the target system]
-=> print nfsargs
-nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
-=> print addip
-addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
-=> run nfsargs addip
-=> tftp 900000 /path/to/tftp/location/kernel.itb
-Using FEC device
-TFTP from server 192.168.1.1; our IP address is 192.168.160.5
-Filename '/path/to/tftp/location/kernel.itb'.
-Load address: 0x900000
-Loading: #################################################################
-done
-Bytes transferred = 944464 (e6950 hex)
-=> iminfo
-
-## Checking Image at 00900000 ...
-   FIT image found
-   FIT description: Simple image with single Linux kernel
-   Created:	    2008-03-11	16:26:15 UTC
-    Image 0 (kernel)
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000e0
-     Data Size:    943347 Bytes = 921.2 kB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2ae2bb40
-     Hash algo:    sha1
-     Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
-    Default Configuration: 'config-1'
-    Configuration 0 (config-1)
-     Description:  Boot Linux kernel
-     Kernel:	   kernel
-
-=> bootm
-## Booting kernel from FIT Image at 00900000 ...
-   Using 'config-1' configuration
-   Trying 'kernel' kernel subimage
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000e0
-     Data Size:    943347 Bytes = 921.2 kB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2ae2bb40
-     Hash algo:    sha1
-     Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
-   Verifying Hash Integrity ... crc32+ sha1+ OK
-   Uncompressing Kernel Image ... OK
-Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
-Linux version 2.4.25 (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 czw lip 5 17:56:18 CEST 2007
-On node 0 totalpages: 65536
-zone(0): 65536 pages.
-zone(1): 0 pages.
-zone(2): 0 pages.
-Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_6xx ip=192.168.160.5:192.168.1.1::255.255.0.0:lite5200b:eth0:off panic=1
-Calibrating delay loop... 307.20 BogoMIPS
-
-
-Example 2 -- new-style (FDT) kernel booting
--------------------------------------------
-
-Consider another simple scenario, where a PPC Linux kernel is to be booted
-new-style, i.e., with a FDT blob. In this case there are two prerequisite data
-files: vmlinux.bin.gz (Linux kernel) and target.dtb (FDT blob). The uImage can
-be produced using image source file doc/uImage.FIT/kernel_fdt.its like this
-(note again, that both prerequisite data files are assumed to be present in
-the current working directory -- image source file kernel_fdt.its can be
-modified to take the files from some other location if needed):
-
-[on the host system]
-$ mkimage -f kernel_fdt.its kernel_fdt.itb
-DTC: dts->dtb  on file "kernel_fdt.its"
-$
-$ mkimage -l kernel_fdt.itb
-FIT description: Simple image with single Linux kernel and FDT blob
-Created:	 Tue Mar 11 16:29:22 2008
- Image 0 (kernel)
-  Description:	Vanilla Linux kernel
-  Type:		Kernel Image
-  Compression:	gzip compressed
-  Data Size:	1092037 Bytes = 1066.44 kB = 1.04 MB
-  Architecture: PowerPC
-  OS:		Linux
-  Load Address: 0x00000000
-  Entry Point:	0x00000000
-  Hash algo:	crc32
-  Hash value:	2c0cc807
-  Hash algo:	sha1
-  Hash value:	264b59935470e42c418744f83935d44cdf59a3bb
- Image 1 (fdt-1)
-  Description:	Flattened Device Tree blob
-  Type:		Flat Device Tree
-  Compression:	uncompressed
-  Data Size:	16384 Bytes = 16.00 kB = 0.02 MB
-  Architecture: PowerPC
-  Hash algo:	crc32
-  Hash value:	0d655d71
-  Hash algo:	sha1
-  Hash value:	25ab4e15cd4b8a5144610394560d9c318ce52def
- Default Configuration: 'conf-1'
- Configuration 0 (conf-1)
-  Description:	Boot Linux kernel with FDT blob
-  Kernel:	kernel
-  FDT:		fdt-1
-
-
-The resulting image file kernel_fdt.itb can be now transferred to the target,
-inspected and booted:
-
-[on the target system]
-=> tftp 900000 /path/to/tftp/location/kernel_fdt.itb
-Using FEC device
-TFTP from server 192.168.1.1; our IP address is 192.168.160.5
-Filename '/path/to/tftp/location/kernel_fdt.itb'.
-Load address: 0x900000
-Loading: #################################################################
-	 ###########
-done
-Bytes transferred = 1109776 (10ef10 hex)
-=> iminfo
-
-## Checking Image at 00900000 ...
-   FIT image found
-   FIT description: Simple image with single Linux kernel and FDT blob
-   Created:	    2008-03-11	15:29:22 UTC
-    Image 0 (kernel)
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000ec
-     Data Size:    1092037 Bytes =  1 MB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2c0cc807
-     Hash algo:    sha1
-     Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
-    Image 1 (fdt-1)
-     Description:  Flattened Device Tree blob
-     Type:	   Flat Device Tree
-     Compression:  uncompressed
-     Data Start:   0x00a0abdc
-     Data Size:    16384 Bytes = 16 kB
-     Architecture: PowerPC
-     Hash algo:    crc32
-     Hash value:   0d655d71
-     Hash algo:    sha1
-     Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
-    Default Configuration: 'conf-1'
-    Configuration 0 (conf-1)
-     Description:  Boot Linux kernel with FDT blob
-     Kernel:	   kernel
-     FDT:	   fdt-1
-=> bootm
-## Booting kernel from FIT Image at 00900000 ...
-   Using 'conf-1' configuration
-   Trying 'kernel' kernel subimage
-     Description:  Vanilla Linux kernel
-     Type:	   Kernel Image
-     Compression:  gzip compressed
-     Data Start:   0x009000ec
-     Data Size:    1092037 Bytes =  1 MB
-     Architecture: PowerPC
-     OS:	   Linux
-     Load Address: 0x00000000
-     Entry Point:  0x00000000
-     Hash algo:    crc32
-     Hash value:   2c0cc807
-     Hash algo:    sha1
-     Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
-   Verifying Hash Integrity ... crc32+ sha1+ OK
-   Uncompressing Kernel Image ... OK
-## Flattened Device Tree from FIT Image at 00900000
-   Using 'conf-1' configuration
-   Trying 'fdt-1' FDT blob subimage
-     Description:  Flattened Device Tree blob
-     Type:	   Flat Device Tree
-     Compression:  uncompressed
-     Data Start:   0x00a0abdc
-     Data Size:    16384 Bytes = 16 kB
-     Architecture: PowerPC
-     Hash algo:    crc32
-     Hash value:   0d655d71
-     Hash algo:    sha1
-     Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
-   Verifying Hash Integrity ... crc32+ sha1+ OK
-   Booting using the fdt blob at 0xa0abdc
-   Loading Device Tree to 007fc000, end 007fffff ... OK
-[    0.000000] Using lite5200 machine description
-[    0.000000] Linux version 2.6.24-rc6-gaebecdfc (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sat Jan 12 15:38:48 CET 2008
-
-
-Example 3 -- advanced booting
------------------------------
-
-Refer to doc/uImage.FIT/multi.its for an image source file that allows more
-sophisticated booting scenarios (multiple kernels, ramdisks and fdt blobs).

doc/uImage.FIT/kernel.its

@@ -1,91 +0,0 @@
-/*
- * Simple U-Boot uImage source file containing a single kernel
- */
-
-/dts-v1/;
-
-/ {
-	description = "Simple image with single Linux kernel";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			description = "Vanilla Linux kernel";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "crc32";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-	};
-
-	configurations {
-		default = "config-1";
-		config-1 {
-			description = "Boot Linux kernel";
-			kernel = "kernel";
-		};
-	};
-};
-
-
-
-For x86 a setup node is also required: see x86-fit-boot.txt.
-
-/dts-v1/;
-
-/ {
-	description = "Simple image with single Linux kernel on x86";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			description = "Vanilla Linux kernel";
-			data = /incbin/("./image.bin.lzo");
-			type = "kernel";
-			arch = "x86";
-			os = "linux";
-			compression = "lzo";
-			load = <0x01000000>;
-			entry = <0x00000000>;
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-
-		setup {
-			description = "Linux setup.bin";
-			data = /incbin/("./setup.bin");
-			type = "x86_setup";
-			arch = "x86";
-			os = "linux";
-			compression = "none";
-			load = <0x00090000>;
-			entry = <0x00090000>;
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-	};
-
-	configurations {
-		default = "config-1";
-		config-1 {
-			description = "Boot Linux kernel";
-			kernel = "kernel";
-			setup = "setup";
-		};
-	};
-};
-
-Note: the above assumes a 32-bit kernel. To directly boot a 64-bit kernel,
-change both arch values to "x86_64". U-Boot will then change to 64-bit mode
-before booting the kernel (see boot_linux_kernel()).

doc/uImage.FIT/kernel_fdt.its

@@ -1,51 +0,0 @@
-/*
- * Simple U-Boot uImage source file containing a single kernel and FDT blob
- */
-
-/dts-v1/;
-
-/ {
-	description = "Simple image with single Linux kernel and FDT blob";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			description = "Vanilla Linux kernel";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "crc32";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-		fdt-1 {
-			description = "Flattened Device Tree blob";
-			data = /incbin/("./target.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "none";
-			hash-1 {
-				algo = "crc32";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-	};
-
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			description = "Boot Linux kernel with FDT blob";
-			kernel = "kernel";
-			fdt = "fdt-1";
-		};
-	};
-};

doc/uImage.FIT/kernel_fdts_compressed.its

@@ -1,73 +0,0 @@
-/*
- * U-Boot uImage source file with a kernel and multiple compressed FDT blobs.
- * Since the FDTs are compressed, configurations must provide a compatible
- * string to match directly.
- */
-
-/dts-v1/;
-
-/ {
-	description = "Image with single Linux kernel and compressed FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			description = "Vanilla Linux kernel";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "crc32";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-		fdt@1 {
-			description = "Flattened Device Tree blob 1";
-			data = /incbin/("./myboard-var1.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "gzip";
-			hash-1 {
-				algo = "crc32";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-		fdt@2 {
-			description = "Flattened Device Tree blob 2";
-			data = /incbin/("./myboard-var2.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "lzma";
-			hash-1 {
-				algo = "crc32";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-	};
-
-	configurations {
-		default = "conf@1";
-		conf@1 {
-			description = "Boot Linux kernel with FDT blob 1";
-			kernel = "kernel";
-			fdt = "fdt@1";
-			compatible = "myvendor,myboard-variant1";
-		};
-		conf@2 {
-			description = "Boot Linux kernel with FDT blob 2";
-			kernel = "kernel";
-			fdt = "fdt@2";
-			compatible = "myvendor,myboard-variant2";
-		};
-	};
-};

doc/uImage.FIT/multi-with-fpga.its

@@ -1,68 +0,0 @@
-/*
- * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
- * This example makes use of the 'loadables' field
- */
-
-/dts-v1/;
-
-/ {
-	description = "Configuration to load fpga before Kernel";
-	#address-cells = <1>;
-
-	images {
-		fdt-1 {
-			description = "zc706";
-			data = /incbin/("/tftpboot/devicetree.dtb");
-			type = "flat_dt";
-			arch = "arm";
-			compression = "none";
-			load = <0x10000000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-
-		fpga {
-			description = "FPGA";
-			data = /incbin/("/tftpboot/download.bit");
-			type = "fpga";
-			arch = "arm";
-			compression = "none";
-			load = <0x30000000>;
-			compatible = "u-boot,fpga-legacy"
-			hash-1 {
-				algo = "md5";
-			};
-		};
-
-		linux_kernel {
-			description = "Linux";
-			data = /incbin/("/tftpboot/zImage");
-			type = "kernel";
-			arch = "arm";
-			os = "linux";
-			compression = "none";
-			load = <0x8000>;
-			entry = <0x8000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-	};
-
-	configurations {
-		default = "config-2";
-		config-1 {
-			description = "Linux";
-			kernel = "linux_kernel";
-			fdt = "fdt-1";
-		};
-
-		config-2 {
-			description = "Linux with fpga";
-			kernel = "linux_kernel";
-			fdt = "fdt-1";
-			loadables = "fpga";
-		};
-	};
-};

doc/uImage.FIT/multi-with-loadables.its

@@ -1,89 +0,0 @@
-/*
- * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
- * This example makes use of the 'loadables' field
- */
-
-/dts-v1/;
-
-/ {
-	description = "Configuration to load a Xen Kernel";
-	#address-cells = <1>;
-
-	images {
-		xen_kernel {
-			description = "xen binary";
-			data = /incbin/("./xen");
-			type = "kernel";
-			arch = "arm";
-			os = "linux";
-			compression = "none";
-			load = <0xa0000000>;
-			entry = <0xa0000000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-
-		fdt-1 {
-			description = "xexpress-ca15 tree blob";
-			data = /incbin/("./vexpress-v2p-ca15-tc1.dtb");
-			type = "flat_dt";
-			arch = "arm";
-			compression = "none";
-			load = <0xb0000000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-
-		fdt-2 {
-			description = "xexpress-ca15 tree blob";
-			data = /incbin/("./vexpress-v2p-ca15-tc1.dtb");
-			type = "flat_dt";
-			arch = "arm";
-			compression = "none";
-			load = <0xb0400000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-
-		linux_kernel {
-			description = "Linux Image";
-			data = /incbin/("./Image");
-			type = "kernel";
-			arch = "arm";
-			os = "linux";
-			compression = "none";
-			load = <0xa0000000>;
-			entry = <0xa0000000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-	};
-
-	configurations {
-		default = "config-2";
-
-		config-1 {
-			description = "Just plain Linux";
-			kernel = "linux_kernel";
-			fdt = "fdt-1";
-		};
-
-		config-2 {
-			description = "Xen one loadable";
-			kernel = "xen_kernel";
-			fdt = "fdt-1";
-			loadables = "linux_kernel";
-		};
-
-		config-3 {
-			description = "Xen two loadables";
-			kernel = "xen_kernel";
-			fdt = "fdt-1";
-			loadables = "linux_kernel", "fdt-2";
-		};
-	};
-};

doc/uImage.FIT/multi.its

@@ -1,133 +0,0 @@
-/*
- * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
- */
-
-/dts-v1/;
-
-/ {
-	description = "Various kernels, ramdisks and FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel-1 {
-			description = "vanilla-2.6.23";
-			data = /incbin/("./vmlinux.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "md5";
-			};
-			hash-2 {
-				algo = "sha1";
-			};
-		};
-
-		kernel-2 {
-			description = "2.6.23-denx";
-			data = /incbin/("./2.6.23-denx.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-
-		kernel-3 {
-			description = "2.4.25-denx";
-			data = /incbin/("./2.4.25-denx.bin.gz");
-			type = "kernel";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "md5";
-			};
-		};
-
-		ramdisk-1 {
-			description = "eldk-4.2-ramdisk";
-			data = /incbin/("./eldk-4.2-ramdisk");
-			type = "ramdisk";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-
-		ramdisk-2 {
-			description = "eldk-3.1-ramdisk";
-			data = /incbin/("./eldk-3.1-ramdisk");
-			type = "ramdisk";
-			arch = "ppc";
-			os = "linux";
-			compression = "gzip";
-			load = <00000000>;
-			entry = <00000000>;
-			hash-1 {
-				algo = "crc32";
-			};
-		};
-
-		fdt-1 {
-			description = "tqm5200-fdt";
-			data = /incbin/("./tqm5200.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "none";
-			hash-1 {
-				algo = "crc32";
-			};
-		};
-
-		fdt-2 {
-			description = "tqm5200s-fdt";
-			data = /incbin/("./tqm5200s.dtb");
-			type = "flat_dt";
-			arch = "ppc";
-			compression = "none";
-			load = <00700000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-
-	};
-
-	configurations {
-		default = "config-1";
-
-		config-1 {
-			description = "tqm5200 vanilla-2.6.23 configuration";
-			kernel = "kernel-1";
-			ramdisk = "ramdisk-1";
-			fdt = "fdt-1";
-		};
-
-		config-2 {
-			description = "tqm5200s denx-2.6.23 configuration";
-			kernel = "kernel-2";
-			ramdisk = "ramdisk-1";
-			fdt = "fdt-2";
-		};
-
-		config-3 {
-			description = "tqm5200s denx-2.4.25 configuration";
-			kernel = "kernel-3";
-			ramdisk = "ramdisk-2";
-		};
-	};
-};

doc/uImage.FIT/multi_spl.its

@@ -1,96 +0,0 @@
-/dts-v1/;
-
-/*
- * (Bogus) example FIT image description file demonstrating the usage
- * of multiple images loaded by the SPL.
- * Several binaries will be loaded at their respective load addresses.
- *
- * For booting U-Boot, "firmware" is searched first. If not found, "loadables"
- * is used to identify images to be loaded into memory. If falcon boot is
- * enabled, "kernel" is searched first. If not found, it falls back to the
- * same flow as booting U-Boot. Changing image type will result skipping
- * specific image.
- *
- * Finally the one image specifying an entry point will be entered by the SPL.
- */
-
-/ {
-	description = "multiple firmware blobs and U-Boot, loaded by SPL";
-	#address-cells = <0x1>;
-
-	images {
-
-		uboot {
-			description = "U-Boot (64-bit)";
-			type = "standalone";
-			arch = "arm64";
-			compression = "none";
-			load = <0x4a000000>;
-		};
-
-		atf {
-			description = "ARM Trusted Firmware";
-			type = "firmware";
-			arch = "arm64";
-			compression = "none";
-			load = <0x18000>;
-			entry = <0x18000>;
-		};
-
-		mgmt-firmware {
-			description = "arisc management processor firmware";
-			type = "firmware";
-			arch = "or1k";
-			compression = "none";
-			load = <0x40000>;
-		};
-
-		fdt-1 {
-			description = "Pine64+ DT";
-			type = "flat_dt";
-			compression = "none";
-			load = <0x4fa00000>;
-			arch = "arm64";
-		};
-
-		fdt-2 {
-			description = "Pine64 DT";
-			type = "flat_dt";
-			compression = "none";
-			load = <0x4fa00000>;
-			arch = "arm64";
-		};
-
-		kernel {
-			description = "4.7-rc5 kernel";
-			type = "kernel";
-			compression = "none";
-			load = <0x40080000>;
-			arch = "arm64";
-		};
-
-		initrd {
-			description = "Debian installer initrd";
-			type = "ramdisk";
-			compression = "none";
-			load = <0x4fe00000>;
-			arch = "arm64";
-		};
-	};
-
-	configurations {
-		default = "config-1";
-
-		config-1 {
-			description = "sun50i-a64-pine64-plus";
-			loadables = "uboot", "atf", "kernel", "initrd";
-			fdt = "fdt-1";
-		};
-
-		config-2 {
-			description = "sun50i-a64-pine64";
-			loadables = "uboot", "atf", "mgmt-firmware";
-			fdt = "fdt-2";
-		};
-	};
-};

doc/uImage.FIT/overlay-fdt-boot.txt

@@ -1,225 +0,0 @@
-U-Boot FDT Overlay FIT usage
-============================
-
-Introduction
-------------
-In many cases it is desirable to have a single FIT image support a multitude
-of similar boards and their expansion options. The same kernel on DT enabled
-platforms can support this easily enough by providing a DT blob upon boot
-that matches the desired configuration.
-
-This document focuses on specifically using overlays as part of a FIT image.
-General information regarding overlays including its syntax and building it
-can be found in doc/README.fdt-overlays
-
-Configuration without overlays
-------------------------------
-
-Take a hypothetical board named 'foo' where there are different supported
-revisions, reva and revb. Assume that both board revisions can use add a bar
-add-on board, while only the revb board can use a baz add-on board.
-
-Without using overlays the configuration would be as follows for every case.
-
-	/dts-v1/;
-	/ {
-		images {
-			kernel {
-				data = /incbin/("./zImage");
-				type = "kernel";
-				arch = "arm";
-				os = "linux";
-				load = <0x82000000>;
-				entry = <0x82000000>;
-			};
-			fdt-1 {
-				data = /incbin/("./foo-reva.dtb");
-				type = "flat_dt";
-				arch = "arm";
-			};
-			fdt-2 {
-				data = /incbin/("./foo-revb.dtb");
-				type = "flat_dt";
-				arch = "arm";
-			};
-			fdt-3 {
-				data = /incbin/("./foo-reva-bar.dtb");
-				type = "flat_dt";
-				arch = "arm";
-			};
-			fdt-4 {
-				data = /incbin/("./foo-revb-bar.dtb");
-				type = "flat_dt";
-				arch = "arm";
-			};
-			fdt-5 {
-				data = /incbin/("./foo-revb-baz.dtb");
-				type = "flat_dt";
-				arch = "arm";
-			};
-			fdt-6 {
-				data = /incbin/("./foo-revb-bar-baz.dtb");
-				type = "flat_dt";
-				arch = "arm";
-			};
-		};
-
-		configurations {
-			default = "foo-reva.dtb;
-			foo-reva.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1";
-			};
-			foo-revb.dtb {
-				kernel = "kernel";
-				fdt = "fdt-2";
-			};
-			foo-reva-bar.dtb {
-				kernel = "kernel";
-				fdt = "fdt-3";
-			};
-			foo-revb-bar.dtb {
-				kernel = "kernel";
-				fdt = "fdt-4";
-			};
-			foo-revb-baz.dtb {
-				kernel = "kernel";
-				fdt = "fdt-5";
-			};
-			foo-revb-bar-baz.dtb {
-				kernel = "kernel";
-				fdt = "fdt-6";
-			};
-		};
-	};
-
-Note the blob needs to be compiled for each case and the combinatorial explosion of
-configurations. A typical device tree blob is in the low hunderds of kbytes so a
-multitude of configuration grows the image quite a bit.
-
-Booting this image is done by using
-
-	# bootm <addr>#<config>
-
-Where config is one of:
-	foo-reva.dtb, foo-revb.dtb, foo-reva-bar.dtb, foo-revb-bar.dtb,
-	foo-revb-baz.dtb, foo-revb-bar-baz.dtb
-
-This selects the DTB to use when booting.
-
-Configuration using overlays
-----------------------------
-
-Device tree overlays can be applied to a base DT and result in the same blob
-being passed to the booting kernel. This saves on space and avoid the combinatorial
-explosion problem.
-
-	/dts-v1/;
-	/ {
-		images {
-			kernel {
-				data = /incbin/("./zImage");
-				type = "kernel";
-				arch = "arm";
-				os = "linux";
-				load = <0x82000000>;
-				entry = <0x82000000>;
-			};
-			fdt-1 {
-				data = /incbin/("./foo.dtb");
-				type = "flat_dt";
-				arch = "arm";
-				load = <0x87f00000>;
-			};
-			fdt-2 {
-				data = /incbin/("./reva.dtbo");
-				type = "flat_dt";
-				arch = "arm";
-				load = <0x87fc0000>;
-			};
-			fdt-3 {
-				data = /incbin/("./revb.dtbo");
-				type = "flat_dt";
-				arch = "arm";
-				load = <0x87fc0000>;
-			};
-			fdt-4 {
-				data = /incbin/("./bar.dtbo");
-				type = "flat_dt";
-				arch = "arm";
-				load = <0x87fc0000>;
-			};
-			fdt-5 {
-				data = /incbin/("./baz.dtbo");
-				type = "flat_dt";
-				arch = "arm";
-				load = <0x87fc0000>;
-			};
-		};
-
-		configurations {
-			default = "foo-reva.dtb;
-			foo-reva.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1", "fdt-2";
-			};
-			foo-revb.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1", "fdt-3";
-			};
-			foo-reva-bar.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1", "fdt-2", "fdt-4";
-			};
-			foo-revb-bar.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1", "fdt-3", "fdt-4";
-			};
-			foo-revb-baz.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1", "fdt-3", "fdt-5";
-			};
-			foo-revb-bar-baz.dtb {
-				kernel = "kernel";
-				fdt = "fdt-1", "fdt-3", "fdt-4", "fdt-5";
-			};
-			bar {
-				fdt = "fdt-4";
-			};
-			baz {
-				fdt = "fdt-5";
-			};
-		};
-	};
-
-Booting this image is exactly the same as the non-overlay example.
-u-boot will retrieve the base blob and apply the overlays in sequence as
-they are declared in the configuration.
-
-Note the minimum amount of different DT blobs, as well as the requirement for
-the DT blobs to have a load address; the overlay application requires the blobs
-to be writeable.
-
-Configuration using overlays and feature selection
---------------------------------------------------
-
-Although the configuration in the previous section works is a bit inflexible
-since it requires all possible configuration options to be laid out before
-hand in the FIT image. For the add-on boards the extra config selection method
-might make sense.
-
-Note the two bar & baz configuration nodes. To boot a reva board with
-the bar add-on board enabled simply use:
-
-	# bootm <addr>#foo-reva.dtb#bar
-
-While booting a revb with bar and baz is as follows:
-
-	# bootm <addr>#foo-revb.dtb#bar#baz
-
-The limitation for a feature selection configuration node is that a single
-fdt option is currently supported.
-
-Pantelis Antoniou
-pantelis.antoniou@konsulko.com
-12/6/2017

doc/uImage.FIT/sec_firmware_ppa.its

@@ -1,49 +0,0 @@
-/dts-v1/;
-
-/*
- * Example FIT image description file demonstrating the usage
- * of SEC Firmware and multiple loadable images loaded by the u-boot.
- * For booting PPA (SEC Firmware), "firmware" is searched and loaded.
- *
- * Multiple binaries will be loaded as "loadables" (if present) at their
- * respective load offsets from firmware image address.
- */
-
-/{
-	description = "PPA Firmware";
-	#address-cells = <1>;
-	images {
-		firmware@1 {
-			description = "PPA Firmware: <version>";
-			data = /incbin/("../obj/monitor.bin");
-			type = "firmware";
-			arch = "arm64";
-			compression = "none";
-		};
-		trustedOS@1 {
-			description = "Trusted OS";
-			data = /incbin/("../../tee.bin");
-			type = "OS";
-			arch = "arm64";
-			compression = "none";
-			load = <0x00200000>;
-		};
-		fuse_scr {
-			description = "Fuse Script";
-			data = /incbin/("../../fuse_scr.bin");
-			type = "firmware";
-			arch = "arm64";
-			compression = "none";
-			load = <0x00180000>;
-		};
-	};
-
-	configurations {
-		default = "config-1";
-		config-1 {
-			description = "PPA Secure firmware";
-			firmware = "firmware@1";
-			loadables = "trustedOS@1", "fuse_scr";
-		};
-	};
-};

doc/uImage.FIT/sign-configs.its

@@ -1,45 +0,0 @@
-/dts-v1/;
-
-/ {
-	description = "Chrome OS kernel image with one or more FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			data = /incbin/("test-kernel.bin");
-			type = "kernel_noload";
-			arch = "sandbox";
-			os = "linux";
-			compression = "lzo";
-			load = <0x4>;
-			entry = <0x8>;
-			kernel-version = <1>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-		fdt-1 {
-			description = "snow";
-			data = /incbin/("sandbox-kernel.dtb");
-			type = "flat_dt";
-			arch = "sandbox";
-			compression = "none";
-			fdt-version = <1>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-	};
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			kernel = "kernel";
-			fdt = "fdt-1";
-			signature {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-				sign-images = "fdt", "kernel";
-			};
-		};
-	};
-};

doc/uImage.FIT/sign-images.its

@@ -1,42 +0,0 @@
-/dts-v1/;
-
-/ {
-	description = "Chrome OS kernel image with one or more FDT blobs";
-	#address-cells = <1>;
-
-	images {
-		kernel {
-			data = /incbin/("test-kernel.bin");
-			type = "kernel_noload";
-			arch = "sandbox";
-			os = "linux";
-			compression = "none";
-			load = <0x4>;
-			entry = <0x8>;
-			kernel-version = <1>;
-			signature {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-			};
-		};
-		fdt-1 {
-			description = "snow";
-			data = /incbin/("sandbox-kernel.dtb");
-			type = "flat_dt";
-			arch = "sandbox";
-			compression = "none";
-			fdt-version = <1>;
-			signature {
-				algo = "sha1,rsa2048";
-				key-name-hint = "dev";
-			};
-		};
-	};
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			kernel = "kernel";
-			fdt = "fdt-1";
-		};
-	};
-};

doc/uImage.FIT/signature.txt

@@ -1,707 +0,0 @@
-U-Boot FIT Signature Verification
-=================================
-
-Introduction
-------------
-FIT supports hashing of images so that these hashes can be checked on
-loading. This protects against corruption of the image. However it does not
-prevent the substitution of one image for another.
-
-The signature feature allows the hash to be signed with a private key such
-that it can be verified using a public key later. Provided that the private
-key is kept secret and the public key is stored in a non-volatile place,
-any image can be verified in this way.
-
-See verified-boot.txt for more general information on verified boot.
-
-
-Concepts
---------
-Some familiarity with public key cryptography is assumed in this section.
-
-The procedure for signing is as follows:
-
-   - hash an image in the FIT
-   - sign the hash with a private key to produce a signature
-   - store the resulting signature in the FIT
-
-The procedure for verification is:
-
-   - read the FIT
-   - obtain the public key
-   - extract the signature from the FIT
-   - hash the image from the FIT
-   - verify (with the public key) that the extracted signature matches the
-       hash
-
-The signing is generally performed by mkimage, as part of making a firmware
-image for the device. The verification is normally done in U-Boot on the
-device.
-
-
-Algorithms
-----------
-In principle any suitable algorithm can be used to sign and verify a hash.
-U-Boot supports a few hashing and verification algorithms. See below for
-details.
-
-While it is acceptable to bring in large cryptographic libraries such as
-openssl on the host side (e.g. mkimage), it is not desirable for U-Boot.
-For the run-time verification side, it is important to keep code and data
-size as small as possible.
-
-For this reason the RSA image verification uses pre-processed public keys
-which can be used with a very small amount of code - just some extraction
-of data from the FDT and exponentiation mod n. Code size impact is a little
-under 5KB on Tegra Seaboard, for example.
-
-It is relatively straightforward to add new algorithms if required. If
-another RSA variant is needed, then it can be added with the
-U_BOOT_CRYPTO_ALGO() macro. If another algorithm is needed (such as DSA) then
-it can be placed in a directory alongside lib/rsa/, and its functions added
-using U_BOOT_CRYPTO_ALGO().
-
-
-Creating an RSA key pair and certificate
-----------------------------------------
-To create a new public/private key pair, size 2048 bits:
-
-$ openssl genpkey -algorithm RSA -out keys/dev.key \
-    -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
-
-To create a certificate for this containing the public key:
-
-$ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
-
-If you like you can look at the public key also:
-
-$ openssl rsa -in keys/dev.key -pubout
-
-
-Device Tree Bindings
---------------------
-The following properties are required in the FIT's signature node(s) to
-allow the signer to operate. These should be added to the .its file.
-Signature nodes sit at the same level as hash nodes and are called
-signature-1, signature-2, etc.
-
-- algo: Algorithm name (e.g. "sha1,rsa2048")
-
-- key-name-hint: Name of key to use for signing. The keys will normally be in
-a single directory (parameter -k to mkimage). For a given key <name>, its
-private key is stored in <name>.key and the certificate is stored in
-<name>.crt.
-
-When the image is signed, the following properties are added (mandatory):
-
-- value: The signature data (e.g. 256 bytes for 2048-bit RSA)
-
-When the image is signed, the following properties are optional:
-
-- timestamp: Time when image was signed (standard Unix time_t format)
-
-- signer-name: Name of the signer (e.g. "mkimage")
-
-- signer-version: Version string of the signer (e.g. "2013.01")
-
-- comment: Additional information about the signer or image
-
-- padding: The padding algorithm, it may be pkcs-1.5 or pss,
-	if no value is provided we assume pkcs-1.5
-
-For config bindings (see Signed Configurations below), the following
-additional properties are optional:
-
-- sign-images: A list of images to sign, each being a property of the conf
-node that contains then. The default is "kernel,fdt" which means that these
-two images will be looked up in the config and signed if present.
-
-For config bindings, these properties are added by the signer:
-
-- hashed-nodes: A list of nodes which were hashed by the signer. Each is
-	a string - the full path to node. A typical value might be:
-
-	hashed-nodes = "/", "/configurations/conf-1", "/images/kernel",
-		"/images/kernel/hash-1", "/images/fdt-1",
-		"/images/fdt-1/hash-1";
-
-- hashed-strings: The start and size of the string region of the FIT that
-	was hashed
-
-Example: See sign-images.its for an example image tree source file and
-sign-configs.its for config signing.
-
-
-Public Key Storage
-------------------
-In order to verify an image that has been signed with a public key we need to
-have a trusted public key. This cannot be stored in the signed image, since
-it would be easy to alter. For this implementation we choose to store the
-public key in U-Boot's control FDT (using CONFIG_OF_CONTROL).
-
-Public keys should be stored as sub-nodes in a /signature node. Required
-properties are:
-
-- algo: Algorithm name (e.g. "sha1,rsa2048" or "sha256,ecdsa256")
-
-Optional properties are:
-
-- key-name-hint: Name of key used for signing. This is only a hint since it
-is possible for the name to be changed. Verification can proceed by checking
-all available signing keys until one matches.
-
-- required: If present this indicates that the key must be verified for the
-image / configuration to be considered valid. Only required keys are
-normally verified by the FIT image booting algorithm. Valid values are
-"image" to force verification of all images, and "conf" to force verification
-of the selected configuration (which then relies on hashes in the images to
-verify those).
-
-Each signing algorithm has its own additional properties.
-
-For RSA the following are mandatory:
-
-- rsa,num-bits: Number of key bits (e.g. 2048)
-- rsa,modulus: Modulus (N) as a big-endian multi-word integer
-- rsa,exponent: Public exponent (E) as a 64 bit unsigned integer
-- rsa,r-squared: (2^num-bits)^2 as a big-endian multi-word integer
-- rsa,n0-inverse: -1 / modulus[0] mod 2^32
-
-For ECDSA the following are mandatory:
-- ecdsa,curve: Name of ECDSA curve (e.g. "prime256v1")
-- ecdsa,x-point: Public key X coordinate as a big-endian multi-word integer
-- ecdsa,y-point: Public key Y coordinate as a big-endian multi-word integer
-
-These parameters can be added to a binary device tree using parameter -K of the
-mkimage command::
-
-    tools/mkimage -f fit.its -K control.dtb -k keys -r image.fit
-
-Here is an example of a generated device tree node::
-
-	signature {
-		key-dev {
-			required = "conf";
-			algo = "sha256,rsa2048";
-			rsa,r-squared = <0xb76d1acf 0xa1763ca5 0xeb2f126
-					0x742edc80 0xd3f42177 0x9741d9d9
-					0x35bb476e 0xff41c718 0xd3801430
-					0xf22537cb 0xa7e79960 0xae32a043
-					0x7da1427a 0x341d6492 0x3c2762f5
-					0xaac04726 0x5b262d96 0xf984e86d
-					0xb99443c7 0x17080c33 0x940f6892
-					0xd57a95d1 0x6ea7b691 0xc5038fa8
-					0x6bb48a6e 0x73f1b1ea 0x37160841
-					0xe05715ce 0xa7c45bbd 0x690d82d5
-					0x99c2454c 0x6ff117b3 0xd830683b
-					0x3f81c9cf 0x1ca38a91 0x0c3392e4
-					0xd817c625 0x7b8e9a24 0x175b89ea
-					0xad79f3dc 0x4d50d7b4 0x9d4e90f8
-					0xad9e2939 0xc165d6a4 0x0ada7e1b
-					0xfb1bf495 0xfc3131c2 0xb8c6e604
-					0xc2761124 0xf63de4a6 0x0e9565f9
-					0xc8e53761 0x7e7a37a5 0xe99dcdae
-					0x9aff7e1e 0xbd44b13d 0x6b0e6aa4
-					0x038907e4 0x8e0d6850 0xef51bc20
-					0xf73c94af 0x88bea7b1 0xcbbb1b30
-					0xd024b7f3>;
-			rsa,modulus = <0xc0711d6cb 0x9e86db7f 0x45986dbe
-				       0x023f1e8c9 0xe1a4c4d0 0x8a0dfdc9
-				       0x023ba0c48 0x06815f6a 0x5caa0654
-				       0x07078c4b7 0x3d154853 0x40729023
-				       0x0b007c8fe 0x5a3647e5 0x23b41e20
-				       0x024720591 0x66915305 0x0e0b29b0
-				       0x0de2ad30d 0x8589430f 0xb1590325
-				       0x0fb9f5d5e 0x9eba752a 0xd88e6de9
-				       0x056b3dcc6 0x9a6b8e61 0x6784f61f
-				       0x000f39c21 0x5eec6b33 0xd78e4f78
-				       0x0921a305f 0xaa2cc27e 0x1ca917af
-				       0x06e1134f4 0xd48cac77 0x4e914d07
-				       0x0f707aa5a 0x0d141f41 0x84677f1d
-				       0x0ad47a049 0x028aedb6 0xd5536fcf
-				       0x03fef1e4f 0x133a03d2 0xfd7a750a
-				       0x0f9159732 0xd207812e 0x6a807375
-				       0x06434230d 0xc8e22dad 0x9f29b3d6
-				       0x07c44ac2b 0xfa2aad88 0xe2429504
-				       0x041febd41 0x85d0d142 0x7b194d65
-				       0x06e5d55ea 0x41116961 0xf3181dde
-				       0x068bf5fbc 0x3dd82047 0x00ee647e
-				       0x0d7a44ab3>;
-			rsa,exponent = <0x00 0x10001>;
-			rsa,n0-inverse = <0xb3928b85>;
-			rsa,num-bits = <0x800>;
-			key-name-hint = "dev";
-		};
-	};
-
-
-Signed Configurations
----------------------
-While signing images is useful, it does not provide complete protection
-against several types of attack. For example, it it possible to create a
-FIT with the same signed images, but with the configuration changed such
-that a different one is selected (mix and match attack). It is also possible
-to substitute a signed image from an older FIT version into a newer FIT
-(roll-back attack).
-
-As an example, consider this FIT:
-
-/ {
-	images {
-		kernel-1 {
-			data = <data for kernel1>
-			signature-1 {
-				algo = "sha1,rsa2048";
-				value = <...kernel signature 1...>
-			};
-		};
-		kernel-2 {
-			data = <data for kernel2>
-			signature-1 {
-				algo = "sha1,rsa2048";
-				value = <...kernel signature 2...>
-			};
-		};
-		fdt-1 {
-			data = <data for fdt1>;
-			signature-1 {
-				algo = "sha1,rsa2048";
-				value = <...fdt signature 1...>
-			};
-		};
-		fdt-2 {
-			data = <data for fdt2>;
-			signature-1 {
-				algo = "sha1,rsa2048";
-				value = <...fdt signature 2...>
-			};
-		};
-	};
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			kernel = "kernel-1";
-			fdt = "fdt-1";
-		};
-		conf-2 {
-			kernel = "kernel-2";
-			fdt = "fdt-2";
-		};
-	};
-};
-
-Since both kernels are signed it is easy for an attacker to add a new
-configuration 3 with kernel 1 and fdt 2:
-
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			kernel = "kernel-1";
-			fdt = "fdt-1";
-		};
-		conf-2 {
-			kernel = "kernel-2";
-			fdt = "fdt-2";
-		};
-		conf-3 {
-			kernel = "kernel-1";
-			fdt = "fdt-2";
-		};
-	};
-
-With signed images, nothing protects against this. Whether it gains an
-advantage for the attacker is debatable, but it is not secure.
-
-To solve this problem, we support signed configurations. In this case it
-is the configurations that are signed, not the image. Each image has its
-own hash, and we include the hash in the configuration signature.
-
-So the above example is adjusted to look like this:
-
-/ {
-	images {
-		kernel-1 {
-			data = <data for kernel1>
-			hash-1 {
-				algo = "sha1";
-				value = <...kernel hash 1...>
-			};
-		};
-		kernel-2 {
-			data = <data for kernel2>
-			hash-1 {
-				algo = "sha1";
-				value = <...kernel hash 2...>
-			};
-		};
-		fdt-1 {
-			data = <data for fdt1>;
-			hash-1 {
-				algo = "sha1";
-				value = <...fdt hash 1...>
-			};
-		};
-		fdt-2 {
-			data = <data for fdt2>;
-			hash-1 {
-				algo = "sha1";
-				value = <...fdt hash 2...>
-			};
-		};
-	};
-	configurations {
-		default = "conf-1";
-		conf-1 {
-			kernel = "kernel-1";
-			fdt = "fdt-1";
-			signature-1 {
-				algo = "sha1,rsa2048";
-				value = <...conf 1 signature...>;
-			};
-		};
-		conf-2 {
-			kernel = "kernel-2";
-			fdt = "fdt-2";
-			signature-1 {
-				algo = "sha1,rsa2048";
-				value = <...conf 1 signature...>;
-			};
-		};
-	};
-};
-
-
-You can see that we have added hashes for all images (since they are no
-longer signed), and a signature to each configuration. In the above example,
-mkimage will sign configurations/conf-1, the kernel and fdt that are
-pointed to by the configuration (/images/kernel-1, /images/kernel-1/hash-1,
-/images/fdt-1, /images/fdt-1/hash-1) and the root structure of the image
-(so that it isn't possible to add or remove root nodes). The signature is
-written into /configurations/conf-1/signature-1/value. It can easily be
-verified later even if the FIT has been signed with other keys in the
-meantime.
-
-
-Details
--------
-The signature node contains a property ('hashed-nodes') which lists all the
-nodes that the signature was made over.  The image is walked in order and each
-tag processed as follows:
-- DTB_BEGIN_NODE: The tag and the following name are included in the signature
-  if the node or its parent are present in 'hashed-nodes'
-- DTB_END_NODE: The tag is included in the signature if the node or its parent
-  are present in 'hashed-nodes'
-- DTB_PROPERTY: The tag, the length word, the offset in the string table, and
-  the data are all included if the current node is present in 'hashed-nodes'
-  and the property name is not 'data'.
-- DTB_END: The tag is always included in the signature.
-- DTB_NOP: The tag is included in the signature if the current node is present
-  in 'hashed-nodes'
-
-In addition, the signature contains a property 'hashed-strings' which contains
-the offset and length in the string table of the strings that are to be
-included in the signature (this is done last).
-
-IMPORTANT:  To verify the signature outside u-boot, it is vital to not only
-calculate the hash of the image and verify the signature with that, but also to
-calculate the hashes of the kernel, fdt, and ramdisk images and check those
-match the hash values in the corresponding 'hash*' subnodes.
-
-
-Verification
-------------
-FITs are verified when loaded. After the configuration is selected a list
-of required images is produced. If there are 'required' public keys, then
-each image must be verified against those keys. This means that every image
-that might be used by the target needs to be signed with 'required' keys.
-
-This happens automatically as part of a bootm command when FITs are used.
-
-For Signed Configurations, the default verification behavior can be changed by
-the following optional property in /signature node in U-Boot's control FDT.
-
-- required-mode: Valid values are "any" to allow verified boot to succeed if
-the selected configuration is signed by any of the 'required' keys, and "all"
-to allow verified boot to succeed if the selected configuration is signed by
-all of the 'required' keys.
-
-This property can be added to a binary device tree using fdtput as shown in
-below examples::
-
-	fdtput -t s control.dtb /signature required-mode any
-	fdtput -t s control.dtb /signature required-mode all
-
-
-Enabling FIT Verification
--------------------------
-In addition to the options to enable FIT itself, the following CONFIGs must
-be enabled:
-
-CONFIG_FIT_SIGNATURE - enable signing and verification in FITs
-CONFIG_RSA - enable RSA algorithm for signing
-CONFIG_ECDSA - enable ECDSA algorithm for signing
-
-WARNING: When relying on signed FIT images with required signature check
-the legacy image format is default disabled by not defining
-CONFIG_LEGACY_IMAGE_FORMAT
-
-
-Testing
--------
-An easy way to test signing and verification is to use the test script
-provided in test/vboot/vboot_test.sh. This uses sandbox (a special version
-of U-Boot which runs under Linux) to show the operation of a 'bootm'
-command loading and verifying images.
-
-A sample run is show below:
-
-$ make O=sandbox sandbox_config
-$ make O=sandbox
-$ O=sandbox ./test/vboot/vboot_test.sh
-
-
-Simple Verified Boot Test
-=========================
-
-Please see doc/uImage.FIT/verified-boot.txt for more information
-
-/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
-Build keys
-do sha1 test
-Build FIT with signed images
-Test Verified Boot Run: unsigned signatures:: OK
-Sign images
-Test Verified Boot Run: signed images: OK
-Build FIT with signed configuration
-Test Verified Boot Run: unsigned config: OK
-Sign images
-Test Verified Boot Run: signed config: OK
-check signed config on the host
-Signature check OK
-OK
-Test Verified Boot Run: signed config: OK
-Test Verified Boot Run: signed config with bad hash: OK
-do sha256 test
-Build FIT with signed images
-Test Verified Boot Run: unsigned signatures:: OK
-Sign images
-Test Verified Boot Run: signed images: OK
-Build FIT with signed configuration
-Test Verified Boot Run: unsigned config: OK
-Sign images
-Test Verified Boot Run: signed config: OK
-check signed config on the host
-Signature check OK
-OK
-Test Verified Boot Run: signed config: OK
-Test Verified Boot Run: signed config with bad hash: OK
-
-Test passed
-
-
-Software signing: keydir vs keyfile
------------------------------------
-
-In the simplest case, signing is done by giving mkimage the 'keyfile'. This is
-the path to a file containing the signing key.
-
-The alternative is to pass the 'keydir' argument. In this case the filename of
-the key is derived from the 'keydir' and the "key-name-hint" property in the
-FIT. In this case the "key-name-hint" property is mandatory, and the key must
-exist in "<keydir>/<key-name-hint>.<ext>" Here the extension "ext" is
-specific to the signing algorithm.
-
-
-Hardware Signing with PKCS#11 or with HSM
------------------------------------------
-
-Securely managing private signing keys can challenging, especially when the
-keys are stored on the file system of a computer that is connected to the
-Internet. If an attacker is able to steal the key, they can sign malicious FIT
-images which will appear genuine to your devices.
-
-An alternative solution is to keep your signing key securely stored on hardware
-device like a smartcard, USB token or Hardware Security Module (HSM) and have
-them perform the signing. PKCS#11 is standard for interfacing with these crypto
-device.
-
-Requirements:
-Smartcard/USB token/HSM which can work with some openssl engine
-openssl
-
-For pkcs11 engine usage:
-libp11 (provides pkcs11 engine)
-p11-kit (recommended to simplify setup)
-opensc (for smartcards and smartcard like USB devices)
-gnutls (recommended for key generation, p11tool)
-
-For generic HSMs respective openssl engine must be installed and locateable by
-openssl. This may require setting up LD_LIBRARY_PATH if engine is not installed
-to openssl's default search paths.
-
-PKCS11 engine support forms "key id" based on "keydir" and with
-"key-name-hint". "key-name-hint" is used as "object" name (if not defined in
-keydir). "keydir" (if defined) is used to define (prefix for) which PKCS11 source
-is being used for lookup up for the key.
-
-PKCS11 engine key ids:
-   "pkcs11:<keydir>;object=<key-name-hint>;type=<public|private>"
-or, if keydir contains "object="
-   "pkcs11:<keydir>;type=<public|private>"
-or
-   "pkcs11:object=<key-name-hint>;type=<public|private>",
-
-Generic HSM engine support forms "key id" based on "keydir" and with
-"key-name-hint". If "keydir" is specified for mkimage it is used as a prefix in
-"key id" and is appended with "key-name-hint".
-
-Generic engine key ids:
-  "<keydir><key-name-hint>"
-or
-  "<key-name-hint>"
-
-In order to set the pin in the HSM, an environment variable "MKIMAGE_SIGN_PIN"
-can be specified.
-
-The following examples use the Nitrokey Pro using pkcs11 engine. Instructions
-for other devices may vary.
-
-Notes on pkcs11 engine setup:
-
-Make sure p11-kit, opensc are installed and that p11-kit is setup to use opensc.
-/usr/share/p11-kit/modules/opensc.module should be present on your system.
-
-
-Generating Keys On the Nitrokey:
-
-$ gpg --card-edit
-
-Reader ...........: Nitrokey Nitrokey Pro (xxxxxxxx0000000000000000) 00 00
-Application ID ...: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-Version ..........: 2.1
-Manufacturer .....: ZeitControl
-Serial number ....: xxxxxxxx
-Name of cardholder: [not set]
-Language prefs ...: de
-Sex ..............: unspecified
-URL of public key : [not set]
-Login data .......: [not set]
-Signature PIN ....: forced
-Key attributes ...: rsa2048 rsa2048 rsa2048
-Max. PIN lengths .: 32 32 32
-PIN retry counter : 3 0 3
-Signature counter : 0
-Signature key ....: [none]
-Encryption key....: [none]
-Authentication key: [none]
-General key info..: [none]
-
-gpg/card> generate
-Make off-card backup of encryption key? (Y/n) n
-
-Please note that the factory settings of the PINs are
-  PIN = '123456' Admin PIN = '12345678'
-You should change them using the command --change-pin
-
-What keysize do you want for the Signature key? (2048) 4096
-The card will now be re-configured to generate a key of 4096 bits
-Note: There is no guarantee that the card supports the requested size.
-  If the key generation does not succeed, please check the
-  documentation of your card to see what sizes are allowed.
-What keysize do you want for the Encryption key? (2048) 4096
-The card will now be re-configured to generate a key of 4096 bits
-What keysize do you want for the Authentication key? (2048) 4096
-The card will now be re-configured to generate a key of 4096 bits
-Please specify how long the key should be valid.
-  0 = key does not expire
-  <n> = key expires in n days
-  <n>w = key expires in n weeks
-  <n>m = key expires in n months
-  <n>y = key expires in n years
-Key is valid for? (0)
-Key does not expire at all
-Is this correct? (y/N) y
-
-GnuPG needs to construct a user ID to identify your key.
-
-Real name: John Doe
-Email address: john.doe@email.com
-Comment:
-You selected this USER-ID:
-  "John Doe <john.doe@email.com>"
-
-Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
-
-
-Using p11tool to get the token URL:
-
-Depending on system configuration, gpg-agent may need to be killed first.
-
-$ p11tool --provider /usr/lib/opensc-pkcs11.so --list-tokens
-Token 0:
-URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29
-Label: OpenPGP card (User PIN (sig))
-Type: Hardware token
-Manufacturer: ZeitControl
-Model: PKCS#15 emulated
-Serial: 000xxxxxxxxx
-Module: (null)
-
-
-Token 1:
-URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%29
-Label: OpenPGP card (User PIN)
-Type: Hardware token
-Manufacturer: ZeitControl
-Model: PKCS#15 emulated
-Serial: 000xxxxxxxxx
-Module: (null)
-
-Use the portion of the signature token URL after "pkcs11:" as the keydir argument (-k) to mkimage below.
-
-
-Use the URL of the token to list the private keys:
-
-$ p11tool --login --provider /usr/lib/opensc-pkcs11.so --list-privkeys \
-"pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29"
-Token 'OpenPGP card (User PIN (sig))' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29' requires user PIN
-Enter PIN:
-Object 0:
-URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29;id=%01;object=Signature%20key;type=private
-Type: Private key
-Label: Signature key
-Flags: CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE;
-ID: 01
-
-Use the label, in this case "Signature key" as the key-name-hint in your FIT.
-
-Create the fitImage:
-$ ./tools/mkimage -f fit-image.its fitImage
-
-
-Sign the fitImage with the hardware key:
-
-$ ./tools/mkimage -F -k \
-"model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29" \
--K u-boot.dtb -N pkcs11 -r fitImage
-
-
-Future Work
------------
-- Roll-back protection using a TPM is done using the tpm command. This can
-be scripted, but we might consider a default way of doing this, built into
-bootm.
-
-
-Possible Future Work
---------------------
-- More sandbox tests for failure modes
-- Passwords for keys/certificates
-- Perhaps implement OAEP
-- Enhance bootm to permit scripted signature verification (so that a script
-can verify an image but not actually boot it)
-
-
-Simon Glass
-sjg@chromium.org
-1-1-13

doc/uImage.FIT/source_file_format.txt

@@ -1,322 +0,0 @@
-U-Boot new uImage source file format (bindings definition)
-==========================================================
-
-Author: Marian Balakowicz <m8@semihalf.com>
-External data additions, 25/1/16 Simon Glass <sjg@chromium.org>
-
-1) Introduction
----------------
-
-Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
-booting method which requires that hardware description is available to the
-kernel in the form of Flattened Device Tree.
-
-Booting with a Flattened Device Tree is much more flexible and is intended to
-replace direct passing of 'struct bd_info' which was used to boot pre-FDT
-kernels.
-
-However, U-Boot needs to support both techniques to provide backward
-compatibility for platforms which are not FDT ready. Number of elements
-playing role in the booting process has increased and now includes the FDT
-blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
-in the system memory and passed to bootm as a arguments. Some of them may be
-missing: FDT is not present for legacy platforms, ramdisk is always optional.
-Additionally, old uImage format has been extended to support multi sub-images
-but the support is limited by simple format of the legacy uImage structure.
-Single binary header 'struct legacy_img_hdr' is not flexible enough to cover all
-possible scenarios.
-
-All those factors combined clearly show that there is a need for new, more
-flexible, multi component uImage format.
-
-
-2) New uImage format assumptions
---------------------------------
-
-a) Implementation
-
-Libfdt has been selected for the new uImage format implementation as (1) it
-provides needed functionality, (2) is actively maintained and developed and
-(3) increases code reuse as it is already part of the U-Boot source tree.
-
-b) Terminology
-
-This document defines new uImage structure by providing FDT bindings for new
-uImage internals. Bindings are defined from U-Boot perspective, i.e. describe
-final form of the uImage at the moment when it reaches U-Boot. User
-perspective may be simpler, as some of the properties (like timestamps and
-hashes) will need to be filled in automatically by the U-Boot mkimage tool.
-
-To avoid confusion with the kernel FDT the following naming convention is
-proposed for the new uImage format related terms:
-
-FIT	- Flattened uImage Tree
-
-FIT is formally a flattened device tree (in the libfdt meaning), which
-conforms to bindings defined in this document.
-
-.its	- image tree source
-.itb	- flattened image tree blob
-
-c) Image building procedure
-
-The following picture shows how the new uImage is prepared. Input consists of
-image source file (.its) and a set of data files. Image is created with the
-help of standard U-Boot mkimage tool which in turn uses dtc (device tree
-compiler) to produce image tree blob (.itb).  Resulting .itb file is the
-actual binary of a new uImage.
-
-
-tqm5200.its
-+
-vmlinux.bin.gz	   mkimage + dtc	       xfer to target
-eldk-4.2-ramdisk  --------------> tqm5200.itb --------------> bootm
-tqm5200.dtb			     /|\
-...				      |
-				 'new uImage'
-
-	- create .its file, automatically filled-in properties are omitted
-	- call mkimage tool on a .its file
-	- mkimage calls dtc to create .itb image and assures that
-	  missing properties are added
-	- .itb (new uImage) is uploaded onto the target and used therein
-
-
-d) Unique identifiers
-
-To identify FIT sub-nodes representing images, hashes, configurations (which
-are defined in the following sections), the "unit name" of the given sub-node
-is used as it's identifier as it assures uniqueness without additional
-checking required.
-
-
-3) Root node properties
------------------------
-
-Root node of the uImage Tree should have the following layout:
-
-/ o image-tree
-    |- description = "image description"
-    |- timestamp = <12399321>
-    |- #address-cells = <1>
-    |
-    o images
-    | |
-    | o image-1 {...}
-    | o image-2 {...}
-    | ...
-    |
-    o configurations
-      |- default = "conf-1"
-      |
-      o conf-1 {...}
-      o conf-2 {...}
-      ...
-
-
-  Optional property:
-  - description : Textual description of the uImage
-
-  Mandatory property:
-  - timestamp : Last image modification time being counted in seconds since
-    1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
-
-  Conditionally mandatory property:
-  - #address-cells : Number of 32bit cells required to represent entry and
-    load addresses supplied within sub-image nodes. May be omitted when no
-    entry or load addresses are used.
-
-  Mandatory nodes:
-  - images : This node contains a set of sub-nodes, each of them representing
-    single component sub-image (like kernel, ramdisk, etc.). At least one
-    sub-image is required.
-  - configurations : Contains a set of available configuration nodes and
-    defines a default configuration.
-
-
-4) '/images' node
------------------
-
-This node is a container node for component sub-image nodes. Each sub-node of
-the '/images' node should have the following layout:
-
- o image-1
-   |- description = "component sub-image description"
-   |- data = /incbin/("path/to/data/file.bin")
-   |- type = "sub-image type name"
-   |- arch = "ARCH name"
-   |- os = "OS name"
-   |- compression = "compression name"
-   |- load = <00000000>
-   |- entry = <00000000>
-   |
-   o hash-1 {...}
-   o hash-2 {...}
-   ...
-
-  Mandatory properties:
-  - description : Textual description of the component sub-image
-  - type : Name of component sub-image type, supported types are:
-    "standalone", "kernel", "kernel_noload", "ramdisk", "firmware", "script",
-    "filesystem", "flat_dt" and others (see uimage_type in common/image.c).
-  - data : Path to the external file which contains this node's binary data.
-  - compression : Compression used by included data. Supported compressions
-    are "gzip" and "bzip2". If no compression is used compression property
-    should be set to "none". If the data is compressed but it should not be
-    uncompressed by U-Boot (e.g. compressed ramdisk), this should also be set
-    to "none".
-
-  Conditionally mandatory property:
-  - os : OS name, mandatory for types "kernel". Valid OS names are:
-    "openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix",
-    "solaris", "irix", "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx",
-    "u-boot", "rtems", "unity", "integrity".
-  - arch : Architecture name, mandatory for types: "standalone", "kernel",
-    "firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
-    "arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
-    "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200",
-    "sandbox".
-  - entry : entry point address, address size is determined by
-    '#address-cells' property of the root node.
-    Mandatory for types: "firmware", and "kernel".
-  - load : load address, address size is determined by '#address-cells'
-    property of the root node.
-    Mandatory for types: "firmware", and "kernel".
-  - compatible : compatible method for loading image.
-    Mandatory for types: "fpga", and images that do not specify a load address.
-    Supported compatible methods:
-    "u-boot,fpga-legacy" - the generic fpga loading routine.
-    "u-boot,zynqmp-fpga-ddrauth" - signed non-encrypted FPGA bitstream for
-    Xilinx Zynq UltraScale+ (ZymqMP) device.
-    "u-boot,zynqmp-fpga-enc" - encrypted FPGA bitstream for Xilinx Zynq
-    UltraScale+ (ZynqMP) device.
-  - phase : U-Boot phase for which the image is intended.
-    "spl" - image is an SPL image
-    "u-boot" - image is a U-Boot image
-
-  Optional nodes:
-  - hash-1 : Each hash sub-node represents separate hash or checksum
-    calculated for node's data according to specified algorithm.
-
-
-5) Hash nodes
--------------
-
-o hash-1
-  |- algo = "hash or checksum algorithm name"
-  |- value = [hash or checksum value]
-
-  Mandatory properties:
-  - algo : Algorithm name, supported are "crc32", "md5" and "sha1".
-  - value : Actual checksum or hash value, correspondingly 4, 16 or 20 bytes
-    long.
-
-
-6) '/configurations' node
--------------------------
-
-The 'configurations' node creates convenient, labeled boot configurations,
-which combine together kernel images with their ramdisks and fdt blobs.
-
-The 'configurations' node has has the following structure:
-
-o configurations
-  |- default = "default configuration sub-node unit name"
-  |
-  o config-1 {...}
-  o config-2 {...}
-  ...
-
-
-  Optional property:
-  - default : Selects one of the configuration sub-nodes as a default
-    configuration.
-
-  Mandatory nodes:
-  - configuration-sub-node-unit-name : At least one of the configuration
-    sub-nodes is required.
-
-
-7) Configuration nodes
-----------------------
-
-Each configuration has the following structure:
-
-o config-1
-  |- description = "configuration description"
-  |- kernel = "kernel sub-node unit name"
-  |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
-  |- loadables = "loadables sub-node unit-name"
-  |- script = "
-  |- compatible = "vendor,board-style device tree compatible string"
-
-
-  Mandatory properties:
-  - description : Textual configuration description.
-  - kernel or firmware: Unit name of the corresponding kernel or firmware
-    (u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified,
-    control is passed to the firmware image.
-
-  Optional properties:
-  - fdt : Unit name of the corresponding fdt blob (component image node of a
-    "fdt type"). Additional fdt overlay nodes can be supplied which signify
-    that the resulting device tree blob is generated by the first base fdt
-    blob with all subsequent overlays applied.
-  - fpga : Unit name of the corresponding fpga bitstream blob
-    (component image node of a "fpga type").
-  - loadables : Unit name containing a list of additional binaries to be
-    loaded at their given locations.  "loadables" is a comma-separated list
-    of strings. U-Boot will load each binary at its given start-address and
-    may optionally invoke additional post-processing steps on this binary based
-    on its component image node type.
-  - script : The image to use when loading a U-Boot script (for use with the
-    source command).
-  - compatible : The root compatible string of the U-Boot device tree that
-    this configuration shall automatically match when CONFIG_FIT_BEST_MATCH is
-    enabled. If this property is not provided, the compatible string will be
-    extracted from the fdt blob instead. This is only possible if the fdt is
-    not compressed, so images with compressed fdts that want to use compatible
-    string matching must always provide this property.
-
-The FDT blob is required to properly boot FDT based kernel, so the minimal
-configuration for 2.6 FDT kernel is (kernel, fdt) pair.
-
-Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
-'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
-not* be specified in a configuration node.
-
-
-8) External data
-----------------
-
-The above format shows a 'data' property which holds the data for each image.
-It is also possible for this data to reside outside the FIT itself. This
-allows the FIT to be quite small, so that it can be loaded and scanned
-without loading a large amount of data. Then when an image is needed it can
-be loaded from an external source.
-
-In this case the 'data' property is omitted. Instead you can use:
-
-  - data-offset : offset of the data in a separate image store. The image
-    store is placed immediately after the last byte of the device tree binary,
-    aligned to a 4-byte boundary.
-  - data-size : size of the data in bytes
-
-The 'data-offset' property can be substituted with 'data-position', which
-defines an absolute position or address as the offset. This is helpful when
-booting U-Boot proper before performing relocation. Pass '-p [offset]' to
-mkimage to enable 'data-position'.
-
-Normal kernel FIT image has data embedded within FIT structure. U-Boot image
-for SPL boot has external data. Existence of 'data-offset' can be used to
-identify which format is used.
-
-For FIT image with external data, it would be better to align each blob of data
-to block(512 byte) for block device, so that we don't need to do the copy when
-read the image data in SPL. Pass '-B 0x200' to mkimage to align the FIT
-structure and data to 512 byte, other values available for other align size.
-
-9) Examples
------------
-
-Please see doc/uImage.FIT/*.its for actual image source files.

doc/uImage.FIT/uefi.its

@@ -1,67 +0,0 @@
-/*
- * Example FIT image description file demonstrating the usage of the
- * bootm command to launch UEFI binaries.
- *
- * Two boot configurations are available to enable booting GRUB2 on QEMU,
- * the former uses a FDT blob contained in the FIT image, while the later
- * relies on the FDT provided by the board emulator.
- */
-
-/dts-v1/;
-
-/ {
-	description = "GRUB2 EFI and QEMU FDT blob";
-	#address-cells = <1>;
-
-	images {
-		efi-grub {
-			description = "GRUB EFI Firmware";
-			data = /incbin/("bootarm.efi");
-			type = "kernel_noload";
-			arch = "arm";
-			os = "efi";
-			compression = "none";
-			load = <0x0>;
-			entry = <0x0>;
-			hash-1 {
-				algo = "sha256";
-			};
-		};
-
-		fdt-qemu {
-			description = "QEMU DTB";
-			data = /incbin/("qemu-arm.dtb");
-			type = "flat_dt";
-			arch = "arm";
-			compression = "none";
-			hash-1 {
-				algo = "sha256";
-			};
-		};
-	};
-
-	configurations {
-		default = "config-grub-fdt";
-
-		config-grub-fdt {
-			description = "GRUB EFI Boot w/ FDT";
-			kernel = "efi-grub";
-			fdt = "fdt-qemu";
-			signature-1 {
-				algo = "sha256,rsa2048";
-				key-name-hint = "dev";
-				sign-images = "kernel", "fdt";
-			};
-		};
-
-		config-grub-nofdt {
-			description = "GRUB EFI Boot w/o FDT";
-			kernel = "efi-grub";
-			signature-1 {
-				algo = "sha256,rsa2048";
-				key-name-hint = "dev";
-				sign-images = "kernel";
-			};
-		};
-	};
-};

doc/uImage.FIT/update3.its

@@ -1,44 +0,0 @@
-/*
- * Example Automatic software update file.
- */
-
-/dts-v1/;
-
-/ {
-	description = "Automatic software updates: kernel, ramdisk, FDT";
-	#address-cells = <1>;
-
-	images {
-		update-1 {
-			description = "Linux kernel binary";
-			data = /incbin/("./vmlinux.bin.gz");
-			compression = "none";
-			type = "firmware";
-			load = <FF700000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-		update-2 {
-			description = "Ramdisk image";
-			data = /incbin/("./ramdisk_image.gz");
-			compression = "none";
-			type = "firmware";
-			load = <FF8E0000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-
-		update-3 {
-			description = "FDT blob";
-			data = /incbin/("./blob.fdt");
-			compression = "none";
-			type = "firmware";
-			load = <FFAC0000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-	};
-};

doc/uImage.FIT/update_uboot.its

@@ -1,24 +0,0 @@
-/*
- * Automatic software update for U-Boot
- * Make sure the flashing addresses ('load' prop) is correct for your board!
- */
-
-/dts-v1/;
-
-/ {
-	description = "Automatic U-Boot update";
-	#address-cells = <1>;
-
-	images {
-		update-1 {
-			description = "U-Boot binary";
-			data = /incbin/("./u-boot.bin");
-			compression = "none";
-			type = "firmware";
-			load = <0xFFFC0000>;
-			hash-1 {
-				algo = "sha1";
-			};
-		};
-	};
-};

doc/uImage.FIT/x86-fit-boot.txt

@@ -1,272 +0,0 @@
-Booting Linux on x86 with FIT
-=============================
-
-Background
-----------
-
-(corrections to the text below are welcome)
-
-Generally Linux x86 uses its own very complex booting method. There is a setup
-binary which contains all sorts of parameters and a compressed self-extracting
-binary for the kernel itself, often with a small built-in serial driver to
-display decompression progress.
-
-The x86 CPU has various processor modes. I am no expert on these, but my
-understanding is that an x86 CPU (even a really new one) starts up in a 16-bit
-'real' mode where only 1MB of memory is visible, moves to 32-bit 'protected'
-mode where 4GB is visible (or more with special memory access techniques) and
-then to 64-bit 'long' mode if 64-bit execution is required.
-
-Partly the self-extracting nature of Linux was introduced to cope with boot
-loaders that were barely capable of loading anything. Even changing to 32-bit
-mode was something of a challenge, so putting this logic in the kernel seemed
-to make sense.
-
-Bit by bit more and more logic has been added to this post-boot pre-Linux
-wrapper:
-
-- Changing to 32-bit mode
-- Decompression
-- Serial output (with drivers for various chips)
-- Load address randomisation
-- Elf loader complete with relocation (for the above)
-- Random number generator via 3 methods (again for the above)
-- Some sort of EFI mini-loader (1000+ glorious lines of code)
-- Locating and tacking on a device tree and ramdisk
-
-To my mind, if you sit back and look at things from first principles, this
-doesn't make a huge amount of sense. Any boot loader worth its salts already
-has most of the above features and more besides. The boot loader already knows
-the layout of memory, has a serial driver, can decompress things, includes an
-ELF loader and supports device tree and ramdisks. The decision to duplicate
-all these features in a Linux wrapper caters for the lowest common
-denominator: a boot loader which consists of a BIOS call to load something off
-disk, followed by a jmp instruction.
-
-(Aside: On ARM systems, we worry that the boot loader won't know where to load
-the kernel. It might be easier to just provide that information in the image,
-or in the boot loader rather than adding a self-relocator to put it in the
-right place. Or just use ELF?
-
-As a result, the x86 kernel boot process is needlessly complex. The file
-format is also complex, and obfuscates the contents to a degree that it is
-quite a challenge to extract anything from it. This bzImage format has become
-so prevalent that is actually isn't possible to produce the 'raw' kernel build
-outputs with the standard Makefile (as it is on ARM for example, at least at
-the time of writing).
-
-This document describes an alternative boot process which uses simple raw
-images which are loaded into the right place by the boot loader and then
-executed.
-
-
-Build the kernel
-----------------
-
-Note: these instructions assume a 32-bit kernel. U-Boot also supports directly
-booting a 64-bit kernel by jumping into 64-bit mode first (see below).
-
-You can build the kernel as normal with 'make'. This will create a file called
-'vmlinux'. This is a standard ELF file and you can look at it if you like:
-
-$ objdump -h vmlinux
-
-vmlinux:     file format elf32-i386
-
-Sections:
-Idx Name          Size      VMA       LMA       File off  Algn
-  0 .text         00416850  81000000  01000000  00001000  2**5
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
-  1 .notes        00000024  81416850  01416850  00417850  2**2
-                  CONTENTS, ALLOC, LOAD, READONLY, CODE
-  2 __ex_table    00000c50  81416880  01416880  00417880  2**3
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  3 .rodata       00154b9e  81418000  01418000  00419000  2**5
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  4 __bug_table   0000597c  8156cba0  0156cba0  0056dba0  2**0
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  5 .pci_fixup    00001b80  8157251c  0157251c  0057351c  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  6 .tracedata    00000024  8157409c  0157409c  0057509c  2**0
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  7 __ksymtab     00007ec0  815740c0  015740c0  005750c0  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  8 __ksymtab_gpl 00004a28  8157bf80  0157bf80  0057cf80  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
-  9 __ksymtab_strings 0001d6fc  815809a8  015809a8  005819a8  2**0
-                  CONTENTS, ALLOC, LOAD, READONLY, DATA
- 10 __init_rodata 00001c3c  8159e0a4  0159e0a4  0059f0a4  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 11 __param       00000ff0  8159fce0  0159fce0  005a0ce0  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 12 __modver      00000330  815a0cd0  015a0cd0  005a1cd0  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 13 .data         00063000  815a1000  015a1000  005a2000  2**12
-                  CONTENTS, ALLOC, LOAD, RELOC, DATA
- 14 .init.text    0002f104  81604000  01604000  00605000  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
- 15 .init.data    00040cdc  81634000  01634000  00635000  2**12
-                  CONTENTS, ALLOC, LOAD, RELOC, DATA
- 16 .x86_cpu_dev.init 0000001c  81674cdc  01674cdc  00675cdc  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 17 .altinstructions 0000267c  81674cf8  01674cf8  00675cf8  2**0
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 18 .altinstr_replacement 00000942  81677374  01677374  00678374  2**0
-                  CONTENTS, ALLOC, LOAD, READONLY, CODE
- 19 .iommu_table  00000014  81677cb8  01677cb8  00678cb8  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 20 .apicdrivers  00000004  81677cd0  01677cd0  00678cd0  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, DATA
- 21 .exit.text    00001a80  81677cd8  01677cd8  00678cd8  2**0
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
- 22 .data..percpu 00007880  8167a000  0167a000  0067b000  2**12
-                  CONTENTS, ALLOC, LOAD, RELOC, DATA
- 23 .smp_locks    00003000  81682000  01682000  00683000  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
- 24 .bss          000a1000  81685000  01685000  00686000  2**12
-                  ALLOC
- 25 .brk          00424000  81726000  01726000  00686000  2**0
-                  ALLOC
- 26 .comment      00000049  00000000  00000000  00686000  2**0
-                  CONTENTS, READONLY
- 27 .GCC.command.line 0003e055  00000000  00000000  00686049  2**0
-                  CONTENTS, READONLY
- 28 .debug_aranges 0000f4c8  00000000  00000000  006c40a0  2**3
-                  CONTENTS, RELOC, READONLY, DEBUGGING
- 29 .debug_info   0440b0df  00000000  00000000  006d3568  2**0
-                  CONTENTS, RELOC, READONLY, DEBUGGING
- 30 .debug_abbrev 0022a83b  00000000  00000000  04ade647  2**0
-                  CONTENTS, READONLY, DEBUGGING
- 31 .debug_line   004ead0d  00000000  00000000  04d08e82  2**0
-                  CONTENTS, RELOC, READONLY, DEBUGGING
- 32 .debug_frame  0010a960  00000000  00000000  051f3b90  2**2
-                  CONTENTS, RELOC, READONLY, DEBUGGING
- 33 .debug_str    001b442d  00000000  00000000  052fe4f0  2**0
-                  CONTENTS, READONLY, DEBUGGING
- 34 .debug_loc    007c7fa9  00000000  00000000  054b291d  2**0
-                  CONTENTS, RELOC, READONLY, DEBUGGING
- 35 .debug_ranges 00098828  00000000  00000000  05c7a8c8  2**3
-                  CONTENTS, RELOC, READONLY, DEBUGGING
-
-There is also the setup binary mentioned earlier. This is at
-arch/x86/boot/setup.bin and is about 12KB in size. It includes the command
-line and various settings need by the kernel. Arguably the boot loader should
-provide all of this also, but setting it up is some complex that the kernel
-helps by providing a head start.
-
-As you can see the code loads to address 0x01000000 and everything else
-follows after that. We could load this image using the 'bootelf' command but
-we would still need to provide the setup binary. This is not supported by
-U-Boot although I suppose you could mostly script it. This would permit the
-use of a relocatable kernel.
-
-All we need to boot is the vmlinux file and the setup.bin file.
-
-
-Create a FIT
-------------
-
-To create a FIT you will need a source file describing what should go in the
-FIT. See kernel.its for an example for x86 and also instructions on setting
-the 'arch' value for booting 64-bit kernels if desired. Put this into a file
-called image.its.
-
-Note that setup is loaded to the special address of 0x90000 (a special address
-you just have to know) and the kernel is loaded to 0x01000000 (the address you
-saw above). This means that you will need to load your FIT to a different
-address so that U-Boot doesn't overwrite it when decompressing. Something like
-0x02000000 will do so you can set CONFIG_SYS_LOAD_ADDR to that.
-
-In that example the kernel is compressed with lzo. Also we need to provide a
-flat binary, not an ELF. So the steps needed to set things are are:
-
-   # Create a flat binary
-   objcopy -O binary vmlinux vmlinux.bin
-
-   # Compress it into LZO format
-   lzop vmlinux.bin
-
-   # Build a FIT image
-   mkimage -f image.its image.fit
-
-(be careful to run the mkimage from your U-Boot tools directory since it
-will have x86_setup support.)
-
-You can take a look at the resulting fit file if you like:
-
-$ dumpimage -l image.fit
-FIT description: Simple image with single Linux kernel on x86
-Created:         Tue Oct  7 10:57:24 2014
- Image 0 (kernel)
-  Description:  Vanilla Linux kernel
-  Created:      Tue Oct  7 10:57:24 2014
-  Type:         Kernel Image
-  Compression:  lzo compressed
-  Data Size:    4591767 Bytes = 4484.15 kB = 4.38 MB
-  Architecture: Intel x86
-  OS:           Linux
-  Load Address: 0x01000000
-  Entry Point:  0x00000000
-  Hash algo:    sha1
-  Hash value:   446b5163ebfe0fb6ee20cbb7a8501b263cd92392
- Image 1 (setup)
-  Description:  Linux setup.bin
-  Created:      Tue Oct  7 10:57:24 2014
-  Type:         x86 setup.bin
-  Compression:  uncompressed
-  Data Size:    12912 Bytes = 12.61 kB = 0.01 MB
-  Hash algo:    sha1
-  Hash value:   a1f2099cf47ff9816236cd534c77af86e713faad
- Default Configuration: 'config-1'
- Configuration 0 (config-1)
-  Description:  Boot Linux kernel
-  Kernel:       kernel
-
-
-Booting the FIT
----------------
-
-To make it boot you need to load it and then use 'bootm' to boot it. A
-suitable script to do this from a network server is:
-
-   bootp
-   tftp image.fit
-   bootm
-
-This will load the image from the network and boot it. The command line (from
-the 'bootargs' environment variable) will be passed to the kernel.
-
-If you want a ramdisk you can add it as normal with FIT. If you want a device
-tree then x86 doesn't normally use those - it has ACPI instead.
-
-
-Why Bother?
------------
-
-1. It demystifies the process of booting an x86 kernel
-2. It allows use of the standard U-Boot boot file format
-3. It allows U-Boot to perform decompression - problems will provide an error
-message and you are still in the boot loader. It is possible to investigate.
-4. It avoids all the pre-loader code in the kernel which is quite complex to
-follow
-5. You can use verified/secure boot and other features which haven't yet been
-added to the pre-Linux
-6. It makes x86 more like other architectures in the way it boots a kernel.
-You can potentially use the same file format for the kernel, and the same
-procedure for building and packaging it.
-
-
-References
-----------
-
-In the Linux kernel, Documentation/x86/boot.txt defines the boot protocol for
-the kernel including the setup.bin format. This is handled in U-Boot in
-arch/x86/lib/zimage.c and arch/x86/lib/bootm.c.
-
-Various files in the same directory as this file describe the FIT format.
-
-
---
-Simon Glass
-sjg@chromium.org
-7-Oct-2014

doc/usage/cmd/bind.rst

@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+bind command
+============
+
+Synopsis
+--------
+
+::
+
+    bind <node path> <driver>
+    bind <class> <index> <driver>
+
+Description
+-----------
+
+The bind command is used to bind a device to a driver. This makes the
+device available in U-Boot.
+
+While binding to a *node path* typically provides a working device
+binding by parent node and driver may lead to a device that is only
+partially initialized.
+
+node path
+    path of the device's device-tree node
+
+class
+    device class name
+
+index
+    index of the parent device in the device class
+
+driver
+    device driver name
+
+Example
+-------
+
+Given a system with a real time clock device with device path */pl031@9010000*
+and using driver rtc-pl031 unbinding and binding of the device is demonstrated
+using the two alternative bind syntaxes.
+
+.. code-block::
+
+    => dm tree
+     Class     Index  Probed  Driver                Name
+    -----------------------------------------------------------
+     root          0  [ + ]   root_driver           root_driver
+    ...
+     rtc           0  [   ]   rtc-pl031             |-- pl031@9010000
+    ...
+    => fdt addr $fdtcontroladdr
+    Working FDT set to 7ed7fdb0
+    => fdt print
+    / {
+            interrupt-parent = <0x00008003>;
+            model = "linux,dummy-virt";
+            #size-cells = <0x00000002>;
+            #address-cells = <0x00000002>;
+            compatible = "linux,dummy-virt";
+    ...
+            pl031@9010000 {
+                    clock-names = "apb_pclk";
+                    clocks = <0x00008000>;
+                    interrupts = <0x00000000 0x00000002 0x00000004>;
+                    reg = <0x00000000 0x09010000 0x00000000 0x00001000>;
+                    compatible = "arm,pl031", "arm,primecell";
+            };
+    ...
+    }
+    => unbind /pl031@9010000
+    => date
+    Cannot find RTC: err=-19
+    => dm tree
+     Class     Index  Probed  Driver                Name
+    -----------------------------------------------------------
+     root          0  [ + ]   root_driver           root_driver
+    ...
+    => bind /pl031@9010000 rtc-pl031
+    => dm tree
+     Class     Index  Probed  Driver                Name
+    -----------------------------------------------------------
+     root          0  [ + ]   root_driver           root_driver
+    ...
+     rtc           0  [   ]   rtc-pl031             |-- pl031@9010000
+    => date
+    Date: 2023-06-22 (Thursday)    Time: 15:14:51
+    => unbind rtc 0 rtc-pl031
+    => bind root 0 rtc-pl031
+    => date
+    Date: 1980-08-19 (Tuesday)    Time: 14:45:30
+
+Obviously the device is not initialized correctly by the last bind command.
+
+Configuration
+-------------
+
+The bind command is only available if CONFIG_CMD_BIND=y.
+
+Return code
+-----------
+
+The return code $? is 0 (true) on success and 1 (false) on failure.

doc/usage/cmd/bootm.rst

@@ -0,0 +1,300 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+bootm command
+=============
+
+Synopsis
+--------
+
+::
+
+    bootm [fit_addr]#<conf>[#extra-conf]
+    bootm [[fit_addr]:<os_subimg>] [[<fit_addr2>]:<rd_subimg2>] [[<fit_addr3>]:<fdt_subimg>]
+
+    bootm <addr1> [[<addr2> [<addr3>]]    # Legacy boot
+
+Description
+-----------
+
+The *bootm* command is used to boot an Operating System. It has a large number
+of options depending on what needs to be booted.
+
+Note that the second form supports the first and/or second arguments to be
+omitted by using a hyphen '-' instead.
+
+fit_addr / fit_addr2 / fit_addr3
+    address of FIT to boot, defaults to CONFIG_SYS_LOAD_ADDR. See notes below.
+
+conf
+    configuration unit to boot (must be preceded by hash '#')
+
+extra-conf
+    extra configuration to boot. This is supported only for additional
+    devicetree overlays to apply on the base device tree supplied by the first
+    configuration unit.
+
+os_subimg
+    OS sub-image to boot (must be preceded by colon ':')
+
+rd_subimg
+    ramdisk sub-image to boot. Use a hyphen '-' if there is no ramdisk but an
+    FDT is needed.
+
+fdt_subimg
+    FDT sub-image to boot
+
+See below for legacy boot. Booting using :doc:`../fit/index` is recommended.
+
+Note on current image address
+-----------------------------
+
+When bootm is called without arguments, the image at current image address is
+booted. The current image address is the address set most recently by a load
+command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example,
+consider the following commands::
+
+    tftp 200000 /tftpboot/kernel
+    bootm
+    # Last command is equivalent to:
+    # bootm 200000
+
+As shown above, with FIT the address portion of any argument
+can be omitted. If <addr3> is omitted, then it is assumed that image at
+<addr2> should be used. Similarly, when <addr2> is omitted, it is assumed that
+image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
+current image address is to be used. For example, consider the following
+commands::
+
+    tftp 200000 /tftpboot/uImage
+    bootm :kernel-1
+    # Last command is equivalent to:
+    # bootm 200000:kernel-1
+
+    tftp 200000 /tftpboot/uImage
+    bootm 400000:kernel-1 :ramdisk-1
+    # Last command is equivalent to:
+    # bootm 400000:kernel-1 400000:ramdisk-1
+
+    tftp 200000 /tftpboot/uImage
+    bootm :kernel-1 400000:ramdisk-1 :fdt-1
+    # Last command is equivalent to:
+    # bootm 200000:kernel-1 400000:ramdisk-1 400000:fdt-1
+
+
+Legacy boot
+-----------
+
+U-Boot supports a legacy image format, enabled by `CONFIG_LEGACY_IMAGE_FORMAT`.
+This is not recommended as it is quite limited and insecure. Use
+:doc:`../fit/index` instead. It is documented here for old boards which still
+use it.
+
+Arguments are:
+
+addr1
+    address of legacy image to boot. If the image includes a second component
+    (ramdisk) it is used as well, unless the second parameter is hyphen '-'.
+
+addr2
+    address of legacy image to use as ramdisk
+
+addr3
+    address of legacy image to use as FDT
+
+
+Example syntax
+--------------
+
+This section provides various examples of possible usage::
+
+    1.  bootm       /* boot image at the current address, equivalent to 2,3,8 */
+
+This is equivalent to cases 2, 3 or 8, depending on the type of image at
+the current image address.
+
+Boot method: see cases 2,3,8
+
+Legacy uImage syntax
+~~~~~~~~~~~~~~~~~~~~
+
+::
+
+    2.  bootm <addr1>            /* single image at <addr1> */
+
+Boot kernel image located at <addr1>.
+
+Boot method: non-FDT
+
+::
+
+    3.  bootm <addr1>            /* multi-image at <addr1>  */
+
+First and second components of the image at <addr1> are assumed to be a
+kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
+with the ramdisk from the image.
+
+Boot method: depends on the number of components at <addr1>, and on whether
+U-Boot is compiled with OF support, which it should be.
+
+    ==================== ======================== ========================
+    Configuration        2 components             3 components
+                         (kernel, initrd)         (kernel, initrd, fdt)
+    ==================== ======================== ========================
+    #ifdef CONFIG_OF_*                   non-FDT                     FDT
+    #ifndef CONFIG_OF_*                  non-FDT                 non-FDT
+    ==================== ======================== ========================
+
+::
+
+    4.  bootm <addr1> -            /* multi-image at <addr1>  */
+
+Similar to case 3, but the kernel is booted without initrd.  Second
+component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
+
+Boot method: see case 3
+
+::
+
+    5.  bootm <addr1> <addr2>        /* single image at <addr1> */
+
+Boot kernel image located at <addr1> with initrd loaded with ramdisk
+from the image at <addr2>.
+
+Boot method: non-FDT
+
+::
+
+    6.  bootm <addr1> <addr2> <addr3>   /* single image at <addr1> */
+
+<addr1> is the address of a kernel image, <addr2> is the address of a
+ramdisk image, and <addr3> is the address of a FDT binary blob.  Kernel is
+booted with initrd loaded with ramdisk from the image at <addr2>.
+
+Boot method: FDT
+
+::
+
+    7.  bootm <addr1> -      <addr3>   /* single image at <addr1> */
+
+<addr1> is the address of a kernel image and <addr3> is the address of
+a FDT binary blob. Kernel is booted without initrd.
+
+Boot method: FDT
+
+FIT syntax
+~~~~~~~~~~
+
+::
+
+    8.  bootm <addr1>
+
+Image at <addr1> is assumed to contain a default configuration, which
+is booted.
+
+Boot method: FDT or non-FDT, depending on whether the default configuration
+defines FDT
+
+::
+
+    9.  bootm [<addr1>]:<subimg1>
+
+Similar to case 2: boot kernel stored in <subimg1> from the image at
+address <addr1>.
+
+Boot method: non-FDT
+
+::
+
+    10. bootm [<addr1>]#<conf>[#<extra-conf[#...]]
+
+Boot configuration <conf> from the image at <addr1>.
+
+Boot method: FDT or non-FDT, depending on whether the configuration given
+defines FDT
+
+::
+
+    11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
+
+Equivalent to case 5: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>.
+
+Boot method: non-FDT
+
+::
+
+    12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
+
+Equivalent to case 6: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
+
+Boot method: FDT
+
+::
+
+    13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
+
+Similar to case 12, the difference being that <addr3> is the address
+of FDT binary blob that is to be passed to the kernel.
+
+Boot method: FDT
+
+::
+
+    14. bootm [<addr1>]:<subimg1> -              [<addr3>]:<subimg3>
+
+Equivalent to case 7: boot kernel stored in <subimg1> from the image
+at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
+<addr3>.
+
+Boot method: FDT
+
+    15. bootm [<addr1>]:<subimg1> -              <addr3>
+
+Similar to case 14, the difference being that <addr3> is the address
+of the FDT binary blob that is to be passed to the kernel.
+
+Boot method: FDT
+
+
+
+Example
+-------
+
+boot kernel "kernel-1" stored in a new uImage located at 200000::
+
+    bootm 200000:kernel-1
+
+boot configuration "cfg-1" from a new uImage located at 200000::
+
+    bootm 200000#cfg-1
+
+boot configuration "cfg-1" with extra "cfg-2" from a new uImage located
+at 200000::
+
+    bootm 200000#cfg-1#cfg-2
+
+boot "kernel-1" from a new uImage at 200000 with initrd "ramdisk-2" found in
+some other new uImage stored at address 800000::
+
+    bootm 200000:kernel-1 800000:ramdisk-2
+
+boot "kernel-2" from a new uImage at 200000, with initrd "ramdisk-1" and FDT
+"fdt-1", both stored in some other new uImage located at 800000::
+
+    bootm 200000:kernel-1 800000:ramdisk-1 800000:fdt-1
+
+boot kernel "kernel-2" with initrd "ramdisk-2", both stored in a new uImage
+at address 200000, with a raw FDT blob stored at address 600000::
+
+    bootm 200000:kernel-2 200000:ramdisk-2 600000
+
+boot kernel "kernel-2" from new uImage at 200000 with FDT "fdt-1" from the
+same new uImage::
+
+    bootm 200000:kernel-2 - 200000:fdt-1
+
+.. sectionauthor:: Bartlomiej Sieka <tur@semihalf.com>
+.. sectionauthor:: Simon Glass <sjg@chromium.org>

doc/usage/cmd/imxtract.rst

@@ -0,0 +1,81 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+imxtract command
+================
+
+Synopsis
+--------
+
+::
+
+    imxtract addr part [dest]
+    imxtract addr uname [dest]
+
+Description
+-----------
+
+The imxtract command is used to extract a part of a multi-image file.
+
+Two different file formats are supported:
+
+* FIT images
+* legacy U-Boot images
+
+addr
+    Address of the multi-image file from which a part shall be extracted
+
+part
+    Index (hexadecimal) of the part of a legacy U-Boot image to be extracted
+
+uname
+    Name of the part of a FIT image to be extracted
+
+dest
+    Destination address (defaults to 0x0)
+
+The value of environment variable *verify* controls if the hashes and
+signatures of FIT images or the check sums of legacy U-Boot images are checked.
+To enable checking set *verify* to one of the values *1*, *yes*, *true*.
+(Actually only the first letter is checked disregarding the case.)
+
+To list the parts of an image the *iminfo* command can be used.
+
+Examples
+--------
+
+With verify=no incorrect hashes, signatures, or check sums don't stop the
+extraction. But correct hashes are still indicated in the output
+(here: md5, sha1).
+
+.. code-block:: console
+
+    => setenv verify no
+    => imxtract $loadaddr kernel-1 $kernel_addr_r
+    ## Copying 'kernel-1' subimage from FIT image at 40200000 ...
+    md5+ sha1+    Loading part 0 ... OK
+    =>
+
+With verify=yes incorrect hashes, signatures, or check sums stop the extraction.
+
+.. code-block:: console
+
+    => setenv verify yes
+    => imxtract $loadaddr kernel-1 $kernel_addr_r
+    ## Copying 'kernel-1' subimage from FIT image at 40200000 ...
+    md5 error!
+    Bad hash value for 'hash-1' hash node in 'kernel-1' image node
+    Bad Data Hash
+    =>
+
+Configuration
+-------------
+
+The imxtract command is only available if CONFIG_CMD_XIMG=y. Support for FIT
+images requires CONFIG_FIT=y. Support for legacy U-Boot images requires
+CONFIG_LEGACY_IMAGE_FORMAT=y.
+
+Return value
+------------
+
+On success the return value $? of the command is 0 (true). On failure the
+return value is 1 (false).

doc/usage/cmd/loadb.rst

@@ -13,7 +13,7 @@ Synopsis
 Description
 -----------
 
-The loady command is used to transfer a file to the device via the serial line
+The loadb command is used to transfer a file to the device via the serial line
 using the Kermit protocol.
 
 The number of transferred bytes is saved in environment variable filesize.

doc/usage/cmd/loads.rst

@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+loads command
+=============
+
+Synopsis
+--------
+
+::
+
+    loads [offset [baud]]
+
+Description
+-----------
+
+The loads command is used to transfer a file to the device via the serial line
+using the Motorola S-record file format.
+
+offset
+    offset added to the addresses in the S-record file
+
+baud
+    baud rate to use for download. This parameter is only available if
+    CONFIG_SYS_LOADS_BAUD_CHANGE=y
+
+Example
+-------
+
+As example file to be transferred we use a script printing 'hello s-record'.
+Here are the commands to create the S-record file:
+
+.. code-block:: bash
+
+    $ echo 'echo hello s-record' > script.txt
+    $ mkimage -T script -d script.txt script.scr
+    Image Name:
+    Created:      Sun Jun 25 10:35:02 2023
+    Image Type:   PowerPC Linux Script (gzip compressed)
+    Data Size:    28 Bytes = 0.03 KiB = 0.00 MiB
+    Load Address: 00000000
+    Entry Point:  00000000
+    Contents:
+       Image 0: 20 Bytes = 0.02 KiB = 0.00 MiB
+    $ srec_cat script.scr -binary -CRLF -Output script.srec
+    $ echo -e "S9030000FC\r" >> script.srec
+    $ cat script.srec
+    S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D
+    S1230000270519566D773EB6649815E30000001700000000000000003DE3D97005070601E2
+    S12300200000000000000000000000000000000000000000000000000000000000000000BC
+    S11A00400000000F0000000068656C6C6F20732D7265636F72640A39
+    S5030003F9
+    S9030000FC
+    $
+
+The load address in the first S1 record is 0x0000.
+
+The terminal emulation program picocom is invoked with *cat* as the send
+command to transfer the file.
+
+.. code-block::
+
+    picocom --send-cmd 'cat' --baud 115200 /dev/ttyUSB0
+
+After entering the *loads* command the key sequence <CTRL-A><CTRL-S> is used to
+let picocom prompt for the file name. Picocom invokes the program *cat* for the
+file transfer. The loaded script is executed using the *source* command.
+
+.. code-block::
+
+    => loads $scriptaddr
+    ## Ready for S-Record download ...
+
+    *** file: script.srec
+    $ cat script.srec
+
+    *** exit status: 0 ***
+
+    ## First Load Addr = 0x4FC00000
+    ## Last  Load Addr = 0x4FC0005B
+    ## Total Size      = 0x0000005C = 92 Bytes
+    ## Start Addr      = 0x00000000
+    => source $scriptaddr
+    ## Executing script at 4fc00000
+    hello s-record
+    =>
+
+Configuration
+-------------
+
+The command is only available if CONFIG_CMD_LOADS=y. The parameter to set the
+baud rate is only available if CONFIG_SYS_LOADS_BAUD_CHANGE=y
+
+Return value
+------------
+
+The return value $? is 0 (true) on success, 1 (false) otherwise.

doc/usage/cmd/saves.rst

@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+saves command
+=============
+
+Synopsis
+--------
+
+::
+
+    saves [offset [size [baud]]]
+
+Description
+-----------
+
+The *saves* command is used to transfer a file from the device via the serial
+line using the Motorola S-record file format.
+
+offset
+    start address of memory area to save, defaults to 0x0
+
+size
+    size of memory area to save, defaults to 0x0
+
+baud
+    baud rate to use for upload. This parameter is only available if
+    CONFIG_SYS_LOADS_BAUD_CHANGE=y
+
+Example
+-------
+
+In the example the *screen* command is used to connect to the U-Boot serial
+console.
+
+In a first screen session a file is loaded from the SD-card and the *saves*
+command is invoked. <CTRL+A><k> is used to kill the screen session.
+
+A new screen session is started which logs the output to a file and the
+<ENTER> key is hit to start the file output. <CTRL+A><k> is issued to kill the
+screen session.
+
+The log file is converted to a binary file using the *srec_cat* command.
+A negative offset of -1337982976 (= -0x4c000000) is applied to compensate for
+the offset used in the *saves* command.
+
+.. code-block::
+
+    $ screen /dev/ttyUSB0 115200
+    => echo $scriptaddr
+    0x4FC00000
+    => load mmc 0:1 $scriptaddr boot.txt
+    124 bytes read in 1 ms (121.1 KiB/s)
+    => saves $scriptaddr $filesize
+    ## Ready for S-Record upload, press ENTER to proceed ...
+    Really kill this window [y/n]
+    $ screen -Logfile out.srec -L /dev/ttyUSB0 115200
+    S0030000FC
+    S3154FC00000736574656E76206175746F6C6F616420AD
+    S3154FC000106E6F0A646863700A6C6F6164206D6D633E
+    S3154FC0002020303A3120246664745F616464725F72B3
+    S3154FC00030206474620A6C6F6164206D6D6320303AC0
+    S3154FC000403120246B65726E656C5F616464725F72DA
+    S3154FC0005020736E702E6566690A626F6F74656669C6
+    S3154FC0006020246B65726E656C5F616464725F7220CB
+    S3114FC00070246664745F616464725F720A38
+    S70500000000FA
+    ## S-Record upload complete
+    =>
+    Really kill this window [y/n]
+    $ srec_cat out.srec -offset -1337982976 -Output out.txt -binary 2>/dev/null
+    $ cat out.txt
+    setenv autoload no
+    dhcp
+    load mmc 0:1 $fdt_addr_r dtb
+    load mmc 0:1 $kernel_addr_r snp.efi
+    bootefi $kernel_addr_r $fdt_addr_r
+    $
+
+Configuration
+-------------
+
+The command is only available if CONFIG_CMD_SAVES=y. The parameter to set the
+baud rate is only available if CONFIG_SYS_LOADS_BAUD_CHANGE=y
+
+Return value
+------------
+
+The return value $? is 0 (true) on success, 1 (false) otherwise.

doc/usage/cmd/source.rst

@@ -22,7 +22,7 @@ Two formats for script files exist:
 * Flat Image Tree (FIT)
 
 The benefit of the FIT images is that they can be signed and verifed as
-decribed in :download:`signature.txt <../../uImage.FIT/signature.txt>`.
+described in :doc:`../fit/signature`.
 
 Both formats can be created with the mkimage tool.
 

doc/usage/cmd/unbind.rst

@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+unbind command
+==============
+
+Synopsis
+--------
+
+::
+
+    unbind <node path>
+    unbind <class> <index>
+    unbind <class> <index> <driver>
+
+Description
+-----------
+
+The unbind command is used to unbind a device from a driver. This makes the
+device unavailable in U-Boot.
+
+node path
+    path of the device's device-tree node
+
+class
+    device class name
+
+index
+    index of the device in the device class
+
+driver
+    device driver name
+
+Example
+-------
+
+Given a system with a real time clock device with device path */pl031@9010000*
+and using driver rtc-pl031 unbinding and binding of the device is demonstrated
+using the three alternative unbind syntaxes.
+
+.. code-block::
+
+    => dm tree
+     Class     Index  Probed  Driver                Name
+    -----------------------------------------------------------
+     root          0  [ + ]   root_driver           root_driver
+    ...
+     rtc           0  [   ]   rtc-pl031             |-- pl031@9010000
+    ...
+    => fdt addr $fdtcontroladdr
+    Working FDT set to 7ed7fdb0
+    => fdt print
+    / {
+            interrupt-parent = <0x00008003>;
+            model = "linux,dummy-virt";
+            #size-cells = <0x00000002>;
+            #address-cells = <0x00000002>;
+            compatible = "linux,dummy-virt";
+    ...
+            pl031@9010000 {
+                    clock-names = "apb_pclk";
+                    clocks = <0x00008000>;
+                    interrupts = <0x00000000 0x00000002 0x00000004>;
+                    reg = <0x00000000 0x09010000 0x00000000 0x00001000>;
+                    compatible = "arm,pl031", "arm,primecell";
+            };
+    ...
+    }
+    => unbind /pl031@9010000
+    => dm tree
+     Class     Index  Probed  Driver                Name
+    -----------------------------------------------------------
+     root          0  [ + ]   root_driver           root_driver
+    ...
+    => unbind /pl031@9010000
+    Cannot find a device with path /pl031@9010000
+    => bind /pl031@9010000 rtc-pl031
+    => dm tree
+     Class     Index  Probed  Driver                Name
+    -----------------------------------------------------------
+     root          0  [ + ]   root_driver           root_driver
+    ...
+     rtc           0  [   ]   rtc-pl031             |-- pl031@9010000
+    => unbind rtc 0
+    => bind /pl031@9010000 rtc-pl031
+    => unbind rtc 0 rtc-pl031
+
+Configuration
+-------------
+
+The unbind command is only available if CONFIG_CMD_BIND=y.
+
+Return code
+-----------
+
+The return code $? is 0 (true) on success and 1 (false) on failure.

doc/usage/fit/beaglebone_vboot.rst

@@ -0,0 +1,612 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Verified Boot on the Beaglebone Black
+=====================================
+
+Introduction
+------------
+
+Before reading this, please read :doc:`verified-boot` and :doc:`signature`.
+These instructions are for mainline U-Boot from v2014.07 onwards.
+
+There is quite a bit of documentation in this directory describing how
+verified boot works in U-Boot. There is also a test which runs through the
+entire process of signing an image and running U-Boot (sandbox) to check it.
+However, it might be useful to also have an example on a real board.
+
+Beaglebone Black is a fairly common board so seems to be a reasonable choice
+for an example of how to enable verified boot using U-Boot.
+
+First a note that may to help avoid confusion. U-Boot and Linux both use
+device tree. They may use the same device tree source, but it is seldom useful
+for them to use the exact same binary from the same place. More typically,
+U-Boot has its device tree packaged with it, and the kernel's device tree is
+packaged with the kernel. In particular this is important with verified boot,
+since U-Boot's device tree must be immutable. If it can be changed then the
+public keys can be changed and verified boot is useless. An attacker can
+simply generate a new key and put his public key into U-Boot so that
+everything verifies. On the other hand the kernel's device tree typically
+changes when the kernel changes, so it is useful to package an updated device
+tree with the kernel binary. U-Boot supports the latter with its flexible FIT
+format (Flat Image Tree).
+
+
+Overview
+--------
+
+The steps are roughly as follows:
+
+#. Build U-Boot for the board, with the verified boot options enabled.
+
+#. Obtain a suitable Linux kernel
+
+#. Create a Image Tree Source file (ITS) file describing how you want the
+   kernel to be packaged, compressed and signed.
+
+#. Create a key pair
+
+#. Sign the kernel
+
+#. Put the public key into U-Boot's image
+
+#. Put U-Boot and the kernel onto the board
+
+#. Try it
+
+
+Step 1: Build U-Boot
+--------------------
+
+a. Set up the environment variable to point to your toolchain. You will need
+   this for U-Boot and also for the kernel if you build it. For example if you
+   installed a Linaro version manually it might be something like::
+
+       export CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-
+
+   or if you just installed gcc-arm-linux-gnueabi then it might be::
+
+       export CROSS_COMPILE=arm-linux-gnueabi-
+
+b. Configure and build U-Boot with verified boot enabled::
+
+    export UBOOT=/path/to/u-boot
+    cd $UBOOT
+    # You can add -j10 if you have 10 CPUs to make it faster
+    make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all
+    export UOUT=$UBOOT/b/am335x_boneblack_vboot
+
+c. You will now have a U-Boot image::
+
+    file b/am335x_boneblack_vboot/u-boot-dtb.img
+    b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage,
+      U-Boot 2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image
+      (Not compressed), 395375 bytes, Sat May 31 16:19:04 2014,
+      Load Address: 0x80800000, Entry Point: 0x00000000,
+      Header CRC: 0x0ABD6ACA, Data CRC: 0x36DEF7E4
+
+
+Step 2: Build Linux
+--------------------
+
+a. Find the kernel image ('Image') and device tree (.dtb) file you plan to
+   use. In our case it is am335x-boneblack.dtb and it is built with the kernel.
+   At the time of writing an SD Boot image can be obtained from here::
+
+       http://www.elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD
+
+   You can write this to an SD card and then mount it to extract the kernel and
+   device tree files.
+
+   You can also build a kernel. Instructions for this are are here::
+
+       http://elinux.org/Building_BBB_Kernel
+
+   or you can use your favourite search engine. Following these instructions
+   produces a kernel Image and device tree files. For the record the steps
+   were::
+
+        export KERNEL=/path/to/kernel
+        cd $KERNEL
+        git clone git://github.com/beagleboard/kernel.git .
+        git checkout v3.14
+        ./patch.sh
+        cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig
+        cd kernel
+        make beaglebone_defconfig
+        make uImage dtbs   # -j10 if you have 10 CPUs
+        export OKERNEL=$KERNEL/kernel/arch/arm/boot
+
+b. You now have the 'Image' and 'am335x-boneblack.dtb' files needed to boot.
+
+
+Step 3: Create the ITS
+----------------------
+
+Set up a directory for your work::
+
+   export WORK=/path/to/dir
+   cd $WORK
+
+Put this into a file in that directory called sign.its::
+
+    /dts-v1/;
+
+    / {
+        description = "Beaglebone black";
+        #address-cells = <1>;
+
+        images {
+            kernel {
+                data = /incbin/("Image.lzo");
+                type = "kernel";
+                arch = "arm";
+                os = "linux";
+                compression = "lzo";
+                load = <0x80008000>;
+                entry = <0x80008000>;
+                hash-1 {
+                    algo = "sha1";
+                };
+            };
+            fdt-1 {
+                description = "beaglebone-black";
+                data = /incbin/("am335x-boneblack.dtb");
+                type = "flat_dt";
+                arch = "arm";
+                compression = "none";
+                hash-1 {
+                    algo = "sha1";
+                };
+            };
+        };
+        configurations {
+            default = "conf-1";
+            conf-1 {
+                kernel = "kernel";
+                fdt = "fdt-1";
+                signature-1 {
+                    algo = "sha1,rsa2048";
+                    key-name-hint = "dev";
+                    sign-images = "fdt", "kernel";
+                };
+            };
+        };
+    };
+
+
+The explanation for this is all in the documentation you have already read.
+But briefly it packages a kernel and device tree, and provides a single
+configuration to be signed with a key named 'dev'. The kernel is compressed
+with LZO to make it smaller.
+
+
+Step 4: Create a key pair
+-------------------------
+
+See :doc:`signature` for details on this step::
+
+   cd $WORK
+   mkdir keys
+   openssl genrsa -F4 -out keys/dev.key 2048
+   openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+Note: keys/dev.key contains your private key and is very secret. If anyone
+gets access to that file they can sign kernels with it. Keep it secure.
+
+
+Step 5: Sign the kernel
+-----------------------
+
+We need to use mkimage (which was built when you built U-Boot) to package the
+Linux kernel into a FIT (Flat Image Tree, a flexible file format that U-Boot
+can load) using the ITS file you just created.
+
+At the same time we must put the public key into U-Boot device tree, with the
+'required' property, which tells U-Boot that this key must be verified for the
+image to be valid. You will make this key available to U-Boot for booting in
+step 6::
+
+   ln -s $OKERNEL/dts/am335x-boneblack.dtb
+   ln -s $OKERNEL/Image
+   ln -s $UOUT/u-boot-dtb.img
+   cp $UOUT/arch/arm/dts/am335x-boneblack.dtb am335x-boneblack-pubkey.dtb
+   lzop Image
+   $UOUT/tools/mkimage -f sign.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit
+
+You should see something like this::
+
+    FIT description: Beaglebone black
+    Created:         Sun Jun  1 12:50:30 2014
+     Image 0 (kernel)
+      Description:  unavailable
+      Created:      Sun Jun  1 12:50:30 2014
+      Type:         Kernel Image
+      Compression:  lzo compressed
+      Data Size:    7790938 Bytes = 7608.34 kB = 7.43 MB
+      Architecture: ARM
+      OS:           Linux
+      Load Address: 0x80008000
+      Entry Point:  0x80008000
+      Hash algo:    sha1
+      Hash value:   c94364646427e10f423837e559898ef02c97b988
+     Image 1 (fdt-1)
+      Description:  beaglebone-black
+      Created:      Sun Jun  1 12:50:30 2014
+      Type:         Flat Device Tree
+      Compression:  uncompressed
+      Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
+      Architecture: ARM
+      Hash algo:    sha1
+      Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+     Default Configuration: 'conf-1'
+     Configuration 0 (conf-1)
+      Description:  unavailable
+      Kernel:       kernel
+      FDT:          fdt-1
+
+
+Now am335x-boneblack-pubkey.dtb contains the public key and image.fit contains
+the signed kernel. Jump to step 6 if you like, or continue reading to increase
+your understanding.
+
+You can also run fit_check_sign to check it::
+
+   $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
+
+which results in::
+
+    Verifying Hash Integrity ... sha1,rsa2048:dev+
+    ## Loading kernel from FIT Image at 7fc6ee469000 ...
+       Using 'conf-1' configuration
+       Verifying Hash Integrity ...
+    sha1,rsa2048:dev+
+    OK
+
+       Trying 'kernel' kernel subimage
+         Description:  unavailable
+         Created:      Sun Jun  1 12:50:30 2014
+         Type:         Kernel Image
+         Compression:  lzo compressed
+         Data Size:    7790938 Bytes = 7608.34 kB = 7.43 MB
+         Architecture: ARM
+         OS:           Linux
+         Load Address: 0x80008000
+         Entry Point:  0x80008000
+         Hash algo:    sha1
+         Hash value:   c94364646427e10f423837e559898ef02c97b988
+       Verifying Hash Integrity ...
+    sha1+
+    OK
+
+    Unimplemented compression type 4
+    ## Loading fdt from FIT Image at 7fc6ee469000 ...
+       Using 'conf-1' configuration
+       Trying 'fdt-1' fdt subimage
+         Description:  beaglebone-black
+         Created:      Sun Jun  1 12:50:30 2014
+         Type:         Flat Device Tree
+         Compression:  uncompressed
+         Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
+         Architecture: ARM
+         Hash algo:    sha1
+         Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+       Verifying Hash Integrity ...
+    sha1+
+    OK
+
+       Loading Flat Device Tree ... OK
+
+    ## Loading ramdisk from FIT Image at 7fc6ee469000 ...
+       Using 'conf-1' configuration
+    Could not find subimage node
+
+    Signature check OK
+
+
+At the top, you see "sha1,rsa2048:dev+". This means that it checked an RSA key
+of size 2048 bits using SHA1 as the hash algorithm. The key name checked was
+'dev' and the '+' means that it verified. If it showed '-' that would be bad.
+
+Once the configuration is verified it is then possible to rely on the hashes
+in each image referenced by that configuration. So fit_check_sign goes on to
+load each of the images. We have a kernel and an FDT but no ramkdisk. In each
+case fit_check_sign checks the hash and prints sha1+ meaning that the SHA1
+hash verified. This means that none of the images has been tampered with.
+
+There is a test in test/vboot which uses U-Boot's sandbox build to verify that
+the above flow works.
+
+But it is fun to do this by hand, so you can load image.fit into a hex editor
+like ghex, and change a byte in the kernel::
+
+    $UOUT/tools/fit_info -f image.fit -n /images/kernel -p data
+    NAME: kernel
+    LEN: 7790938
+    OFF: 168
+
+This tells us that the kernel starts at byte offset 168 (decimal) in image.fit
+and extends for about 7MB. Try changing a byte at 0x2000 (say) and run
+fit_check_sign again. You should see something like::
+
+    Verifying Hash Integrity ... sha1,rsa2048:dev+
+    ## Loading kernel from FIT Image at 7f5a39571000 ...
+       Using 'conf-1' configuration
+       Verifying Hash Integrity ...
+    sha1,rsa2048:dev+
+    OK
+
+       Trying 'kernel' kernel subimage
+         Description:  unavailable
+         Created:      Sun Jun  1 13:09:21 2014
+         Type:         Kernel Image
+         Compression:  lzo compressed
+         Data Size:    7790938 Bytes = 7608.34 kB = 7.43 MB
+         Architecture: ARM
+         OS:           Linux
+         Load Address: 0x80008000
+         Entry Point:  0x80008000
+         Hash algo:    sha1
+         Hash value:   c94364646427e10f423837e559898ef02c97b988
+       Verifying Hash Integrity ...
+    sha1 error
+    Bad hash value for 'hash-1' hash node in 'kernel' image node
+    Bad Data Hash
+
+    ## Loading fdt from FIT Image at 7f5a39571000 ...
+       Using 'conf-1' configuration
+       Trying 'fdt-1' fdt subimage
+         Description:  beaglebone-black
+         Created:      Sun Jun  1 13:09:21 2014
+         Type:         Flat Device Tree
+         Compression:  uncompressed
+         Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
+         Architecture: ARM
+         Hash algo:    sha1
+         Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+       Verifying Hash Integrity ...
+    sha1+
+    OK
+
+       Loading Flat Device Tree ... OK
+
+    ## Loading ramdisk from FIT Image at 7f5a39571000 ...
+       Using 'conf-1' configuration
+    Could not find subimage node
+
+    Signature check Bad (error 1)
+
+
+It has detected the change in the kernel.
+
+You can also be sneaky and try to switch images, using the libfdt utilities
+that come with dtc (package name is device-tree-compiler but you will need a
+recent version like 1.4::
+
+    dtc -v
+    Version: DTC 1.4.0
+
+First we can check which nodes are actually hashed by the configuration::
+
+    $ fdtget -l image.fit /
+    images
+    configurations
+
+    $ fdtget -l image.fit /configurations
+    conf-1
+    fdtget -l image.fit /configurations/conf-1
+    signature-1
+
+    $ fdtget -p image.fit /configurations/conf-1/signature-1
+    hashed-strings
+    hashed-nodes
+    timestamp
+    signer-version
+    signer-name
+    value
+    algo
+    key-name-hint
+    sign-images
+
+    $ fdtget image.fit /configurations/conf-1/signature-1 hashed-nodes
+    / /configurations/conf-1 /images/fdt-1 /images/fdt-1/hash /images/kernel /images/kernel/hash-1
+
+This gives us a bit of a look into the signature that mkimage added. Note you
+can also use fdtdump to list the entire device tree.
+
+Say we want to change the kernel that this configuration uses
+(/images/kernel). We could just put a new kernel in the image, but we will
+need to change the hash to match. Let's simulate that by changing a byte of
+the hash::
+
+    fdtget -tx image.fit /images/kernel/hash-1 value
+    c9436464 6427e10f 423837e5 59898ef0 2c97b988
+    fdtput -tx image.fit /images/kernel/hash-1 value c9436464 6427e10f 423837e5 59898ef0 2c97b981
+
+Now check it again::
+
+    $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
+    Verifying Hash Integrity ... sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
+    rsa_verify_with_keynode: RSA failed to verify: -13
+    -
+    Failed to verify required signature 'key-dev'
+    Signature check Bad (error 1)
+
+This time we don't even get as far as checking the images, since the
+configuration signature doesn't match. We can't change any hashes without the
+signature check noticing. The configuration is essentially locked. U-Boot has
+a public key for which it requires a match, and will not permit the use of any
+configuration that does not match that public key. The only way the
+configuration will match is if it was signed by the matching private key.
+
+It would also be possible to add a new signature node that does match your new
+configuration. But that won't work since you are not allowed to change the
+configuration in any way. Try it with a fresh (valid) image if you like by
+running the mkimage link again. Then::
+
+    fdtput -p image.fit /configurations/conf-1/signature-1 value fred
+    $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
+    Verifying Hash Integrity ... -
+    sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
+    rsa_verify_with_keynode: RSA failed to verify: -13
+    -
+    Failed to verify required signature 'key-dev'
+    Signature check Bad (error 1)
+
+
+Of course it would be possible to add an entirely new configuration and boot
+with that, but it still needs to be signed, so it won't help.
+
+
+6. Put the public key into U-Boot's image
+-----------------------------------------
+
+Having confirmed that the signature is doing its job, let's try it out in
+U-Boot on the board. U-Boot needs access to the public key corresponding to
+the private key that you signed with so that it can verify any kernels that
+you sign::
+
+    cd $UBOOT
+    make O=b/am335x_boneblack_vboot EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb
+
+Here we are overriding the normal device tree file with our one, which
+contains the public key.
+
+Now you have a special U-Boot image with the public key. It can verify can
+kernel that you sign with the private key as in step 5.
+
+If you like you can take a look at the public key information that mkimage
+added to U-Boot's device tree::
+
+    fdtget -p am335x-boneblack-pubkey.dtb /signature/key-dev
+    required
+    algo
+    rsa,r-squared
+    rsa,modulus
+    rsa,n0-inverse
+    rsa,num-bits
+    key-name-hint
+
+This has information about the key and some pre-processed values which U-Boot
+can use to verify against it. These values are obtained from the public key
+certificate by mkimage, but require quite a bit of code to generate. To save
+code space in U-Boot, the information is extracted and written in raw form for
+U-Boot to easily use. The same mechanism is used in Google's Chrome OS.
+
+Notice the 'required' property. This marks the key as required - U-Boot will
+not boot any image that does not verify against this key.
+
+
+7. Put U-Boot and the kernel onto the board
+-------------------------------------------
+
+The method here varies depending on how you are booting. For this example we
+are booting from an micro-SD card with two partitions, one for U-Boot and one
+for Linux. Put it into your machine and write U-Boot and the kernel to it.
+Here the card is /dev/sde::
+
+    cd $WORK
+    export UDEV=/dev/sde1   # Change thes two lines to the correct device
+    export KDEV=/dev/sde2
+    sudo mount $UDEV /mnt/tmp && sudo cp $UOUT/u-boot-dtb.img /mnt/tmp/u-boot.img  && sleep 1 && sudo umount $UDEV
+    sudo mount $KDEV /mnt/tmp && sudo cp $WORK/image.fit /mnt/tmp/boot/image.fit && sleep 1 && sudo umount $KDEV
+
+
+8. Try it
+---------
+
+Boot the board using the commands below::
+
+    setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
+    ext2load mmc 0:2 82000000 /boot/image.fit
+    bootm 82000000
+
+You should then see something like this::
+
+    U-Boot# setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
+    U-Boot# ext2load mmc 0:2 82000000 /boot/image.fit
+    7824930 bytes read in 589 ms (12.7 MiB/s)
+    U-Boot# bootm 82000000
+    ## Loading kernel from FIT Image at 82000000 ...
+       Using 'conf-1' configuration
+       Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
+       Trying 'kernel' kernel subimage
+         Description:  unavailable
+         Created:      2014-06-01  19:32:54 UTC
+         Type:         Kernel Image
+         Compression:  lzo compressed
+         Data Start:   0x820000a8
+         Data Size:    7790938 Bytes = 7.4 MiB
+         Architecture: ARM
+         OS:           Linux
+         Load Address: 0x80008000
+         Entry Point:  0x80008000
+         Hash algo:    sha1
+         Hash value:   c94364646427e10f423837e559898ef02c97b988
+       Verifying Hash Integrity ... sha1+ OK
+    ## Loading fdt from FIT Image at 82000000 ...
+       Using 'conf-1' configuration
+       Trying 'fdt-1' fdt subimage
+         Description:  beaglebone-black
+         Created:      2014-06-01  19:32:54 UTC
+         Type:         Flat Device Tree
+         Compression:  uncompressed
+         Data Start:   0x8276e2ec
+         Data Size:    31547 Bytes = 30.8 KiB
+         Architecture: ARM
+         Hash algo:    sha1
+         Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+       Verifying Hash Integrity ... sha1+ OK
+       Booting using the fdt blob at 0x8276e2ec
+       Uncompressing Kernel Image ... OK
+       Loading Device Tree to 8fff5000, end 8ffffb3a ... OK
+
+    Starting kernel ...
+
+    [    0.582377] omap_init_mbox: hwmod doesn't have valid attrs
+    [    2.589651] musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
+    [    2.595830] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
+    [    2.606470] musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
+    [    2.612723] musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
+    [    2.940808] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
+    [    7.248889] libphy: PHY 4a101000.mdio:01 not found
+    [    7.253995] net eth0: phy 4a101000.mdio:01 not found on slave 1
+    systemd-fsck[83]: Angstrom: clean, 50607/218160 files, 306348/872448 blocks
+
+    .---O---.
+    |       |                  .-.           o o
+    |   |   |-----.-----.-----.| |   .----..-----.-----.
+    |       |     | __  |  ---'| '--.|  .-'|     |     |
+    |   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
+    '---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
+                    -'  |
+                    '---'
+
+    The Angstrom Distribution beaglebone ttyO0
+
+    Angstrom v2012.12 - Kernel 3.14.1+
+
+    beaglebone login:
+
+At this point your kernel has been verified and you can be sure that it is one
+that you signed. As an exercise, try changing image.fit as in step 5 and see
+what happens.
+
+
+Further Improvements
+--------------------
+
+Several of the steps here can be easily automated. In particular it would be
+capital if signing and packaging a kernel were easy, perhaps a simple make
+target in the kernel.
+
+Some mention of how to use multiple .dtb files in a FIT might be useful.
+
+U-Boot's verified boot mechanism has not had a robust and independent security
+review. Such a review should look at the implementation and its resistance to
+attacks.
+
+Perhaps the verified boot feature could be integrated into the Amstrom
+distribution.
+
+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>, 2-June-14

doc/usage/fit/howto.rst

@@ -0,0 +1,419 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+How to use images in the new image format
+=========================================
+
+Overview
+--------
+
+The new uImage format allows more flexibility in handling images of various
+types (kernel, ramdisk, etc.), it also enhances integrity protection of images
+with sha1 and md5 checksums.
+
+Two auxiliary tools are needed on the development host system in order to
+create an uImage in the new format: mkimage and dtc, although only one
+(mkimage) is invoked directly. dtc is called from within mkimage and operates
+behind the scenes, but needs to be present in the $PATH nevertheless. It is
+important that the dtc used has support for binary includes -- refer to::
+
+    git://git.kernel.org/pub/scm/utils/dtc/dtc.git
+
+for its latest version. mkimage (together with dtc) takes as input
+an image source file, which describes the contents of the image and defines
+its various properties used during booting. By convention, image source file
+has the ".its" extension, also, the details of its format are given in
+doc/uImage.FIT/source_file_format.txt. The actual data that is to be included in
+the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
+form of paths to appropriate data files. The outcome of the image creation
+process is a binary file (by convention with the ".itb" extension) that
+contains all the referenced data (kernel, ramdisk, etc.) and other information
+needed by U-Boot to handle the uImage properly. The uImage file is then
+transferred to the target (e.g., via tftp) and booted using the bootm command.
+
+To summarize the prerequisites needed for new uImage creation:
+
+- mkimage
+- dtc (with support for binary includes)
+- image source file (`*.its`)
+- image data file(s)
+
+
+Here's a graphical overview of the image creation and booting process::
+
+    image source file     mkimage + dtc          transfer to target
+        +          ---------------> image file --------------------> bootm
+    image data file(s)
+
+SPL usage
+---------
+
+The SPL can make use of the new image format as well, this traditionally
+is used to ship multiple device tree files within one image. Code in the SPL
+will choose the one matching the current board and append this to the
+U-Boot proper binary to be automatically used up by it.
+Aside from U-Boot proper and one device tree blob the SPL can load multiple,
+arbitrary image files as well. These binaries should be specified in their
+own subnode under the /images node, which should then be referenced from one or
+multiple /configurations subnodes. The required images must be enumerated in
+the "loadables" property as a list of strings.
+
+If a platform specific image source file (.its) is shipped with the U-Boot
+source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol.
+In this case it will be automatically used by U-Boot's Makefile to generate
+the image.
+If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR
+can point to a script which generates this image source file during
+the build process. It gets passed a list of device tree files (taken from the
+CONFIG_OF_LIST symbol).
+
+The SPL also records to a DT all additional images (called loadables) which are
+loaded. The information about loadables locations is passed via the DT node with
+fit-images name.
+
+Finally, if there are multiple xPL phases (e.g. SPL, VPL), images can be marked
+as intended for a particular phase using the 'phase' property. For example, if
+fit_image_load() is called with image_ph(IH_PHASE_SPL, IH_TYPE_FIRMWARE), then
+only the image listed into the "firmware" property where phase is set to "spl"
+will be loaded.
+
+Loadables Example
+-----------------
+Consider the following case for an ARM64 platform where U-Boot runs in EL2
+started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware).
+
+::
+
+    /dts-v1/;
+
+    / {
+        description = "Configuration to load ATF before U-Boot";
+
+        images {
+            uboot {
+                description = "U-Boot (64-bit)";
+                data = /incbin/("u-boot-nodtb.bin");
+                type = "firmware";
+                os = "u-boot";
+                arch = "arm64";
+                compression = "none";
+                load = <0x8 0x8000000>;
+                entry = <0x8 0x8000000>;
+                hash {
+                    algo = "md5";
+                };
+            };
+            atf {
+                description = "ARM Trusted Firmware";
+                data = /incbin/("bl31.bin");
+                type = "firmware";
+                os = "arm-trusted-firmware";
+                arch = "arm64";
+                compression = "none";
+                load = <0xfffea000>;
+                entry = <0xfffea000>;
+                hash {
+                    algo = "md5";
+                };
+            };
+            fdt_1 {
+                description = "zynqmp-zcu102-revA";
+                data = /incbin/("arch/arm/dts/zynqmp-zcu102-revA.dtb");
+                type = "flat_dt";
+                arch = "arm64";
+                compression = "none";
+                load = <0x100000>;
+                hash {
+                    algo = "md5";
+                };
+            };
+        };
+        configurations {
+            default = "config_1";
+
+            config_1 {
+                description = "zynqmp-zcu102-revA";
+                firmware = "atf";
+                loadables = "uboot";
+                fdt = "fdt_1";
+            };
+        };
+    };
+
+In this case the SPL records via fit-images DT node the information about
+loadables U-Boot image::
+
+    ZynqMP> fdt addr $fdtcontroladdr
+    ZynqMP> fdt print /fit-images
+    fit-images {
+        uboot {
+            os = "u-boot";
+            type = "firmware";
+            size = <0x001017c8>;
+            entry = <0x00000008 0x08000000>;
+            load = <0x00000008 0x08000000>;
+        };
+    };
+
+As you can see entry and load properties are 64bit wide to support loading
+images above 4GB (in past entry and load properties where just 32bit).
+
+
+Example 1 -- old-style (non-FDT) kernel booting
+-----------------------------------------------
+
+Consider a simple scenario, where a PPC Linux kernel built from sources on the
+development host is to be booted old-style (non-FDT) by U-Boot on an embedded
+target. Assume that the outcome of the build is vmlinux.bin.gz, a file which
+contains a gzip-compressed PPC Linux kernel (the only data file in this case).
+The uImage can be produced using the image source file
+doc/uImage.FIT/kernel.its (note that kernel.its assumes that vmlinux.bin.gz is
+in the current working directory; if desired, an alternative path can be
+specified in the kernel.its file). Here's how to create the image and inspect
+its contents:
+
+[on the host system]::
+
+    $ mkimage -f kernel.its kernel.itb
+    DTC: dts->dtb  on file "kernel.its"
+    $
+    $ mkimage -l kernel.itb
+    FIT description: Simple image with single Linux kernel
+    Created:     Tue Mar 11 17:26:15 2008
+     Image 0 (kernel)
+      Description:    Vanilla Linux kernel
+      Type:        Kernel Image
+      Compression:    gzip compressed
+      Data Size:    943347 Bytes = 921.24 kB = 0.90 MB
+      Architecture: PowerPC
+      OS:        Linux
+      Load Address: 0x00000000
+      Entry Point:    0x00000000
+      Hash algo:    crc32
+      Hash value:    2ae2bb40
+      Hash algo:    sha1
+      Hash value:    3c200f34e2c226ddc789240cca0c59fc54a67cf4
+     Default Configuration: 'config-1'
+     Configuration 0 (config-1)
+      Description:    Boot Linux kernel
+      Kernel:    kernel
+
+
+The resulting image file kernel.itb can be now transferred to the target,
+inspected and booted (note that first three U-Boot commands below are shown
+for completeness -- they are part of the standard booting procedure and not
+specific to the new image format).
+
+[on the target system]::
+
+    => print nfsargs
+    nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
+    => print addip
+    addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
+    => run nfsargs addip
+    => tftp 900000 /path/to/tftp/location/kernel.itb
+    Using FEC device
+    TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+    Filename '/path/to/tftp/location/kernel.itb'.
+    Load address: 0x900000
+    Loading: #################################################################
+    done
+    Bytes transferred = 944464 (e6950 hex)
+    => iminfo
+
+    ## Checking Image at 00900000 ...
+       FIT image found
+       FIT description: Simple image with single Linux kernel
+       Created:        2008-03-11    16:26:15 UTC
+        Image 0 (kernel)
+         Description:  Vanilla Linux kernel
+         Type:       Kernel Image
+         Compression:  gzip compressed
+         Data Start:   0x009000e0
+         Data Size:    943347 Bytes = 921.2 kB
+         Architecture: PowerPC
+         OS:       Linux
+         Load Address: 0x00000000
+         Entry Point:  0x00000000
+         Hash algo:    crc32
+         Hash value:   2ae2bb40
+         Hash algo:    sha1
+         Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
+        Default Configuration: 'config-1'
+        Configuration 0 (config-1)
+         Description:  Boot Linux kernel
+         Kernel:       kernel
+
+    => bootm
+    ## Booting kernel from FIT Image at 00900000 ...
+       Using 'config-1' configuration
+       Trying 'kernel' kernel subimage
+         Description:  Vanilla Linux kernel
+         Type:       Kernel Image
+         Compression:  gzip compressed
+         Data Start:   0x009000e0
+         Data Size:    943347 Bytes = 921.2 kB
+         Architecture: PowerPC
+         OS:       Linux
+         Load Address: 0x00000000
+         Entry Point:  0x00000000
+         Hash algo:    crc32
+         Hash value:   2ae2bb40
+         Hash algo:    sha1
+         Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
+       Verifying Hash Integrity ... crc32+ sha1+ OK
+       Uncompressing Kernel Image ... OK
+    Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
+    Linux version 2.4.25 (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 czw lip 5 17:56:18 CEST 2007
+    On node 0 totalpages: 65536
+    zone(0): 65536 pages.
+    zone(1): 0 pages.
+    zone(2): 0 pages.
+    Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_6xx ip=192.168.160.5:192.168.1.1::255.255.0.0:lite5200b:eth0:off panic=1
+    Calibrating delay loop... 307.20 BogoMIPS
+
+
+Example 2 -- new-style (FDT) kernel booting
+-------------------------------------------
+
+Consider another simple scenario, where a PPC Linux kernel is to be booted
+new-style, i.e., with a FDT blob. In this case there are two prerequisite data
+files: vmlinux.bin.gz (Linux kernel) and target.dtb (FDT blob). The uImage can
+be produced using image source file doc/uImage.FIT/kernel_fdt.its like this
+(note again, that both prerequisite data files are assumed to be present in
+the current working directory -- image source file kernel_fdt.its can be
+modified to take the files from some other location if needed):
+
+[on the host system]::
+
+    $ mkimage -f kernel_fdt.its kernel_fdt.itb
+    DTC: dts->dtb  on file "kernel_fdt.its"
+    $
+    $ mkimage -l kernel_fdt.itb
+    FIT description: Simple image with single Linux kernel and FDT blob
+    Created:     Tue Mar 11 16:29:22 2008
+     Image 0 (kernel)
+      Description:    Vanilla Linux kernel
+      Type:        Kernel Image
+      Compression:    gzip compressed
+      Data Size:    1092037 Bytes = 1066.44 kB = 1.04 MB
+      Architecture: PowerPC
+      OS:        Linux
+      Load Address: 0x00000000
+      Entry Point:    0x00000000
+      Hash algo:    crc32
+      Hash value:    2c0cc807
+      Hash algo:    sha1
+      Hash value:    264b59935470e42c418744f83935d44cdf59a3bb
+     Image 1 (fdt-1)
+      Description:    Flattened Device Tree blob
+      Type:        Flat Device Tree
+      Compression:    uncompressed
+      Data Size:    16384 Bytes = 16.00 kB = 0.02 MB
+      Architecture: PowerPC
+      Hash algo:    crc32
+      Hash value:    0d655d71
+      Hash algo:    sha1
+      Hash value:    25ab4e15cd4b8a5144610394560d9c318ce52def
+     Default Configuration: 'conf-1'
+     Configuration 0 (conf-1)
+      Description:    Boot Linux kernel with FDT blob
+      Kernel:    kernel
+      FDT:        fdt-1
+
+
+The resulting image file kernel_fdt.itb can be now transferred to the target,
+inspected and booted:
+
+[on the target system]::
+
+    => tftp 900000 /path/to/tftp/location/kernel_fdt.itb
+    Using FEC device
+    TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+    Filename '/path/to/tftp/location/kernel_fdt.itb'.
+    Load address: 0x900000
+    Loading: #################################################################
+         ###########
+    done
+    Bytes transferred = 1109776 (10ef10 hex)
+    => iminfo
+
+    ## Checking Image at 00900000 ...
+       FIT image found
+       FIT description: Simple image with single Linux kernel and FDT blob
+       Created:        2008-03-11    15:29:22 UTC
+        Image 0 (kernel)
+         Description:  Vanilla Linux kernel
+         Type:       Kernel Image
+         Compression:  gzip compressed
+         Data Start:   0x009000ec
+         Data Size:    1092037 Bytes =  1 MB
+         Architecture: PowerPC
+         OS:       Linux
+         Load Address: 0x00000000
+         Entry Point:  0x00000000
+         Hash algo:    crc32
+         Hash value:   2c0cc807
+         Hash algo:    sha1
+         Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
+        Image 1 (fdt-1)
+         Description:  Flattened Device Tree blob
+         Type:       Flat Device Tree
+         Compression:  uncompressed
+         Data Start:   0x00a0abdc
+         Data Size:    16384 Bytes = 16 kB
+         Architecture: PowerPC
+         Hash algo:    crc32
+         Hash value:   0d655d71
+         Hash algo:    sha1
+         Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
+        Default Configuration: 'conf-1'
+        Configuration 0 (conf-1)
+         Description:  Boot Linux kernel with FDT blob
+         Kernel:       kernel
+         FDT:       fdt-1
+    => bootm
+    ## Booting kernel from FIT Image at 00900000 ...
+       Using 'conf-1' configuration
+       Trying 'kernel' kernel subimage
+         Description:  Vanilla Linux kernel
+         Type:       Kernel Image
+         Compression:  gzip compressed
+         Data Start:   0x009000ec
+         Data Size:    1092037 Bytes =  1 MB
+         Architecture: PowerPC
+         OS:       Linux
+         Load Address: 0x00000000
+         Entry Point:  0x00000000
+         Hash algo:    crc32
+         Hash value:   2c0cc807
+         Hash algo:    sha1
+         Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
+       Verifying Hash Integrity ... crc32+ sha1+ OK
+       Uncompressing Kernel Image ... OK
+    ## Flattened Device Tree from FIT Image at 00900000
+       Using 'conf-1' configuration
+       Trying 'fdt-1' FDT blob subimage
+         Description:  Flattened Device Tree blob
+         Type:       Flat Device Tree
+         Compression:  uncompressed
+         Data Start:   0x00a0abdc
+         Data Size:    16384 Bytes = 16 kB
+         Architecture: PowerPC
+         Hash algo:    crc32
+         Hash value:   0d655d71
+         Hash algo:    sha1
+         Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
+       Verifying Hash Integrity ... crc32+ sha1+ OK
+       Booting using the fdt blob at 0xa0abdc
+       Loading Device Tree to 007fc000, end 007fffff ... OK
+    [    0.000000] Using lite5200 machine description
+    [    0.000000] Linux version 2.6.24-rc6-gaebecdfc (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sat Jan 12 15:38:48 CET 2008
+
+
+Example 3 -- advanced booting
+-----------------------------
+
+Refer to :doc:`multi` for an image source file that allows more
+sophisticated booting scenarios (multiple kernels, ramdisks and fdt blobs).
+
+.. sectionauthor:: Bartlomiej Sieka <tur@semihalf.com>

doc/usage/fit/index.rst

@@ -6,3 +6,14 @@ Flat Image Tree (FIT)
 U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
 images that it it reads and boots. Documentation about FIT is available at
 doc/uImage.FIT
+
+.. toctree::
+    :maxdepth: 1
+
+    source_file_format
+    howto
+    x86-fit-boot
+    signature
+    verified-boot
+    beaglebone_vboot
+    overlay-fdt-boot

doc/usage/fit/kernel.rst

@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Single kernel
+=============
+
+::
+
+    /dts-v1/;
+
+    / {
+        description = "Simple image with single Linux kernel";
+        #address-cells = <1>;
+
+        images {
+            kernel {
+                description = "Vanilla Linux kernel";
+                data = /incbin/("./vmlinux.bin.gz");
+                type = "kernel";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "crc32";
+                };
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+        };
+
+        configurations {
+            default = "config-1";
+            config-1 {
+                description = "Boot Linux kernel";
+                kernel = "kernel";
+            };
+        };
+    };
+
+
+For x86 a setup node is also required: see x86-fit-boot::
+
+    /dts-v1/;
+
+    / {
+        description = "Simple image with single Linux kernel on x86";
+        #address-cells = <1>;
+
+        images {
+            kernel {
+                description = "Vanilla Linux kernel";
+                data = /incbin/("./image.bin.lzo");
+                type = "kernel";
+                arch = "x86";
+                os = "linux";
+                compression = "lzo";
+                load = <0x01000000>;
+                entry = <0x00000000>;
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+
+            setup {
+                description = "Linux setup.bin";
+                data = /incbin/("./setup.bin");
+                type = "x86_setup";
+                arch = "x86";
+                os = "linux";
+                compression = "none";
+                load = <0x00090000>;
+                entry = <0x00090000>;
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+        };
+
+        configurations {
+            default = "config-1";
+            config-1 {
+                description = "Boot Linux kernel";
+                kernel = "kernel";
+                setup = "setup";
+            };
+        };
+    };
+
+Note: the above assumes a 32-bit kernel. To directly boot a 64-bit kernel,
+change both arch values to "x86_64". U-Boot will then change to 64-bit mode
+before booting the kernel (see boot_linux_kernel()).

doc/usage/fit/kernel_fdt.rst

@@ -0,0 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Single kernel and FDT blob
+==========================
+
+::
+
+	/dts-v1/;
+
+	/ {
+	description = "Simple image with single Linux kernel and FDT blob";
+	#address-cells = <1>;
+
+	images {
+		kernel {
+		description = "Vanilla Linux kernel";
+		data = /incbin/("./vmlinux.bin.gz");
+		type = "kernel";
+		arch = "ppc";
+		os = "linux";
+		compression = "gzip";
+		load = <00000000>;
+		entry = <00000000>;
+		hash-1 {
+			algo = "crc32";
+		};
+		hash-2 {
+			algo = "sha1";
+		};
+		};
+		fdt-1 {
+		description = "Flattened Device Tree blob";
+		data = /incbin/("./target.dtb");
+		type = "flat_dt";
+		arch = "ppc";
+		compression = "none";
+		hash-1 {
+			algo = "crc32";
+		};
+		hash-2 {
+			algo = "sha1";
+		};
+		};
+	};
+
+	configurations {
+		default = "conf-1";
+		conf-1 {
+		description = "Boot Linux kernel with FDT blob";
+		kernel = "kernel";
+		fdt = "fdt-1";
+		};
+	};
+	};

doc/usage/fit/kernel_fdts_compressed.rst

@@ -0,0 +1,77 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Kernel and multiple compressed FDT blobs
+========================================
+
+Since the FDTs are compressed, configurations must provide a compatible
+string to match directly.
+
+::
+
+    /dts-v1/;
+
+    / {
+        description = "Image with single Linux kernel and compressed FDT blobs";
+        #address-cells = <1>;
+
+        images {
+            kernel {
+                description = "Vanilla Linux kernel";
+                data = /incbin/("./vmlinux.bin.gz");
+                type = "kernel";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "crc32";
+                };
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+            fdt@1 {
+                description = "Flattened Device Tree blob 1";
+                data = /incbin/("./myboard-var1.dtb");
+                type = "flat_dt";
+                arch = "ppc";
+                compression = "gzip";
+                hash-1 {
+                    algo = "crc32";
+                };
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+            fdt@2 {
+                description = "Flattened Device Tree blob 2";
+                data = /incbin/("./myboard-var2.dtb");
+                type = "flat_dt";
+                arch = "ppc";
+                compression = "lzma";
+                hash-1 {
+                    algo = "crc32";
+                };
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+        };
+
+        configurations {
+            default = "conf@1";
+            conf@1 {
+                description = "Boot Linux kernel with FDT blob 1";
+                kernel = "kernel";
+                fdt = "fdt@1";
+                compatible = "myvendor,myboard-variant1";
+            };
+            conf@2 {
+                description = "Boot Linux kernel with FDT blob 2";
+                kernel = "kernel";
+                fdt = "fdt@2";
+                compatible = "myvendor,myboard-variant2";
+            };
+        };
+    };

doc/usage/fit/multi-with-fpga.rst

@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Multiple kernels, ramdisks and FDT blobs with FPGA
+==================================================
+
+This example makes use of the 'loadables' field::
+
+    /dts-v1/;
+
+    / {
+        description = "Configuration to load fpga before Kernel";
+        #address-cells = <1>;
+
+        images {
+            fdt-1 {
+                description = "zc706";
+                data = /incbin/("/tftpboot/devicetree.dtb");
+                type = "flat_dt";
+                arch = "arm";
+                compression = "none";
+                load = <0x10000000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+
+            fpga {
+                description = "FPGA";
+                data = /incbin/("/tftpboot/download.bit");
+                type = "fpga";
+                arch = "arm";
+                compression = "none";
+                load = <0x30000000>;
+                compatible = "u-boot,fpga-legacy"
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+
+            linux_kernel {
+                description = "Linux";
+                data = /incbin/("/tftpboot/zImage");
+                type = "kernel";
+                arch = "arm";
+                os = "linux";
+                compression = "none";
+                load = <0x8000>;
+                entry = <0x8000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+        };
+
+        configurations {
+            default = "config-2";
+            config-1 {
+                description = "Linux";
+                kernel = "linux_kernel";
+                fdt = "fdt-1";
+            };
+
+            config-2 {
+                description = "Linux with fpga";
+                kernel = "linux_kernel";
+                fdt = "fdt-1";
+                loadables = "fpga";
+            };
+        };
+    };

doc/usage/fit/multi-with-loadables.rst

@@ -0,0 +1,91 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Multiple kernels, ramdisks and FDT blobs with Xen
+=================================================
+
+This example makes use of the 'loadables' field::
+
+    /dts-v1/;
+
+    / {
+        description = "Configuration to load a Xen Kernel";
+        #address-cells = <1>;
+
+        images {
+            xen_kernel {
+                description = "xen binary";
+                data = /incbin/("./xen");
+                type = "kernel";
+                arch = "arm";
+                os = "linux";
+                compression = "none";
+                load = <0xa0000000>;
+                entry = <0xa0000000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+
+            fdt-1 {
+                description = "xexpress-ca15 tree blob";
+                data = /incbin/("./vexpress-v2p-ca15-tc1.dtb");
+                type = "flat_dt";
+                arch = "arm";
+                compression = "none";
+                load = <0xb0000000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+
+            fdt-2 {
+                description = "xexpress-ca15 tree blob";
+                data = /incbin/("./vexpress-v2p-ca15-tc1.dtb");
+                type = "flat_dt";
+                arch = "arm";
+                compression = "none";
+                load = <0xb0400000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+
+            linux_kernel {
+                description = "Linux Image";
+                data = /incbin/("./Image");
+                type = "kernel";
+                arch = "arm";
+                os = "linux";
+                compression = "none";
+                load = <0xa0000000>;
+                entry = <0xa0000000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+        };
+
+        configurations {
+            default = "config-2";
+
+            config-1 {
+                description = "Just plain Linux";
+                kernel = "linux_kernel";
+                fdt = "fdt-1";
+            };
+
+            config-2 {
+                description = "Xen one loadable";
+                kernel = "xen_kernel";
+                fdt = "fdt-1";
+                loadables = "linux_kernel";
+            };
+
+            config-3 {
+                description = "Xen two loadables";
+                kernel = "xen_kernel";
+                fdt = "fdt-1";
+                loadables = "linux_kernel", "fdt-2";
+            };
+        };
+    };

doc/usage/fit/multi.rst

@@ -0,0 +1,136 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Multiple kernels, ramdisks and FDT blobs
+========================================
+
+::
+
+    /dts-v1/;
+
+    / {
+        description = "Various kernels, ramdisks and FDT blobs";
+        #address-cells = <1>;
+
+        images {
+            kernel-1 {
+                description = "vanilla-2.6.23";
+                data = /incbin/("./vmlinux.bin.gz");
+                type = "kernel";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "md5";
+                };
+                hash-2 {
+                    algo = "sha1";
+                };
+            };
+
+            kernel-2 {
+                description = "2.6.23-denx";
+                data = /incbin/("./2.6.23-denx.bin.gz");
+                type = "kernel";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "sha1";
+                };
+            };
+
+            kernel-3 {
+                description = "2.4.25-denx";
+                data = /incbin/("./2.4.25-denx.bin.gz");
+                type = "kernel";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "md5";
+                };
+            };
+
+            ramdisk-1 {
+                description = "eldk-4.2-ramdisk";
+                data = /incbin/("./eldk-4.2-ramdisk");
+                type = "ramdisk";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "sha1";
+                };
+            };
+
+            ramdisk-2 {
+                description = "eldk-3.1-ramdisk";
+                data = /incbin/("./eldk-3.1-ramdisk");
+                type = "ramdisk";
+                arch = "ppc";
+                os = "linux";
+                compression = "gzip";
+                load = <00000000>;
+                entry = <00000000>;
+                hash-1 {
+                    algo = "crc32";
+                };
+            };
+
+            fdt-1 {
+                description = "tqm5200-fdt";
+                data = /incbin/("./tqm5200.dtb");
+                type = "flat_dt";
+                arch = "ppc";
+                compression = "none";
+                hash-1 {
+                    algo = "crc32";
+                };
+            };
+
+            fdt-2 {
+                description = "tqm5200s-fdt";
+                data = /incbin/("./tqm5200s.dtb");
+                type = "flat_dt";
+                arch = "ppc";
+                compression = "none";
+                load = <00700000>;
+                hash-1 {
+                    algo = "sha1";
+                };
+            };
+
+        };
+
+        configurations {
+            default = "config-1";
+
+            config-1 {
+                description = "tqm5200 vanilla-2.6.23 configuration";
+                kernel = "kernel-1";
+                ramdisk = "ramdisk-1";
+                fdt = "fdt-1";
+            };
+
+            config-2 {
+                description = "tqm5200s denx-2.6.23 configuration";
+                kernel = "kernel-2";
+                ramdisk = "ramdisk-1";
+                fdt = "fdt-2";
+            };
+
+            config-3 {
+                description = "tqm5200s denx-2.4.25 configuration";
+                kernel = "kernel-3";
+                ramdisk = "ramdisk-2";
+            };
+        };
+    };

doc/usage/fit/multi_spl.rst

@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Multiple images for SPL
+=======================
+
+(Bogus) example FIT image description file demonstrating the usage
+of multiple images loaded by the SPL.
+Several binaries will be loaded at their respective load addresses.
+
+For booting U-Boot, "firmware" is searched first. If not found, "loadables"
+is used to identify images to be loaded into memory. If falcon boot is
+enabled, "kernel" is searched first. If not found, it falls back to the
+same flow as booting U-Boot. Changing image type will result skipping
+specific image.
+
+Finally the one image specifying an entry point will be entered by the SPL.
+
+::
+
+    /dts-v1/;
+
+    / {
+        description = "multiple firmware blobs and U-Boot, loaded by SPL";
+        #address-cells = <0x1>;
+
+        images {
+
+            uboot {
+                description = "U-Boot (64-bit)";
+                type = "standalone";
+                arch = "arm64";
+                compression = "none";
+                load = <0x4a000000>;
+            };
+
+            atf {
+                description = "ARM Trusted Firmware";
+                type = "firmware";
+                arch = "arm64";
+                compression = "none";
+                load = <0x18000>;
+                entry = <0x18000>;
+            };
+
+            mgmt-firmware {
+                description = "arisc management processor firmware";
+                type = "firmware";
+                arch = "or1k";
+                compression = "none";
+                load = <0x40000>;
+            };
+
+            fdt-1 {
+                description = "Pine64+ DT";
+                type = "flat_dt";
+                compression = "none";
+                load = <0x4fa00000>;
+                arch = "arm64";
+            };
+
+            fdt-2 {
+                description = "Pine64 DT";
+                type = "flat_dt";
+                compression = "none";
+                load = <0x4fa00000>;
+                arch = "arm64";
+            };
+
+            kernel {
+                description = "4.7-rc5 kernel";
+                type = "kernel";
+                compression = "none";
+                load = <0x40080000>;
+                arch = "arm64";
+            };
+
+            initrd {
+                description = "Debian installer initrd";
+                type = "ramdisk";
+                compression = "none";
+                load = <0x4fe00000>;
+                arch = "arm64";
+            };
+        };
+
+        configurations {
+            default = "config-1";
+
+            config-1 {
+                description = "sun50i-a64-pine64-plus";
+                loadables = "uboot", "atf", "kernel", "initrd";
+                fdt = "fdt-1";
+            };
+
+            config-2 {
+                description = "sun50i-a64-pine64";
+                loadables = "uboot", "atf", "mgmt-firmware";
+                fdt = "fdt-2";
+            };
+        };
+    };

doc/usage/fit/overlay-fdt-boot.rst

@@ -0,0 +1,227 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot FDT Overlay FIT usage
+============================
+
+Introduction
+------------
+
+In many cases it is desirable to have a single FIT image support a multitude
+of similar boards and their expansion options. The same kernel on DT enabled
+platforms can support this easily enough by providing a DT blob upon boot
+that matches the desired configuration.
+
+This document focuses on specifically using overlays as part of a FIT image.
+General information regarding overlays including its syntax and building it
+can be found in doc/README.fdt-overlays
+
+Configuration without overlays
+------------------------------
+
+Take a hypothetical board named 'foo' where there are different supported
+revisions, reva and revb. Assume that both board revisions can use add a bar
+add-on board, while only the revb board can use a baz add-on board.
+
+Without using overlays the configuration would be as follows for every case::
+
+	/dts-v1/;
+	/ {
+	    images {
+	    kernel {
+		data = /incbin/("./zImage");
+		type = "kernel";
+		arch = "arm";
+		os = "linux";
+		load = <0x82000000>;
+		entry = <0x82000000>;
+	    };
+	    fdt-1 {
+		data = /incbin/("./foo-reva.dtb");
+		type = "flat_dt";
+		arch = "arm";
+	    };
+	    fdt-2 {
+		data = /incbin/("./foo-revb.dtb");
+		type = "flat_dt";
+		arch = "arm";
+	    };
+	    fdt-3 {
+		data = /incbin/("./foo-reva-bar.dtb");
+		type = "flat_dt";
+		arch = "arm";
+	    };
+	    fdt-4 {
+		data = /incbin/("./foo-revb-bar.dtb");
+		type = "flat_dt";
+		arch = "arm";
+	    };
+	    fdt-5 {
+		data = /incbin/("./foo-revb-baz.dtb");
+		type = "flat_dt";
+		arch = "arm";
+	    };
+	    fdt-6 {
+		data = /incbin/("./foo-revb-bar-baz.dtb");
+		type = "flat_dt";
+		arch = "arm";
+	    };
+	    };
+
+	    configurations {
+	    default = "foo-reva.dtb;
+	    foo-reva.dtb {
+		kernel = "kernel";
+		fdt = "fdt-1";
+	    };
+	    foo-revb.dtb {
+		kernel = "kernel";
+		fdt = "fdt-2";
+	    };
+	    foo-reva-bar.dtb {
+		kernel = "kernel";
+		fdt = "fdt-3";
+	    };
+	    foo-revb-bar.dtb {
+		kernel = "kernel";
+		fdt = "fdt-4";
+	    };
+	    foo-revb-baz.dtb {
+		kernel = "kernel";
+		fdt = "fdt-5";
+	    };
+	    foo-revb-bar-baz.dtb {
+		kernel = "kernel";
+		fdt = "fdt-6";
+	    };
+	    };
+	};
+
+Note the blob needs to be compiled for each case and the combinatorial explosion of
+configurations. A typical device tree blob is in the low hunderds of kbytes so a
+multitude of configuration grows the image quite a bit.
+
+Booting this image is done by using::
+
+    # bootm <addr>#<config>
+
+Where config is one of::
+
+    foo-reva.dtb, foo-revb.dtb, foo-reva-bar.dtb, foo-revb-bar.dtb,
+    foo-revb-baz.dtb, foo-revb-bar-baz.dtb
+
+This selects the DTB to use when booting.
+
+Configuration using overlays
+----------------------------
+
+Device tree overlays can be applied to a base DT and result in the same blob
+being passed to the booting kernel. This saves on space and avoid the combinatorial
+explosion problem::
+
+    /dts-v1/;
+    / {
+        images {
+            kernel {
+                data = /incbin/("./zImage");
+                type = "kernel";
+                arch = "arm";
+                os = "linux";
+                load = <0x82000000>;
+                entry = <0x82000000>;
+            };
+            fdt-1 {
+                data = /incbin/("./foo.dtb");
+                type = "flat_dt";
+                arch = "arm";
+                load = <0x87f00000>;
+            };
+            fdt-2 {
+                data = /incbin/("./reva.dtbo");
+                type = "flat_dt";
+                arch = "arm";
+                load = <0x87fc0000>;
+            };
+            fdt-3 {
+                data = /incbin/("./revb.dtbo");
+                type = "flat_dt";
+                arch = "arm";
+                load = <0x87fc0000>;
+            };
+            fdt-4 {
+                data = /incbin/("./bar.dtbo");
+                type = "flat_dt";
+                arch = "arm";
+                load = <0x87fc0000>;
+            };
+            fdt-5 {
+                data = /incbin/("./baz.dtbo");
+                type = "flat_dt";
+                arch = "arm";
+                load = <0x87fc0000>;
+            };
+        };
+
+        configurations {
+            default = "foo-reva.dtb;
+            foo-reva.dtb {
+                kernel = "kernel";
+                fdt = "fdt-1", "fdt-2";
+            };
+            foo-revb.dtb {
+                kernel = "kernel";
+                fdt = "fdt-1", "fdt-3";
+            };
+            foo-reva-bar.dtb {
+                kernel = "kernel";
+                fdt = "fdt-1", "fdt-2", "fdt-4";
+            };
+            foo-revb-bar.dtb {
+                kernel = "kernel";
+                fdt = "fdt-1", "fdt-3", "fdt-4";
+            };
+            foo-revb-baz.dtb {
+                kernel = "kernel";
+                fdt = "fdt-1", "fdt-3", "fdt-5";
+            };
+            foo-revb-bar-baz.dtb {
+                kernel = "kernel";
+                fdt = "fdt-1", "fdt-3", "fdt-4", "fdt-5";
+            };
+            bar {
+                fdt = "fdt-4";
+            };
+            baz {
+                fdt = "fdt-5";
+            };
+        };
+    };
+
+Booting this image is exactly the same as the non-overlay example.
+u-boot will retrieve the base blob and apply the overlays in sequence as
+they are declared in the configuration.
+
+Note the minimum amount of different DT blobs, as well as the requirement for
+the DT blobs to have a load address; the overlay application requires the blobs
+to be writeable.
+
+Configuration using overlays and feature selection
+--------------------------------------------------
+
+Although the configuration in the previous section works is a bit inflexible
+since it requires all possible configuration options to be laid out before
+hand in the FIT image. For the add-on boards the extra config selection method
+might make sense.
+
+Note the two bar & baz configuration nodes. To boot a reva board with
+the bar add-on board enabled simply use::
+
+    => bootm <addr>#foo-reva.dtb#bar
+
+While booting a revb with bar and baz is as follows::
+
+    => bootm <addr>#foo-revb.dtb#bar#baz
+
+The limitation for a feature selection configuration node is that a single
+fdt option is currently supported.
+
+.. sectionauthor:: Pantelis Antoniou <pantelis.antoniou@konsulko.com>, 12/6/2017

doc/usage/fit/sec_firmware_ppa.rst

@@ -0,0 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+SEC Firmware and multiple loadable images
+=========================================
+
+Example FIT image description file demonstrating the usage
+of SEC Firmware and multiple loadable images loaded by U-Boot.
+For booting PPA (SEC Firmware), "firmware" is searched and loaded.
+
+Multiple binaries will be loaded as "loadables" (if present) at their
+respective load offsets from firmware image address.
+
+::
+
+    /dts-v1/;
+
+    /{
+        description = "PPA Firmware";
+        #address-cells = <1>;
+        images {
+            firmware@1 {
+                description = "PPA Firmware: <version>";
+                data = /incbin/("../obj/monitor.bin");
+                type = "firmware";
+                arch = "arm64";
+                compression = "none";
+            };
+            trustedOS@1 {
+                description = "Trusted OS";
+                data = /incbin/("../../tee.bin");
+                type = "OS";
+                arch = "arm64";
+                compression = "none";
+                load = <0x00200000>;
+            };
+            fuse_scr {
+                description = "Fuse Script";
+                data = /incbin/("../../fuse_scr.bin");
+                type = "firmware";
+                arch = "arm64";
+                compression = "none";
+                load = <0x00180000>;
+            };
+        };
+
+        configurations {
+            default = "config-1";
+            config-1 {
+                description = "PPA Secure firmware";
+                firmware = "firmware@1";
+                loadables = "trustedOS@1", "fuse_scr";
+            };
+        };
+    };