[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Andreas Dannenberg]

TI K3 SoCs like the AM654x devices are fundamentally dependent on a
firmware called SYSFW (System Firmware) being loaded into the dedicated
DMSC (Device Management and Security Controller) processor to provide
various services via TISCI (Texas Instruments System Control Interface)
to manage device aspects such as core bringup, power, clocks, security,
and so on across the entire SoC.

Currently public U-Boot does not boot on an actual AM654x EVM due to
the missing loading and startup of SYSFW, with this being the only piece
missing preventing a successful boot from SD/MMC-type media. This gap
is addressed with this patch series.

Note that the loading and starting of SYSFW is done in the context of
board_init_f() in SPL which poses some unique challenges due to the very
constrained nature of this environment (minimal amount of SRAM, no DDR
yet available).

In order to be as lean as possible on resource use an approach was chosen
that extends the existing SPL loader framework to be usable beyond the
usual "loading U-Boot" use case. While this patch series only makes
changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS-
and sector/partition-based RAW boot at this time we have this solution
in production today but extended to SPI/OSPI and Y-Modem without any
issues.

While I also have a working solution based on the existing FS loader
framework this has its own challenges, namely by its very nature only
addressing a subset of our use cases (no eMMC/SD RAW boot support for
example), being heavier on resource usage (needing to use ENV to pass
parameters), and not addressing the need to probe the boot peripheral.
This particular framework works well for use cases requiring to load
firmware from FS-based media once DDR is up and U-Boot is in a more
"initialized" state but it is not a one-fits all solution for very
early use in SPL board_init_f() accross different boot modes.


Andreas Dannenberg (10):
  mmc: k3_arasan: Allow driver to probe without PDs specified
  spl: Allow skipping clearing BSS during relocation
  spl: Make image loader infrastructure more universal
  arm: K3: Introduce System Firmware loader framework
  armV7R: K3: am654: Allow using SPL BSS pre-relocation
  armv7R: K3: am654: Use full malloc implementation in SPL
  armV7R: K3: am654: Load SYSFW binary and config from boot media
  configs: am65x_evm_r5: All sysfw to be loaded via MMC
  configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
  configs: am65x_hs_evm: Add Support for eMMC boot

Faiz Abbas (2):
  configs: am65x_evm: Add Support for eMMC boot
  am65x: README: Add eMMC layout and flash instructions

Lokesh Vutla (1):
  armv7R: dts: k3: am654: Update mmc nodes for loading sysfw

 arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
 arch/arm/lib/crt0.S                          |   3 +
 arch/arm/mach-k3/Kconfig                     |  40 +++
 arch/arm/mach-k3/Makefile                    |   1 +
 arch/arm/mach-k3/am6_init.c                  |  34 ++-
 arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
 arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
 board/ti/am65x/Kconfig                       |   1 +
 board/ti/am65x/README                        |  52 ++++
 common/spl/Kconfig                           |  13 +
 common/spl/spl_fit.c                         |  14 +
 common/spl/spl_mmc.c                         |  76 ++++--
 configs/am65x_evm_a53_defconfig              |   2 +
 configs/am65x_evm_r5_defconfig               |   7 +-
 configs/am65x_hs_evm_a53_defconfig           |   2 +
 configs/am65x_hs_evm_r5_defconfig            |   7 +-
 drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
 include/configs/am65x_evm.h                  |  30 ++-
 include/spl.h                                |  26 ++
 19 files changed, 577 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
 create mode 100644 arch/arm/mach-k3/sysfw-loader.c

-- 
2.17.1

[U-Boot] [PATCH 01/13] mmc: k3_arasan: Allow driver to probe without PDs specified

[Andreas Dannenberg]

We would like to use the driver even without power domains being
specified for cases such as during early boot when the required power
domains have already gotten enabled by the SoC's boot ROM and such
explicit initialization is not needed and possible.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 drivers/mmc/k3_arsan_sdhci.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/k3_arsan_sdhci.c b/drivers/mmc/k3_arsan_sdhci.c
index d5f2857382..785ba135c7 100644
--- a/drivers/mmc/k3_arsan_sdhci.c
+++ b/drivers/mmc/k3_arsan_sdhci.c
@@ -31,14 +31,14 @@ static int k3_arasan_sdhci_probe(struct udevice *dev)
 	int ret;
 
 	ret = power_domain_get_by_index(dev, &sdhci_pwrdmn, 0);
-	if (ret) {
-		dev_err(dev, "failed to get power domain\n");
-		return ret;
-	}
-
-	ret = power_domain_on(&sdhci_pwrdmn);
-	if (ret) {
-		dev_err(dev, "Power domain on failed\n");
+	if (!ret) {
+		ret = power_domain_on(&sdhci_pwrdmn);
+		if (ret) {
+			dev_err(dev, "Power domain on failed\n");
+			return ret;
+		}
+	} else if (ret != -ENOENT && ret != -ENODEV && ret != -ENOSYS) {
+		dev_err(dev, "power_domain_get() failed: %d\n", ret);
 		return ret;
 	}
 
-- 
2.17.1

[U-Boot] [PATCH 02/13] spl: Allow skipping clearing BSS during relocation

[Andreas Dannenberg]

On some platform we have sufficient memory available early on to allow
setting up and using a basic BSS prior to relocation. In order to be
able to preserve data written to BSS during early startup add a Kconfig
option allowing to skip the clearing of the BSS section during setting
up of the final environment / relocation.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 arch/arm/lib/crt0.S |  3 +++
 common/spl/Kconfig  | 13 +++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index fe312db690..17645469fc 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -124,6 +124,8 @@ here:
 	movne	sp, r0
 	movne	r9, r0
 # endif
+
+#if !CONFIG_IS_ENABLED(SKIP_CLEAR_BSS)
 	ldr	r0, =__bss_start	/* this is auto-relocated! */
 
 #ifdef CONFIG_USE_ARCH_MEMSET
@@ -141,6 +143,7 @@ clbss_l:cmp	r0, r1			/* while not at end of BSS */
 	addlo	r0, r0, #4		/* move to next */
 	blo	clbss_l
 #endif
+#endif
 
 #if ! defined(CONFIG_SPL_BUILD)
 	bl coloured_LED_init
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index dd078fe79d..f9eb1a0e31 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -188,6 +188,19 @@ config TPL_BANNER_PRINT
 	  info. Disabling this option could be useful to reduce SPL boot time
 	  (e.g. approx. 6 ms faster, when output on i.MX6 with 115200 baud).
 
+
+config SPL_SKIP_CLEAR_BSS
+	depends on ARM && !ARM64
+	bool "Skips clearing BSS section during environment setup / relocation"
+	help
+	  On some platform we have sufficient memory available early on to
+	  allow setting up and using a basic BSS prior to relocation. In order
+	  to preserve data written to BSS during early startup use use this
+	  option to skip the clearing of the BSS section. Note that activating
+	  this option implies that you are responsible for clearing the BSS
+	  section yourself, otherwise you will most likely end up with an
+	  invalid post-relocation environment.
+
 config SPL_DISPLAY_PRINT
 	bool "Display a board-specific message in SPL"
 	help
-- 
2.17.1

[U-Boot] [PATCH 03/13] spl: Make image loader infrastructure more universal

[Andreas Dannenberg]

The current U-Boot SPL image loader infrastructure is very powerful,
able to initialize and load from a variety of boot media however it
is strongly geared towards loading specific types of images in a very
specific way. To address the need being able to use this infrastructure
to load arbitrary image files go ahead and refactor it as follows:

- Refactor existing spl_mmc_load_image function into superset function,
  accepting additional arguments such as filenames and media load offset
  (same concept can also be applied toother spl_XXX_load_image functions)
- Extend the loader function to "remember" their peripheral initialization
  status so that the init is only done once during the boot process,
- Extend the FIT image loading function to allow skipping the parsing/
  processing of the FIT contents (so that this can be done separately
  in a more customized fashion)
- Populate the SPL_LOAD_IMAGE_METHOD() list with a trampoline function,
  invoking the newly refactored superset functions in a way to maintain
  compatibility with the existing behavior

This refactoring initially covers MMC/SD card loading (RAW and FS-based).

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 common/spl/spl_fit.c | 14 ++++++++
 common/spl/spl_mmc.c | 76 +++++++++++++++++++++++++++++---------------
 include/spl.h        | 26 +++++++++++++++
 3 files changed, 91 insertions(+), 25 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 87ecf0bb9e..969f7775c1 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -340,6 +340,16 @@ static int spl_fit_image_get_os(const void *fit, int noffset, uint8_t *os)
 #endif
 }
 
+/*
+ * Weak default function to allow customizing SPL fit loading for load-only
+ * use cases by allowing to skip the parsing/processing of the FIT contents
+ * (so that this can be done separately in a more customized fashion)
+ */
+__weak bool spl_load_simple_fit_skip_processing(void)
+{
+	return false;
+}
+
 int spl_load_simple_fit(struct spl_image_info *spl_image,
 			struct spl_load_info *info, ulong sector, void *fit)
 {
@@ -389,6 +399,10 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	if (count == 0)
 		return -EIO;
 
+	/* skip further processing if requested to enable load-only use cases */
+	if (spl_load_simple_fit_skip_processing())
+		return 0;
+
 	/* find the node holding the images information */
 	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
 	if (images < 0) {
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 324d91c884..b3619889f7 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -151,7 +151,8 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
 
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
-					struct mmc *mmc, int partition)
+					struct mmc *mmc, int partition,
+					unsigned long sector)
 {
 	disk_partition_t info;
 	int err;
@@ -180,8 +181,7 @@ static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
 	}
 
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
-	return mmc_load_image_raw_sector(spl_image, mmc,
-			info.start + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+	return mmc_load_image_raw_sector(spl_image, mmc, info.start + sector);
 #else
 	return mmc_load_image_raw_sector(spl_image, mmc, info.start);
 #endif
@@ -234,7 +234,8 @@ static int mmc_load_image_raw_os(struct spl_image_info *spl_image,
 #endif
 
 #ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
-static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc)
+static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc,
+			      const char *filename)
 {
 	int err = -ENOSYS;
 
@@ -248,7 +249,7 @@ static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc)
 #ifdef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
 	err = spl_load_image_fat(spl_image, mmc_get_blk_desc(mmc),
 				 CONFIG_SYS_MMCSD_FS_BOOT_PARTITION,
-				 CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+				 filename);
 	if (!err)
 		return err;
 #endif
@@ -263,7 +264,7 @@ static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc)
 #ifdef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
 	err = spl_load_image_ext(spl_image, mmc_get_blk_desc(mmc),
 				 CONFIG_SYS_MMCSD_FS_BOOT_PARTITION,
-				 CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+				 filename);
 	if (!err)
 		return err;
 #endif
@@ -276,7 +277,8 @@ static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc)
 	return err;
 }
 #else
-static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc)
+static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc,
+			      const char *filename)
 {
 	return -ENOSYS;
 }
@@ -301,24 +303,31 @@ int spl_boot_partition(const u32 boot_device)
 }
 #endif
 
-int spl_mmc_load_image(struct spl_image_info *spl_image,
-		       struct spl_boot_device *bootdev)
+int spl_mmc_load(struct spl_image_info *spl_image,
+		 struct spl_boot_device *bootdev,
+		 const char *filename,
+		 int raw_part,
+		 unsigned long raw_sect)
 {
-	struct mmc *mmc = NULL;
+	static struct mmc *mmc;
 	u32 boot_mode;
 	int err = 0;
 	__maybe_unused int part;
 
-	err = spl_mmc_find_device(&mmc, bootdev->boot_device);
-	if (err)
-		return err;
+	/* Perform peripheral init only once */
+	if (!mmc) {
+		err = spl_mmc_find_device(&mmc, bootdev->boot_device);
+		if (err)
+			return err;
 
-	err = mmc_init(mmc);
-	if (err) {
+		err = mmc_init(mmc);
+		if (err) {
+			mmc = NULL;
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-		printf("spl: mmc init failed with error: %d\n", err);
+			printf("spl: mmc init failed with error: %d\n", err);
 #endif
-		return err;
+			return err;
+		}
 	}
 
 	boot_mode = spl_boot_mode(bootdev->boot_device);
@@ -356,17 +365,13 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
 				return err;
 		}
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
-		err = spl_boot_partition(bootdev->boot_device);
-		if (!err)
-			return err;
-
-		err = mmc_load_image_raw_partition(spl_image, mmc, err);
+		err = mmc_load_image_raw_partition(spl_image, mmc, raw_part,
+						   raw_sect);
 		if (!err)
 			return err;
 #endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
-		err = mmc_load_image_raw_sector(spl_image, mmc,
-			CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+		err = mmc_load_image_raw_sector(spl_image, mmc, raw_sect);
 		if (!err)
 			return err;
 #endif
@@ -374,7 +379,7 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
 	case MMCSD_MODE_FS:
 		debug("spl: mmc boot mode: fs\n");
 
-		err = spl_mmc_do_fs_boot(spl_image, mmc);
+		err = spl_mmc_do_fs_boot(spl_image, mmc, filename);
 		if (!err)
 			return err;
 
@@ -388,6 +393,27 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
 	return err;
 }
 
+int spl_mmc_load_image(struct spl_image_info *spl_image,
+		       struct spl_boot_device *bootdev)
+{
+	return spl_mmc_load(spl_image, bootdev,
+#ifdef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
+			    CONFIG_SPL_FS_LOAD_PAYLOAD_NAME,
+#else
+			    NULL,
+#endif
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
+			    spl_boot_partition(bootdev->boot_device),
+#else
+			    0,
+#endif
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
+			    CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+#else
+			    0);
+#endif
+}
+
 SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
 SPL_LOAD_IMAGE_METHOD("MMC2", 0, BOOT_DEVICE_MMC2, spl_mmc_load_image);
 SPL_LOAD_IMAGE_METHOD("MMC2_2", 0, BOOT_DEVICE_MMC2_2, spl_mmc_load_image);
diff --git a/include/spl.h b/include/spl.h
index f09909e189..94ca5d5c6a 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -108,6 +108,15 @@ struct spl_load_info {
  */
 binman_sym_extern(ulong, u_boot_any, image_pos);
 
+/**
+ * spl_load_simple_fit_skip_processing() - Hook to allow skipping the FIT
+ *	image processing during spl_load_simple_fit().
+ *
+ * Return true to skip FIT processing, false to preserve the full code flow
+ * of spl_load_simple_fit().
+ */
+bool spl_load_simple_fit_skip_processing(void);
+
 /**
  * spl_load_simple_fit() - Loads a fit image from a device.
  * @spl_image:	Image description to set up
@@ -330,6 +339,23 @@ int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, char *devstr);
 int spl_mmc_load_image(struct spl_image_info *spl_image,
 		       struct spl_boot_device *bootdev);
 
+/**
+ * spl_mmc_load() - Load an image file from MMC/SD media
+ *
+ * @param spl_image	Image data filled in by loading process
+ * @param bootdev	Describes which device to load from
+ * @param filename	Name of file to load (in FS mode)
+ * @param raw_part	Partition to load from (in RAW mode)
+ * @param raw_sect	Sector to load from (in RAW mode)
+ *
+ * @return 0 on success, otherwise error code
+ */
+int spl_mmc_load(struct spl_image_info *spl_image,
+		 struct spl_boot_device *bootdev,
+		 const char *filename,
+		 int raw_part,
+		 unsigned long raw_sect);
+
 /**
  * spl_invoke_atf - boot using an ARM trusted firmware image
  */
-- 
2.17.1

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Andreas Dannenberg]

Introduce a framework that allows loading the System Firmware (SYSFW)
binary as well as the associated configuration data from an image tree
blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
RAW mode partition or sector.

To simplify the handling of and loading from the different boot media
we tap into the existing U-Boot SPL framework usually used for loading
U-Boot by building on an earlier commit that exposes some of that
functionality.

Note that this initial implementation only supports FS and RAW-based
eMMC/SD card boot.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
 arch/arm/mach-k3/Kconfig                     |  40 +++
 arch/arm/mach-k3/Makefile                    |   1 +
 arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
 arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
 4 files changed, 316 insertions(+)
 create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
 create mode 100644 arch/arm/mach-k3/sysfw-loader.c

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index e677a2e01b..f1731dda58 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
 	int
 	default 16
 
+config K3_LOAD_SYSFW
+	bool
+	depends on SPL
+	default n
+
+config K3_SYSFW_IMAGE_NAME
+	string "File name of SYSFW firmware and configuration blob"
+	depends on K3_LOAD_SYSFW
+	default	"sysfw.itb"
+	help
+	  Filename of the combined System Firmware and configuration image tree
+	  blob to be loaded when booting from a filesystem.
+
+config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
+	hex "MMC sector to load SYSFW firmware and configuration blob from"
+	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+	default 0x3600
+	help
+	  Address on the MMC to load the combined System Firmware and
+	  configuration image tree blob from, when the MMC is being used
+	  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
+
+config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
+	hex "MMC partition to load SYSFW firmware and configuration blob from"
+	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+	default 2
+	help
+	  Partition on the MMC to the combined System Firmware and configuration
+	  image tree blob from, when the MMC is being used in raw mode.
+
+config K3_SYSFW_IMAGE_SIZE_MAX
+	int "Amount of memory dynamically allocated for loading SYSFW blob"
+	depends on K3_LOAD_SYSFW
+	default	269000
+	help
+	  Amount of memory reserved through dynamic allocation at runtime for
+	  loading the combined System Firmware and configuration image tree
+	  blob. Keep it as tight as possible, as this directly affects the
+	  overall SPL memory footprint.
+
 config SYS_K3_SPL_ATF
 	bool "Start Cortex-A from SPL"
 	depends on SPL && CPU_V7R
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 0c3a4f7db1..6c895400c2 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
 obj-$(CONFIG_ARM64) += arm64-mmu.o
 obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
 obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
+obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
 obj-y += common.o
diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h b/arch/arm/mach-k3/include/mach/sysfw-loader.h
new file mode 100644
index 0000000000..36eb265348
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ *	Andreas Dannenberg <dannenberg@ti.com>
+ */
+
+#ifndef _SYSFW_LOADER_H_
+#define _SYSFW_LOADER_H_
+
+void k3_sysfw_loader(void (*config_pm_done_callback)(void));
+
+#endif
diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
new file mode 100644
index 0000000000..a222266c27
--- /dev/null
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: System Firmware Loader
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ *	Andreas Dannenberg <dannenberg@ti.com>
+ */
+
+#include <common.h>
+#include <spl.h>
+#include <malloc.h>
+#include <remoteproc.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+#include <asm/arch/sys_proto.h>
+
+/* Name of the FIT image nodes for SYSFW and its config data */
+#define SYSFW_FIRMWARE			"sysfw.bin"
+#define SYSFW_CFG_BOARD			"board-cfg.bin"
+#define SYSFW_CFG_PM			"pm-cfg.bin"
+#define SYSFW_CFG_RM			"rm-cfg.bin"
+#define SYSFW_CFG_SEC			"sec-cfg.bin"
+
+#ifdef CONFIG_SPL_BUILD
+
+static bool sysfw_loaded;
+static void *sysfw_load_address;
+
+/*
+ * Populate SPL hook to override the default load address used by the SPL
+ * loader function with a custom address for SYSFW loading.
+ */
+struct image_header *spl_get_load_buffer(ssize_t offset, size_t size)
+{
+	if (sysfw_loaded)
+		return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset);
+	else if (sysfw_load_address)
+		return sysfw_load_address;
+	else
+		panic("SYSFW load address not defined!");
+}
+
+/*
+ * Populate SPL hook to skip the default SPL loader FIT post-processing steps
+ * during SYSFW loading and return to the calling function so we can perform
+ * our own custom processing.
+ */
+bool spl_load_simple_fit_skip_processing(void)
+{
+	return !sysfw_loaded;
+}
+
+static int fit_get_data_by_name(const void *fit, int images, const char *name,
+				const void **addr, size_t *size)
+{
+	int node_offset;
+
+	node_offset = fdt_subnode_offset(fit, images, name);
+	if (node_offset < 0)
+		return -ENOENT;
+
+	return fit_image_get_data(fit, node_offset, addr, size);
+}
+
+static void k3_sysfw_load_using_fit(void *fit)
+{
+	int images;
+	const void *sysfw_addr;
+	size_t sysfw_size;
+	int ret;
+
+	/* Find the node holding the images information */
+	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
+	if (images < 0)
+		panic("Cannot find /images node (%d)\n", images);
+
+	/* Extract System Firmware (SYSFW) image from FIT */
+	ret = fit_get_data_by_name(fit, images, SYSFW_FIRMWARE,
+				   &sysfw_addr, &sysfw_size);
+	if (ret < 0)
+		panic("Error accessing %s node in FIT (%d)\n", SYSFW_FIRMWARE,
+		      ret);
+
+	/*
+	 * Start up system controller firmware
+	 *
+	 * It is assumed that remoteproc device 0 is the corresponding
+	 * system-controller that runs SYSFW. Make sure DT reflects the same.
+	 */
+	ret = rproc_dev_init(0);
+	if (ret)
+		panic("rproc failed to be initialized (%d)\n", ret);
+
+	ret = rproc_load(0, (ulong)sysfw_addr, (ulong)sysfw_size);
+	if (ret)
+		panic("Firmware failed to start on rproc (%d)\n", ret);
+
+	ret = rproc_start(0);
+	if (ret)
+		panic("Firmware init failed on rproc (%d)\n", ret);
+}
+
+static void k3_sysfw_configure_using_fit(void *fit,
+					 struct ti_sci_handle *ti_sci)
+{
+	struct ti_sci_board_ops *board_ops = &ti_sci->ops.board_ops;
+	int images;
+	const void *cfg_fragment_addr;
+	size_t cfg_fragment_size;
+	int ret;
+
+	/* Find the node holding the images information */
+	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
+	if (images < 0)
+		panic("Cannot find /images node (%d)\n", images);
+
+	/* Extract board configuration from FIT */
+	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_BOARD,
+				   &cfg_fragment_addr, &cfg_fragment_size);
+	if (ret < 0)
+		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_BOARD,
+		      ret);
+
+	/* Apply board configuration to SYSFW */
+	ret = board_ops->board_config(ti_sci,
+				      (u64)(u32)cfg_fragment_addr,
+				      (u32)cfg_fragment_size);
+	if (ret)
+		panic("Failed to set board configuration (%d)\n", ret);
+
+	/* Extract power/clock (PM) specific configuration from FIT */
+	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_PM,
+				   &cfg_fragment_addr, &cfg_fragment_size);
+	if (ret < 0)
+		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_PM,
+		      ret);
+
+	/* Apply power/clock (PM) specific configuration to SYSFW */
+	ret = board_ops->board_config_pm(ti_sci,
+					 (u64)(u32)cfg_fragment_addr,
+					 (u32)cfg_fragment_size);
+	if (ret)
+		panic("Failed to set board PM configuration (%d)\n", ret);
+
+	/* Extract resource management (RM) specific configuration from FIT */
+	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
+				   &cfg_fragment_addr, &cfg_fragment_size);
+	if (ret < 0)
+		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_RM,
+		      ret);
+
+	/* Apply resource management (RM) configuration to SYSFW */
+	ret = board_ops->board_config_rm(ti_sci,
+					 (u64)(u32)cfg_fragment_addr,
+					 (u32)cfg_fragment_size);
+	if (ret)
+		panic("Failed to set board RM configuration (%d)\n", ret);
+
+	/* Extract security specific configuration from FIT */
+	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
+				   &cfg_fragment_addr, &cfg_fragment_size);
+	if (ret < 0)
+		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_SEC,
+		      ret);
+
+	/* Apply security configuration to SYSFW */
+	ret = board_ops->board_config_security(ti_sci,
+					       (u64)(u32)cfg_fragment_addr,
+					       (u32)cfg_fragment_size);
+	if (ret)
+		panic("Failed to set board security configuration (%d)\n",
+		      ret);
+}
+
+void k3_sysfw_loader(void (*config_pm_done_callback)(void))
+{
+	struct spl_image_info spl_image = { 0 };
+	struct spl_boot_device bootdev = { 0 };
+	struct ti_sci_handle *ti_sci;
+	int ret;
+
+	/* Reserve a block of aligned memory for loading the SYSFW image */
+	sysfw_load_address = memalign(ARCH_DMA_MINALIGN,
+				      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
+	if (!sysfw_load_address)
+		panic("Error allocating %u bytes of memory for SYSFW image\n",
+		      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
+
+	debug("%s: allocated %u bytes at 0x%p\n", __func__,
+	      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX, sysfw_load_address);
+
+	/* Set load address for legacy modes that bypass spl_get_load_buffer */
+	spl_image.load_addr = (uintptr_t)sysfw_load_address;
+
+	bootdev.boot_device = spl_boot_device();
+
+	/* Load combined System Controller firmware and config data image */
+	switch (bootdev.boot_device) {
+#if CONFIG_IS_ENABLED(MMC_SUPPORT)
+	case BOOT_DEVICE_MMC1:
+	case BOOT_DEVICE_MMC2:
+	case BOOT_DEVICE_MMC2_2:
+		ret = spl_mmc_load(&spl_image, &bootdev,
+#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
+				   CONFIG_K3_SYSFW_IMAGE_NAME,
+#else
+				   NULL,
+#endif
+#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
+				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART,
+#else
+				   0,
+#endif
+#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
+				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT);
+#else
+				   0);
+#endif
+		break;
+#endif
+	default:
+		panic("Loading SYSFW image from device %u not supported!\n",
+		      bootdev.boot_device);
+	}
+
+	if (ret)
+		panic("Error %d occurred during loading SYSFW image!\n", ret);
+
+	/*
+	 * Now that SYSFW got loaded set helper flag to restore regular SPL
+	 * loader behavior so we can later boot into the next stage as expected.
+	 */
+	sysfw_loaded = true;
+
+	/* Ensure the SYSFW image is in FIT format */
+	if (image_get_magic((const image_header_t *)sysfw_load_address) !=
+	    FDT_MAGIC)
+		panic("SYSFW image not in FIT format!\n");
+
+	/* Extract and start SYSFW */
+	k3_sysfw_load_using_fit(sysfw_load_address);
+
+	/* Get handle for accessing SYSFW services */
+	ti_sci = get_ti_sci_handle();
+
+	/* Parse and apply the different SYSFW configuration fragments */
+	k3_sysfw_configure_using_fit(sysfw_load_address, ti_sci);
+
+	/*
+	 * Now that all clocks and PM aspects are setup, invoke a user-
+	 * provided callback function. Usually this callback would be used
+	 * to setup or re-configure the U-Boot console UART.
+	 */
+	if (config_pm_done_callback)
+		config_pm_done_callback();
+
+	/* Output System Firmware version info */
+	printf("SYSFW ABI: %d.%d (firmware rev 0x%04x '%.*s')\n",
+	       ti_sci->version.abi_major, ti_sci->version.abi_minor,
+	       ti_sci->version.firmware_revision,
+	       sizeof(ti_sci->version.firmware_description),
+	       ti_sci->version.firmware_description);
+}
+#endif
-- 
2.17.1

[U-Boot] [PATCH 05/13] armV7R: K3: am654: Allow using SPL BSS pre-relocation

[Andreas Dannenberg]

In order to be able to use more advanced driver functionality which often
relies on having BSS initialized during early boot prior to relocation
several things need to be in place:

1) Memory needs to be available for BSS to use. For this, we locate BSS
   at the top of the MCU SRAM area, with the stack starting right below
   it,
