* [U-Boot] [RFC 01/11] mmc: k3_arasan: Allow driver to probe without PDs specified
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 02/11] spl: Allow skipping clearing BSS during relocation Andreas Dannenberg
` (10 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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>
---
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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 02/11] spl: Allow skipping clearing BSS during relocation
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 01/11] mmc: k3_arasan: Allow driver to probe without PDs specified Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 03/11] spl: mmc: Export function to get device index Andreas Dannenberg
` (9 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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>
---
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 30fba20e1b..e24833a6f8 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -126,6 +126,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
@@ -143,6 +145,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 c7cd34449a..098cbb2f7f 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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 03/11] spl: mmc: Export function to get device index
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 01/11] mmc: k3_arasan: Allow driver to probe without PDs specified Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 02/11] spl: Allow skipping clearing BSS during relocation Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data Andreas Dannenberg
` (8 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
To better support use cases where we want to side-load additional files
during SPL execution from MMC media export the SPL MMC framework function
for determining the MMC boot device index.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
common/spl/spl_mmc.c | 2 +-
include/spl.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 324d91c884..6bdc348e94 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -94,7 +94,7 @@ end:
return 0;
}
-static int spl_mmc_get_device_index(u32 boot_device)
+int spl_mmc_get_device_index(u32 boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
diff --git a/include/spl.h b/include/spl.h
index f09909e189..98e8d1e951 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -327,6 +327,8 @@ bool spl_was_boot_source(void);
*/
int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, char *devstr);
+int spl_mmc_get_device_index(u32 boot_device);
+
int spl_mmc_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev);
--
2.17.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (2 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 03/11] spl: mmc: Export function to get device index Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-21 5:40 ` Chee, Tien Fong
2019-05-16 20:54 ` [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework Andreas Dannenberg
` (7 subsequent siblings)
11 siblings, 1 reply; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
To give us more flexibility using the FS loader eliminate the need of
always having to use the ENV to configure the block device but rather
allow the respective block device and partition to be setup through
platform data.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
drivers/misc/fs_loader.c | 17 ++++++++++++++++-
include/fs_loader.h | 4 ++++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index f42eeff8f6..69f474da99 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -81,6 +81,15 @@ static int select_fs_dev(struct device_platdata *plat)
return -ENODEV;
}
}
+ } else if (plat->blkdev) {
+ struct blk_desc *desc = blk_get_by_device(plat->blkdev);
+
+ if (desc) {
+ ret = fs_set_blk_dev_with_part(desc, plat->blkpart);
+ } else {
+ debug("%s: No device found\n", __func__);
+ return -ENODEV;
+ }
} else if (plat->mtdpart && plat->ubivol) {
ret = mount_ubifs(plat->mtdpart, plat->ubivol);
if (ret)
@@ -138,13 +147,18 @@ static int _request_firmware_prepare(struct udevice *dev,
static int fw_get_filesystem_firmware(struct udevice *dev)
{
loff_t actread;
- char *storage_interface, *dev_part, *ubi_mtdpart, *ubi_volume;
+ char *storage_interface = NULL;
+ char *dev_part = NULL;
+ char *ubi_mtdpart = NULL;
+ char *ubi_volume = NULL;
int ret;
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
storage_interface = env_get("storage_interface");
dev_part = env_get("fw_dev_part");
ubi_mtdpart = env_get("fw_ubi_mtdpart");
ubi_volume = env_get("fw_ubi_volume");
+#endif
if (storage_interface && dev_part) {
ret = fs_set_blk_dev(storage_interface, dev_part, FS_TYPE_ANY);
@@ -159,6 +173,7 @@ static int fw_get_filesystem_firmware(struct udevice *dev)
else
ret = -ENODEV;
} else {
+ debug("%s: init via platdata\n", __func__);
ret = select_fs_dev(dev->platdata);
}
diff --git a/include/fs_loader.h b/include/fs_loader.h
index b728c06fcf..adaa2b5db8 100644
--- a/include/fs_loader.h
+++ b/include/fs_loader.h
@@ -28,11 +28,15 @@ struct phandle_part {
* This holds information about all supported storage devices for driver use.
*
* @phandlepart: Attribute data for block device.
+ * @blkdev: Block device (alternative to using phandlepart)
+ * @blkpart: Partition number of block device (alternative to using phandlepart)
* @mtdpart: MTD partition for ubi partition.
* @ubivol: UBI volume-name for ubifsmount.
*/
struct device_platdata {
struct phandle_part phandlepart;
+ struct udevice *blkdev;
+ u32 blkpart;
char *mtdpart;
char *ubivol;
};
--
2.17.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data
2019-05-16 20:54 ` [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data Andreas Dannenberg
@ 2019-05-21 5:40 ` Chee, Tien Fong
2019-05-21 18:37 ` dannenberg at ti.com
0 siblings, 1 reply; 21+ messages in thread
From: Chee, Tien Fong @ 2019-05-21 5:40 UTC (permalink / raw)
To: u-boot
On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> To give us more flexibility using the FS loader eliminate the need of
> always having to use the ENV to configure the block device but rather
> allow the respective block device and partition to be setup through
> platform data.
>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Why not using DT method?
> ---
> drivers/misc/fs_loader.c | 17 ++++++++++++++++-
> include/fs_loader.h | 4 ++++
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index f42eeff8f6..69f474da99 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -81,6 +81,15 @@ static int select_fs_dev(struct device_platdata
> *plat)
> return -ENODEV;
> }
> }
> + } else if (plat->blkdev) {
> + struct blk_desc *desc = blk_get_by_device(plat-
> >blkdev);
> +
> + if (desc) {
> + ret = fs_set_blk_dev_with_part(desc, plat-
> >blkpart);
> + } else {
> + debug("%s: No device found\n", __func__);
> + return -ENODEV;
> + }
> } else if (plat->mtdpart && plat->ubivol) {
> ret = mount_ubifs(plat->mtdpart, plat->ubivol);
> if (ret)
> @@ -138,13 +147,18 @@ static int _request_firmware_prepare(struct
> udevice *dev,
> static int fw_get_filesystem_firmware(struct udevice *dev)
> {
> loff_t actread;
> - char *storage_interface, *dev_part, *ubi_mtdpart,
> *ubi_volume;
> + char *storage_interface = NULL;
> + char *dev_part = NULL;
> + char *ubi_mtdpart = NULL;
> + char *ubi_volume = NULL;
> int ret;
>
> +#if CONFIG_IS_ENABLED(ENV_SUPPORT)
> storage_interface = env_get("storage_interface");
> dev_part = env_get("fw_dev_part");
> ubi_mtdpart = env_get("fw_ubi_mtdpart");
> ubi_volume = env_get("fw_ubi_volume");
> +#endif
>
> if (storage_interface && dev_part) {
> ret = fs_set_blk_dev(storage_interface, dev_part,
> FS_TYPE_ANY);
> @@ -159,6 +173,7 @@ static int fw_get_filesystem_firmware(struct
> udevice *dev)
> else
> ret = -ENODEV;
> } else {
> + debug("%s: init via platdata\n", __func__);
> ret = select_fs_dev(dev->platdata);
> }
>
> diff --git a/include/fs_loader.h b/include/fs_loader.h
> index b728c06fcf..adaa2b5db8 100644
> --- a/include/fs_loader.h
> +++ b/include/fs_loader.h
> @@ -28,11 +28,15 @@ struct phandle_part {
> * This holds information about all supported storage devices for
> driver use.
> *
> * @phandlepart: Attribute data for block device.
> + * @blkdev: Block device (alternative to using phandlepart)
> + * @blkpart: Partition number of block device (alternative to using
> phandlepart)
> * @mtdpart: MTD partition for ubi partition.
> * @ubivol: UBI volume-name for ubifsmount.
> */
> struct device_platdata {
> struct phandle_part phandlepart;
> + struct udevice *blkdev;
> + u32 blkpart;
> char *mtdpart;
> char *ubivol;
> };
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data
2019-05-21 5:40 ` Chee, Tien Fong
@ 2019-05-21 18:37 ` dannenberg at ti.com
0 siblings, 0 replies; 21+ messages in thread
From: dannenberg at ti.com @ 2019-05-21 18:37 UTC (permalink / raw)
To: u-boot
Hi TF,
first, thanks for taking time to continue having the discussion around
this patch series.
On Tue, May 21, 2019 at 05:40:59AM +0000, Chee, Tien Fong wrote:
> On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> > To give us more flexibility using the FS loader eliminate the need of
> > always having to use the ENV to configure the block device but rather
> > allow the respective block device and partition to be setup through
> > platform data.
> >
> > Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
>
> Why not using DT method?
We would like to use a single U-Boot build to support all of the
different boot modes (boot media) a given device supports. In case of
this RFC series this is really distilled down to only mmc0 and mmc1 but
this already illustrates the point. The patch 05/11 shows how
spl_boot_device() is used to make the MMC probing dependent on the boot
device mmc0 vs mmc1. So hard-coding in DT will lose this flexibility. Of
course there would be ways out such as dynamically updating DTS or to
extend the FS loader probe function to select from multiple DTS nodes
based on boot device, but all would come at a cost of additional memory
consumption.
--
Andreas Dannenberg
Texas Instruments Inc
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (3 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 04/11] misc: fs_loader: Allow initializing blkdev using platform data Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-21 5:21 ` Chee, Tien Fong
2019-05-21 5:41 ` Chee, Tien Fong
2019-05-16 20:54 ` [U-Boot] [RFC 06/11] armV7R: K3: am654: Allow using SPL BSS pre-relocation Andreas Dannenberg
` (6 subsequent siblings)
11 siblings, 2 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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 boot media using the FS loader
framework.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
arch/arm/mach-k3/Kconfig | 22 ++
arch/arm/mach-k3/Makefile | 3 +
arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 +
arch/arm/mach-k3/sysfw-loader.c | 296 +++++++++++++++++++
4 files changed, 333 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..fd28593cec 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -58,6 +58,28 @@ config SYS_K3_BOOT_CORE_ID
int
default 16
+config K3_LOAD_SYSFW
+ bool
+ depends on SPL
+
+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_SIZE_MAX
+ int "Amount of memory dynamically allocated for loading SYSFW blob"
+ depends on K3_LOAD_SYSFW
+ default 269000
+ help
+ Amount of memory (in bytes) 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..3af7f2ec96 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -7,4 +7,7 @@ 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
+ifeq ($(CONFIG_SPL_BUILD),y)
+obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
+endif
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..c335c7ed92
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018 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..1191640acd
--- /dev/null
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: System Firmware Loader
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andreas Dannenberg <dannenberg@ti.com>
+ */
+
+#include <common.h>
+#include <spl.h>
+#include <dm.h>
+#include <dm/uclass-internal.h>
+#include <dm/pinctrl.h>
+#include <remoteproc.h>
+#include <linux/libfdt.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+#include <image.h>
+#include <malloc.h>
+#include <fs_loader.h>
+#include <mmc.h>
+
+#include <asm/io.h>
+#include <asm/spl.h>
+#include <asm/sections.h>
+#include <asm/armv7_mpu.h>
+#include <asm/arch/hardware.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"
+
+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, struct ti_sci_handle **ti_sci)
+{
+ int images;
+ const void *sysfw_addr;
+ size_t sysfw_size;
+ struct udevice *dev;
+ 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);
+
+ /* Bring up the Device Management and Security Controller (SYSFW) */
+ ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", &dev);
+ if (ret)
+ panic("Failed to initialize SYSFW (%d)\n", ret);
+
+ /* Establish handle for easier access */
+ *ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
+}
+
+static void k3_sysfw_configure_using_fit(void *fit,
+ struct ti_sci_handle *ti_sci,
+ void (*config_pm_done_callback)(void))
+{
+ 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);
+
+ /*
+ * 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();
+}
+
+static int k3_sysfw_load_mmc_fs(const char *filename, void *buf, size_t max_size)
+{
+ int mmc_dev;
+ struct udevice *mmcdev;
+ struct mmc *mmc;
+ struct udevice *fsdev;
+ struct device_platdata *plat;
+ int ret;
+
+ /* Bring up the MMC boot device */
+
+ mmc_dev = spl_mmc_get_device_index(spl_boot_device());
+ if (mmc_dev < 0) {
+ pr_err("%s: Getting MMC device index failed (%d)\n", __func__,
+ mmc_dev);
+ return mmc_dev;
+ }
+
+ ret = uclass_get_device(UCLASS_MMC, mmc_dev, &mmcdev);
+ if (ret < 0) {
+ pr_err("%s: Getting MMC device failed (%d)\n", __func__, ret);
+ return ret;
+ }
+
+ ret = mmc_initialize(NULL);
+ if (ret < 0) {
+ pr_err("%s: Initializing MMC device failed (%d)\n", __func__,
+ ret);
+ return ret;
+ }
+
+ mmc = mmc_get_mmc_dev(mmcdev);
+ if (!mmc) {
+ pr_err("%s: Getting underlying MMC device failed\n", __func__);
+ return -ENODEV;
+ }
+
+ ret = mmc_init(mmc);
+ if (ret) {
+ printf("%s: mmc init failed with error: %d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Use the FS loader framework to perform the actual FW loading */
+
+ ret = uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, &fsdev);
+ if (ret < 0) {
+ pr_err("%s: Getting FW loader device failed (%d)\n", __func__,
+ ret);
+ return ret;
+ }
+
+ plat = fsdev->platdata;
+ plat->blkdev = mmcdev;
+ plat->blkpart = CONFIG_SYS_MMCSD_FS_BOOT_PARTITION;
+
+ return request_firmware_into_buf(fsdev, filename, buf, max_size, 0);
+}
+
+void k3_sysfw_loader(void (*config_pm_done_callback)(void))
+{
+ void *addr;
+ struct spl_boot_device bootdev = { 0 };
+ struct ti_sci_handle *ti_sci;
+ u32 boot_mode;
+ int ret;
+
+ addr = memalign(ARCH_DMA_MINALIGN, CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
+ if (!addr)
+ 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, addr);
+
+ bootdev.boot_device = spl_boot_device();
+ boot_mode = spl_boot_mode(bootdev.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:
+#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
+ if (boot_mode == MMCSD_MODE_FS) {
+ ret = k3_sysfw_load_mmc_fs(CONFIG_K3_SYSFW_IMAGE_NAME,
+ addr,
+ CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
+ } else
+#endif
+ {
+ panic("Non-FS load of SYSFW image from device %u not supported!\n",
+ bootdev.boot_device);
+ }
+ break;
+#endif
+ default:
+ panic("Loading SYSFW image from device %u not supported!\n",
+ bootdev.boot_device);
+ }
+
+ if (ret < 0)
+ panic("Error %d occurred during loading SYSFW image!\n", ret);
+
+ /* Ensure the SYSFW image is in FIT format */
+ if (image_get_magic((const image_header_t *)addr) != FDT_MAGIC)
+ panic("SYSFW image not in FIT format!\n");
+
+ /* Extract and start SYSFW */
+ k3_sysfw_load_using_fit(addr, &ti_sci);
+
+ /* Parse and apply the different SYSFW configuration fragments */
+ k3_sysfw_configure_using_fit(addr, ti_sci, 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);
+}
--
2.17.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework
2019-05-16 20:54 ` [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework Andreas Dannenberg
@ 2019-05-21 5:21 ` Chee, Tien Fong
2019-05-21 18:42 ` dannenberg at ti.com
2019-05-21 5:41 ` Chee, Tien Fong
1 sibling, 1 reply; 21+ messages in thread
From: Chee, Tien Fong @ 2019-05-21 5:21 UTC (permalink / raw)
To: u-boot
On Thu, 2019-05-16 at 15:54 -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 boot media using the FS
> loader
> framework.
>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> ---
> arch/arm/mach-k3/Kconfig | 22 ++
> arch/arm/mach-k3/Makefile | 3 +
> arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 +
> arch/arm/mach-k3/sysfw-loader.c | 296
> +++++++++++++++++++
> 4 files changed, 333 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..fd28593cec 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -58,6 +58,28 @@ config SYS_K3_BOOT_CORE_ID
> int
> default 16
>
> +config K3_LOAD_SYSFW
> + bool
> + depends on SPL
> +
> +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_SIZE_MAX
> + int "Amount of memory dynamically allocated for loading
> SYSFW blob"
> + depends on K3_LOAD_SYSFW
> + default 269000
> + help
> + Amount of memory (in bytes) 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..3af7f2ec96 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -7,4 +7,7 @@ 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
> +ifeq ($(CONFIG_SPL_BUILD),y)
> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> +endif
> 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..c335c7ed92
> --- /dev/null
> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2018 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..1191640acd
> --- /dev/null
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: System Firmware Loader
> + *
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti
> .com/
> + * Andreas Dannenberg <dannenberg@ti.com>
> + */
> +
> +#include <common.h>
> +#include <spl.h>
> +#include <dm.h>
> +#include <dm/uclass-internal.h>
> +#include <dm/pinctrl.h>
> +#include <remoteproc.h>
> +#include <linux/libfdt.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +#include <image.h>
> +#include <malloc.h>
> +#include <fs_loader.h>
> +#include <mmc.h>
> +
> +#include <asm/io.h>
> +#include <asm/spl.h>
> +#include <asm/sections.h>
> +#include <asm/armv7_mpu.h>
> +#include <asm/arch/hardware.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"
> +
> +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, struct ti_sci_handle
> **ti_sci)
> +{
> + int images;
> + const void *sysfw_addr;
> + size_t sysfw_size;
> + struct udevice *dev;
> + 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);
> +
> + /* Bring up the Device Management and Security Controller
> (SYSFW) */
> + ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc",
> &dev);
> + if (ret)
> + panic("Failed to initialize SYSFW (%d)\n", ret);
> +
> + /* Establish handle for easier access */
> + *ti_sci = (struct ti_sci_handle
> *)(ti_sci_get_handle_from_sysfw(dev));
> +}
> +
> +static void k3_sysfw_configure_using_fit(void *fit,
> + struct ti_sci_handle
> *ti_sci,
> + void
> (*config_pm_done_callback)(void))
> +{
> + 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_fragmen
> t_addr,
> + (u32)cfg_fragment_siz
> e);
> + if (ret)
> + panic("Failed to set board security configuration
> (%d)\n",
> + ret);
> +
> + /*
> + * 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();
> +}
> +
> +static int k3_sysfw_load_mmc_fs(const char *filename, void *buf,
> size_t max_size)
> +{
> + int mmc_dev;
> + struct udevice *mmcdev;
> + struct mmc *mmc;
> + struct udevice *fsdev;
> + struct device_platdata *plat;
> + int ret;
> +
> + /* Bring up the MMC boot device */
> +
> + mmc_dev = spl_mmc_get_device_index(spl_boot_device());
> + if (mmc_dev < 0) {
> + pr_err("%s: Getting MMC device index failed (%d)\n",
> __func__,
> + mmc_dev);
> + return mmc_dev;
> + }
> +
> + ret = uclass_get_device(UCLASS_MMC, mmc_dev, &mmcdev);
> + if (ret < 0) {
> + pr_err("%s: Getting MMC device failed (%d)\n",
> __func__, ret);
> + return ret;
> + }
> +
> + ret = mmc_initialize(NULL);
> + if (ret < 0) {
> + pr_err("%s: Initializing MMC device failed (%d)\n",
> __func__,
> + ret);
> + return ret;
> + }
> +
> + mmc = mmc_get_mmc_dev(mmcdev);
> + if (!mmc) {
> + pr_err("%s: Getting underlying MMC device failed\n",
> __func__);
> + return -ENODEV;
> + }
> +
> + ret = mmc_init(mmc);
> + if (ret) {
> + printf("%s: mmc init failed with error: %d\n",
> __func__, ret);
> + return ret;
> + }
> +
The probe function in fs loader already support the block init, and the
block init would init the mmc.
> + /* Use the FS loader framework to perform the actual FW
> loading */
> +
> + ret = uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0,
> &fsdev);
> + if (ret < 0) {
> + pr_err("%s: Getting FW loader device failed (%d)\n",
> __func__,
> + ret);
> + return ret;
> + }
> +
> + plat = fsdev->platdata;
> + plat->blkdev = mmcdev;
> + plat->blkpart = CONFIG_SYS_MMCSD_FS_BOOT_PARTITION;
> +
> + return request_firmware_into_buf(fsdev, filename, buf,
> max_size, 0);
> +}
> +
> +void k3_sysfw_loader(void (*config_pm_done_callback)(void))
> +{
> + void *addr;
> + struct spl_boot_device bootdev = { 0 };
> + struct ti_sci_handle *ti_sci;
> + u32 boot_mode;
> + int ret;
> +
> + addr = memalign(ARCH_DMA_MINALIGN,
> CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
> + if (!addr)
> + 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, addr);
> +
> + bootdev.boot_device = spl_boot_device();
> + boot_mode = spl_boot_mode(bootdev.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:
> +#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
> + if (boot_mode == MMCSD_MODE_FS) {
> + ret =
> k3_sysfw_load_mmc_fs(CONFIG_K3_SYSFW_IMAGE_NAME,
> + addr,
> + CONFIG_K3_SYSFW_I
> MAGE_SIZE_MAX);
> + } else
> +#endif
> + {
> + panic("Non-FS load of SYSFW image from
> device %u not supported!\n",
> + bootdev.boot_device);
> + }
> + break;
> +#endif
> + default:
> + panic("Loading SYSFW image from device %u not
> supported!\n",
> + bootdev.boot_device);
> + }
> +
> + if (ret < 0)
> + panic("Error %d occurred during loading SYSFW
> image!\n", ret);
> +
> + /* Ensure the SYSFW image is in FIT format */
> + if (image_get_magic((const image_header_t *)addr) !=
> FDT_MAGIC)
> + panic("SYSFW image not in FIT format!\n");
> +
> + /* Extract and start SYSFW */
> + k3_sysfw_load_using_fit(addr, &ti_sci);
> +
> + /* Parse and apply the different SYSFW configuration
> fragments */
> + k3_sysfw_configure_using_fit(addr, ti_sci,
> 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);
> +}
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework
2019-05-21 5:21 ` Chee, Tien Fong
@ 2019-05-21 18:42 ` dannenberg at ti.com
0 siblings, 0 replies; 21+ messages in thread
From: dannenberg at ti.com @ 2019-05-21 18:42 UTC (permalink / raw)
To: u-boot
Hi TF,
On Tue, May 21, 2019 at 05:21:15AM +0000, Chee, Tien Fong wrote:
> On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> > + if (mmc_dev < 0) {
> > + pr_err("%s: Getting MMC device index failed (%d)\n",
> > __func__,
> > + mmc_dev);
> > + return mmc_dev;
> > + }
> > +
> > + ret = uclass_get_device(UCLASS_MMC, mmc_dev, &mmcdev);
> > + if (ret < 0) {
> > + pr_err("%s: Getting MMC device failed (%d)\n",
> > __func__, ret);
> > + return ret;
> > + }
> > +
> > + ret = mmc_initialize(NULL);
> > + if (ret < 0) {
> > + pr_err("%s: Initializing MMC device failed (%d)\n",
> > __func__,
> > + ret);
> > + return ret;
> > + }
> > +
> > + mmc = mmc_get_mmc_dev(mmcdev);
> > + if (!mmc) {
> > + pr_err("%s: Getting underlying MMC device failed\n",
> > __func__);
> > + return -ENODEV;
> > + }
> > +
> > + ret = mmc_init(mmc);
> > + if (ret) {
> > + printf("%s: mmc init failed with error: %d\n",
> > __func__, ret);
> > + return ret;
> > + }
> > +
>
> The probe function in fs loader already support the block init, and the
> block init would init the mmc.
Yes I'm sure this could have gotten simplified if I were to use the DTS
to describe the boot device. But as explained earlier I was exploring a
way to make it work without DTS for added flexibility so I can pick the
boot device at runtime.
--
Andreas Dannenberg
Texas Instruments Inc
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework
2019-05-16 20:54 ` [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework Andreas Dannenberg
2019-05-21 5:21 ` Chee, Tien Fong
@ 2019-05-21 5:41 ` Chee, Tien Fong
1 sibling, 0 replies; 21+ messages in thread
From: Chee, Tien Fong @ 2019-05-21 5:41 UTC (permalink / raw)
To: u-boot
On Thu, 2019-05-16 at 15:54 -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 boot media using the FS
> loader
> framework.
>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> ---
> arch/arm/mach-k3/Kconfig | 22 ++
> arch/arm/mach-k3/Makefile | 3 +
> arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 +
> arch/arm/mach-k3/sysfw-loader.c | 296
> +++++++++++++++++++
> 4 files changed, 333 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..fd28593cec 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -58,6 +58,28 @@ config SYS_K3_BOOT_CORE_ID
> int
> default 16
>
> +config K3_LOAD_SYSFW
> + bool
> + depends on SPL
> +
> +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_SIZE_MAX
> + int "Amount of memory dynamically allocated for loading
> SYSFW blob"
> + depends on K3_LOAD_SYSFW
> + default 269000
> + help
> + Amount of memory (in bytes) 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..3af7f2ec96 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -7,4 +7,7 @@ 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
> +ifeq ($(CONFIG_SPL_BUILD),y)
> +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> +endif
> 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..c335c7ed92
> --- /dev/null
> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2018 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..1191640acd
> --- /dev/null
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: System Firmware Loader
> + *
> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti
> .com/
> + * Andreas Dannenberg <dannenberg@ti.com>
> + */
> +
> +#include <common.h>
> +#include <spl.h>
> +#include <dm.h>
> +#include <dm/uclass-internal.h>
> +#include <dm/pinctrl.h>
> +#include <remoteproc.h>
> +#include <linux/libfdt.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +#include <image.h>
> +#include <malloc.h>
> +#include <fs_loader.h>
> +#include <mmc.h>
> +
> +#include <asm/io.h>
> +#include <asm/spl.h>
> +#include <asm/sections.h>
> +#include <asm/armv7_mpu.h>
> +#include <asm/arch/hardware.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"
> +
> +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, struct ti_sci_handle
> **ti_sci)
> +{
> + int images;
> + const void *sysfw_addr;
> + size_t sysfw_size;
> + struct udevice *dev;
> + 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);
> +
> + /* Bring up the Device Management and Security Controller
> (SYSFW) */
> + ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc",
> &dev);
> + if (ret)
> + panic("Failed to initialize SYSFW (%d)\n", ret);
> +
> + /* Establish handle for easier access */
> + *ti_sci = (struct ti_sci_handle
> *)(ti_sci_get_handle_from_sysfw(dev));
> +}
> +
> +static void k3_sysfw_configure_using_fit(void *fit,
> + struct ti_sci_handle
> *ti_sci,
> + void
> (*config_pm_done_callback)(void))
> +{
> + 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_fragmen
> t_addr,
> + (u32)cfg_fragment_siz
> e);
> + if (ret)
> + panic("Failed to set board security configuration
> (%d)\n",
> + ret);
> +
> + /*
> + * 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();
> +}
> +
> +static int k3_sysfw_load_mmc_fs(const char *filename, void *buf,
> size_t max_size)
> +{
> + int mmc_dev;
> + struct udevice *mmcdev;
> + struct mmc *mmc;
> + struct udevice *fsdev;
> + struct device_platdata *plat;
> + int ret;
> +
> + /* Bring up the MMC boot device */
> +
> + mmc_dev = spl_mmc_get_device_index(spl_boot_device());
> + if (mmc_dev < 0) {
> + pr_err("%s: Getting MMC device index failed (%d)\n",
> __func__,
> + mmc_dev);
> + return mmc_dev;
> + }
> +
> + ret = uclass_get_device(UCLASS_MMC, mmc_dev, &mmcdev);
> + if (ret < 0) {
> + pr_err("%s: Getting MMC device failed (%d)\n",
> __func__, ret);
> + return ret;
> + }
> +
> + ret = mmc_initialize(NULL);
> + if (ret < 0) {
> + pr_err("%s: Initializing MMC device failed (%d)\n",
> __func__,
> + ret);
> + return ret;
> + }
> +
> + mmc = mmc_get_mmc_dev(mmcdev);
> + if (!mmc) {
> + pr_err("%s: Getting underlying MMC device failed\n",
> __func__);
> + return -ENODEV;
> + }
> +
> + ret = mmc_init(mmc);
> + if (ret) {
> + printf("%s: mmc init failed with error: %d\n",
> __func__, ret);
> + return ret;
> + }
> +
Can use the fs loader probe for mmc init.
> + /* Use the FS loader framework to perform the actual FW
> loading */
> +
> + ret = uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0,
> &fsdev);
> + if (ret < 0) {
> + pr_err("%s: Getting FW loader device failed (%d)\n",
> __func__,
> + ret);
> + return ret;
> + }
> +
> + plat = fsdev->platdata;
> + plat->blkdev = mmcdev;
> + plat->blkpart = CONFIG_SYS_MMCSD_FS_BOOT_PARTITION;
> +
> + return request_firmware_into_buf(fsdev, filename, buf,
> max_size, 0);
> +}
> +
> +void k3_sysfw_loader(void (*config_pm_done_callback)(void))
> +{
> + void *addr;
> + struct spl_boot_device bootdev = { 0 };
> + struct ti_sci_handle *ti_sci;
> + u32 boot_mode;
> + int ret;
> +
> + addr = memalign(ARCH_DMA_MINALIGN,
> CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
> + if (!addr)
> + 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, addr);
> +
> + bootdev.boot_device = spl_boot_device();
> + boot_mode = spl_boot_mode(bootdev.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:
> +#ifdef CONFIG_K3_SYSFW_IMAGE_NAME
> + if (boot_mode == MMCSD_MODE_FS) {
> + ret =
> k3_sysfw_load_mmc_fs(CONFIG_K3_SYSFW_IMAGE_NAME,
> + addr,
> + CONFIG_K3_SYSFW_I
> MAGE_SIZE_MAX);
> + } else
> +#endif
> + {
> + panic("Non-FS load of SYSFW image from
> device %u not supported!\n",
> + bootdev.boot_device);
> + }
> + break;
> +#endif
> + default:
> + panic("Loading SYSFW image from device %u not
> supported!\n",
> + bootdev.boot_device);
> + }
> +
> + if (ret < 0)
> + panic("Error %d occurred during loading SYSFW
> image!\n", ret);
> +
> + /* Ensure the SYSFW image is in FIT format */
> + if (image_get_magic((const image_header_t *)addr) !=
> FDT_MAGIC)
> + panic("SYSFW image not in FIT format!\n");
> +
> + /* Extract and start SYSFW */
> + k3_sysfw_load_using_fit(addr, &ti_sci);
> +
> + /* Parse and apply the different SYSFW configuration
> fragments */
> + k3_sysfw_configure_using_fit(addr, ti_sci,
> 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);
> +}
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC 06/11] armV7R: K3: am654: Allow using SPL BSS pre-relocation
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (4 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 05/11] arm: K3: Introduce System Firmware loader framework Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 07/11] armv7R: K3: am654: Use full malloc implementation in SPL Andreas Dannenberg
` (5 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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..22477efa5b 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 global
+ * data 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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 07/11] armv7R: K3: am654: Use full malloc implementation in SPL
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (5 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 06/11] armV7R: K3: am654: Allow using SPL BSS pre-relocation Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 08/11] armV7R: K3: am654: Load SYSFW binary and config from boot media Andreas Dannenberg
` (4 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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 3814872ec7..73f614944f 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 0b12f15782..49eca7de64 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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 08/11] armV7R: K3: am654: Load SYSFW binary and config from boot media
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (6 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 07/11] armv7R: K3: am654: Use full malloc implementation in SPL Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC Andreas Dannenberg
` (3 subsequent siblings)
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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 22477efa5b..f50eded03f 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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (7 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 08/11] armV7R: K3: am654: Load SYSFW binary and config from boot media Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-21 5:40 ` Chee, Tien Fong
2019-05-16 20:54 ` [U-Boot] [RFC 10/11] configs: am65x_evm_r5: All sysfw to be loaded via MMC Andreas Dannenberg
` (2 subsequent siblings)
11 siblings, 1 reply; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
From: Lokesh Vutla <lokeshvutla@ti.com>
In order to load the sysfw.itb from an 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.
Furthermore, create a new node for the FS loader framework which we want
to use to load the actual firmware file from the boot media.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
---
arch/arm/dts/k3-am654-r5-base-board.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 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..75880158a2 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -22,6 +22,12 @@
chosen {
stdout-path = "serial2:115200n8";
tick-timer = &timer1;
+ firmware-loader = &fs_loader0;
+ };
+
+ fs_loader0: fs_loader at 0 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
};
aliases {
@@ -96,6 +102,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 +149,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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC
2019-05-16 20:54 ` [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC Andreas Dannenberg
@ 2019-05-21 5:40 ` Chee, Tien Fong
2019-05-21 18:53 ` dannenberg at ti.com
0 siblings, 1 reply; 21+ messages in thread
From: Chee, Tien Fong @ 2019-05-21 5:40 UTC (permalink / raw)
To: u-boot
On Thu, 2019-05-16 at 15:54 -0500, Andreas Dannenberg wrote:
> From: Lokesh Vutla <lokeshvutla@ti.com>
>
> In order to load the sysfw.itb from an 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.
>
> Furthermore, create a new node for the FS loader framework which we
> want
> to use to load the actual firmware file from the boot media.
>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> ---
> arch/arm/dts/k3-am654-r5-base-board.dts | 24
> ++++++++++++++++++++++++
> 1 file changed, 24 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..75880158a2 100644
> --- a/arch/arm/dts/k3-am654-r5-base-board.dts
> +++ b/arch/arm/dts/k3-am654-r5-base-board.dts
> @@ -22,6 +22,12 @@
> chosen {
> stdout-path = "serial2:115200n8";
> tick-timer = &timer1;
> + firmware-loader = &fs_loader0;
> + };
> +
> + fs_loader0: fs_loader at 0 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
Why not using phandlepart = <&mmc 1>, this would help to avoid mmc init
duplication in a few places such as patch [05/11].
> };
>
> aliases {
> @@ -96,6 +102,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 +149,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;
> +};
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC
2019-05-21 5:40 ` Chee, Tien Fong
@ 2019-05-21 18:53 ` dannenberg at ti.com
0 siblings, 0 replies; 21+ messages in thread
From: dannenberg at ti.com @ 2019-05-21 18:53 UTC (permalink / raw)
To: u-boot
Hi TF,
On Tue, May 21, 2019 at 05:40:19AM +0000, Chee, Tien Fong wrote:
> > + fs_loader0: fs_loader at 0 {
> > + u-boot,dm-pre-reloc;
> > + compatible = "u-boot,fs-loader";
>
> Why not using phandlepart = <&mmc 1>, this would help to avoid mmc init
> duplication in a few places such as patch [05/11].
>
See comment on earlier patch, this path was chosen to allow for
flexibility during runtime. When using FS loader as you intended it to
get used it works very well (we are actually using it for other purposes
on another device).
Hence my argument that the approach I chose with the original [1] SYSFW
loader series of opening up the SPL loader framework in a "lean & mean"
fashion and the FS loader driver as it is today are really things that
are complementary and can co-exist when one starts looking under the hood.
--
Andreas Dannenberg
Texas Instruments Inc
[1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC 10/11] configs: am65x_evm_r5: All sysfw to be loaded via MMC
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (8 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-16 20:54 ` [U-Boot] [RFC 11/11] configs: am65x_hs_evm_r5: " Andreas Dannenberg
2019-05-17 11:24 ` [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Tom Rini
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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 | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 73f614944f..7633e42065 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
@@ -60,6 +61,7 @@ CONFIG_DA8XX_GPIO=y
CONFIG_DM_MAILBOX=y
CONFIG_K3_SEC_PROXY=y
CONFIG_MISC=y
+CONFIG_FS_LOADER=y
CONFIG_DM_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_K3_ARASAN=y
@@ -87,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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 11/11] configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (9 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 10/11] configs: am65x_evm_r5: All sysfw to be loaded via MMC Andreas Dannenberg
@ 2019-05-16 20:54 ` Andreas Dannenberg
2019-05-17 11:24 ` [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Tom Rini
11 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-16 20:54 UTC (permalink / raw)
To: u-boot
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 | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig
index 49eca7de64..4c3bf54e27 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
@@ -62,6 +63,7 @@ CONFIG_DA8XX_GPIO=y
CONFIG_DM_MAILBOX=y
CONFIG_K3_SEC_PROXY=y
CONFIG_MISC=y
+CONFIG_FS_LOADER=y
CONFIG_DM_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_K3_ARASAN=y
@@ -89,3 +91,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
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader
2019-05-16 20:54 [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Andreas Dannenberg
` (10 preceding siblings ...)
2019-05-16 20:54 ` [U-Boot] [RFC 11/11] configs: am65x_hs_evm_r5: " Andreas Dannenberg
@ 2019-05-17 11:24 ` Tom Rini
2019-05-21 19:04 ` Andreas Dannenberg
11 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2019-05-17 11:24 UTC (permalink / raw)
To: u-boot
On Thu, May 16, 2019 at 03:54:43PM -0500, Andreas Dannenberg wrote:
> This series provides an alternative solution to the previously posted
> series titled "System Firmware Loader for TI K3 family SoCs" [1] using
> the existing FS loader driver rather than extending the SPL loader
> framework like the original patch series. Unlike the original series,
> it does not support eMMC/SD partition/sector based RAW loading, and
> it is larger in size.
>
> It is only provided to support the discussion around to the initial
> series posted as "System Firmware Loader for TI K3 family SoCs" and
> is not intended to supersede this series, hence it is labeled as
> "RFC".
>
> The interesting pieces are really in patches 04/11 (extension of
> FS loader to allow using platform data so one does not have to use
> either ENV or DTS), and 05/11 which implementes the usage of FS
> loader, including the required sequence of MMC initialization steps
> inspired by how SPL does it.
>
> [1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461
Andreas, thanks for posting this.
TF, do you see some way, given this series, to make changes such that
"fs_loader" can be made smaller? And support more of Andreas' use cases
than it does here? 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/750a033f/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader
2019-05-17 11:24 ` [U-Boot] [RFC 00/11] SYSFW Loader for TI K3 family SoCs using FS Loader Tom Rini
@ 2019-05-21 19:04 ` Andreas Dannenberg
0 siblings, 0 replies; 21+ messages in thread
From: Andreas Dannenberg @ 2019-05-21 19:04 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Fri, May 17, 2019 at 07:24:48AM -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 03:54:43PM -0500, Andreas Dannenberg wrote:
>
> > This series provides an alternative solution to the previously posted
> > series titled "System Firmware Loader for TI K3 family SoCs" [1] using
> > the existing FS loader driver rather than extending the SPL loader
> > framework like the original patch series. Unlike the original series,
> > it does not support eMMC/SD partition/sector based RAW loading, and
> > it is larger in size.
> >
> > It is only provided to support the discussion around to the initial
> > series posted as "System Firmware Loader for TI K3 family SoCs" and
> > is not intended to supersede this series, hence it is labeled as
> > "RFC".
> >
> > The interesting pieces are really in patches 04/11 (extension of
> > FS loader to allow using platform data so one does not have to use
> > either ENV or DTS), and 05/11 which implementes the usage of FS
> > loader, including the required sequence of MMC initialization steps
> > inspired by how SPL does it.
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461
>
> Andreas, thanks for posting this.
>
> TF, do you see some way, given this series, to make changes such that
> "fs_loader" can be made smaller? And support more of Andreas' use cases
> than it does here? Thanks!
I'm not sure FS loader can be made much smaller but I'm more concerned
how it would scale if I were to add support for the other boot modes we
need such as eMMC/SD raw mode, QSPI/OSPI, Y-Modem, and others to come.
For all of those we have a solution in production similar to what was
proposed here [1] tapping into the SPL loader framework at (almost) zero
cost. Growing FS loader beyond what it is today plus adding in the
support for runtime-selection of firmware load media all added up may
quickly become prohibitive for very space constrained scenarios like on
our AM654x devices.
--
Andreas Dannenberg
Texas Instruments Inc
[1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461
^ permalink raw reply [flat|nested] 21+ messages in thread