2) We need to zero-initialize BSS ourselves which will we do during
   board_init_f(),
3) We would also like to skip the implicit zero-initialization as part of
   SPL relocation, so that already initialized variables will carry over
   post-relocation. We will do this with a separate commit by turning on
   the respective CONFIG option.

In this commit we also clean up the assignment of the initial SP address
as part of the refactoring, taking into account the pre-decrement post-
increment nature in which the SP is used on ARM.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 arch/arm/mach-k3/am6_init.c |  7 +++++++
 include/configs/am65x_evm.h | 25 +++++++++++++++++++++++--
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 60a580305d..dfa6d60adf 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -78,6 +78,13 @@ void board_init_f(ulong dummy)
 
 #ifdef CONFIG_CPU_V7R
 	setup_k3_mpu_regions();
+
+	/*
+	 * When running SPL on R5 we are using SRAM for BSS to have globals
+	 * and static variables etc. working prior to relocation. Since this
+	 * means we need to self-manage BSS, clear that section now.
+	 */
+	memset(__bss_start, 0, __bss_end - __bss_start);
 #endif
 
 	/* Init DM early in-order to invoke system controller */
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index b043bf886b..cff60a8444 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -19,6 +19,29 @@
 #define CONFIG_SYS_SDRAM_BASE1		0x880000000
 
 /* SPL Loader Configuration */
+#ifdef CONFIG_TARGET_AM654_A53_EVM
+#define CONFIG_SYS_INIT_SP_ADDR         (CONFIG_SPL_TEXT_BASE +	\
+					 CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE)
+#else
+/*
+ * Maximum size in memory allocated to the SPL BSS. Keep it as tight as
+ * possible (to allow the build to go through), as this directly affects
+ * our memory footprint. The less we use for BSS the more we have available
+ * for everything else.
+ */
+#define CONFIG_SPL_BSS_MAX_SIZE		0x5000
+/*
+ * Link BSS to be within SPL in a dedicated region located near the top of
+ * the MCU SRAM, this way making it available also before relocation. Note
+ * that we are not using the actual top of the MCU SRAM as there is a memory
+ * location filled in by the boot ROM that we want to read out without any
+ * interference from the C context.
+ */
+#define CONFIG_SPL_BSS_START_ADDR	(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX -\
+					 CONFIG_SPL_BSS_MAX_SIZE)
+/* Set the stack right below the SPL BSS section */
+#define CONFIG_SYS_INIT_SP_ADDR         CONFIG_SPL_BSS_START_ADDR
+#endif
 
 #ifdef CONFIG_SYS_K3_SPL_ATF
 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME	"tispl.bin"
@@ -29,8 +52,6 @@
 #endif
 
 #define CONFIG_SPL_MAX_SIZE		CONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE
-#define CONFIG_SYS_INIT_SP_ADDR         (CONFIG_SPL_TEXT_BASE +	\
-					CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE - 4)
 
 #define CONFIG_SYS_BOOTM_LEN		SZ_64M
 
-- 
2.17.1

[U-Boot] [PATCH 06/13] armv7R: K3: am654: Use full malloc implementation in SPL

[Andreas Dannenberg]

Switch to using the full malloc scheme in post-relocation SPL to allow
better utilization of available memory for example by allowing memory
to get freed. Initially allocate a 16MB-sized region in DDR starting
at address 0x84000000 for this purpose.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 configs/am65x_evm_r5_defconfig    | 1 -
 configs/am65x_hs_evm_r5_defconfig | 1 -
 include/configs/am65x_evm.h       | 3 +++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 8dce577cf7..3f4134b5f5 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -18,7 +18,6 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_USE_BOOTCOMMAND=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_TEXT_BASE=0x41c00000
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_I2C_SUPPORT=y
diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig
index 8d5d3590b2..d4d23416cc 100644
--- a/configs/am65x_hs_evm_r5_defconfig
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -20,7 +20,6 @@ CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_USE_BOOTCOMMAND=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_TEXT_BASE=0x41c00000
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_I2C_SUPPORT=y
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index cff60a8444..a90f38edc9 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -41,6 +41,9 @@
 					 CONFIG_SPL_BSS_MAX_SIZE)
 /* Set the stack right below the SPL BSS section */
 #define CONFIG_SYS_INIT_SP_ADDR         CONFIG_SPL_BSS_START_ADDR
+/* Configure R5 SPL post-relocation malloc pool in DDR */
+#define CONFIG_SYS_SPL_MALLOC_START	0x84000000
+#define CONFIG_SYS_SPL_MALLOC_SIZE	SZ_16M
 #endif
 
 #ifdef CONFIG_SYS_K3_SPL_ATF
-- 
2.17.1

[U-Boot] [PATCH 07/13] armV7R: K3: am654: Load SYSFW binary and config from boot media

[Andreas Dannenberg]

Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM654 early initialization sequence. While
at it also initialize the WKUP_UART0 pinmux as it is used by SYSFW
to print diagnostic messages.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 arch/arm/mach-k3/am6_init.c | 27 ++++++++++++++++++++++++++-
 board/ti/am65x/Kconfig      |  1 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index dfa6d60adf..08f2eb9438 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -10,8 +10,11 @@
 #include <asm/io.h>
 #include <spl.h>
 #include <asm/arch/hardware.h>
+#include <asm/arch/sysfw-loader.h>
 #include "common.h"
 #include <dm.h>
+#include <dm/uclass-internal.h>
+#include <dm/pinctrl.h>
 
 #ifdef CONFIG_SPL_BUILD
 static void mmr_unlock(u32 base, u32 partition)
@@ -63,7 +66,7 @@ static void store_boot_index_from_rom(void)
 
 void board_init_f(ulong dummy)
 {
-#if defined(CONFIG_K3_AM654_DDRSS)
+#if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS)
 	struct udevice *dev;
 	int ret;
 #endif
@@ -90,8 +93,30 @@ void board_init_f(ulong dummy)
 	/* Init DM early in-order to invoke system controller */
 	spl_early_init();
 
+#ifdef CONFIG_K3_LOAD_SYSFW
+	/*
+	 * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue
+	 * regardless of the result of pinctrl. Do this without probing the
+	 * device, but instead by searching the device that would request the
+	 * given sequence number if probed. The UART will be used by the system
+	 * firmware (SYSFW) image for various purposes and SYSFW depends on us
+	 * to initialize its pin settings.
+	 */
+	ret = uclass_find_device_by_seq(UCLASS_SERIAL, 0, true, &dev);
+	if (!ret)
+		pinctrl_select_state(dev, "default");
+
+	/*
+	 * Load, start up, and configure system controller firmware. Provide
+	 * the U-Boot console init function to the SYSFW post-PM configuration
+	 * callback hook, effectively switching on (or over) the console
+	 * output.
+	 */
+	k3_sysfw_loader(preloader_console_init);
+#else
 	/* Prepare console output */
 	preloader_console_init();
+#endif
 
 #ifdef CONFIG_K3_AM654_DDRSS
 	ret = uclass_get_device(UCLASS_RAM, 0, &dev);
diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
index 98172c28f5..60bb834aca 100644
--- a/board/ti/am65x/Kconfig
+++ b/board/ti/am65x/Kconfig
@@ -18,6 +18,7 @@ config TARGET_AM654_R5_EVM
 	select CPU_V7R
 	select SYS_THUMB_BUILD
 	select SOC_K3_AM6
+	select K3_LOAD_SYSFW
 	select K3_AM654_DDRSS
 	imply SYS_K3_SPL_ATF
 
-- 
2.17.1

[U-Boot] [PATCH 08/13] armv7R: dts: k3: am654: Update mmc nodes for loading sysfw

[Andreas Dannenberg]

From: Lokesh Vutla <lokeshvutla@ti.com>

In order to load the sysfw.itb from a mmc device, clocks
should be hard coded to the same value as ROM configured
frequency. Clock updates cannot happen at this point as
sysfw is not yet available. So updating the clock properties
for mmc nodes.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 arch/arm/dts/k3-am654-r5-base-board.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts b/arch/arm/dts/k3-am654-r5-base-board.dts
index a07038be70..94bdf57a14 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -96,6 +96,12 @@
 		u-boot,dm-spl;
 	};
 
+	clk_200mhz: dummy_clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <200000000>;
+		u-boot,dm-spl;
+	};
 };
 
 &dmsc {
@@ -137,3 +143,15 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&wkup_vtt_pins_default>;
 };
+
+&sdhci0 {
+	clock-names = "clk_xin";
+	clocks = <&clk_200mhz>;
+	/delete-property/ power-domains;
+};
+
+&sdhci1 {
+	clock-names = "clk_xin";
+	clocks = <&clk_200mhz>;
+	/delete-property/ power-domains;
+};
-- 
2.17.1

[U-Boot] [PATCH 09/13] configs: am65x_evm_r5: All sysfw to be loaded via MMC

[Andreas Dannenberg]

Enable all the relevant configs that enables support for loading
sysfw via MMC.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 configs/am65x_evm_r5_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 3f4134b5f5..6861a9f05b 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -3,7 +3,7 @@ CONFIG_ARCH_K3=y
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x55000
 CONFIG_SOC_K3_AM6=y
 CONFIG_TARGET_AM654_R5_EVM=y
 CONFIG_SPL_MMC_SUPPORT=y
@@ -20,6 +20,7 @@ CONFIG_USE_BOOTCOMMAND=y
 CONFIG_SPL_TEXT_BASE=0x41c00000
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_SKIP_CLEAR_BSS=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
@@ -86,3 +87,4 @@ CONFIG_SYSRESET_TI_SCI=y
 CONFIG_TIMER=y
 CONFIG_SPL_TIMER=y
 CONFIG_OMAP_TIMER=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
-- 
2.17.1

[U-Boot] [PATCH 10/13] configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC

[Andreas Dannenberg]

Enable all the relevant configs that enables support for loading
sysfw via MMC.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 configs/am65x_hs_evm_r5_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig
index d4d23416cc..03b8bd0ec6 100644
--- a/configs/am65x_hs_evm_r5_defconfig
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -4,7 +4,7 @@ CONFIG_TI_SECURE_DEVICE=y
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x55000
 CONFIG_SOC_K3_AM6=y
 CONFIG_TARGET_AM654_R5_EVM=y
 CONFIG_SPL_MMC_SUPPORT=y
@@ -22,6 +22,7 @@ CONFIG_USE_BOOTCOMMAND=y
 CONFIG_SPL_TEXT_BASE=0x41c00000
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_SKIP_CLEAR_BSS=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
@@ -88,3 +89,4 @@ CONFIG_SYSRESET_TI_SCI=y
 CONFIG_TIMER=y
 CONFIG_SPL_TIMER=y
 CONFIG_OMAP_TIMER=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
-- 
2.17.1

[U-Boot] [PATCH 11/13] configs: am65x_evm: Add Support for eMMC boot

[Andreas Dannenberg]

From: Faiz Abbas <faiz_abbas@ti.com>

Add configs to support RAW boot mode in eMMC.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 configs/am65x_evm_a53_defconfig | 2 ++
 configs/am65x_evm_r5_defconfig  | 2 ++
 include/configs/am65x_evm.h     | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 101fae1456..0d9c4bf685 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -22,6 +22,8 @@ CONFIG_SPL_TEXT_BASE=0x80080000
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 6861a9f05b..a23afaeb22 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -21,6 +21,8 @@ CONFIG_SPL_TEXT_BASE=0x41c00000
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_SKIP_CLEAR_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index a90f38edc9..56bd69a82a 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -92,6 +92,8 @@
 	EXTRA_ENV_AM65X_BOARD_SETTINGS					\
 	EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC
 
+#define CONFIG_SUPPORT_EMMC_BOOT
+
 /* Now for the remaining common defines */
 #include <configs/ti_armv7_common.h>
 
-- 
2.17.1

[U-Boot] [PATCH 12/13] configs: am65x_hs_evm: Add Support for eMMC boot

[Andreas Dannenberg]

Add configs to support RAW boot mode in eMMC.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
 configs/am65x_hs_evm_a53_defconfig | 2 ++
 configs/am65x_hs_evm_r5_defconfig  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig
index 7af0046ee3..6e226d9bff 100644
--- a/configs/am65x_hs_evm_a53_defconfig
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -25,6 +25,8 @@ CONFIG_SPL_TEXT_BASE=0x80080000
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig
index 03b8bd0ec6..c6a472d5e4 100644
--- a/configs/am65x_hs_evm_r5_defconfig
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -23,6 +23,8 @@ CONFIG_SPL_TEXT_BASE=0x41c00000
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_SKIP_CLEAR_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
 CONFIG_SPL_DM_RESET=y
-- 
2.17.1

[U-Boot] [PATCH 13/13] am65x: README: Add eMMC layout and flash instructions

[Andreas Dannenberg]

From: Faiz Abbas <faiz_abbas@ti.com>

Add instructions for flashing boot images to the eMMC with a
layout of the address where each image needs to be flashed.

Also add instructions to flash filesystem partition in user
partition and boot kernel from the rootfs.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 board/ti/am65x/README | 52 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/board/ti/am65x/README b/board/ti/am65x/README
index 0b82bd557b..16384e05ea 100644
--- a/board/ti/am65x/README
+++ b/board/ti/am65x/README
@@ -209,3 +209,55 @@ Image formats:
                 | |    Secure config  | |
                 | +-------------------+ |
                 +-----------------------+
+
+eMMC:
+-----
+ROM supports booting from eMMC from boot0 partition offset 0x0
+
+Flashing images to eMMC:
+
+The following commands can be used to download tiboot3.bin, tispl.bin,
+u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0
+partition at respective addresses.
+
+=> mmc dev 0 1
+=> fatload mmc 1 ${loadaddr} tiboot3.bin
+=> mmc write ${loadaddr} 0x0 0x400
+=> fatload mmc 1 ${loadaddr} tispl.bin
+=> mmc write ${loadaddr} 0x400 0x1000
+=> fatload mmc 1 ${loadaddr} u-boot.img
+=> mmc write ${loadaddr} 0x1400 0x2000
+=> fatload mmc 1 ${loadaddr} sysfw.itb
+=> mmc write ${loadaddr} 0x3600 0x800
+
+To give the ROM access to the boot partition, the following commands must be
+used for the first time:
+=> mmc partconf 0 1 1 1
+=> mmc bootbus 0 1 0 0
+
+To create a software partition for the rootfs, the following command can be
+used:
+=> gpt write mmc 0 ${partitions}
+
+eMMC layout:
+
+           boot0 partition (8 MB)                        user partition
+   0x0+----------------------------------+      0x0+-------------------------+
+      |     tiboot3.bin (512 KB)         |         |                         |
+ 0x400+----------------------------------+         |                         |
+      |       tispl.bin (2 MB)           |         |                         |
+0x1400+----------------------------------+         |        rootfs           |
+      |       u-boot.img (4 MB)          |         |                         |
+0x3400+----------------------------------+         |                         |
+      |      environment (128 KB)        |         |                         |
+0x3500+----------------------------------+         |                         |
+      |   backup environment (128 KB)    |         |                         |
+0x3600+----------------------------------+         |                         |
+      |          sysfw (1 MB)            |         |                         |
+0x3E00+----------------------------------+         +-------------------------+
+
+Kernel image and DT are expected to be present in the /boot folder of rootfs.
+To boot kernel from eMMC, use the following commands:
+=> setenv mmcdev 0
+=> setenv bootpart 0
+=> boot
-- 
2.17.1

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Simon Goldschmidt]

On 07.05.19 19:25, Andreas Dannenberg wrote:
> Introduce a framework that allows loading the System Firmware (SYSFW)
> binary as well as the associated configuration data from an image tree
> blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> RAW mode partition or sector.
> 
> To simplify the handling of and loading from the different boot media
> we tap into the existing U-Boot SPL framework usually used for loading
> U-Boot by building on an earlier commit that exposes some of that
> functionality.
> 
> Note that this initial implementation only supports FS and RAW-based
> eMMC/SD card boot.
> 
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Without having a too deep understanding of this, all this stuff looks 
like it would be similar to drivers/misc/fs_loader.c?

Could it build on top of that?

Regards,
Simon

> ---
>   arch/arm/mach-k3/Kconfig                     |  40 +++
>   arch/arm/mach-k3/Makefile                    |   1 +
>   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>   arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
>   4 files changed, 316 insertions(+)
>   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> 
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index e677a2e01b..f1731dda58 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
>   	int
>   	default 16
>   
> +config K3_LOAD_SYSFW
> +	bool
> +	depends on SPL
> +	default n
> +
> +config K3_SYSFW_IMAGE_NAME
> +	string "File name of SYSFW firmware and configuration blob"
> +	depends on K3_LOAD_SYSFW
> +	default	"sysfw.itb"
> +	help
> +	  Filename of the combined System Firmware and configuration image tree
> +	  blob to be loaded when booting from a filesystem.
> +
> +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
> +	hex "MMC sector to load SYSFW firmware and configuration blob from"
> +	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> +	default 0x3600
> +	help
> +	  Address on the MMC to load the combined System Firmware and
> +	  configuration image tree blob from, when the MMC is being used
> +	  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
> +
> +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
> +	hex "MMC partition to load SYSFW firmware and configuration blob from"
> +	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> +	default 2
> +	help
> +	  Partition on the MMC to the combined System Firmware and configuration
> +	  image tree blob from, when the MMC is being used in raw mode.
> +
> +config K3_SYSFW_IMAGE_SIZE_MAX
> +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> +	depends on K3_LOAD_SYSFW
> +	default	269000
> +	help
> +	  Amount of memory reserved through dynamic allocation at runtime for
> +	  loading the combined System Firmware and configuration image tree
> +	  blob. Keep it as tight as possible, as this directly affects the
> +	  overall SPL memory footprint.
> +
>   config SYS_K3_SPL_ATF
>   	bool "Start Cortex-A from SPL"
>   	depends on SPL && CPU_V7R
> diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> index 0c3a4f7db1..6c895400c2 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
>   obj-$(CONFIG_ARM64) += arm64-mmu.o
>   obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
>   obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
>   obj-y += common.o
> diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> new file mode 100644
> index 0000000000..36eb265348
> --- /dev/null
> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> + *	Andreas Dannenberg <dannenberg@ti.com>
> + */
> +
> +#ifndef _SYSFW_LOADER_H_
> +#define _SYSFW_LOADER_H_
> +
> +void k3_sysfw_loader(void (*config_pm_done_callback)(void));
> +
> +#endif
> diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> new file mode 100644
> index 0000000000..a222266c27
> --- /dev/null
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -0,0 +1,263 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: System Firmware Loader
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> + *	Andreas Dannenberg <dannenberg@ti.com>
> + */
> +
> +#include <common.h>
> +#include <spl.h>
> +#include <malloc.h>
> +#include <remoteproc.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +#include <asm/arch/sys_proto.h>
> +
> +/* Name of the FIT image nodes for SYSFW and its config data */
> +#define SYSFW_FIRMWARE			"sysfw.bin"
> +#define SYSFW_CFG_BOARD			"board-cfg.bin"
> +#define SYSFW_CFG_PM			"pm-cfg.bin"
> +#define SYSFW_CFG_RM			"rm-cfg.bin"
> +#define SYSFW_CFG_SEC			"sec-cfg.bin"
> +
> +#ifdef CONFIG_SPL_BUILD
> +
> +static bool sysfw_loaded;
> +static void *sysfw_load_address;
> +
> +/*
> + * Populate SPL hook to override the default load address used by the SPL
> + * loader function with a custom address for SYSFW loading.
> + */
> +struct image_header *spl_get_load_buffer(ssize_t offset, size_t size)
> +{
> +	if (sysfw_loaded)
> +		return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset);
> +	else if (sysfw_load_address)
> +		return sysfw_load_address;
> +	else
> +		panic("SYSFW load address not defined!");
> +}
> +
> +/*
> + * Populate SPL hook to skip the default SPL loader FIT post-processing steps
> + * during SYSFW loading and return to the calling function so we can perform
> + * our own custom processing.
> + */
> +bool spl_load_simple_fit_skip_processing(void)
> +{
> +	return !sysfw_loaded;
> +}
> +
> +static int fit_get_data_by_name(const void *fit, int images, const char *name,
> +				const void **addr, size_t *size)
> +{
> +	int node_offset;
> +
> +	node_offset = fdt_subnode_offset(fit, images, name);
> +	if (node_offset < 0)
> +		return -ENOENT;
> +
> +	return fit_image_get_data(fit, node_offset, addr, size);
> +}
> +
> +static void k3_sysfw_load_using_fit(void *fit)
> +{
> +	int images;
> +	const void *sysfw_addr;
> +	size_t sysfw_size;
> +	int ret;
> +
> +	/* Find the node holding the images information */
> +	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> +	if (images < 0)
> +		panic("Cannot find /images node (%d)\n", images);
> +
> +	/* Extract System Firmware (SYSFW) image from FIT */
> +	ret = fit_get_data_by_name(fit, images, SYSFW_FIRMWARE,
> +				   &sysfw_addr, &sysfw_size);
> +	if (ret < 0)
> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_FIRMWARE,
> +		      ret);
> +
> +	/*
> +	 * Start up system controller firmware
> +	 *
> +	 * It is assumed that remoteproc device 0 is the corresponding
> +	 * system-controller that runs SYSFW. Make sure DT reflects the same.
> +	 */
> +	ret = rproc_dev_init(0);
> +	if (ret)
> +		panic("rproc failed to be initialized (%d)\n", ret);
> +
> +	ret = rproc_load(0, (ulong)sysfw_addr, (ulong)sysfw_size);
> +	if (ret)
> +		panic("Firmware failed to start on rproc (%d)\n", ret);
> +
> +	ret = rproc_start(0);
> +	if (ret)
> +		panic("Firmware init failed on rproc (%d)\n", ret);
> +}
> +
> +static void k3_sysfw_configure_using_fit(void *fit,
> +					 struct ti_sci_handle *ti_sci)
> +{
> +	struct ti_sci_board_ops *board_ops = &ti_sci->ops.board_ops;
> +	int images;
> +	const void *cfg_fragment_addr;
> +	size_t cfg_fragment_size;
> +	int ret;
> +
> +	/* Find the node holding the images information */
> +	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> +	if (images < 0)
> +		panic("Cannot find /images node (%d)\n", images);
> +
> +	/* Extract board configuration from FIT */
> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_BOARD,
> +				   &cfg_fragment_addr, &cfg_fragment_size);
> +	if (ret < 0)
> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_BOARD,
> +		      ret);
> +
> +	/* Apply board configuration to SYSFW */
> +	ret = board_ops->board_config(ti_sci,
> +				      (u64)(u32)cfg_fragment_addr,
> +				      (u32)cfg_fragment_size);
> +	if (ret)
> +		panic("Failed to set board configuration (%d)\n", ret);
> +
> +	/* Extract power/clock (PM) specific configuration from FIT */
> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_PM,
> +				   &cfg_fragment_addr, &cfg_fragment_size);
> +	if (ret < 0)
> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_PM,
> +		      ret);
> +
> +	/* Apply power/clock (PM) specific configuration to SYSFW */
> +	ret = board_ops->board_config_pm(ti_sci,
> +					 (u64)(u32)cfg_fragment_addr,
> +					 (u32)cfg_fragment_size);
> +	if (ret)
> +		panic("Failed to set board PM configuration (%d)\n", ret);
> +
> +	/* Extract resource management (RM) specific configuration from FIT */
> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
> +				   &cfg_fragment_addr, &cfg_fragment_size);
> +	if (ret < 0)
> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_RM,
> +		      ret);
> +
> +	/* Apply resource management (RM) configuration to SYSFW */
> +	ret = board_ops->board_config_rm(ti_sci,
> +					 (u64)(u32)cfg_fragment_addr,
> +					 (u32)cfg_fragment_size);
> +	if (ret)
> +		panic("Failed to set board RM configuration (%d)\n", ret);
> +
> +	/* Extract security specific configuration from FIT */
> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
> +				   &cfg_fragment_addr, &cfg_fragment_size);
> +	if (ret < 0)
> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_SEC,
> +		      ret);
> +
> +	/* Apply security configuration to SYSFW */
> +	ret = board_ops->board_config_security(ti_sci,
> +					       (u64)(u32)cfg_fragment_addr,
> +					       (u32)cfg_fragment_size);
> +	if (ret)
> +		panic("Failed to set board security configuration (%d)\n",
> +		      ret);
> +}
> +
> +void k3_sysfw_loader(void (*config_pm_done_callback)(void))
> +{
> +	struct spl_image_info spl_image = { 0 };
> +	struct spl_boot_device bootdev = { 0 };
> +	struct ti_sci_handle *ti_sci;
> +	int ret;
> +
> +	/* Reserve a block of aligned memory for loading the SYSFW image */
> +	sysfw_load_address = memalign(ARCH_DMA_MINALIGN,
> +				      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
> +	if (!sysfw_load_address)
> +		panic("Error allocating %u bytes of memory for SYSFW image\n",
> +		      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
> +
> +	debug("%s: allocated %u bytes at 0x%p\n", __func__,
> +	      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX, sysfw_load_address);
> +
> +	/* Set load address for legacy modes that bypass spl_get_load_buffer */
> +	spl_image.load_addr = (uintptr_t)sysfw_load_address;
> +
> +	bootdev.boot_device = spl_boot_device();
> +
> +	/* Load combined System Controller firmware and config data image */
> +	switch (bootdev.boot_device) {
> +#if CONFIG_IS_ENABLED(MMC_SUPPORT)
> +	case BOOT_DEVICE_MMC1:
> +	case BOOT_DEVICE_MMC2:
> +	case BOOT_DEVICE_MMC2_2:
> +		ret = spl_mmc_load(&spl_image, &bootdev,
> +#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
> +				   CONFIG_K3_SYSFW_IMAGE_NAME,
> +#else
> +				   NULL,
> +#endif
> +#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
> +				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART,
> +#else
> +				   0,
> +#endif
> +#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
> +				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT);
> +#else
> +				   0);
> +#endif
> +		break;
> +#endif
> +	default:
> +		panic("Loading SYSFW image from device %u not supported!\n",
> +		      bootdev.boot_device);
> +	}
> +
> +	if (ret)
> +		panic("Error %d occurred during loading SYSFW image!\n", ret);
> +
> +	/*
> +	 * Now that SYSFW got loaded set helper flag to restore regular SPL
> +	 * loader behavior so we can later boot into the next stage as expected.
> +	 */
> +	sysfw_loaded = true;
> +
> +	/* Ensure the SYSFW image is in FIT format */
> +	if (image_get_magic((const image_header_t *)sysfw_load_address) !=
> +	    FDT_MAGIC)
> +		panic("SYSFW image not in FIT format!\n");
> +
> +	/* Extract and start SYSFW */
> +	k3_sysfw_load_using_fit(sysfw_load_address);
> +
> +	/* Get handle for accessing SYSFW services */
> +	ti_sci = get_ti_sci_handle();
> +
> +	/* Parse and apply the different SYSFW configuration fragments */
> +	k3_sysfw_configure_using_fit(sysfw_load_address, ti_sci);
> +
> +	/*
> +	 * Now that all clocks and PM aspects are setup, invoke a user-
> +	 * provided callback function. Usually this callback would be used
> +	 * to setup or re-configure the U-Boot console UART.
> +	 */
> +	if (config_pm_done_callback)
> +		config_pm_done_callback();
> +
> +	/* Output System Firmware version info */
> +	printf("SYSFW ABI: %d.%d (firmware rev 0x%04x '%.*s')\n",
> +	       ti_sci->version.abi_major, ti_sci->version.abi_minor,
> +	       ti_sci->version.firmware_revision,
> +	       sizeof(ti_sci->version.firmware_description),
> +	       ti_sci->version.firmware_description);
> +}
> +#endif
> 

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Andreas Dannenberg]

Hi Simon,

On Tue, May 07, 2019 at 08:16:07PM +0200, Simon Goldschmidt wrote:
> 
> 
> On 07.05.19 19:25, Andreas Dannenberg wrote:
> > Introduce a framework that allows loading the System Firmware (SYSFW)
> > binary as well as the associated configuration data from an image tree
> > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > RAW mode partition or sector.
> > 
> > To simplify the handling of and loading from the different boot media
> > we tap into the existing U-Boot SPL framework usually used for loading
> > U-Boot by building on an earlier commit that exposes some of that
> > functionality.
> > 
> > Note that this initial implementation only supports FS and RAW-based
> > eMMC/SD card boot.
> > 
> > Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> 
> Without having a too deep understanding of this, all this stuff looks like
> it would be similar to drivers/misc/fs_loader.c?
> 
> Could it build on top of that?

Yes and no. Can you please review the associated cover letter, it
addresses this very question which I expected to get raised.

Thanks,
Andreas

> 
> Regards,
> Simon
> 
> > ---
> >   arch/arm/mach-k3/Kconfig                     |  40 +++
> >   arch/arm/mach-k3/Makefile                    |   1 +
> >   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
> >   arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
> >   4 files changed, 316 insertions(+)
> >   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
> >   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> > 
> > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > index e677a2e01b..f1731dda58 100644
> > --- a/arch/arm/mach-k3/Kconfig
> > +++ b/arch/arm/mach-k3/Kconfig
> > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> >   	int
> >   	default 16
> > +config K3_LOAD_SYSFW
> > +	bool
> > +	depends on SPL
> > +	default n
> > +
> > +config K3_SYSFW_IMAGE_NAME
> > +	string "File name of SYSFW firmware and configuration blob"
> > +	depends on K3_LOAD_SYSFW
> > +	default	"sysfw.itb"
> > +	help
> > +	  Filename of the combined System Firmware and configuration image tree
> > +	  blob to be loaded when booting from a filesystem.
> > +
> > +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
> > +	hex "MMC sector to load SYSFW firmware and configuration blob from"
> > +	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> > +	default 0x3600
> > +	help
> > +	  Address on the MMC to load the combined System Firmware and
> > +	  configuration image tree blob from, when the MMC is being used
> > +	  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
> > +
> > +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
> > +	hex "MMC partition to load SYSFW firmware and configuration blob from"
> > +	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> > +	default 2
> > +	help
> > +	  Partition on the MMC to the combined System Firmware and configuration
> > +	  image tree blob from, when the MMC is being used in raw mode.
> > +
> > +config K3_SYSFW_IMAGE_SIZE_MAX
> > +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> > +	depends on K3_LOAD_SYSFW
> > +	default	269000
> > +	help
> > +	  Amount of memory reserved through dynamic allocation at runtime for
> > +	  loading the combined System Firmware and configuration image tree
> > +	  blob. Keep it as tight as possible, as this directly affects the
> > +	  overall SPL memory footprint.
> > +
> >   config SYS_K3_SPL_ATF
> >   	bool "Start Cortex-A from SPL"
> >   	depends on SPL && CPU_V7R
> > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> > index 0c3a4f7db1..6c895400c2 100644
> > --- a/arch/arm/mach-k3/Makefile
> > +++ b/arch/arm/mach-k3/Makefile
> > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
> >   obj-$(CONFIG_ARM64) += arm64-mmu.o
> >   obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
> >   obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> >   obj-y += common.o
> > diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> > new file mode 100644
> > index 0000000000..36eb265348
> > --- /dev/null
> > +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> > @@ -0,0 +1,12 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> > + *	Andreas Dannenberg <dannenberg@ti.com>
> > + */
> > +
> > +#ifndef _SYSFW_LOADER_H_
> > +#define _SYSFW_LOADER_H_
> > +
> > +void k3_sysfw_loader(void (*config_pm_done_callback)(void));
> > +
> > +#endif
> > diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> > new file mode 100644
> > index 0000000000..a222266c27
> > --- /dev/null
> > +++ b/arch/arm/mach-k3/sysfw-loader.c
> > @@ -0,0 +1,263 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * K3: System Firmware Loader
> > + *
> > + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> > + *	Andreas Dannenberg <dannenberg@ti.com>
> > + */
> > +
> > +#include <common.h>
> > +#include <spl.h>
> > +#include <malloc.h>
> > +#include <remoteproc.h>
> > +#include <linux/soc/ti/ti_sci_protocol.h>
> > +#include <asm/arch/sys_proto.h>
> > +
> > +/* Name of the FIT image nodes for SYSFW and its config data */
> > +#define SYSFW_FIRMWARE			"sysfw.bin"
> > +#define SYSFW_CFG_BOARD			"board-cfg.bin"
> > +#define SYSFW_CFG_PM			"pm-cfg.bin"
> > +#define SYSFW_CFG_RM			"rm-cfg.bin"
> > +#define SYSFW_CFG_SEC			"sec-cfg.bin"
> > +
> > +#ifdef CONFIG_SPL_BUILD
> > +
> > +static bool sysfw_loaded;
> > +static void *sysfw_load_address;
> > +
> > +/*
> > + * Populate SPL hook to override the default load address used by the SPL
> > + * loader function with a custom address for SYSFW loading.
> > + */
> > +struct image_header *spl_get_load_buffer(ssize_t offset, size_t size)
> > +{
> > +	if (sysfw_loaded)
> > +		return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset);
> > +	else if (sysfw_load_address)
> > +		return sysfw_load_address;
> > +	else
> > +		panic("SYSFW load address not defined!");
> > +}
> > +
> > +/*
> > + * Populate SPL hook to skip the default SPL loader FIT post-processing steps
> > + * during SYSFW loading and return to the calling function so we can perform
> > + * our own custom processing.
> > + */
> > +bool spl_load_simple_fit_skip_processing(void)
> > +{
> > +	return !sysfw_loaded;
> > +}
> > +
> > +static int fit_get_data_by_name(const void *fit, int images, const char *name,
> > +				const void **addr, size_t *size)
> > +{
> > +	int node_offset;
> > +
> > +	node_offset = fdt_subnode_offset(fit, images, name);
> > +	if (node_offset < 0)
> > +		return -ENOENT;
> > +
> > +	return fit_image_get_data(fit, node_offset, addr, size);
> > +}
> > +
> > +static void k3_sysfw_load_using_fit(void *fit)
> > +{
> > +	int images;
> > +	const void *sysfw_addr;
> > +	size_t sysfw_size;
> > +	int ret;
> > +
> > +	/* Find the node holding the images information */
> > +	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> > +	if (images < 0)
> > +		panic("Cannot find /images node (%d)\n", images);
> > +
> > +	/* Extract System Firmware (SYSFW) image from FIT */
> > +	ret = fit_get_data_by_name(fit, images, SYSFW_FIRMWARE,
> > +				   &sysfw_addr, &sysfw_size);
> > +	if (ret < 0)
> > +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_FIRMWARE,
> > +		      ret);
> > +
> > +	/*
> > +	 * Start up system controller firmware
> > +	 *
> > +	 * It is assumed that remoteproc device 0 is the corresponding
> > +	 * system-controller that runs SYSFW. Make sure DT reflects the same.
> > +	 */
> > +	ret = rproc_dev_init(0);
> > +	if (ret)
> > +		panic("rproc failed to be initialized (%d)\n", ret);
> > +
> > +	ret = rproc_load(0, (ulong)sysfw_addr, (ulong)sysfw_size);
> > +	if (ret)
> > +		panic("Firmware failed to start on rproc (%d)\n", ret);
> > +
> > +	ret = rproc_start(0);
> > +	if (ret)
> > +		panic("Firmware init failed on rproc (%d)\n", ret);
> > +}
> > +
> > +static void k3_sysfw_configure_using_fit(void *fit,
> > +					 struct ti_sci_handle *ti_sci)
> > +{
> > +	struct ti_sci_board_ops *board_ops = &ti_sci->ops.board_ops;
> > +	int images;
> > +	const void *cfg_fragment_addr;
> > +	size_t cfg_fragment_size;
> > +	int ret;
> > +
> > +	/* Find the node holding the images information */
> > +	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> > +	if (images < 0)
> > +		panic("Cannot find /images node (%d)\n", images);
> > +
> > +	/* Extract board configuration from FIT */
> > +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_BOARD,
> > +				   &cfg_fragment_addr, &cfg_fragment_size);
> > +	if (ret < 0)
> > +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_BOARD,
> > +		      ret);
> > +
> > +	/* Apply board configuration to SYSFW */
> > +	ret = board_ops->board_config(ti_sci,
> > +				      (u64)(u32)cfg_fragment_addr,
> > +				      (u32)cfg_fragment_size);
> > +	if (ret)
> > +		panic("Failed to set board configuration (%d)\n", ret);
> > +
> > +	/* Extract power/clock (PM) specific configuration from FIT */
> > +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_PM,
> > +				   &cfg_fragment_addr, &cfg_fragment_size);
> > +	if (ret < 0)
> > +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_PM,
> > +		      ret);
> > +
> > +	/* Apply power/clock (PM) specific configuration to SYSFW */
> > +	ret = board_ops->board_config_pm(ti_sci,
> > +					 (u64)(u32)cfg_fragment_addr,
> > +					 (u32)cfg_fragment_size);
> > +	if (ret)
> > +		panic("Failed to set board PM configuration (%d)\n", ret);
> > +
> > +	/* Extract resource management (RM) specific configuration from FIT */
> > +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
> > +				   &cfg_fragment_addr, &cfg_fragment_size);
> > +	if (ret < 0)
> > +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_RM,
> > +		      ret);
> > +
> > +	/* Apply resource management (RM) configuration to SYSFW */
> > +	ret = board_ops->board_config_rm(ti_sci,
> > +					 (u64)(u32)cfg_fragment_addr,
> > +					 (u32)cfg_fragment_size);
> > +	if (ret)
> > +		panic("Failed to set board RM configuration (%d)\n", ret);
> > +
> > +	/* Extract security specific configuration from FIT */
> > +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
> > +				   &cfg_fragment_addr, &cfg_fragment_size);
> > +	if (ret < 0)
> > +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_SEC,
> > +		      ret);
> > +
> > +	/* Apply security configuration to SYSFW */
> > +	ret = board_ops->board_config_security(ti_sci,
> > +					       (u64)(u32)cfg_fragment_addr,
> > +					       (u32)cfg_fragment_size);
> > +	if (ret)
> > +		panic("Failed to set board security configuration (%d)\n",
> > +		      ret);
> > +}
> > +
> > +void k3_sysfw_loader(void (*config_pm_done_callback)(void))
> > +{
> > +	struct spl_image_info spl_image = { 0 };
> > +	struct spl_boot_device bootdev = { 0 };
> > +	struct ti_sci_handle *ti_sci;
> > +	int ret;
> > +
> > +	/* Reserve a block of aligned memory for loading the SYSFW image */
> > +	sysfw_load_address = memalign(ARCH_DMA_MINALIGN,
> > +				      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
> > +	if (!sysfw_load_address)
> > +		panic("Error allocating %u bytes of memory for SYSFW image\n",
> > +		      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
> > +
> > +	debug("%s: allocated %u bytes at 0x%p\n", __func__,
> > +	      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX, sysfw_load_address);
> > +
> > +	/* Set load address for legacy modes that bypass spl_get_load_buffer */
> > +	spl_image.load_addr = (uintptr_t)sysfw_load_address;
> > +
> > +	bootdev.boot_device = spl_boot_device();
> > +
> > +	/* Load combined System Controller firmware and config data image */
> > +	switch (bootdev.boot_device) {
> > +#if CONFIG_IS_ENABLED(MMC_SUPPORT)
> > +	case BOOT_DEVICE_MMC1:
> > +	case BOOT_DEVICE_MMC2:
> > +	case BOOT_DEVICE_MMC2_2:
> > +		ret = spl_mmc_load(&spl_image, &bootdev,
> > +#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
> > +				   CONFIG_K3_SYSFW_IMAGE_NAME,
> > +#else
> > +				   NULL,
> > +#endif
> > +#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
> > +				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART,
> > +#else
> > +				   0,
> > +#endif
> > +#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
> > +				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT);
> > +#else
> > +				   0);
> > +#endif
> > +		break;
> > +#endif
> > +	default:
> > +		panic("Loading SYSFW image from device %u not supported!\n",
> > +		      bootdev.boot_device);
> > +	}
> > +
> > +	if (ret)
> > +		panic("Error %d occurred during loading SYSFW image!\n", ret);
> > +
> > +	/*
> > +	 * Now that SYSFW got loaded set helper flag to restore regular SPL
> > +	 * loader behavior so we can later boot into the next stage as expected.
> > +	 */
> > +	sysfw_loaded = true;
> > +
> > +	/* Ensure the SYSFW image is in FIT format */
> > +	if (image_get_magic((const image_header_t *)sysfw_load_address) !=
> > +	    FDT_MAGIC)
> > +		panic("SYSFW image not in FIT format!\n");
> > +
> > +	/* Extract and start SYSFW */
> > +	k3_sysfw_load_using_fit(sysfw_load_address);
> > +
> > +	/* Get handle for accessing SYSFW services */
> > +	ti_sci = get_ti_sci_handle();
> > +
> > +	/* Parse and apply the different SYSFW configuration fragments */
> > +	k3_sysfw_configure_using_fit(sysfw_load_address, ti_sci);
> > +
> > +	/*
> > +	 * Now that all clocks and PM aspects are setup, invoke a user-
> > +	 * provided callback function. Usually this callback would be used
> > +	 * to setup or re-configure the U-Boot console UART.
> > +	 */
> > +	if (config_pm_done_callback)
> > +		config_pm_done_callback();
> > +
> > +	/* Output System Firmware version info */
> > +	printf("SYSFW ABI: %d.%d (firmware rev 0x%04x '%.*s')\n",
> > +	       ti_sci->version.abi_major, ti_sci->version.abi_minor,
> > +	       ti_sci->version.firmware_revision,
> > +	       sizeof(ti_sci->version.firmware_description),
> > +	       ti_sci->version.firmware_description);
> > +}
> > +#endif
> > 

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Simon Goldschmidt]

On 07.05.19 21:17, Andreas Dannenberg wrote:
> Hi Simon,
> 
> On Tue, May 07, 2019 at 08:16:07PM +0200, Simon Goldschmidt wrote:
>>
>>
>> On 07.05.19 19:25, Andreas Dannenberg wrote:
>>> Introduce a framework that allows loading the System Firmware (SYSFW)
>>> binary as well as the associated configuration data from an image tree
>>> blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
>>> RAW mode partition or sector.
>>>
>>> To simplify the handling of and loading from the different boot media
>>> we tap into the existing U-Boot SPL framework usually used for loading
>>> U-Boot by building on an earlier commit that exposes some of that
>>> functionality.
>>>
>>> Note that this initial implementation only supports FS and RAW-based
>>> eMMC/SD card boot.
>>>
>>> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>
>> Without having a too deep understanding of this, all this stuff looks like
>> it would be similar to drivers/misc/fs_loader.c?
>>
>> Could it build on top of that?
> 
> Yes and no. Can you please review the associated cover letter, it
> addresses this very question which I expected to get raised.

Ah, ok. Indeed I seemed to skip those lines when reading the cover 
letter, sorry.

Regards,
Simon

> 
> Thanks,
> Andreas
> 
>>
>> Regards,
>> Simon
>>
>>> ---
>>>    arch/arm/mach-k3/Kconfig                     |  40 +++
>>>    arch/arm/mach-k3/Makefile                    |   1 +
>>>    arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>>>    arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
>>>    4 files changed, 316 insertions(+)
>>>    create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>>>    create mode 100644 arch/arm/mach-k3/sysfw-loader.c
>>>
>>> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
>>> index e677a2e01b..f1731dda58 100644
>>> --- a/arch/arm/mach-k3/Kconfig
>>> +++ b/arch/arm/mach-k3/Kconfig
>>> @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
>>>    	int
>>>    	default 16
>>> +config K3_LOAD_SYSFW
>>> +	bool
>>> +	depends on SPL
>>> +	default n
>>> +
>>> +config K3_SYSFW_IMAGE_NAME
>>> +	string "File name of SYSFW firmware and configuration blob"
>>> +	depends on K3_LOAD_SYSFW
>>> +	default	"sysfw.itb"
>>> +	help
>>> +	  Filename of the combined System Firmware and configuration image tree
>>> +	  blob to be loaded when booting from a filesystem.
>>> +
>>> +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
>>> +	hex "MMC sector to load SYSFW firmware and configuration blob from"
>>> +	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
>>> +	default 0x3600
>>> +	help
>>> +	  Address on the MMC to load the combined System Firmware and
>>> +	  configuration image tree blob from, when the MMC is being used
>>> +	  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
>>> +
>>> +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
>>> +	hex "MMC partition to load SYSFW firmware and configuration blob from"
>>> +	depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
>>> +	default 2
>>> +	help
>>> +	  Partition on the MMC to the combined System Firmware and configuration
>>> +	  image tree blob from, when the MMC is being used in raw mode.
>>> +
>>> +config K3_SYSFW_IMAGE_SIZE_MAX
>>> +	int "Amount of memory dynamically allocated for loading SYSFW blob"
>>> +	depends on K3_LOAD_SYSFW
>>> +	default	269000
>>> +	help
>>> +	  Amount of memory reserved through dynamic allocation at runtime for
>>> +	  loading the combined System Firmware and configuration image tree
>>> +	  blob. Keep it as tight as possible, as this directly affects the
>>> +	  overall SPL memory footprint.
>>> +
>>>    config SYS_K3_SPL_ATF
>>>    	bool "Start Cortex-A from SPL"
>>>    	depends on SPL && CPU_V7R
>>> diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
>>> index 0c3a4f7db1..6c895400c2 100644
>>> --- a/arch/arm/mach-k3/Makefile
>>> +++ b/arch/arm/mach-k3/Makefile
>>> @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
>>>    obj-$(CONFIG_ARM64) += arm64-mmu.o
>>>    obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
>>>    obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
>>> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
>>>    obj-y += common.o
>>> diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h b/arch/arm/mach-k3/include/mach/sysfw-loader.h
>>> new file mode 100644
>>> index 0000000000..36eb265348
>>> --- /dev/null
>>> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
>>> @@ -0,0 +1,12 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>> +/*
>>> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
>>> + *	Andreas Dannenberg <dannenberg@ti.com>
>>> + */
>>> +
>>> +#ifndef _SYSFW_LOADER_H_
>>> +#define _SYSFW_LOADER_H_
>>> +
>>> +void k3_sysfw_loader(void (*config_pm_done_callback)(void));
>>> +
>>> +#endif
>>> diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
>>> new file mode 100644
>>> index 0000000000..a222266c27
>>> --- /dev/null
>>> +++ b/arch/arm/mach-k3/sysfw-loader.c
>>> @@ -0,0 +1,263 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * K3: System Firmware Loader
>>> + *
>>> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
>>> + *	Andreas Dannenberg <dannenberg@ti.com>
>>> + */
>>> +
>>> +#include <common.h>
>>> +#include <spl.h>
>>> +#include <malloc.h>
>>> +#include <remoteproc.h>
>>> +#include <linux/soc/ti/ti_sci_protocol.h>
>>> +#include <asm/arch/sys_proto.h>
>>> +
>>> +/* Name of the FIT image nodes for SYSFW and its config data */
>>> +#define SYSFW_FIRMWARE			"sysfw.bin"
>>> +#define SYSFW_CFG_BOARD			"board-cfg.bin"
>>> +#define SYSFW_CFG_PM			"pm-cfg.bin"
>>> +#define SYSFW_CFG_RM			"rm-cfg.bin"
>>> +#define SYSFW_CFG_SEC			"sec-cfg.bin"
>>> +
>>> +#ifdef CONFIG_SPL_BUILD
>>> +
>>> +static bool sysfw_loaded;
>>> +static void *sysfw_load_address;
>>> +
>>> +/*
>>> + * Populate SPL hook to override the default load address used by the SPL
>>> + * loader function with a custom address for SYSFW loading.
>>> + */
>>> +struct image_header *spl_get_load_buffer(ssize_t offset, size_t size)
>>> +{
>>> +	if (sysfw_loaded)
>>> +		return (struct image_header *)(CONFIG_SYS_TEXT_BASE + offset);
>>> +	else if (sysfw_load_address)
>>> +		return sysfw_load_address;
>>> +	else
>>> +		panic("SYSFW load address not defined!");
>>> +}
>>> +
>>> +/*
>>> + * Populate SPL hook to skip the default SPL loader FIT post-processing steps
>>> + * during SYSFW loading and return to the calling function so we can perform
>>> + * our own custom processing.
>>> + */
>>> +bool spl_load_simple_fit_skip_processing(void)
>>> +{
>>> +	return !sysfw_loaded;
>>> +}
>>> +
>>> +static int fit_get_data_by_name(const void *fit, int images, const char *name,
>>> +				const void **addr, size_t *size)
>>> +{
>>> +	int node_offset;
>>> +
>>> +	node_offset = fdt_subnode_offset(fit, images, name);
>>> +	if (node_offset < 0)
>>> +		return -ENOENT;
>>> +
>>> +	return fit_image_get_data(fit, node_offset, addr, size);
>>> +}
>>> +
>>> +static void k3_sysfw_load_using_fit(void *fit)
>>> +{
>>> +	int images;
>>> +	const void *sysfw_addr;
>>> +	size_t sysfw_size;
>>> +	int ret;
>>> +
>>> +	/* Find the node holding the images information */
>>> +	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
>>> +	if (images < 0)
>>> +		panic("Cannot find /images node (%d)\n", images);
>>> +
>>> +	/* Extract System Firmware (SYSFW) image from FIT */
>>> +	ret = fit_get_data_by_name(fit, images, SYSFW_FIRMWARE,
>>> +				   &sysfw_addr, &sysfw_size);
>>> +	if (ret < 0)
>>> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_FIRMWARE,
>>> +		      ret);
>>> +
>>> +	/*
>>> +	 * Start up system controller firmware
>>> +	 *
>>> +	 * It is assumed that remoteproc device 0 is the corresponding
>>> +	 * system-controller that runs SYSFW. Make sure DT reflects the same.
>>> +	 */
>>> +	ret = rproc_dev_init(0);
>>> +	if (ret)
>>> +		panic("rproc failed to be initialized (%d)\n", ret);
>>> +
>>> +	ret = rproc_load(0, (ulong)sysfw_addr, (ulong)sysfw_size);
>>> +	if (ret)
>>> +		panic("Firmware failed to start on rproc (%d)\n", ret);
>>> +
>>> +	ret = rproc_start(0);
>>> +	if (ret)
>>> +		panic("Firmware init failed on rproc (%d)\n", ret);
>>> +}
>>> +
>>> +static void k3_sysfw_configure_using_fit(void *fit,
>>> +					 struct ti_sci_handle *ti_sci)
>>> +{
>>> +	struct ti_sci_board_ops *board_ops = &ti_sci->ops.board_ops;
>>> +	int images;
>>> +	const void *cfg_fragment_addr;
>>> +	size_t cfg_fragment_size;
>>> +	int ret;
>>> +
>>> +	/* Find the node holding the images information */
>>> +	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
>>> +	if (images < 0)
>>> +		panic("Cannot find /images node (%d)\n", images);
>>> +
>>> +	/* Extract board configuration from FIT */
>>> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_BOARD,
>>> +				   &cfg_fragment_addr, &cfg_fragment_size);
>>> +	if (ret < 0)
>>> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_BOARD,
>>> +		      ret);
>>> +
>>> +	/* Apply board configuration to SYSFW */
>>> +	ret = board_ops->board_config(ti_sci,
>>> +				      (u64)(u32)cfg_fragment_addr,
>>> +				      (u32)cfg_fragment_size);
>>> +	if (ret)
>>> +		panic("Failed to set board configuration (%d)\n", ret);
>>> +
>>> +	/* Extract power/clock (PM) specific configuration from FIT */
>>> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_PM,
>>> +				   &cfg_fragment_addr, &cfg_fragment_size);
>>> +	if (ret < 0)
>>> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_PM,
>>> +		      ret);
>>> +
>>> +	/* Apply power/clock (PM) specific configuration to SYSFW */
>>> +	ret = board_ops->board_config_pm(ti_sci,
>>> +					 (u64)(u32)cfg_fragment_addr,
>>> +					 (u32)cfg_fragment_size);
>>> +	if (ret)
>>> +		panic("Failed to set board PM configuration (%d)\n", ret);
>>> +
>>> +	/* Extract resource management (RM) specific configuration from FIT */
>>> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
>>> +				   &cfg_fragment_addr, &cfg_fragment_size);
>>> +	if (ret < 0)
>>> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_RM,
>>> +		      ret);
>>> +
>>> +	/* Apply resource management (RM) configuration to SYSFW */
>>> +	ret = board_ops->board_config_rm(ti_sci,
>>> +					 (u64)(u32)cfg_fragment_addr,
>>> +					 (u32)cfg_fragment_size);
>>> +	if (ret)
>>> +		panic("Failed to set board RM configuration (%d)\n", ret);
>>> +
>>> +	/* Extract security specific configuration from FIT */
>>> +	ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
>>> +				   &cfg_fragment_addr, &cfg_fragment_size);
>>> +	if (ret < 0)
>>> +		panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_SEC,
>>> +		      ret);
>>> +
>>> +	/* Apply security configuration to SYSFW */
>>> +	ret = board_ops->board_config_security(ti_sci,
>>> +					       (u64)(u32)cfg_fragment_addr,
>>> +					       (u32)cfg_fragment_size);
>>> +	if (ret)
>>> +		panic("Failed to set board security configuration (%d)\n",
>>> +		      ret);
>>> +}
>>> +
>>> +void k3_sysfw_loader(void (*config_pm_done_callback)(void))
>>> +{
>>> +	struct spl_image_info spl_image = { 0 };
>>> +	struct spl_boot_device bootdev = { 0 };
>>> +	struct ti_sci_handle *ti_sci;
>>> +	int ret;
>>> +
>>> +	/* Reserve a block of aligned memory for loading the SYSFW image */
>>> +	sysfw_load_address = memalign(ARCH_DMA_MINALIGN,
>>> +				      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
>>> +	if (!sysfw_load_address)
>>> +		panic("Error allocating %u bytes of memory for SYSFW image\n",
>>> +		      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
>>> +
>>> +	debug("%s: allocated %u bytes at 0x%p\n", __func__,
>>> +	      CONFIG_K3_SYSFW_IMAGE_SIZE_MAX, sysfw_load_address);
>>> +
>>> +	/* Set load address for legacy modes that bypass spl_get_load_buffer */
>>> +	spl_image.load_addr = (uintptr_t)sysfw_load_address;
>>> +
>>> +	bootdev.boot_device = spl_boot_device();
>>> +
>>> +	/* Load combined System Controller firmware and config data image */
>>> +	switch (bootdev.boot_device) {
>>> +#if CONFIG_IS_ENABLED(MMC_SUPPORT)
>>> +	case BOOT_DEVICE_MMC1:
>>> +	case BOOT_DEVICE_MMC2:
>>> +	case BOOT_DEVICE_MMC2_2:
>>> +		ret = spl_mmc_load(&spl_image, &bootdev,
>>> +#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
>>> +				   CONFIG_K3_SYSFW_IMAGE_NAME,
>>> +#else
>>> +				   NULL,
>>> +#endif
>>> +#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART
>>> +				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART,
>>> +#else
>>> +				   0,
>>> +#endif
>>> +#ifdef CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT
>>> +				   CONFIG_K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT);
>>> +#else
>>> +				   0);
>>> +#endif
>>> +		break;
>>> +#endif
>>> +	default:
>>> +		panic("Loading SYSFW image from device %u not supported!\n",
>>> +		      bootdev.boot_device);
>>> +	}
>>> +
>>> +	if (ret)
>>> +		panic("Error %d occurred during loading SYSFW image!\n", ret);
>>> +
>>> +	/*
>>> +	 * Now that SYSFW got loaded set helper flag to restore regular SPL
>>> +	 * loader behavior so we can later boot into the next stage as expected.
>>> +	 */
>>> +	sysfw_loaded = true;
>>> +
>>> +	/* Ensure the SYSFW image is in FIT format */
>>> +	if (image_get_magic((const image_header_t *)sysfw_load_address) !=
>>> +	    FDT_MAGIC)
>>> +		panic("SYSFW image not in FIT format!\n");
>>> +
>>> +	/* Extract and start SYSFW */
>>> +	k3_sysfw_load_using_fit(sysfw_load_address);
>>> +
>>> +	/* Get handle for accessing SYSFW services */
>>> +	ti_sci = get_ti_sci_handle();
>>> +
>>> +	/* Parse and apply the different SYSFW configuration fragments */
>>> +	k3_sysfw_configure_using_fit(sysfw_load_address, ti_sci);
>>> +
>>> +	/*
>>> +	 * Now that all clocks and PM aspects are setup, invoke a user-
>>> +	 * provided callback function. Usually this callback would be used
>>> +	 * to setup or re-configure the U-Boot console UART.
>>> +	 */
>>> +	if (config_pm_done_callback)
>>> +		config_pm_done_callback();
>>> +
>>> +	/* Output System Firmware version info */
>>> +	printf("SYSFW ABI: %d.%d (firmware rev 0x%04x '%.*s')\n",
>>> +	       ti_sci->version.abi_major, ti_sci->version.abi_minor,
>>> +	       ti_sci->version.firmware_revision,
>>> +	       sizeof(ti_sci->version.firmware_description),
>>> +	       ti_sci->version.firmware_description);
>>> +}
>>> +#endif
>>>

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Simon Goldschmidt]

On 07.05.19 19:25, Andreas Dannenberg wrote:
> TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> firmware called SYSFW (System Firmware) being loaded into the dedicated
> DMSC (Device Management and Security Controller) processor to provide
> various services via TISCI (Texas Instruments System Control Interface)
> to manage device aspects such as core bringup, power, clocks, security,
> and so on across the entire SoC.
> 
> Currently public U-Boot does not boot on an actual AM654x EVM due to
> the missing loading and startup of SYSFW, with this being the only piece
> missing preventing a successful boot from SD/MMC-type media. This gap
> is addressed with this patch series.
> 
> Note that the loading and starting of SYSFW is done in the context of
> board_init_f() in SPL which poses some unique challenges due to the very
> constrained nature of this environment (minimal amount of SRAM, no DDR
> yet available).
> 
> In order to be as lean as possible on resource use an approach was chosen
> that extends the existing SPL loader framework to be usable beyond the
> usual "loading U-Boot" use case. While this patch series only makes
> changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS-
> and sector/partition-based RAW boot at this time we have this solution
> in production today but extended to SPI/OSPI and Y-Modem without any
> issues.
> 
> While I also have a working solution based on the existing FS loader
> framework this has its own challenges, namely by its very nature only
> addressing a subset of our use cases (no eMMC/SD RAW boot support for
> example), being heavier on resource usage (needing to use ENV to pass
> parameters), and not addressing the need to probe the boot peripheral.
> This particular framework works well for use cases requiring to load
> firmware from FS-based media once DDR is up and U-Boot is in a more
> "initialized" state but it is not a one-fits all solution for very
> early use in SPL board_init_f() accross different boot modes.

And would it be an option to improve the loader (maybe dropping the "fs" 
from its name)? I think it's an "fs" loader because its idea has been 
copied from Linux. I think in U-Boot, it's more common to have things at 
a raw offset instead of a file system. Just thinking...

And the current state of that fs_loader is like it is because it fits 
its single user (socfpga stratix 10), I think.

Anyway, even if you do need yet another loader, would it make sense to 
create a common file instead of adding this in your arch/mach?

Regards,
Simon

> 
> 
> Andreas Dannenberg (10):
>    mmc: k3_arasan: Allow driver to probe without PDs specified
>    spl: Allow skipping clearing BSS during relocation
>    spl: Make image loader infrastructure more universal
>    arm: K3: Introduce System Firmware loader framework
>    armV7R: K3: am654: Allow using SPL BSS pre-relocation
>    armv7R: K3: am654: Use full malloc implementation in SPL
>    armV7R: K3: am654: Load SYSFW binary and config from boot media
>    configs: am65x_evm_r5: All sysfw to be loaded via MMC
>    configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
>    configs: am65x_hs_evm: Add Support for eMMC boot
> 
> Faiz Abbas (2):
>    configs: am65x_evm: Add Support for eMMC boot
>    am65x: README: Add eMMC layout and flash instructions
> 
> Lokesh Vutla (1):
>    armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
> 
>   arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
>   arch/arm/lib/crt0.S                          |   3 +
>   arch/arm/mach-k3/Kconfig                     |  40 +++
>   arch/arm/mach-k3/Makefile                    |   1 +
>   arch/arm/mach-k3/am6_init.c                  |  34 ++-
>   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>   arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
>   board/ti/am65x/Kconfig                       |   1 +
>   board/ti/am65x/README                        |  52 ++++
>   common/spl/Kconfig                           |  13 +
>   common/spl/spl_fit.c                         |  14 +
>   common/spl/spl_mmc.c                         |  76 ++++--
>   configs/am65x_evm_a53_defconfig              |   2 +
>   configs/am65x_evm_r5_defconfig               |   7 +-
>   configs/am65x_hs_evm_a53_defconfig           |   2 +
>   configs/am65x_hs_evm_r5_defconfig            |   7 +-
>   drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
>   include/configs/am65x_evm.h                  |  30 ++-
>   include/spl.h                                |  26 ++
>   19 files changed, 577 insertions(+), 40 deletions(-)
>   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> 

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Chee, Tien Fong]

On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
> 
> On 07.05.19 19:25, Andreas Dannenberg wrote:
> > 
[...]
> > 
> > While I also have a working solution based on the existing FS
> > loader
> > framework this has its own challenges, namely by its very nature
> > only
> > addressing a subset of our use cases (no eMMC/SD RAW boot support
> > for
> > example), 

IMO, it's actually not that hard to enhance RAW support, i think
minimal changes are required. I have attached the patches about an
example of loading RAW from QSPI that i have done locally last few week
ago.

> > being heavier on resource usage (needing to use ENV to pass
> > parameters),

ENV is optional, you can use DTS. For example loading FPGA bitstream
from QSPI RAW:

/* DTS */
/ {
+	aliases {
+		spi0 = &qspi;
+	};
+
+	fs_loader0: fs-loader {
+		u-boot,dm-pre-reloc;
+		compatible = "u-boot,fs-loader";
+		sfconfig = <0 0 100000000 3>;
+	};
+};
+
+&fpga_mgr {
+	u-boot,dm-pre-reloc;
+	firmware-loader = <&fs_loader0>;
+	altr,bitstream = "300000";
+};

> > and not addressing the need to probe the boot peripheral.

You can add more different probing method in function called
"fs_loader_probe". Current fs_loader supports block(sdmmc, emmc, etc...) probing, and with
the patches attached support QSPI probing.

Another idea come to mind, we can use fs_loader for loading FIT boot
image into RAM, and boot from RAM with existing SPL loader framework,
but i'm not sure this implementation fit to your use case?

> > This particular framework works well for use cases requiring to
> > load
> > firmware from FS-based media once DDR is up and U-Boot is in a more
> > "initialized" state but it is not a one-fits all solution for very
> > early use in SPL board_init_f() accross different boot modes.
> And would it be an option to improve the loader (maybe dropping the
> "fs" 
> from its name)? I think it's an "fs" loader because its idea has
> been 
> copied from Linux. I think in U-Boot, it's more common to have things
> at 
> a raw offset instead of a file system. Just thinking...

Current fs_loader only support filesystem, and i agree that it made
sense to remove the "fs" once it supports the RAW offset as well.

Thanks.

Regards,
TF

> 
> And the current state of that fs_loader is like it is because it
> fits 
> its single user (socfpga stratix 10), I think.
> 
> Anyway, even if you do need yet another loader, would it make sense
> to 
> create a common file instead of adding this in your arch/mach?
> 
> Regards,
> Simon
> 
> > 
> > 
> > Andreas Dannenberg (10):
> >    mmc: k3_arasan: Allow driver to probe without PDs specified
> >    spl: Allow skipping clearing BSS during relocation
> >    spl: Make image loader infrastructure more universal
> >    arm: K3: Introduce System Firmware loader framework
> >    armV7R: K3: am654: Allow using SPL BSS pre-relocation
> >    armv7R: K3: am654: Use full malloc implementation in SPL
> >    armV7R: K3: am654: Load SYSFW binary and config from boot media
> >    configs: am65x_evm_r5: All sysfw to be loaded via MMC
> >    configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
> >    configs: am65x_hs_evm: Add Support for eMMC boot
> > 
> > Faiz Abbas (2):
> >    configs: am65x_evm: Add Support for eMMC boot
> >    am65x: README: Add eMMC layout and flash instructions
> > 
> > Lokesh Vutla (1):
> >    armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
> > 
> >   arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
> >   arch/arm/lib/crt0.S                          |   3 +
> >   arch/arm/mach-k3/Kconfig                     |  40 +++
> >   arch/arm/mach-k3/Makefile                    |   1 +
> >   arch/arm/mach-k3/am6_init.c                  |  34 ++-
> >   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
> >   arch/arm/mach-k3/sysfw-loader.c              | 263
> > +++++++++++++++++++
> >   board/ti/am65x/Kconfig                       |   1 +
> >   board/ti/am65x/README                        |  52 ++++
> >   common/spl/Kconfig                           |  13 +
> >   common/spl/spl_fit.c                         |  14 +
> >   common/spl/spl_mmc.c                         |  76 ++++--
> >   configs/am65x_evm_a53_defconfig              |   2 +
> >   configs/am65x_evm_r5_defconfig               |   7 +-
> >   configs/am65x_hs_evm_a53_defconfig           |   2 +
> >   configs/am65x_hs_evm_r5_defconfig            |   7 +-
> >   drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
> >   include/configs/am65x_evm.h                  |  30 ++-
> >   include/spl.h                                |  26 ++
> >   19 files changed, 577 insertions(+), 40 deletions(-)
> >   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
> >   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-misc-fs_loader-Add-QSPI-RAW-partition-loading-suppor.patch
Type: text/x-patch
Size: 6758 bytes
Desc: 0001-misc-fs_loader-Add-QSPI-RAW-partition-loading-suppor.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/9d780f88/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-ARM-dts-socfpga-Add-dts-support-for-QSPI-Arria-10-So.patch
Type: text/x-patch
Size: 19097 bytes
Desc: 0004-ARM-dts-socfpga-Add-dts-support-for-QSPI-Arria-10-So.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/9d780f88/attachment-0001.bin>

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Andreas Dannenberg]

Hi Simon,
comments inlined...

On Tue, May 07, 2019 at 10:00:03PM +0200, Simon Goldschmidt wrote:
> 
> 
> On 07.05.19 19:25, Andreas Dannenberg wrote:
> > TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> > firmware called SYSFW (System Firmware) being loaded into the dedicated
> > DMSC (Device Management and Security Controller) processor to provide
> > various services via TISCI (Texas Instruments System Control Interface)
> > to manage device aspects such as core bringup, power, clocks, security,
> > and so on across the entire SoC.
> > 
> > Currently public U-Boot does not boot on an actual AM654x EVM due to
> > the missing loading and startup of SYSFW, with this being the only piece
> > missing preventing a successful boot from SD/MMC-type media. This gap
> > is addressed with this patch series.
> > 
> > Note that the loading and starting of SYSFW is done in the context of
> > board_init_f() in SPL which poses some unique challenges due to the very
> > constrained nature of this environment (minimal amount of SRAM, no DDR
> > yet available).
> > 
> > In order to be as lean as possible on resource use an approach was chosen
> > that extends the existing SPL loader framework to be usable beyond the
> > usual "loading U-Boot" use case. While this patch series only makes
> > changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS-
> > and sector/partition-based RAW boot at this time we have this solution
> > in production today but extended to SPI/OSPI and Y-Modem without any
> > issues.
> > 
> > While I also have a working solution based on the existing FS loader
> > framework this has its own challenges, namely by its very nature only
> > addressing a subset of our use cases (no eMMC/SD RAW boot support for
> > example), being heavier on resource usage (needing to use ENV to pass
> > parameters), and not addressing the need to probe the boot peripheral.
> > This particular framework works well for use cases requiring to load
> > firmware from FS-based media once DDR is up and U-Boot is in a more
> > "initialized" state but it is not a one-fits all solution for very
> > early use in SPL board_init_f() accross different boot modes.
> 
> And would it be an option to improve the loader (maybe dropping the "fs"
> from its name)? I think it's an "fs" loader because its idea has been copied
> from Linux. I think in U-Boot, it's more common to have things at a raw
> offset instead of a file system. Just thinking...

Agreed this can be refactored and extended and would be useful - except for
some very memory-constrained situations, see below.

> 
> And the current state of that fs_loader is like it is because it fits its
> single user (socfpga stratix 10), I think.

What I needed was something very small as even with the here proposed
solution that heavily re-uses SPL loader code there is only about 61KB
left at the moment in the SRAM memory region SPL executes from, and some
of that 61KB will be used by the stack, and some will be used by other
features still needing to get added to the SPL image unrelated to the
loader functionality under discussion. So space is super tight, and
literally every KB counts. I wish the environment was less constrained
from a memory POV...

> Anyway, even if you do need yet another loader, would it make sense to
> create a common file instead of adding this in your arch/mach?

Be careful not to be mislead from what I'm actually proposing here:

1) A method to load, start (via rproc) and configure the TI K3 System
   Firmware with the patch "arm: K3: Introduce System Firmware loader
   framework" under arch/mach. You can review this patch, 95% of this
   code is only applicable to TI K3 devices, and not any other device,
   platform, or vendor. The actual "loading" part you are concerned with
   is nothing more than a single call over to spl_mmc_load() located
   in the SPL framework. So the logical place for the "SYSFW Loader" is
   said arm/mach location.

2) A method to re-use most/all of the SPL loader code including
   peripheral init/probe functionality most commonly used for only
   loading U-Boot by exposing the core loader functions as an API.
   For MMC/SD, this is introduced with the patch "spl: Make image loader
   infrastructure more universal" and doesn't really add any code
   at all. This has the advantage of minimizing memory footprint and code
   duplication (FS loader replicates some of what the SPL loader does,
   and even more so if extended). I argue this method of opening up
   the SPL loader is actually orthogonal to the current FS loader
   framework, and the FS loader framework could as well tap into the
   SPL loader code as well as it extends and grows to avoid duplication.


--
Andreas Dannenberg
Texas Instruments Inc


> 
> Regards,
> Simon
> 
> > 
> > 
> > Andreas Dannenberg (10):
> >    mmc: k3_arasan: Allow driver to probe without PDs specified
> >    spl: Allow skipping clearing BSS during relocation
> >    spl: Make image loader infrastructure more universal
> >    arm: K3: Introduce System Firmware loader framework
> >    armV7R: K3: am654: Allow using SPL BSS pre-relocation
> >    armv7R: K3: am654: Use full malloc implementation in SPL
> >    armV7R: K3: am654: Load SYSFW binary and config from boot media
> >    configs: am65x_evm_r5: All sysfw to be loaded via MMC
> >    configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
> >    configs: am65x_hs_evm: Add Support for eMMC boot
> > 
> > Faiz Abbas (2):
> >    configs: am65x_evm: Add Support for eMMC boot
> >    am65x: README: Add eMMC layout and flash instructions
> > 
> > Lokesh Vutla (1):
> >    armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
> > 
> >   arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
> >   arch/arm/lib/crt0.S                          |   3 +
> >   arch/arm/mach-k3/Kconfig                     |  40 +++
> >   arch/arm/mach-k3/Makefile                    |   1 +
> >   arch/arm/mach-k3/am6_init.c                  |  34 ++-
> >   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
> >   arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
> >   board/ti/am65x/Kconfig                       |   1 +
> >   board/ti/am65x/README                        |  52 ++++
> >   common/spl/Kconfig                           |  13 +
> >   common/spl/spl_fit.c                         |  14 +
> >   common/spl/spl_mmc.c                         |  76 ++++--
> >   configs/am65x_evm_a53_defconfig              |   2 +
> >   configs/am65x_evm_r5_defconfig               |   7 +-
> >   configs/am65x_hs_evm_a53_defconfig           |   2 +
> >   configs/am65x_hs_evm_r5_defconfig            |   7 +-
> >   drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
> >   include/configs/am65x_evm.h                  |  30 ++-
> >   include/spl.h                                |  26 ++
> >   19 files changed, 577 insertions(+), 40 deletions(-)
> >   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
> >   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> > 

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[dannenberg at ti.com]

Hi TF,
thanks for chiming in. Comments inlined...

On Wed, May 08, 2019 at 04:31:35AM +0000, Chee, Tien Fong wrote:
> On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
> > 
> > On 07.05.19 19:25, Andreas Dannenberg wrote:
> > > 
> [...]
> > > 
> > > While I also have a working solution based on the existing FS
> > > loader
> > > framework this has its own challenges, namely by its very nature
> > > only
> > > addressing a subset of our use cases (no eMMC/SD RAW boot support
> > > for
> > > example), 
> 
> IMO, it's actually not that hard to enhance RAW support, i think
> minimal changes are required. I have attached the patches about an
> example of loading RAW from QSPI that i have done locally last few week
> ago.

As your patches show, no it's not hard, it's more or less taking pieces
from the SPL loader framework and refactoring them into the FS loader,
creating a good and universal solution usable across SPL and U-Boot in
environments that are not tightly constrained in terms of memory.

What I was going after is finding a way to load from different media
"pre-relocation" SPL (board_init_f), with almost no memory available,
where I have to agonize over every single KB available.

> > > being heavier on resource usage (needing to use ENV to pass
> > > parameters),
> 
> ENV is optional, you can use DTS.

Is it? I had to update the FS loader framework when I experimented with
it, please see attached patch. I had refactored it such that I can pass
in all relevant data via platform data for the intial boot mode I was
going after, so that I can dynamically configure it on the fly from
early SPL board_init_f() based on boot media / boot mode, etc.

> For example loading FPGA bitstream from QSPI RAW:
> 
> /* DTS */
> / {
> +	aliases {
> +		spi0 = &qspi;
> +	};
> +
> +	fs_loader0: fs-loader {
> +		u-boot,dm-pre-reloc;
> +		compatible = "u-boot,fs-loader";
> +		sfconfig = <0 0 100000000 3>;
> +	};
> +};
> +
> +&fpga_mgr {
> +	u-boot,dm-pre-reloc;
> +	firmware-loader = <&fs_loader0>;
> +	altr,bitstream = "300000";
> +};

The above hard-codes and duplicates information that is already known to
U-Boot (CONFIG_SF_DEFAULT_*), and will do more of the same as this is
being extended. How does one keep this consistent?

And how does this scale to support like 5 different boot modes using a
single DTB? I guess one  could populate 5 nodes, and then pick one based
on boot mode during SPL execution, by extending the probe function
accordingly.

> 
> > > and not addressing the need to probe the boot peripheral.
> 
> You can add more different probing method in function called
> "fs_loader_probe". Current fs_loader supports block(sdmmc, emmc, etc...) probing, and with
> the patches attached support QSPI probing.
> 
> Another idea come to mind, we can use fs_loader for loading FIT boot
> image into RAM, and boot from RAM with existing SPL loader framework,
> but i'm not sure this implementation fit to your use case?

Unfortunately for what I'm working on there is no space for this. It
would be nice to be able to load our "System Firmware" alongside the
next stage of U-Boot in a single FIT, and then just extact that firmware
image similar to what CONFIG_SPL_FPGA_SUPPORT does in spl_fit.c. 
However I must load SYSFW and the U-Boot next stage as two steps
(while bringing up DDR in-between....).

As I tried to explain in my earlier email to Simon, I almost see the
minimally-intrusive extensions I did to the SPL loader framework via
"spl: Make image loader infrastructure more universal" and the FS loader
framework to be elements that are orthogonal and can both exist. Maybe
FS loader can partially build upon the SPL loader foundation as well?

--
Andreas Dannenberg
Texas Instruments Inc


> 
> > > This particular framework works well for use cases requiring to
> > > load
> > > firmware from FS-based media once DDR is up and U-Boot is in a more
> > > "initialized" state but it is not a one-fits all solution for very
> > > early use in SPL board_init_f() accross different boot modes.
> > And would it be an option to improve the loader (maybe dropping the
> > "fs" 
> > from its name)? I think it's an "fs" loader because its idea has
> > been 
> > copied from Linux. I think in U-Boot, it's more common to have things
> > at 
> > a raw offset instead of a file system. Just thinking...
> 
> Current fs_loader only support filesystem, and i agree that it made
> sense to remove the "fs" once it supports the RAW offset as well.
> 
> Thanks.
> 
> Regards,
> TF
> 
> > 
> > And the current state of that fs_loader is like it is because it
> > fits 
> > its single user (socfpga stratix 10), I think.
> > 
> > Anyway, even if you do need yet another loader, would it make sense
> > to 
> > create a common file instead of adding this in your arch/mach?
> > 
> > Regards,
> > Simon
> > 
> > > 
> > > 
> > > Andreas Dannenberg (10):
> > >    mmc: k3_arasan: Allow driver to probe without PDs specified
> > >    spl: Allow skipping clearing BSS during relocation
> > >    spl: Make image loader infrastructure more universal
> > >    arm: K3: Introduce System Firmware loader framework
> > >    armV7R: K3: am654: Allow using SPL BSS pre-relocation
> > >    armv7R: K3: am654: Use full malloc implementation in SPL
> > >    armV7R: K3: am654: Load SYSFW binary and config from boot media
> > >    configs: am65x_evm_r5: All sysfw to be loaded via MMC
> > >    configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
> > >    configs: am65x_hs_evm: Add Support for eMMC boot
> > > 
> > > Faiz Abbas (2):
> > >    configs: am65x_evm: Add Support for eMMC boot
> > >    am65x: README: Add eMMC layout and flash instructions
> > > 
> > > Lokesh Vutla (1):
> > >    armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
> > > 
> > >   arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
> > >   arch/arm/lib/crt0.S                          |   3 +
> > >   arch/arm/mach-k3/Kconfig                     |  40 +++
> > >   arch/arm/mach-k3/Makefile                    |   1 +
> > >   arch/arm/mach-k3/am6_init.c                  |  34 ++-
> > >   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
> > >   arch/arm/mach-k3/sysfw-loader.c              | 263
> > > +++++++++++++++++++
> > >   board/ti/am65x/Kconfig                       |   1 +
> > >   board/ti/am65x/README                        |  52 ++++
> > >   common/spl/Kconfig                           |  13 +
> > >   common/spl/spl_fit.c                         |  14 +
> > >   common/spl/spl_mmc.c                         |  76 ++++--
> > >   configs/am65x_evm_a53_defconfig              |   2 +
> > >   configs/am65x_evm_r5_defconfig               |   7 +-
> > >   configs/am65x_hs_evm_a53_defconfig           |   2 +
> > >   configs/am65x_hs_evm_r5_defconfig            |   7 +-
> > >   drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
> > >   include/configs/am65x_evm.h                  |  30 ++-
> > >   include/spl.h                                |  26 ++
> > >   19 files changed, 577 insertions(+), 40 deletions(-)
> > >   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
> > >   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> > > 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-misc-fs_loader-Allow-initializing-blkdev-using-platf.patch
Type: text/x-diff
Size: 2922 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/1e439629/attachment.patch>

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Simon Goldschmidt]

Am 08.05.2019 um 20:04 schrieb Andreas Dannenberg:
> Hi Simon,
> comments inlined...
> 
> On Tue, May 07, 2019 at 10:00:03PM +0200, Simon Goldschmidt wrote:
>>
>>
>> On 07.05.19 19:25, Andreas Dannenberg wrote:
>>> TI K3 SoCs like the AM654x devices are fundamentally dependent on a
>>> firmware called SYSFW (System Firmware) being loaded into the dedicated
>>> DMSC (Device Management and Security Controller) processor to provide
>>> various services via TISCI (Texas Instruments System Control Interface)
>>> to manage device aspects such as core bringup, power, clocks, security,
>>> and so on across the entire SoC.
>>>
>>> Currently public U-Boot does not boot on an actual AM654x EVM due to
>>> the missing loading and startup of SYSFW, with this being the only piece
>>> missing preventing a successful boot from SD/MMC-type media. This gap
>>> is addressed with this patch series.
>>>
>>> Note that the loading and starting of SYSFW is done in the context of
>>> board_init_f() in SPL which poses some unique challenges due to the very
>>> constrained nature of this environment (minimal amount of SRAM, no DDR
>>> yet available).
>>>
>>> In order to be as lean as possible on resource use an approach was chosen
>>> that extends the existing SPL loader framework to be usable beyond the
>>> usual "loading U-Boot" use case. While this patch series only makes
>>> changes to the MMC/SD card loader framework to support eMMC/MMC/SD FS-
>>> and sector/partition-based RAW boot at this time we have this solution
>>> in production today but extended to SPI/OSPI and Y-Modem without any
>>> issues.
>>>
>>> While I also have a working solution based on the existing FS loader
>>> framework this has its own challenges, namely by its very nature only
>>> addressing a subset of our use cases (no eMMC/SD RAW boot support for
>>> example), being heavier on resource usage (needing to use ENV to pass
>>> parameters), and not addressing the need to probe the boot peripheral.
>>> This particular framework works well for use cases requiring to load
>>> firmware from FS-based media once DDR is up and U-Boot is in a more
>>> "initialized" state but it is not a one-fits all solution for very
>>> early use in SPL board_init_f() accross different boot modes.
>>
>> And would it be an option to improve the loader (maybe dropping the "fs"
>> from its name)? I think it's an "fs" loader because its idea has been copied
>> from Linux. I think in U-Boot, it's more common to have things at a raw
>> offset instead of a file system. Just thinking...
> 
> Agreed this can be refactored and extended and would be useful - except for
> some very memory-constrained situations, see below.
> 
>>
>> And the current state of that fs_loader is like it is because it fits its
>> single user (socfpga stratix 10), I think.
> 
> What I needed was something very small as even with the here proposed
> solution that heavily re-uses SPL loader code there is only about 61KB
> left at the moment in the SRAM memory region SPL executes from, and some
> of that 61KB will be used by the stack, and some will be used by other
> features still needing to get added to the SPL image unrelated to the
> loader functionality under discussion. So space is super tight, and
> literally every KB counts. I wish the environment was less constrained
> from a memory POV...

I can understand your point on memory usage, but fs_loader started by 
Intel is used in SPL, too. And while they obviously aren't as tight with 
memory there (although I think this is pre DDR, too), I still think we 
should come up with *one* solution, not two.

> 
>> Anyway, even if you do need yet another loader, would it make sense to
>> create a common file instead of adding this in your arch/mach?
> 
> Be careful not to be mislead from what I'm actually proposing here:
> 
> 1) A method to load, start (via rproc) and configure the TI K3 System
>     Firmware with the patch "arm: K3: Introduce System Firmware loader
>     framework" under arch/mach. You can review this patch, 95% of this
>     code is only applicable to TI K3 devices, and not any other device,
>     platform, or vendor. The actual "loading" part you are concerned with
>     is nothing more than a single call over to spl_mmc_load() located
>     in the SPL framework. So the logical place for the "SYSFW Loader" is
>     said arm/mach location.

OK.

> 
> 2) A method to re-use most/all of the SPL loader code including
>     peripheral init/probe functionality most commonly used for only
>     loading U-Boot by exposing the core loader functions as an API.
>     For MMC/SD, this is introduced with the patch "spl: Make image loader
>     infrastructure more universal" and doesn't really add any code
>     at all. This has the advantage of minimizing memory footprint and code
>     duplication (FS loader replicates some of what the SPL loader does,
>     and even more so if extended). I argue this method of opening up
>     the SPL loader is actually orthogonal to the current FS loader
>     framework, and the FS loader framework could as well tap into the
>     SPL loader code as well as it extends and grows to avoid duplication.

You're talking about 3/13 here? I think that's a good approach in 
general. Maybe the actual work left is making fs_loader use these 
loaders in SPL to deduplicate code?

Regards,
Simon

> 
> 
> --
> Andreas Dannenberg
> Texas Instruments Inc
> 
> 
>>
>> Regards,
>> Simon
>>
>>>
>>>
>>> Andreas Dannenberg (10):
>>>     mmc: k3_arasan: Allow driver to probe without PDs specified
>>>     spl: Allow skipping clearing BSS during relocation
>>>     spl: Make image loader infrastructure more universal
>>>     arm: K3: Introduce System Firmware loader framework
>>>     armV7R: K3: am654: Allow using SPL BSS pre-relocation
>>>     armv7R: K3: am654: Use full malloc implementation in SPL
>>>     armV7R: K3: am654: Load SYSFW binary and config from boot media
>>>     configs: am65x_evm_r5: All sysfw to be loaded via MMC
>>>     configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
>>>     configs: am65x_hs_evm: Add Support for eMMC boot
>>>
>>> Faiz Abbas (2):
>>>     configs: am65x_evm: Add Support for eMMC boot
>>>     am65x: README: Add eMMC layout and flash instructions
>>>
>>> Lokesh Vutla (1):
>>>     armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
>>>
>>>    arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
>>>    arch/arm/lib/crt0.S                          |   3 +
>>>    arch/arm/mach-k3/Kconfig                     |  40 +++
>>>    arch/arm/mach-k3/Makefile                    |   1 +
>>>    arch/arm/mach-k3/am6_init.c                  |  34 ++-
>>>    arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
>>>    arch/arm/mach-k3/sysfw-loader.c              | 263 +++++++++++++++++++
>>>    board/ti/am65x/Kconfig                       |   1 +
>>>    board/ti/am65x/README                        |  52 ++++
>>>    common/spl/Kconfig                           |  13 +
>>>    common/spl/spl_fit.c                         |  14 +
>>>    common/spl/spl_mmc.c                         |  76 ++++--
>>>    configs/am65x_evm_a53_defconfig              |   2 +
>>>    configs/am65x_evm_r5_defconfig               |   7 +-
>>>    configs/am65x_hs_evm_a53_defconfig           |   2 +
>>>    configs/am65x_hs_evm_r5_defconfig            |   7 +-
>>>    drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
>>>    include/configs/am65x_evm.h                  |  30 ++-
>>>    include/spl.h                                |  26 ++
>>>    19 files changed, 577 insertions(+), 40 deletions(-)
>>>    create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h
>>>    create mode 100644 arch/arm/mach-k3/sysfw-loader.c
>>>

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Chee, Tien Fong]

On Wed, 2019-05-08 at 13:43 -0500, dannenberg at ti.com wrote:
> Hi TF,
> thanks for chiming in. Comments inlined...
> 
> On Wed, May 08, 2019 at 04:31:35AM +0000, Chee, Tien Fong wrote:
> > 
> > On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
> > > 
> > > 
> > > On 07.05.19 19:25, Andreas Dannenberg wrote:
> > > > 
> > > > 
> > [...]
> > > 
> > > > 
> > > > 
> > > > While I also have a working solution based on the existing FS
> > > > loader
> > > > framework this has its own challenges, namely by its very
> > > > nature
> > > > only
> > > > addressing a subset of our use cases (no eMMC/SD RAW boot
> > > > support
> > > > for
> > > > example), 
> > IMO, it's actually not that hard to enhance RAW support, i think
> > minimal changes are required. I have attached the patches about an
> > example of loading RAW from QSPI that i have done locally last few
> > week
> > ago.
> As your patches show, no it's not hard, it's more or less taking
> pieces
> from the SPL loader framework and refactoring them into the FS
> loader,
> creating a good and universal solution usable across SPL and U-Boot
> in
> environments that are not tightly constrained in terms of memory.
> 
> What I was going after is finding a way to load from different media
> "pre-relocation" SPL (board_init_f), with almost no memory available,
> where I have to agonize over every single KB available.

This is just a simple "loader", provide user flexibility of loading
stuff in anywhere, from SPL to U-Boot. As long as DM is supported by
the time running at "pre-relocation" SPL, then FS loader should be able
to work.

> > 
> > > 
> > > > 
> > > > being heavier on resource usage (needing to use ENV to pass
> > > > parameters),
> > ENV is optional, you can use DTS.
> Is it? I had to update the FS loader framework when I experimented
> with
> it, please see attached patch. I had refactored it such that I can
> pass
> in all relevant data via platform data for the intial boot mode I was
> going after, so that I can dynamically configure it on the fly from
> early SPL board_init_f() based on boot media / boot mode, etc.

Yes, you can tie up loader with target HW node for destination loading.
For example, tie up with FPGA manager node, loading bistream file from
MMC to FPGA manager.

Here is an example, but i put the fs loader phandle under chosen node
because most files and images are stored in the same storage.
http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=0a42a132a4b8
46031df2c4a7d04692240ed34843

> 
> > 
> > For example loading FPGA bitstream from QSPI RAW:
> > 
> > /* DTS */
> > / {
> > +	aliases {
> > +		spi0 = &qspi;
> > +	};
> > +
> > +	fs_loader0: fs-loader {
> > +		u-boot,dm-pre-reloc;
> > +		compatible = "u-boot,fs-loader";
> > +		sfconfig = <0 0 100000000 3>;
> > +	};
> > +};
> > +
> > +&fpga_mgr {
> > +	u-boot,dm-pre-reloc;
> > +	firmware-loader = <&fs_loader0>;
> > +	altr,bitstream = "300000";
> > +};
> The above hard-codes and duplicates information that is already known
> to
> U-Boot (CONFIG_SF_DEFAULT_*), and will do more of the same as this is
> being extended. How does one keep this consistent?

Current fs loader not support RAW loading yet, i'm not sure whether it
should support it by adding more specific storage API(much more messy),
or just fully support filesystem only with one generic filesystem
abstract interface.

This example codes provide user opportunity to override the spi setting
when running fs loader. CONFIG_SF_DEFAULT_* would be used by the
drivers which are not running the fs loader.

> 
> And how does this scale to support like 5 different boot modes using
> a
> single DTB? I guess one  could populate 5 nodes, and then pick one
> based
> on boot mode during SPL execution, by extending the probe function
> accordingly.

This is just a very simple fs loader. This is totally up to user how
they want to scale it up, may be adding the function to populate the fs
loader nodes, or loading the images based on boot storages ordering in
DTS?

> 
> > 
> > 
> > > 
> > > > 
> > > > and not addressing the need to probe the boot peripheral.
> > You can add more different probing method in function called
> > "fs_loader_probe". Current fs_loader supports block(sdmmc, emmc,
> > etc...) probing, and with
> > the patches attached support QSPI probing.
> > 
> > Another idea come to mind, we can use fs_loader for loading FIT
> > boot
> > image into RAM, and boot from RAM with existing SPL loader
> > framework,
> > but i'm not sure this implementation fit to your use case?
> Unfortunately for what I'm working on there is no space for this. It
> would be nice to be able to load our "System Firmware" alongside the
> next stage of U-Boot in a single FIT, and then just extact that
> firmware
> image similar to what CONFIG_SPL_FPGA_SUPPORT does in spl_fit.c. 
> However I must load SYSFW and the U-Boot next stage as two steps
> (while bringing up DDR in-between....).
> 
> As I tried to explain in my earlier email to Simon, I almost see the
> minimally-intrusive extensions I did to the SPL loader framework via
> "spl: Make image loader infrastructure more universal" and the FS
> loader
> framework to be elements that are orthogonal and can both exist.
> Maybe
> FS loader can partially build upon the SPL loader foundation as well?

Yes, fs loader can be in anywhere, it can be part of SPL loader
framework as well. It can be as complement to SPL loader also.

Thanks.

TF.

> 
> --
> Andreas Dannenberg
> Texas Instruments Inc
> 
> 
> > 
> > 
> > > 
> > > > 
> > > > This particular framework works well for use cases requiring to
> > > > load
> > > > firmware from FS-based media once DDR is up and U-Boot is in a
> > > > more
> > > > "initialized" state but it is not a one-fits all solution for
> > > > very
> > > > early use in SPL board_init_f() accross different boot modes.
> > > And would it be an option to improve the loader (maybe dropping
> > > the
> > > "fs" 
> > > from its name)? I think it's an "fs" loader because its idea has
> > > been 
> > > copied from Linux. I think in U-Boot, it's more common to have
> > > things
> > > at 
> > > a raw offset instead of a file system. Just thinking...
> > Current fs_loader only support filesystem, and i agree that it made
> > sense to remove the "fs" once it supports the RAW offset as well.
> > 
> > Thanks.
> > 
> > Regards,
> > TF
> > 
> > > 
> > > 
> > > And the current state of that fs_loader is like it is because it
> > > fits 
> > > its single user (socfpga stratix 10), I think.
> > > 
> > > Anyway, even if you do need yet another loader, would it make
> > > sense
> > > to 
> > > create a common file instead of adding this in your arch/mach?
> > > 
> > > Regards,
> > > Simon
> > > 
> > > > 
> > > > 
> > > > 
> > > > Andreas Dannenberg (10):
> > > >    mmc: k3_arasan: Allow driver to probe without PDs specified
> > > >    spl: Allow skipping clearing BSS during relocation
> > > >    spl: Make image loader infrastructure more universal
> > > >    arm: K3: Introduce System Firmware loader framework
> > > >    armV7R: K3: am654: Allow using SPL BSS pre-relocation
> > > >    armv7R: K3: am654: Use full malloc implementation in SPL
> > > >    armV7R: K3: am654: Load SYSFW binary and config from boot
> > > > media
> > > >    configs: am65x_evm_r5: All sysfw to be loaded via MMC
> > > >    configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
> > > >    configs: am65x_hs_evm: Add Support for eMMC boot
> > > > 
> > > > Faiz Abbas (2):
> > > >    configs: am65x_evm: Add Support for eMMC boot
> > > >    am65x: README: Add eMMC layout and flash instructions
> > > > 
> > > > Lokesh Vutla (1):
> > > >    armv7R: dts: k3: am654: Update mmc nodes for loading sysfw
> > > > 
> > > >   arch/arm/dts/k3-am654-r5-base-board.dts      |  18 ++
> > > >   arch/arm/lib/crt0.S                          |   3 +
> > > >   arch/arm/mach-k3/Kconfig                     |  40 +++
> > > >   arch/arm/mach-k3/Makefile                    |   1 +
> > > >   arch/arm/mach-k3/am6_init.c                  |  34 ++-
> > > >   arch/arm/mach-k3/include/mach/sysfw-loader.h |  12 +
> > > >   arch/arm/mach-k3/sysfw-loader.c              | 263
> > > > +++++++++++++++++++
> > > >   board/ti/am65x/Kconfig                       |   1 +
> > > >   board/ti/am65x/README                        |  52 ++++
> > > >   common/spl/Kconfig                           |  13 +
> > > >   common/spl/spl_fit.c                         |  14 +
> > > >   common/spl/spl_mmc.c                         |  76 ++++--
> > > >   configs/am65x_evm_a53_defconfig              |   2 +
> > > >   configs/am65x_evm_r5_defconfig               |   7 +-
> > > >   configs/am65x_hs_evm_a53_defconfig           |   2 +
> > > >   configs/am65x_hs_evm_r5_defconfig            |   7 +-
> > > >   drivers/mmc/k3_arsan_sdhci.c                 |  16 +-
> > > >   include/configs/am65x_evm.h                  |  30 ++-
> > > >   include/spl.h                                |  26 ++
> > > >   19 files changed, 577 insertions(+), 40 deletions(-)
> > > >   create mode 100644 arch/arm/mach-k3/include/mach/sysfw-
> > > > loader.h
> > > >   create mode 100644 arch/arm/mach-k3/sysfw-loader.c
> > > > 
> 
> 

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Tom Rini]

On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote:

> TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> firmware called SYSFW (System Firmware) being loaded into the dedicated
> DMSC (Device Management and Security Controller) processor to provide
> various services via TISCI (Texas Instruments System Control Interface)
> to manage device aspects such as core bringup, power, clocks, security,
> and so on across the entire SoC.
[snip]
> While I also have a working solution based on the existing FS loader
> framework this has its own challenges, namely by its very nature only
> addressing a subset of our use cases (no eMMC/SD RAW boot support for
> example), being heavier on resource usage (needing to use ENV to pass
> parameters), and not addressing the need to probe the boot peripheral.
> This particular framework works well for use cases requiring to load
> firmware from FS-based media once DDR is up and U-Boot is in a more
> "initialized" state but it is not a one-fits all solution for very
> early use in SPL board_init_f() accross different boot modes.

I think one thing that might help here is to post this alternative
solution and provide the 'size' information for both series.  In
addition, build something like am335x_evm and socfpga_stratix10 for both
series and include their before/after 'size' info too.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/db9abdc8/attachment.sig>

[U-Boot] [PATCH 01/13] mmc: k3_arasan: Allow driver to probe without PDs specified

[Tom Rini]

On Tue, May 07, 2019 at 12:25:30PM -0500, Andreas Dannenberg wrote:

> We would like to use the driver even without power domains being
> specified for cases such as during early boot when the required power
> domains have already gotten enabled by the SoC's boot ROM and such
> explicit initialization is not needed and possible.
> 
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/c8e2c04a/attachment.sig>

[U-Boot] [PATCH 02/13] spl: Allow skipping clearing BSS during relocation

[Tom Rini]

On Tue, May 07, 2019 at 12:25:31PM -0500, Andreas Dannenberg wrote:

> On some platform we have sufficient memory available early on to allow
> setting up and using a basic BSS prior to relocation. In order to be
> able to preserve data written to BSS during early startup add a Kconfig
> option allowing to skip the clearing of the BSS section during setting
> up of the final environment / relocation.
> 
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/a18a695a/attachment.sig>

[U-Boot] [PATCH 03/13] spl: Make image loader infrastructure more universal

[Tom Rini]

On Tue, May 07, 2019 at 12:25:32PM -0500, Andreas Dannenberg wrote:

> The current U-Boot SPL image loader infrastructure is very powerful,
> able to initialize and load from a variety of boot media however it
> is strongly geared towards loading specific types of images in a very
> specific way. To address the need being able to use this infrastructure
> to load arbitrary image files go ahead and refactor it as follows:
> 
> - Refactor existing spl_mmc_load_image function into superset function,
>   accepting additional arguments such as filenames and media load offset
>   (same concept can also be applied toother spl_XXX_load_image functions)
> - Extend the loader function to "remember" their peripheral initialization
>   status so that the init is only done once during the boot process,
> - Extend the FIT image loading function to allow skipping the parsing/
>   processing of the FIT contents (so that this can be done separately
>   in a more customized fashion)
> - Populate the SPL_LOAD_IMAGE_METHOD() list with a trampoline function,
>   invoking the newly refactored superset functions in a way to maintain
>   compatibility with the existing behavior
> 
> This refactoring initially covers MMC/SD card loading (RAW and FS-based).
> 
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/542ebac0/attachment.sig>

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Tom Rini]

On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:

> Introduce a framework that allows loading the System Firmware (SYSFW)
> binary as well as the associated configuration data from an image tree
> blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> RAW mode partition or sector.
> 
> To simplify the handling of and loading from the different boot media
> we tap into the existing U-Boot SPL framework usually used for loading
> U-Boot by building on an earlier commit that exposes some of that
> functionality.
> 
> Note that this initial implementation only supports FS and RAW-based
> eMMC/SD card boot.
[snip]
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index e677a2e01b..f1731dda58 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
>  	int
>  	default 16
>  
> +config K3_LOAD_SYSFW
> +	bool
> +	depends on SPL
> +	default n

'n' is already default, you can drop this.

[snip]
> +config K3_SYSFW_IMAGE_SIZE_MAX
> +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> +	depends on K3_LOAD_SYSFW
> +	default	269000
> +	help
> +	  Amount of memory reserved through dynamic allocation at runtime for
> +	  loading the combined System Firmware and configuration image tree
> +	  blob. Keep it as tight as possible, as this directly affects the
> +	  overall SPL memory footprint.

This is missing a unit, and is 'int' really the best choice here (and
really, I guess, 262.6KiB as a default) ?

[snip]
> diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> index 0c3a4f7db1..6c895400c2 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
>  obj-$(CONFIG_ARM64) += arm64-mmu.o
>  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
>  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
>  obj-y += common.o
[snip]
> diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> new file mode 100644
> index 0000000000..a222266c27
> --- /dev/null
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -0,0 +1,263 @@
[snip]
> +#ifdef CONFIG_SPL_BUILD
[snip of the whole body of the file]
> +#endif

We should be using something else in the Makefile, typically:
obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o
should work.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/c5938637/attachment.sig>

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Andreas Dannenberg]

Hi Tom,

On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote:
> On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote:
> 
> > TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> > firmware called SYSFW (System Firmware) being loaded into the dedicated
> > DMSC (Device Management and Security Controller) processor to provide
> > various services via TISCI (Texas Instruments System Control Interface)
> > to manage device aspects such as core bringup, power, clocks, security,
> > and so on across the entire SoC.
> [snip]
> > While I also have a working solution based on the existing FS loader
> > framework this has its own challenges, namely by its very nature only
> > addressing a subset of our use cases (no eMMC/SD RAW boot support for
> > example), being heavier on resource usage (needing to use ENV to pass
> > parameters), and not addressing the need to probe the boot peripheral.
> > This particular framework works well for use cases requiring to load
> > firmware from FS-based media once DDR is up and U-Boot is in a more
> > "initialized" state but it is not a one-fits all solution for very
> > early use in SPL board_init_f() accross different boot modes.
> 
> I think one thing that might help here is to post this alternative
> solution and provide the 'size' information for both series.  In
> addition, build something like am335x_evm and socfpga_stratix10 for both
> series and include their before/after 'size' info too.  Thanks!

thanks for looking at this more closely. Sure, let me collect some data
on this front and also post the alternative solution. It won't be a
completely fair comparison however as the alternative solution only
supports FS-based MMC boot, whereas the solution proposed here also
supports eMMC/SD RAW boot, both partition and sector-based (and a
combination thereof).

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[dannenberg at ti.com]

Hi TF,

On Mon, May 13, 2019 at 01:37:22PM +0000, Chee, Tien Fong wrote:
> On Wed, 2019-05-08 at 13:43 -0500, dannenberg at ti.com wrote:
> > Hi TF,
> > thanks for chiming in. Comments inlined...
> > 
> > On Wed, May 08, 2019 at 04:31:35AM +0000, Chee, Tien Fong wrote:
> > > 
> > > On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
> > > > 
> > > > 
> > > > On 07.05.19 19:25, Andreas Dannenberg wrote:
> > > > > 
> > > > > 
> > > [...]
> > > > 
> > > > > 
> > > > > 
> > > > > While I also have a working solution based on the existing FS
> > > > > loader
> > > > > framework this has its own challenges, namely by its very
> > > > > nature
> > > > > only
> > > > > addressing a subset of our use cases (no eMMC/SD RAW boot
> > > > > support
> > > > > for
> > > > > example), 
> > > IMO, it's actually not that hard to enhance RAW support, i think
> > > minimal changes are required. I have attached the patches about an
> > > example of loading RAW from QSPI that i have done locally last few
> > > week
> > > ago.
> > As your patches show, no it's not hard, it's more or less taking
> > pieces
> > from the SPL loader framework and refactoring them into the FS
> > loader,
> > creating a good and universal solution usable across SPL and U-Boot
> > in
> > environments that are not tightly constrained in terms of memory.
> > 
> > What I was going after is finding a way to load from different media
> > "pre-relocation" SPL (board_init_f), with almost no memory available,
> > where I have to agonize over every single KB available.
> 
> This is just a simple "loader", provide user flexibility of loading
> stuff in anywhere, from SPL to U-Boot. As long as DM is supported by
> the time running at "pre-relocation" SPL, then FS loader should be able
> to work.

Understood. FS loader also relies on the peripheral being brought up.
For MMC, from my SPL board_init_f() user code I had to do a sequence of
mmc_initialize(), mmc_get_mmc_dev(), and mmc_init() before I could use
the FS loader functionality - just like the U-Boot SPL loader is already
doing this. Hence my concern with code duplication for certain use
cases. Anyways I'll post my use of the FS loader as an RFC here soon
so you can have a look at the whole thing if you like.

> > > > > being heavier on resource usage (needing to use ENV to pass
> > > > > parameters),
> > > ENV is optional, you can use DTS.
> > Is it? I had to update the FS loader framework when I experimented
> > with
> > it, please see attached patch. I had refactored it such that I can
> > pass
> > in all relevant data via platform data for the intial boot mode I was
> > going after, so that I can dynamically configure it on the fly from
> > early SPL board_init_f() based on boot media / boot mode, etc.
> 
> Yes, you can tie up loader with target HW node for destination loading.
> For example, tie up with FPGA manager node, loading bistream file from
> MMC to FPGA manager.
> 
> Here is an example, but i put the fs loader phandle under chosen node
> because most files and images are stored in the same storage.
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=0a42a132a4b8
> 46031df2c4a7d04692240ed34843

Thanks for pointing to this example for DTS-based loading, I think I had
seen this earlier when I looked for implementations using the FS loader
framework.

> > > 
> > > For example loading FPGA bitstream from QSPI RAW:
> > > 
> > > /* DTS */
> > > / {
> > > +	aliases {
> > > +		spi0 = &qspi;
> > > +	};
> > > +
> > > +	fs_loader0: fs-loader {
> > > +		u-boot,dm-pre-reloc;
> > > +		compatible = "u-boot,fs-loader";
> > > +		sfconfig = <0 0 100000000 3>;
> > > +	};
> > > +};
> > > +
> > > +&fpga_mgr {
> > > +	u-boot,dm-pre-reloc;
> > > +	firmware-loader = <&fs_loader0>;
> > > +	altr,bitstream = "300000";
> > > +};
> > The above hard-codes and duplicates information that is already known
> > to
> > U-Boot (CONFIG_SF_DEFAULT_*), and will do more of the same as this is
> > being extended. How does one keep this consistent?
> 
> Current fs loader not support RAW loading yet, i'm not sure whether it
> should support it by adding more specific storage API(much more messy),
> or just fully support filesystem only with one generic filesystem
> abstract interface.
> 
> This example codes provide user opportunity to override the spi setting
> when running fs loader. CONFIG_SF_DEFAULT_* would be used by the
> drivers which are not running the fs loader.
> 
> > 
> > And how does this scale to support like 5 different boot modes using
> > a
> > single DTB? I guess one  could populate 5 nodes, and then pick one
> > based
> > on boot mode during SPL execution, by extending the probe function
> > accordingly.
> 
> This is just a very simple fs loader. This is totally up to user how
> they want to scale it up, may be adding the function to populate the fs
> loader nodes, or loading the images based on boot storages ordering in
> DTS?

This would require on-the-fly FDT manipulation. Again something that can
be done, but challenging in tight environments. I'm not arguing against
FS loader, it is very useful, we actually use it ourselves (not
upstream yet) for use cases involving remote core program loading...

> > > > > and not addressing the need to probe the boot peripheral.
> > > You can add more different probing method in function called
> > > "fs_loader_probe". Current fs_loader supports block(sdmmc, emmc,
> > > etc...) probing, and with
> > > the patches attached support QSPI probing.
> > > 
> > > Another idea come to mind, we can use fs_loader for loading FIT
> > > boot
> > > image into RAM, and boot from RAM with existing SPL loader
> > > framework,
> > > but i'm not sure this implementation fit to your use case?
> > Unfortunately for what I'm working on there is no space for this. It
> > would be nice to be able to load our "System Firmware" alongside the
> > next stage of U-Boot in a single FIT, and then just extact that
> > firmware
> > image similar to what CONFIG_SPL_FPGA_SUPPORT does in spl_fit.c. 
> > However I must load SYSFW and the U-Boot next stage as two steps
> > (while bringing up DDR in-between....).
> > 
> > As I tried to explain in my earlier email to Simon, I almost see the
> > minimally-intrusive extensions I did to the SPL loader framework via
> > "spl: Make image loader infrastructure more universal" and the FS
> > loader
> > framework to be elements that are orthogonal and can both exist.
> > Maybe
> > FS loader can partially build upon the SPL loader foundation as well?
> 
> Yes, fs loader can be in anywhere, it can be part of SPL loader
> framework as well. It can be as complement to SPL loader also.

Yes exactly.

Thanks,

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Andreas Dannenberg]

Hi Tom,

On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> 
> > Introduce a framework that allows loading the System Firmware (SYSFW)
> > binary as well as the associated configuration data from an image tree
> > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > RAW mode partition or sector.
> > 
> > To simplify the handling of and loading from the different boot media
> > we tap into the existing U-Boot SPL framework usually used for loading
> > U-Boot by building on an earlier commit that exposes some of that
> > functionality.
> > 
> > Note that this initial implementation only supports FS and RAW-based
> > eMMC/SD card boot.
> [snip]
> > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > index e677a2e01b..f1731dda58 100644
> > --- a/arch/arm/mach-k3/Kconfig
> > +++ b/arch/arm/mach-k3/Kconfig
> > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> >  	int
> >  	default 16
> >  
> > +config K3_LOAD_SYSFW
> > +	bool
> > +	depends on SPL
> > +	default n
> 
> 'n' is already default, you can drop this.

Ok sure.

> 
> [snip]
> > +config K3_SYSFW_IMAGE_SIZE_MAX
> > +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> > +	depends on K3_LOAD_SYSFW
> > +	default	269000
> > +	help
> > +	  Amount of memory reserved through dynamic allocation at runtime for
> > +	  loading the combined System Firmware and configuration image tree
> > +	  blob. Keep it as tight as possible, as this directly affects the
> > +	  overall SPL memory footprint.
> 
> This is missing a unit, and is 'int' really the best choice here (and
> really, I guess, 262.6KiB as a default) ?

Will add a unit.

As for the specific value, in our R5 SPL memory is very very tight. The
value used here is basically used for a malloc(), and any extra byte
allocated will be "wasted" and not available for stack etc. Also our
SYSFW image that is loaded is fixed size (except some +/-100 odd bytes
if the configuration data is changed that's part of the same SYSFW.ITB
blob), so a rather tailored size makes sense here.
 
> [snip]
> > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> > index 0c3a4f7db1..6c895400c2 100644
> > --- a/arch/arm/mach-k3/Makefile
> > +++ b/arch/arm/mach-k3/Makefile
> > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
> >  obj-$(CONFIG_ARM64) += arm64-mmu.o
> >  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
> >  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> >  obj-y += common.o
> [snip]
> > diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> > new file mode 100644
> > index 0000000000..a222266c27
> > --- /dev/null
> > +++ b/arch/arm/mach-k3/sysfw-loader.c
> > @@ -0,0 +1,263 @@
> [snip]
> > +#ifdef CONFIG_SPL_BUILD
> [snip of the whole body of the file]
> > +#endif
> 
> We should be using something else in the Makefile, typically:
> obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o
> should work.

Well, it won't work like this. We need to make the building of the SYSFW
loader code depending on a CONFIG. This is because for K3 family devices
we build the U-Boot tree into three distinct images [1]:

1) SPL image for running on an R5 (our first stage)
2) SPL image for running on an A53 (our second stage)
3) U-Boot (proper) image for running on an A53 (third stage)

With the change you proposed sysfw-loader.o will get build for A53 SPL
where it is neither needed nor wanted, causing build failures.

What we would need is something like
(CONFIG_K3_LOAD_SYSFW && CONFIG_SPL_BUILD) to conditionally build that
object if we want to get rid of the #ifdef/#endif in sysfw-loader.c I
suppose.

Thanks,
Andreas

[1] https://github.com/u-boot/u-boot/blob/master/board/ti/am65x/README

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Tom Rini]

On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> Hi Tom,
> 
> On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> > 
> > > Introduce a framework that allows loading the System Firmware (SYSFW)
> > > binary as well as the associated configuration data from an image tree
> > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > > RAW mode partition or sector.
> > > 
> > > To simplify the handling of and loading from the different boot media
> > > we tap into the existing U-Boot SPL framework usually used for loading
> > > U-Boot by building on an earlier commit that exposes some of that
> > > functionality.
> > > 
> > > Note that this initial implementation only supports FS and RAW-based
> > > eMMC/SD card boot.
> > [snip]
> > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > > index e677a2e01b..f1731dda58 100644
> > > --- a/arch/arm/mach-k3/Kconfig
> > > +++ b/arch/arm/mach-k3/Kconfig
> > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> > >  	int
> > >  	default 16
> > >  
> > > +config K3_LOAD_SYSFW
> > > +	bool
> > > +	depends on SPL
> > > +	default n
> > 
> > 'n' is already default, you can drop this.
> 
> Ok sure.
> 
> > 
> > [snip]
> > > +config K3_SYSFW_IMAGE_SIZE_MAX
> > > +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> > > +	depends on K3_LOAD_SYSFW
> > > +	default	269000
> > > +	help
> > > +	  Amount of memory reserved through dynamic allocation at runtime for
> > > +	  loading the combined System Firmware and configuration image tree
> > > +	  blob. Keep it as tight as possible, as this directly affects the
> > > +	  overall SPL memory footprint.
> > 
> > This is missing a unit, and is 'int' really the best choice here (and
> > really, I guess, 262.6KiB as a default) ?
> 
> Will add a unit.
> 
> As for the specific value, in our R5 SPL memory is very very tight. The
> value used here is basically used for a malloc(), and any extra byte
> allocated will be "wasted" and not available for stack etc. Also our
> SYSFW image that is loaded is fixed size (except some +/-100 odd bytes
> if the configuration data is changed that's part of the same SYSFW.ITB
> blob), so a rather tailored size makes sense here.

Right, that makes sense.  But how did you get to that
not-exactly-"round" number rather than say 0x41A00 or some other
slightly smaller value in hex?  If 0x41AC8 is right, then, OK, it's
right.  It just seems strange at first.

>  
> > [snip]
> > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> > > index 0c3a4f7db1..6c895400c2 100644
> > > --- a/arch/arm/mach-k3/Makefile
> > > +++ b/arch/arm/mach-k3/Makefile
> > > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
> > >  obj-$(CONFIG_ARM64) += arm64-mmu.o
> > >  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
> > >  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> > > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> > >  obj-y += common.o
> > [snip]
> > > diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> > > new file mode 100644
> > > index 0000000000..a222266c27
> > > --- /dev/null
> > > +++ b/arch/arm/mach-k3/sysfw-loader.c
> > > @@ -0,0 +1,263 @@
> > [snip]
> > > +#ifdef CONFIG_SPL_BUILD
> > [snip of the whole body of the file]
> > > +#endif
> > 
> > We should be using something else in the Makefile, typically:
> > obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o
> > should work.
> 
> Well, it won't work like this. We need to make the building of the SYSFW
> loader code depending on a CONFIG. This is because for K3 family devices
> we build the U-Boot tree into three distinct images [1]:

Then you do:
ifeq ($(CONFIG_SPL_BUILD),y)
obj-$(CONFIG_K3_LOAD_SYSFW) += sysfs-loader.o
endif

As seen in other places, as we do not whole-body ifdef code.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190515/95760cd8/attachment.sig>

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Andreas Dannenberg]

Hi Tom,

On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote:
> On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> > Hi Tom,
> > 
> > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> > > 
> > > > Introduce a framework that allows loading the System Firmware (SYSFW)
> > > > binary as well as the associated configuration data from an image tree
> > > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > > > RAW mode partition or sector.
> > > > 
> > > > To simplify the handling of and loading from the different boot media
> > > > we tap into the existing U-Boot SPL framework usually used for loading
> > > > U-Boot by building on an earlier commit that exposes some of that
> > > > functionality.
> > > > 
> > > > Note that this initial implementation only supports FS and RAW-based
> > > > eMMC/SD card boot.
> > > [snip]
> > > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > > > index e677a2e01b..f1731dda58 100644
> > > > --- a/arch/arm/mach-k3/Kconfig
> > > > +++ b/arch/arm/mach-k3/Kconfig
> > > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> > > >  	int
> > > >  	default 16
> > > >  
> > > > +config K3_LOAD_SYSFW
> > > > +	bool
> > > > +	depends on SPL
> > > > +	default n
> > > 
> > > 'n' is already default, you can drop this.
> > 
> > Ok sure.
> > 
> > > 
> > > [snip]
> > > > +config K3_SYSFW_IMAGE_SIZE_MAX
> > > > +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> > > > +	depends on K3_LOAD_SYSFW
> > > > +	default	269000
> > > > +	help
> > > > +	  Amount of memory reserved through dynamic allocation at runtime for
> > > > +	  loading the combined System Firmware and configuration image tree
> > > > +	  blob. Keep it as tight as possible, as this directly affects the
> > > > +	  overall SPL memory footprint.
> > > 
> > > This is missing a unit, and is 'int' really the best choice here (and
> > > really, I guess, 262.6KiB as a default) ?

I think 'int' is a more natural fit as this is to reserve memory for the
'sysfw.itb' blob we load from media. This blob is build outside U-Boot
using the "System Firmware Image Generator" project [1], and if after
build somebody does an 'll' in the build directory the file size would
show up as decimal, and that's what needs to fit inside
K3_SYSFW_IMAGE_SIZE_MAX.

> > Will add a unit.
> > 
> > As for the specific value, in our R5 SPL memory is very very tight. The
> > value used here is basically used for a malloc(), and any extra byte
> > allocated will be "wasted" and not available for stack etc. Also our
> > SYSFW image that is loaded is fixed size (except some +/-100 odd bytes
> > if the configuration data is changed that's part of the same SYSFW.ITB
> > blob), so a rather tailored size makes sense here.
> 
> Right, that makes sense.  But how did you get to that
> not-exactly-"round" number rather than say 0x41A00 or some other
> slightly smaller value in hex?  If 0x41AC8 is right, then, OK, it's
> right.  It just seems strange at first.

The sysfw.itb blob consumed by the SYSFW loader comprises a fixed
component (the SYSFW itself), plus a few smaller chunks of variable data
containing user configuration data. During initial development the
combined size of this ITB was about 264,900 bytes, and 4KB was added as
slack to accommodate configuration changes, resulting in what looks like
the arbitrary number under discussion. The sysfw.itb blob has actually
since grown in size but there is still plenty of space for it to further
grow if needed. Since we use this value already in production since last
year with no issues I'd rather leave it alone (due to using stack based
malloc in R5 SPL increasing that value would directly decrease available
stack space with our R5 SPL memory layout where the stack is growing
down towards the R5 SPL image itself).

> > > [snip]
> > > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> > > > index 0c3a4f7db1..6c895400c2 100644
> > > > --- a/arch/arm/mach-k3/Makefile
> > > > +++ b/arch/arm/mach-k3/Makefile
> > > > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
> > > >  obj-$(CONFIG_ARM64) += arm64-mmu.o
> > > >  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
> > > >  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> > > > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> > > >  obj-y += common.o
> > > [snip]
> > > > diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> > > > new file mode 100644
> > > > index 0000000000..a222266c27
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-k3/sysfw-loader.c
> > > > @@ -0,0 +1,263 @@
> > > [snip]
> > > > +#ifdef CONFIG_SPL_BUILD
> > > [snip of the whole body of the file]
> > > > +#endif
> > > 
> > > We should be using something else in the Makefile, typically:
> > > obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o
> > > should work.
> > 
> > Well, it won't work like this. We need to make the building of the SYSFW
> > loader code depending on a CONFIG. This is because for K3 family devices
> > we build the U-Boot tree into three distinct images [1]:
> 
> Then you do:
> ifeq ($(CONFIG_SPL_BUILD),y)
> obj-$(CONFIG_K3_LOAD_SYSFW) += sysfs-loader.o
> endif
> 
> As seen in other places, as we do not whole-body ifdef code.  Thanks!

Great suggestion, works like a champ.

--
Andreas Dannenberg
Texas Instruments Inc

[1] http://git.ti.com/gitweb/?p=processor-firmware/system-firmware-image-gen.git;a=summary

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Andreas Dannenberg]

Hi Tom,

On Thu, May 16, 2019 at 10:47:30AM -0500, Andreas Dannenberg wrote:
> Hi Tom,
> 
> On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote:
> > On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> > > Hi Tom,
> > > 
> > > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> > > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> > > > 
> > > > > Introduce a framework that allows loading the System Firmware (SYSFW)
> > > > > binary as well as the associated configuration data from an image tree
> > > > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > > > > RAW mode partition or sector.
> > > > > 
> > > > > To simplify the handling of and loading from the different boot media
> > > > > we tap into the existing U-Boot SPL framework usually used for loading
> > > > > U-Boot by building on an earlier commit that exposes some of that
> > > > > functionality.
> > > > > 
> > > > > Note that this initial implementation only supports FS and RAW-based
> > > > > eMMC/SD card boot.
> > > > [snip]
> > > > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > > > > index e677a2e01b..f1731dda58 100644
> > > > > --- a/arch/arm/mach-k3/Kconfig
> > > > > +++ b/arch/arm/mach-k3/Kconfig
> > > > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> > > > >  	int
> > > > >  	default 16
> > > > >  
> > > > > +config K3_LOAD_SYSFW
> > > > > +	bool
> > > > > +	depends on SPL
> > > > > +	default n
> > > > 
> > > > 'n' is already default, you can drop this.
> > > 
> > > Ok sure.
> > > 
> > > > 
> > > > [snip]
> > > > > +config K3_SYSFW_IMAGE_SIZE_MAX
> > > > > +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> > > > > +	depends on K3_LOAD_SYSFW
> > > > > +	default	269000
> > > > > +	help
> > > > > +	  Amount of memory reserved through dynamic allocation at runtime for
> > > > > +	  loading the combined System Firmware and configuration image tree
> > > > > +	  blob. Keep it as tight as possible, as this directly affects the
> > > > > +	  overall SPL memory footprint.
> > > > 
> > > > This is missing a unit, and is 'int' really the best choice here (and
> > > > really, I guess, 262.6KiB as a default) ?
> 
> I think 'int' is a more natural fit as this is to reserve memory for the
> 'sysfw.itb' blob we load from media. This blob is build outside U-Boot
> using the "System Firmware Image Generator" project [1], and if after
> build somebody does an 'll' in the build directory the file size would
> show up as decimal, and that's what needs to fit inside
> K3_SYSFW_IMAGE_SIZE_MAX.
> 
> > > Will add a unit.
> > > 
> > > As for the specific value, in our R5 SPL memory is very very tight. The
> > > value used here is basically used for a malloc(), and any extra byte
> > > allocated will be "wasted" and not available for stack etc. Also our
> > > SYSFW image that is loaded is fixed size (except some +/-100 odd bytes
> > > if the configuration data is changed that's part of the same SYSFW.ITB
> > > blob), so a rather tailored size makes sense here.
> > 
> > Right, that makes sense.  But how did you get to that
> > not-exactly-"round" number rather than say 0x41A00 or some other
> > slightly smaller value in hex?  If 0x41AC8 is right, then, OK, it's
> > right.  It just seems strange at first.
> 
> The sysfw.itb blob consumed by the SYSFW loader comprises a fixed
> component (the SYSFW itself), plus a few smaller chunks of variable data
> containing user configuration data. During initial development the
> combined size of this ITB was about 264,900 bytes, and 4KB was added as
> slack to accommodate configuration changes, resulting in what looks like
> the arbitrary number under discussion. The sysfw.itb blob has actually
> since grown in size but there is still plenty of space for it to further
> grow if needed. Since we use this value already in production since last
> year with no issues I'd rather leave it alone (due to using stack based
> malloc in R5 SPL increasing that value would directly decrease available
> stack space with our R5 SPL memory layout where the stack is growing
> down towards the R5 SPL image itself).

Small clarification, the size of the early malloc pool is of course
controlled by CONFIG_SYS_MALLOC_F_LEN with K3_SYSFW_IMAGE_SIZE_MAX using
the majority of it. However CONFIG_SYS_MALLOC_F_LEN is dimensioned such
to "tightly wrap" both K3_SYSFW_IMAGE_SIZE_MAX and other users of the
early malloc pool (fat fs is a major one), so the principle is the same.
I'd rather leave K3_SYSFW_IMAGE_SIZE_MAX as it stands.

Some more details on the memory usage to follow...

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs

[Andreas Dannenberg]

Hi Tom,

On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote:
> On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote:
> 
> > TI K3 SoCs like the AM654x devices are fundamentally dependent on a
> > firmware called SYSFW (System Firmware) being loaded into the dedicated
> > DMSC (Device Management and Security Controller) processor to provide
> > various services via TISCI (Texas Instruments System Control Interface)
> > to manage device aspects such as core bringup, power, clocks, security,
> > and so on across the entire SoC.
> [snip]
> > While I also have a working solution based on the existing FS loader
> > framework this has its own challenges, namely by its very nature only
> > addressing a subset of our use cases (no eMMC/SD RAW boot support for
> > example), being heavier on resource usage (needing to use ENV to pass
> > parameters), and not addressing the need to probe the boot peripheral.
> > This particular framework works well for use cases requiring to load
> > firmware from FS-based media once DDR is up and U-Boot is in a more
> > "initialized" state but it is not a one-fits all solution for very
> > early use in SPL board_init_f() accross different boot modes.
> 
> I think one thing that might help here is to post this alternative
> solution and provide the 'size' information for both series.  In
> addition, build something like am335x_evm and socfpga_stratix10 for both
> series and include their before/after 'size' info too.  Thanks!

I collected some data how this series extending the SPL framework affects
the size of the SPL, the increase is quite small nevertheless there is an
increase that may or may not be an issue on certain platforms:

                  |    SPL File    | v2019.07-rc2 | plus SYSFW loader series
------------------+----------------+--------------+-------------------------
am335x_evm        | MLO            | 109,884      | 109,964 (+120 bytes)
socfpga_stratix10 | u-boot-spl.bin |  78,760      |  78,872 (+112 bytes)


Then, I also collected some data comparing how the SYSFW loader based on
extending the SPL loader function (this patch series) stacks up against
a basic FS loader-based implementation of the SYSFW loader functionality
from an AM654 R5 SPL size POV:

 What                     | SPL (tiboot3.bin) | Solution Size (bytes)
--------------------------+-------------------+-----------------------
No SYSFW Loader           |      91,725       |     0 (base for comp)
SPL loader-based solution |      93,265       | 1,540
FS loader-based solution  |      95,417       | 3,692


Basically the FS loader-based solution is ~2x bigger than the SPL-loader
based solution, while also dropping eMMC/SD partition- and sector-based
RAW support. The difference between the solutions is 2,152 and will be
even larger once RAW boot support is added in. Will post the FS loader-
based solution for reference next.


One more word on why I am so concerned with memory. Below is a rough
memory map of our SPL running on an R5 core out of on-chip MCU SRAM
(512KB on AM654x). The stack during "pre-relocation" SPL is growing
down towards where the actual SPL image is. Inside board_init_f()
the SP currently sits at SP=0x41c25b10. The image size of an R5 SPL
with the SPL loader-based solution as proposed with this patch series
sits at 93,265 bytes, effectively leaving 61,119 bytes to be shared
between features that are yet to get added to tiboot3.bin (such as
board-detection EEPROM support, other early boot remote core loading,
additions to dtb), and what can be used as stack by board_init_f()
and its callees. Hence, every kilobyte really counts.

+-----------+  0x41c8 0000
|    BSS    |  CONFIG_SPL_BSS_MAX_SIZE=0x5000
+-----------+
|   malloc  |  CONFIG_SYS_MALLOC_F_LEN=0x55000
+-----------+
|    gd     |
+-----------+
|   Stack   |
+-----------+
|           |  \
~           ~   |== Room for stack growth
|           |  /   and R5 SPL feature
+-----------+      additions
|           |
|tiboot3.bin|
|   (SPL)   |
|           |
+-----------+  0x41c0 0000


--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

[Tom Rini]

On Thu, May 16, 2019 at 02:14:19PM -0500, Andreas Dannenberg wrote:
> Hi Tom,
> 
> On Thu, May 16, 2019 at 10:47:30AM -0500, Andreas Dannenberg wrote:
> > Hi Tom,
> > 
> > On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote:
> > > On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> > > > Hi Tom,
> > > > 
> > > > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> > > > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> > > > > 
> > > > > > Introduce a framework that allows loading the System Firmware (SYSFW)
> > > > > > binary as well as the associated configuration data from an image tree
> > > > > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > > > > > RAW mode partition or sector.
> > > > > > 
> > > > > > To simplify the handling of and loading from the different boot media
> > > > > > we tap into the existing U-Boot SPL framework usually used for loading
> > > > > > U-Boot by building on an earlier commit that exposes some of that
> > > > > > functionality.
> > > > > > 
> > > > > > Note that this initial implementation only supports FS and RAW-based
> > > > > > eMMC/SD card boot.
> > > > > [snip]
> > > > > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > > > > > index e677a2e01b..f1731dda58 100644
> > > > > > --- a/arch/arm/mach-k3/Kconfig
> > > > > > +++ b/arch/arm/mach-k3/Kconfig
> > > > > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> > > > > >  	int
> > > > > >  	default 16
> > > > > >  
> > > > > > +config K3_LOAD_SYSFW
> > > > > > +	bool
> > > > > > +	depends on SPL
> > > > > > +	default n
> > > > > 
> > > > > 'n' is already default, you can drop this.
> > > > 
> > > > Ok sure.
> > > > 
> > > > > 
> > > > > [snip]
> > > > > > +config K3_SYSFW_IMAGE_SIZE_MAX
> > > > > > +	int "Amount of memory dynamically allocated for loading SYSFW blob"
> > > > > > +	depends on K3_LOAD_SYSFW
> > > > > > +	default	269000
> > > > > > +	help
> > > > > > +	  Amount of memory reserved through dynamic allocation at runtime for
> > > > > > +	  loading the combined System Firmware and configuration image tree
> > > > > > +	  blob. Keep it as tight as possible, as this directly affects the
> > > > > > +	  overall SPL memory footprint.
> > > > > 
> > > > > This is missing a unit, and is 'int' really the best choice here (and
> > > > > really, I guess, 262.6KiB as a default) ?
> > 
> > I think 'int' is a more natural fit as this is to reserve memory for the
> > 'sysfw.itb' blob we load from media. This blob is build outside U-Boot
> > using the "System Firmware Image Generator" project [1], and if after
> > build somebody does an 'll' in the build directory the file size would
> > show up as decimal, and that's what needs to fit inside
> > K3_SYSFW_IMAGE_SIZE_MAX.
> > 
> > > > Will add a unit.
> > > > 
> > > > As for the specific value, in our R5 SPL memory is very very tight. The
> > > > value used here is basically used for a malloc(), and any extra byte
> > > > allocated will be "wasted" and not available for stack etc. Also our
> > > > SYSFW image that is loaded is fixed size (except some +/-100 odd bytes
> > > > if the configuration data is changed that's part of the same SYSFW.ITB
> > > > blob), so a rather tailored size makes sense here.
> > > 
> > > Right, that makes sense.  But how did you get to that
> > > not-exactly-"round" number rather than say 0x41A00 or some other
> > > slightly smaller value in hex?  If 0x41AC8 is right, then, OK, it's
> > > right.  It just seems strange at first.
> > 
> > The sysfw.itb blob consumed by the SYSFW loader comprises a fixed
> > component (the SYSFW itself), plus a few smaller chunks of variable data
> > containing user configuration data. During initial development the
> > combined size of this ITB was about 264,900 bytes, and 4KB was added as
> > slack to accommodate configuration changes, resulting in what looks like
> > the arbitrary number under discussion. The sysfw.itb blob has actually
> > since grown in size but there is still plenty of space for it to further
> > grow if needed. Since we use this value already in production since last
> > year with no issues I'd rather leave it alone (due to using stack based
> > malloc in R5 SPL increasing that value would directly decrease available
> > stack space with our R5 SPL memory layout where the stack is growing
> > down towards the R5 SPL image itself).
> 
> Small clarification, the size of the early malloc pool is of course
> controlled by CONFIG_SYS_MALLOC_F_LEN with K3_SYSFW_IMAGE_SIZE_MAX using
> the majority of it. However CONFIG_SYS_MALLOC_F_LEN is dimensioned such
> to "tightly wrap" both K3_SYSFW_IMAGE_SIZE_MAX and other users of the
> early malloc pool (fat fs is a major one), so the principle is the same.
> I'd rather leave K3_SYSFW_IMAGE_SIZE_MAX as it stands.
> 
> Some more details on the memory usage to follow...

That's a very helpful explanation, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190517/bc7c34a5/attachment.sig>

[U-Boot] [PATCH 10/13] configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC

[Simon Glass]

On Tue, 7 May 2019 at 11:26, Andreas Dannenberg <dannenberg@ti.com> wrote:
>
> Enable all the relevant configs that enables support for loading
> sysfw via MMC.
>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> ---
>  configs/am65x_hs_evm_r5_defconfig | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>