All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
@ 2022-12-07  6:23 Rick Chen
  2022-12-07  6:23 ` [PATCH 2/4] riscv: dts: Support Fast-Boot Rick Chen
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-07  6:23 UTC (permalink / raw)
  To: ycliang, rickchen36, rick; +Cc: u-boot, trini, sjg, xypron.glpk

In RISC-V, it only provide normal mode booting currently.
To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
to achieve this feature which will be call Fast-Boot mode. By
enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
of default u-boot.itb after compiling. It initializes memory with
the U-Boot SPL at the first stage, just like what a regular booting
process (i.e. Normal Boot) does in the beginning. Instead of jumping
to the U-Boot proper from OpenSBI before booting Linux Kernel, the
Fast Boot process jumps directly to Linux Kernel to gain shorter
booting time.

Signed-off-by: Rick Chen <rick@andestech.com>
---
 common/spl/Kconfig       | 14 ++++++++++++++
 common/spl/spl_fit.c     |  3 ++-
 common/spl/spl_opensbi.c | 25 ++++++++++++-------------
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 05181bdba3..8805aba1b7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
 	  Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
 	  SBI_SCRATCH_DEBUG_PRINTS.
 
+config SPL_OPENSBI_OS_BOOT
+	bool "openSBI Fast Boot"
+	depends on SPL_OPENSBI
+	help
+	  Enable this openSBI can jump to Linux Kernel directly.
+
+config SPL_OPENSBI_FIT_NAME
+	string "SPL openSBI fit image name"
+	depends on SPL_OPENSBI
+	default "linux.itb" if SPL_OPENSBI_OS_BOOT
+	default "u-boot.itb"
+	help
+	  This will help to generate different fit name accordingly.
+
 config SPL_TARGET
 	string "Addtional build targets for 'make'"
 	default "spl/u-boot-spl.srec" if RCAR_GEN2
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index c1ed31e367..c5b1dfb3ba 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -363,7 +363,8 @@ static bool os_takes_devicetree(uint8_t os)
 	case IH_OS_U_BOOT:
 		return true;
 	case IH_OS_LINUX:
-		return IS_ENABLED(CONFIG_SPL_OS_BOOT);
+		return IS_ENABLED(CONFIG_SPL_OS_BOOT) ||
+			IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT);
 	default:
 		return false;
 	}
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index b0f40076c3..83869c6b18 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -20,7 +20,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 struct fw_dynamic_info opensbi_info;
 
-static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
+static int spl_opensbi_find_os_node(void *blob, int *os_node)
 {
 	int fit_images_node, node;
 	const char *fit_os;
@@ -34,10 +34,9 @@ static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
 		if (!fit_os)
 			continue;
 
-		if (genimg_get_os_id(fit_os) == IH_OS_U_BOOT) {
-			*uboot_node = node;
-			return 0;
-		}
+		*os_node = node;
+
+		return 0;
 	}
 
 	return -ENODEV;
@@ -45,8 +44,8 @@ static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
 
 void spl_invoke_opensbi(struct spl_image_info *spl_image)
 {
-	int ret, uboot_node;
-	ulong uboot_entry;
+	int ret, os_node;
+	ulong os_entry;
 	void (*opensbi_entry)(ulong hartid, ulong dtb, ulong info);
 
 	if (!spl_image->fdt_addr) {
@@ -54,22 +53,22 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
 		hang();
 	}
 
-	/* Find U-Boot image in /fit-images */
-	ret = spl_opensbi_find_uboot_node(spl_image->fdt_addr, &uboot_node);
+	/* Find U-Boot or Linux image in /fit-images */
+	ret = spl_opensbi_find_os_node(spl_image->fdt_addr, &os_node);
 	if (ret) {
 		pr_err("Can't find U-Boot node, %d\n", ret);
 		hang();
 	}
 
-	/* Get U-Boot entry point */
-	ret = fit_image_get_entry(spl_image->fdt_addr, uboot_node, &uboot_entry);
+	/* Get os entry point */
+	ret = fit_image_get_entry(spl_image->fdt_addr, os_node, &os_entry);
 	if (ret)
-		ret = fit_image_get_load(spl_image->fdt_addr, uboot_node, &uboot_entry);
+		ret = fit_image_get_load(spl_image->fdt_addr, os_node, &os_entry);
 
 	/* Prepare opensbi_info object */
 	opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE;
 	opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
-	opensbi_info.next_addr = uboot_entry;
+	opensbi_info.next_addr = os_entry;
 	opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
 	opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
 	opensbi_info.boot_hart = gd->arch.boot_hart;
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 2/4] riscv: dts: Support Fast-Boot
  2022-12-07  6:23 [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Rick Chen
@ 2022-12-07  6:23 ` Rick Chen
  2022-12-07  6:23 ` [PATCH 3/4] riscv: ae350: Support Fast Boot Rick Chen
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-07  6:23 UTC (permalink / raw)
  To: ycliang, rickchen36, rick; +Cc: u-boot, trini, sjg, xypron.glpk

By enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
of default u-boot.itb after compiling. And Lnux Kernel Image will be
appended in linux.itb. Then it can jump to Linux Kernel from openSBI
directly.

Signed-off-by: Rick Chen <rick@andestech.com>
---
 arch/riscv/dts/binman.dtsi | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi
index b8fc8f7f35..ca72719d19 100644
--- a/arch/riscv/dts/binman.dtsi
+++ b/arch/riscv/dts/binman.dtsi
@@ -13,14 +13,27 @@
 
 &binman {
 	itb {
-		filename = "u-boot.itb";
+		filename = CONFIG_SPL_OPENSBI_FIT_NAME;
 
 		fit {
-			description = "Configuration to load OpenSBI before U-Boot";
+			description = "Configuration to load OpenSBI before OS";
 			#address-cells = <1>;
 			fit,fdt-list = "of-list";
 
 			images {
+#ifdef CONFIG_SPL_OPENSBI_OS_BOOT
+				linux {
+					description = "Linux";
+					type = "standalone";
+					os = "Linux";
+					arch = "riscv";
+					compression = "none";
+					load = <CONFIG_TEXT_BASE>;
+					linux_blob: blob-ext {
+						filename = "Image";
+					};
+				};
+#else
 				uboot {
 					description = "U-Boot";
 					type = "standalone";
@@ -33,6 +46,7 @@
 						filename = "u-boot-nodtb.bin";
 					};
 				};
+#endif
 
 				opensbi {
 					description = "OpenSBI fw_dynamic Firmware";
@@ -72,6 +86,12 @@
 					fdt = "fdt-SEQ";
 #endif
 				};
+
+				conf-2 {
+					description = "linux";
+					firmware = "opensbi";
+					loadables = "linux";
+				};
 			};
 		};
 	};
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 3/4] riscv: ae350: Support Fast Boot
  2022-12-07  6:23 [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Rick Chen
  2022-12-07  6:23 ` [PATCH 2/4] riscv: dts: Support Fast-Boot Rick Chen
@ 2022-12-07  6:23 ` Rick Chen
  2022-12-07  6:23 ` [PATCH 4/4] doc: ae350: Add Fast Boot description Rick Chen
  2022-12-09 13:48 ` [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Sean Anderson
  3 siblings, 0 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-07  6:23 UTC (permalink / raw)
  To: ycliang, rickchen36, rick; +Cc: u-boot, trini, sjg, xypron.glpk

Add defconfig for Fast Boot

Signed-off-by: Rick Chen <rick@andestech.com>
---
 board/AndesTech/ax25-ae350/ax25-ae350.c   |  7 ++-
 configs/ae350_rv32_spl_fastboot_defconfig | 53 +++++++++++++++++++++++
 configs/ae350_rv64_spl_fastboot_defconfig | 53 +++++++++++++++++++++++
 3 files changed, 111 insertions(+), 2 deletions(-)
 create mode 100644 configs/ae350_rv32_spl_fastboot_defconfig
 create mode 100644 configs/ae350_rv64_spl_fastboot_defconfig

diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 63a966e092..b5b2b93f76 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -134,7 +134,10 @@ void board_boot_order(u32 *spl_boot_list)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-	/* boot using first FIT config */
-	return 0;
+#if IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT)
+		return strcmp("linux", name);
+#endif
+
+	return -EINVAL;
 }
 #endif
diff --git a/configs/ae350_rv32_spl_fastboot_defconfig b/configs/ae350_rv32_spl_fastboot_defconfig
new file mode 100644
index 0000000000..fe9959b75e
--- /dev/null
+++ b/configs/ae350_rv32_spl_fastboot_defconfig
@@ -0,0 +1,53 @@
+CONFIG_RISCV=y
+CONFIG_TEXT_BASE=0x01800000
+CONFIG_SYS_MALLOC_LEN=0x80000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SECT_SIZE=0x1000
+CONFIG_DEFAULT_DEVICE_TREE="ae350_32"
+CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000000
+CONFIG_SPL=y
+CONFIG_SPL_OPENSBI_OS_BOOT=y
+CONFIG_SYS_LOAD_ADDR=0x100000
+CONFIG_TARGET_AX25_AE350=y
+CONFIG_RISCV_SMODE=y
+# CONFIG_AVAILABLE_HARTS is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xfffff00
+CONFIG_SYS_MONITOR_LEN=786432
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x10000000
+CONFIG_SYS_MONITOR_BASE=0x88000000
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_MAX_SIZE=0x100000
+CONFIG_SPL_BSS_START_ADDR=0x400000
+CONFIG_SYS_PBSIZE=1050
+CONFIG_SYS_BOOTM_LEN=0x4000000
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF_TEST=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_BOOTP_PREFER_SERVERIP=y
+CONFIG_CMD_CACHE=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_MMC=y
+CONFIG_FTSDC010=y
+CONFIG_FTSDC010_SDIO=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_SYS_FLASH_CFI_WIDTH_16BIT=y
+CONFIG_SYS_CFI_FLASH_STATUS_POLL=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_FTMAC100=y
+CONFIG_BAUDRATE=38400
+CONFIG_SYS_NS16550=y
+CONFIG_SPI=y
+CONFIG_ATCSPI200_SPI=y
+# CONFIG_BINMAN_FDT is not set
diff --git a/configs/ae350_rv64_spl_fastboot_defconfig b/configs/ae350_rv64_spl_fastboot_defconfig
new file mode 100644
index 0000000000..118d13bcda
--- /dev/null
+++ b/configs/ae350_rv64_spl_fastboot_defconfig
@@ -0,0 +1,53 @@
+CONFIG_RISCV=y
+CONFIG_TEXT_BASE=0x01800000
+CONFIG_SYS_MALLOC_LEN=0x80000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SECT_SIZE=0x1000
+CONFIG_DEFAULT_DEVICE_TREE="ae350_64"
+CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000000
+CONFIG_SPL=y
+CONFIG_SPL_OPENSBI_OS_BOOT=y
+CONFIG_SYS_LOAD_ADDR=0x100000
+CONFIG_TARGET_AX25_AE350=y
+CONFIG_ARCH_RV64I=y
+CONFIG_RISCV_SMODE=y
+# CONFIG_AVAILABLE_HARTS is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xffffe70
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x10000000
+CONFIG_SYS_MONITOR_BASE=0x88000000
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_MAX_SIZE=0x100000
+CONFIG_SPL_BSS_START_ADDR=0x400000
+CONFIG_SYS_PBSIZE=1050
+CONFIG_SYS_BOOTM_LEN=0x4000000
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF_TEST=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_BOOTP_PREFER_SERVERIP=y
+CONFIG_CMD_CACHE=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_MMC=y
+CONFIG_FTSDC010=y
+CONFIG_FTSDC010_SDIO=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_SYS_FLASH_CFI_WIDTH_16BIT=y
+CONFIG_SYS_CFI_FLASH_STATUS_POLL=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_FTMAC100=y
+CONFIG_BAUDRATE=38400
+CONFIG_SYS_NS16550=y
+CONFIG_SPI=y
+CONFIG_ATCSPI200_SPI=y
+# CONFIG_BINMAN_FDT is not set
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 4/4] doc: ae350: Add Fast Boot description
  2022-12-07  6:23 [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Rick Chen
  2022-12-07  6:23 ` [PATCH 2/4] riscv: dts: Support Fast-Boot Rick Chen
  2022-12-07  6:23 ` [PATCH 3/4] riscv: ae350: Support Fast Boot Rick Chen
@ 2022-12-07  6:23 ` Rick Chen
  2022-12-09 13:48 ` [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Sean Anderson
  3 siblings, 0 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-07  6:23 UTC (permalink / raw)
  To: ycliang, rickchen36, rick; +Cc: u-boot, trini, sjg, xypron.glpk

Descript how to boot Kernel with Fast Boot and record
booting messages here.

Signed-off-by: Rick Chen <rick@andestech.com>
---
 doc/board/AndesTech/ax25-ae350.rst | 140 +++++++++++++++++++++++++++++
 1 file changed, 140 insertions(+)

diff --git a/doc/board/AndesTech/ax25-ae350.rst b/doc/board/AndesTech/ax25-ae350.rst
index b46f427f4b..01b7159117 100644
--- a/doc/board/AndesTech/ax25-ae350.rst
+++ b/doc/board/AndesTech/ax25-ae350.rst
@@ -522,3 +522,143 @@ Messages of U-Boot SPL boots Kernel on AE350 board
     nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
 
     ~ #
+
+
+Fast-Boot on AE350
+------------------
+In hope of reducing the boot time, Andes U-Boot is implemented with a feature similar to
+U-Boot FALCON mode. The boot flow using this feature, called Fast Boot, initializes memory
+with the U-Boot SPL at the first stage, just like what a regular booting process
+(i.e. Normal Boot) does in the beginning. Instead of jumping to the U-Boot proper (normal mode)
+from OpenSBI before booting kernel, the Fast Boot process jumps directly to kernel to enabl
+shorter boot time.
+
+
+Fast-Boot flow
+--------------
+U-Boot SPL --> openSBI --> Linux Kernel
+
+How to run Fast-Boot on AE350
+-------------------------------
+1. Copy Kernel Image (arch/riscv/boot/Image) into U-Boot root directory.
+2. make ae350_rv[32|64]_spl_fastboot_defconfig and build.
+3. linux.itb will be generated here.
+
+
+Messages of Fast-Boot Kernel on AE350 board
+-------------------------------------------
+U-Boot SPL 2023.01-rc1-00100-gf854773d8a-dirty (Dec 05 2022 - 13:54:20 +0800)
+Trying to boot from RAM
+[    0.000000] OF: fdt: Ignoring memory range 0x0 - 0x1800000
+[    0.000000] Linux version 5.4.192-18651-gf2d0487a5fb8-dirty (rick@atcsqa06) (gcc version 10.3.0 (2022-05-13_nds64le-linux-glibc-v5d-_experimental)) #2 SMP PREEMPT Thu Oct 13 10:39:07 CST 2022
+[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
+[    0.000000] printk: bootconsole [sbi0] enabled
+[    0.000000] initrd not found or empty - disabling initrd
+[    0.000000] Zone ranges:
+[    0.000000]   DMA32    [mem 0x0000000001800000-0x000000003fffffff]
+[    0.000000]   Normal   empty
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000001800000-0x000000003fffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000001800000-0x000000003fffffff]
+[    0.000000] SBI specification v0.3 detected
+[    0.000000] SBI implementation ID=0x1 Version=0x10000
+[    0.000000] SBI v0.2 TIME extension detected
+[    0.000000] SBI v0.2 IPI extension detected
+[    0.000000] SBI v0.2 RFENCE extension detected
+[    0.000000] SBI SRST extension detected
+[    0.000000] SBI v0.2 HSM extension detected
+[    0.000000] percpu: Embedded 16 pages/cpu s28120 r8192 d29224 u65536
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 252500
+[    0.000000] Kernel command line: console=ttyS0,38400n8 debug loglevel=7 earlycon=sbi
+[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
+[    0.000000] Sorting __ex_table...
+[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+[    0.000000] Memory: 994544K/1024000K available (4565K kernel code, 290K rwdata, 1655K rodata, 7083K init, 189K bss, 29456K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
+[    0.000000] rcu: Preemptible hierarchical RCU implementation.
+[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
+[    0.000000]  Tasks RCU enabled.
+[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
+[    0.000000] NR_IRQS: 72, nr_irqs: 72, preallocated irqs: 0
+[    0.000000] plic: mapped 71 interrupts with 1 handlers for 2 contexts.
+[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
+[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1bacf917bf, max_idle_ns: 881590412290 ns
+[    0.000091] sched_clock: 64 bits at 60MHz, resolution 16ns, wraps every 4398046511098ns
+[    0.025459] Console: colour dummy device 40x30
+[    0.039116] Calibrating delay loop (skipped), value calculated using timer frequency.. 120.00 BogoMIPS (lpj=600000)
+[    0.070377] pid_max: default: 32768 minimum: 301
+[    0.086700] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.109186] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.160697] rcu: Hierarchical SRCU implementation.
+[    0.181706] smp: Bringing up secondary CPUs ...
+[    0.195674] smp: Brought up 1 node, 1 CPU
+[    0.213734] devtmpfs: initialized
+[    0.247406] random: get_random_u32 called from bucket_table_alloc.isra.0+0x74/0xb8 with crng_init=0
+[    0.282986] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[    0.312829] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
+[    0.339998] NET: Registered protocol family 16
+[    0.607366] v5dmac f0c00000.dma: Atcdmac300 DMA Controller (cpy,slave), 8 channels
+[    0.647193] Advanced Linux Sound Architecture Driver Initialized.
+[    0.674732] clocksource: Switched to clocksource riscv_clocksource
+[    0.872703] NET: Registered protocol family 2
+[    0.889217] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
+[    0.932178] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
+[    0.958401] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
+[    0.983903] TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
+[    1.008992] TCP: Hash tables configured (established 8192 bind 8192)
+[    1.030897] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
+[    1.051467] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
+[    1.075246] NET: Registered protocol family 1
+[    1.097767] RPC: Registered named UNIX socket transport module.
+[    1.116128] RPC: Registered udp transport module.
+[    1.130363] RPC: Registered tcp transport module.
+[    1.145122] RPC: Registered tcp NFSv4.1 backchannel transport module.
+[    8.899871] workingset: timestamp_bits=62 max_order=18 bucket_order=0
+[    9.091511] NFS: Registering the id_resolver key type
+[    9.107526] Key type id_resolver registered
+[    9.120225] Key type id_legacy registered
+[    9.132533] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
+[    9.152713] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
+[    9.383847] io scheduler mq-deadline registered
+[    9.398487] io scheduler kyber registered
+[    9.418464] ATCGPIO100 module inserted
+[    9.437279] faradayfb_main: faradayfb_probe() ...
+[    9.494962] Console: switching to colour frame buffer device 40x30
+[   10.642421] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+[   10.689547] printk: console [ttyS0] disabled
+[   10.704113] f0300000.serial: ttyS0 at MMIO 0xf0300020 (irq = 9, base_baud = 1228800) is a 16550A
+[   10.731684] printk: console [ttyS0] enabled
+[   10.731684] printk: console [ttyS0] enabled
+[   10.757732] printk: bootconsole [sbi0] disabled
+[   10.757732] printk: bootconsole [sbi0] disabled
+[   10.957472] loop: module loaded
+[   10.980597] atcspi200 f0b00000.spi: Andes SPI driver.
+[   10.997877] tun: Universal TUN/TAP device driver, 1.6
+[   11.016613] ftmac100: Loading version 0.2 ...
+[   11.040706] ftmac100 e0100000.mac eth0: irq 19, mapped at (____ptrval____)
+[   11.062414] ftmac100 e0100000.mac eth0: generated random MAC address 02:b3:ca:d8:86:9a
+[   11.089307] i2c /dev entries driver
+[   11.107427] atciic100 f0a00000.i2c: Andes i2c bus driver.
+[   11.138486] ftsdc010g f0e00000.mmc: using dma0chan0 for DMA transfers
+[   11.452749] ftsdc010g f0e00000.mmc: mmc0 - using hw SDIO IRQ
+[   11.608849] mmc0: new SDHC card at address 5048
+[   11.652622] mmcblk0: mmc0:5048 SD16G 14.5 GiB
+[   11.681174] ftssp010 card registered!
+[   11.710825]  mmcblk0: p1 p2
+[   11.753339] NET: Registered protocol family 10
+[   11.785663] Segment Routing with IPv6
+[   11.798553] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
+[   11.827247] NET: Registered protocol family 17
+[   11.841395] NET: Registered protocol family 15
+[   11.866431] ALSA device list:
+[   11.876385]   #0: ftssp_ac97 controller
+[   12.011649] Freeing unused kernel memory: 7080K
+[   12.026235] This architecture does not have kernel memory protection.
+[   12.045926] Run /init as init process
+Sysinit starting
+Mon Sep 26 16:26:43 CST 2022
+
+/root #
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-07  6:23 [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Rick Chen
                   ` (2 preceding siblings ...)
  2022-12-07  6:23 ` [PATCH 4/4] doc: ae350: Add Fast Boot description Rick Chen
@ 2022-12-09 13:48 ` Sean Anderson
  2022-12-09 22:07   ` Tom Rini
  2022-12-12  7:49   ` Rick Chen
  3 siblings, 2 replies; 21+ messages in thread
From: Sean Anderson @ 2022-12-09 13:48 UTC (permalink / raw)
  To: Rick Chen, ycliang, rickchen36; +Cc: u-boot, trini, sjg, xypron.glpk

On 12/7/22 01:23, Rick Chen wrote:
> In RISC-V, it only provide normal mode booting currently.
> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> to achieve this feature which will be call Fast-Boot mode. By

Can you name this something different. We already have something called
fastboot in-tree (the Android-derived protocol) and there's a Microsoft
technology called fastboot (some kind of hibernation). "OS Boot" isn't
very specific either, since we (almost always) boot an OS. Maybe "Eagle
mode" by analogy to Falcon mode, which lets SPL directly boot an OS.

(Is this substantially different from falcon mode anyway?)

> enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> of default u-boot.itb after compiling. It initializes memory with
> the U-Boot SPL at the first stage, just like what a regular booting
> process (i.e. Normal Boot) does in the beginning. Instead of jumping
> to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> Fast Boot process jumps directly to Linux Kernel to gain shorter
> booting time.
> 
> Signed-off-by: Rick Chen <rick@andestech.com>
> ---
>   common/spl/Kconfig       | 14 ++++++++++++++
>   common/spl/spl_fit.c     |  3 ++-
>   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
>   3 files changed, 28 insertions(+), 14 deletions(-)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 05181bdba3..8805aba1b7 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
>   	  Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
>   	  SBI_SCRATCH_DEBUG_PRINTS.
>   
> +config SPL_OPENSBI_OS_BOOT

Please use the same name for the config as for the description.

> +	bool "openSBI Fast Boot"
> +	depends on SPL_OPENSBI
> +	help
> +	  Enable this openSBI can jump to Linux Kernel directly.

Can you put some of the explanation from the commit message here?

> +
> +config SPL_OPENSBI_FIT_NAME
> +	string "SPL openSBI fit image name"
> +	depends on SPL_OPENSBI
> +	default "linux.itb" if SPL_OPENSBI_OS_BOOT
> +	default "u-boot.itb"
> +	help
> +	  This will help to generate different fit name accordingly.

Why not SPL_FS_LOAD_PAYLOAD_NAME?

It looks like the code changes below do not use these configs. Can you
move them to the next patch so it is clearer that they are for binman?

--Sean

>   config SPL_TARGET
>   	string "Addtional build targets for 'make'"
>   	default "spl/u-boot-spl.srec" if RCAR_GEN2
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index c1ed31e367..c5b1dfb3ba 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -363,7 +363,8 @@ static bool os_takes_devicetree(uint8_t os)
>   	case IH_OS_U_BOOT:
>   		return true;
>   	case IH_OS_LINUX:
> -		return IS_ENABLED(CONFIG_SPL_OS_BOOT);
> +		return IS_ENABLED(CONFIG_SPL_OS_BOOT) ||
> +			IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT);
>   	default:
>   		return false;
>   	}
> diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> index b0f40076c3..83869c6b18 100644
> --- a/common/spl/spl_opensbi.c
> +++ b/common/spl/spl_opensbi.c
> @@ -20,7 +20,7 @@ DECLARE_GLOBAL_DATA_PTR;
>   
>   struct fw_dynamic_info opensbi_info;
>   
> -static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
> +static int spl_opensbi_find_os_node(void *blob, int *os_node)
>   {
>   	int fit_images_node, node;
>   	const char *fit_os;
> @@ -34,10 +34,9 @@ static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
>   		if (!fit_os)
>   			continue;
>   
> -		if (genimg_get_os_id(fit_os) == IH_OS_U_BOOT) {
> -			*uboot_node = node;
> -			return 0;
> -		}
> +		*os_node = node;
> +
> +		return 0;
>   	}
>   
>   	return -ENODEV;
> @@ -45,8 +44,8 @@ static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
>   
>   void spl_invoke_opensbi(struct spl_image_info *spl_image)
>   {
> -	int ret, uboot_node;
> -	ulong uboot_entry;
> +	int ret, os_node;
> +	ulong os_entry;
>   	void (*opensbi_entry)(ulong hartid, ulong dtb, ulong info);
>   
>   	if (!spl_image->fdt_addr) {
> @@ -54,22 +53,22 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
>   		hang();
>   	}
>   
> -	/* Find U-Boot image in /fit-images */
> -	ret = spl_opensbi_find_uboot_node(spl_image->fdt_addr, &uboot_node);
> +	/* Find U-Boot or Linux image in /fit-images */
> +	ret = spl_opensbi_find_os_node(spl_image->fdt_addr, &os_node);
>   	if (ret) {
>   		pr_err("Can't find U-Boot node, %d\n", ret);
>   		hang();
>   	}
>   
> -	/* Get U-Boot entry point */
> -	ret = fit_image_get_entry(spl_image->fdt_addr, uboot_node, &uboot_entry);
> +	/* Get os entry point */
> +	ret = fit_image_get_entry(spl_image->fdt_addr, os_node, &os_entry);
>   	if (ret)
> -		ret = fit_image_get_load(spl_image->fdt_addr, uboot_node, &uboot_entry);
> +		ret = fit_image_get_load(spl_image->fdt_addr, os_node, &os_entry);
>   
>   	/* Prepare opensbi_info object */
>   	opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE;
>   	opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
> -	opensbi_info.next_addr = uboot_entry;
> +	opensbi_info.next_addr = os_entry;
>   	opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
>   	opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
>   	opensbi_info.boot_hart = gd->arch.boot_hart;


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-09 13:48 ` [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Sean Anderson
@ 2022-12-09 22:07   ` Tom Rini
  2022-12-12  6:45     ` Rick Chen
  2022-12-12  7:49   ` Rick Chen
  1 sibling, 1 reply; 21+ messages in thread
From: Tom Rini @ 2022-12-09 22:07 UTC (permalink / raw)
  To: Sean Anderson; +Cc: Rick Chen, ycliang, rickchen36, u-boot, sjg, xypron.glpk

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> On 12/7/22 01:23, Rick Chen wrote:
> > In RISC-V, it only provide normal mode booting currently.
> > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > to achieve this feature which will be call Fast-Boot mode. By
> 
> Can you name this something different. We already have something called
> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> technology called fastboot (some kind of hibernation). "OS Boot" isn't
> very specific either, since we (almost always) boot an OS. Maybe "Eagle
> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> 
> (Is this substantially different from falcon mode anyway?)

I was kind of wondering if this is different, really, from Falcon Mode.
Falcon Mode didn't initially have to factor in other-firmware as that's
not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
first read of this was that it seems like the RISC-V specific side of
doing Falcon Mode and dealing with the prior stage needs correctly.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-09 22:07   ` Tom Rini
@ 2022-12-12  6:45     ` Rick Chen
  2022-12-12 15:03       ` Tom Rini
  0 siblings, 1 reply; 21+ messages in thread
From: Rick Chen @ 2022-12-12  6:45 UTC (permalink / raw)
  To: Tom Rini; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

Hi Tom

> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> > On 12/7/22 01:23, Rick Chen wrote:
> > > In RISC-V, it only provide normal mode booting currently.
> > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > to achieve this feature which will be call Fast-Boot mode. By
> >
> > Can you name this something different. We already have something called
> > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> >
> > (Is this substantially different from falcon mode anyway?)
>
> I was kind of wondering if this is different, really, from Falcon Mode.
> Falcon Mode didn't initially have to factor in other-firmware as that's
> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> first read of this was that it seems like the RISC-V specific side of
> doing Falcon Mode and dealing with the prior stage needs correctly.
>

Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
 jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
flow in board_init_r() of common/spl/spl.c.
That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
RISC-V fast boot implementation.

Thanks,
Rick



> --
> Tom

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-09 13:48 ` [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Sean Anderson
  2022-12-09 22:07   ` Tom Rini
@ 2022-12-12  7:49   ` Rick Chen
  2022-12-12 15:52     ` Tom Rini
  1 sibling, 1 reply; 21+ messages in thread
From: Rick Chen @ 2022-12-12  7:49 UTC (permalink / raw)
  To: Sean Anderson; +Cc: Rick Chen, ycliang, u-boot, trini, sjg, xypron.glpk

> On 12/7/22 01:23, Rick Chen wrote:
> > In RISC-V, it only provide normal mode booting currently.
> > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > to achieve this feature which will be call Fast-Boot mode. By
>
> Can you name this something different. We already have something called
> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> technology called fastboot (some kind of hibernation). "OS Boot" isn't
> very specific either, since we (almost always) boot an OS. Maybe "Eagle
> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.

I think fast boot is a behavior which shall be interpreted widely but
not proprietary.
Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.

>
> (Is this substantially different from falcon mode anyway?)

Please see the explanations to Tom.

>
> > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > of default u-boot.itb after compiling. It initializes memory with
> > the U-Boot SPL at the first stage, just like what a regular booting
> > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > booting time.
> >
> > Signed-off-by: Rick Chen <rick@andestech.com>
> > ---
> >   common/spl/Kconfig       | 14 ++++++++++++++
> >   common/spl/spl_fit.c     |  3 ++-
> >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> >   3 files changed, 28 insertions(+), 14 deletions(-)
> >
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index 05181bdba3..8805aba1b7 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> >         SBI_SCRATCH_DEBUG_PRINTS.
> >
> > +config SPL_OPENSBI_OS_BOOT
>
> Please use the same name for the config as for the description.
>
> > +     bool "openSBI Fast Boot"
> > +     depends on SPL_OPENSBI
> > +     help
> > +       Enable this openSBI can jump to Linux Kernel directly.
>
> Can you put some of the explanation from the commit message here?

OK, I will move some messages here from commit messages.

>
> > +
> > +config SPL_OPENSBI_FIT_NAME
> > +     string "SPL openSBI fit image name"
> > +     depends on SPL_OPENSBI
> > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > +     default "u-boot.itb"
> > +     help
> > +       This will help to generate different fit name accordingly.
>
> Why not SPL_FS_LOAD_PAYLOAD_NAME?
>
> It looks like the code changes below do not use these configs. Can you
> move them to the next patch so it is clearer that they are for binman?

I have saw this config, but it does't support SPL_RAM but only for filesystem
That is why I don't leverage it.

I can prepare a patch as below if no other concerns:

config SPL_FS_LOAD_PAYLOAD_NAME
string "File to load for U-Boot from the filesystem"
depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
default "tispl.bin" if SYS_K3_SPL_ATF
default "u-boot.itb" if SPL_LOAD_FIT
default "linux.itb" if SPL_OPENSBI_OS_BOOT
default "u-boot.img"
help
  Filename to read to load U-Boot when reading from filesystem.

Thanks,
Rick

>
> --Sean
>
> >   config SPL_TARGET
> >       string "Addtional build targets for 'make'"
> >       default "spl/u-boot-spl.srec" if RCAR_GEN2
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index c1ed31e367..c5b1dfb3ba 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -363,7 +363,8 @@ static bool os_takes_devicetree(uint8_t os)
> >       case IH_OS_U_BOOT:
> >               return true;
> >       case IH_OS_LINUX:
> > -             return IS_ENABLED(CONFIG_SPL_OS_BOOT);
> > +             return IS_ENABLED(CONFIG_SPL_OS_BOOT) ||
> > +                     IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT);
> >       default:
> >               return false;
> >       }
> > diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> > index b0f40076c3..83869c6b18 100644
> > --- a/common/spl/spl_opensbi.c
> > +++ b/common/spl/spl_opensbi.c
> > @@ -20,7 +20,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> >   struct fw_dynamic_info opensbi_info;
> >
> > -static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
> > +static int spl_opensbi_find_os_node(void *blob, int *os_node)
> >   {
> >       int fit_images_node, node;
> >       const char *fit_os;
> > @@ -34,10 +34,9 @@ static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
> >               if (!fit_os)
> >                       continue;
> >
> > -             if (genimg_get_os_id(fit_os) == IH_OS_U_BOOT) {
> > -                     *uboot_node = node;
> > -                     return 0;
> > -             }
> > +             *os_node = node;
> > +
> > +             return 0;
> >       }
> >
> >       return -ENODEV;
> > @@ -45,8 +44,8 @@ static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
> >
> >   void spl_invoke_opensbi(struct spl_image_info *spl_image)
> >   {
> > -     int ret, uboot_node;
> > -     ulong uboot_entry;
> > +     int ret, os_node;
> > +     ulong os_entry;
> >       void (*opensbi_entry)(ulong hartid, ulong dtb, ulong info);
> >
> >       if (!spl_image->fdt_addr) {
> > @@ -54,22 +53,22 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
> >               hang();
> >       }
> >
> > -     /* Find U-Boot image in /fit-images */
> > -     ret = spl_opensbi_find_uboot_node(spl_image->fdt_addr, &uboot_node);
> > +     /* Find U-Boot or Linux image in /fit-images */
> > +     ret = spl_opensbi_find_os_node(spl_image->fdt_addr, &os_node);
> >       if (ret) {
> >               pr_err("Can't find U-Boot node, %d\n", ret);
> >               hang();
> >       }
> >
> > -     /* Get U-Boot entry point */
> > -     ret = fit_image_get_entry(spl_image->fdt_addr, uboot_node, &uboot_entry);
> > +     /* Get os entry point */
> > +     ret = fit_image_get_entry(spl_image->fdt_addr, os_node, &os_entry);
> >       if (ret)
> > -             ret = fit_image_get_load(spl_image->fdt_addr, uboot_node, &uboot_entry);
> > +             ret = fit_image_get_load(spl_image->fdt_addr, os_node, &os_entry);
> >
> >       /* Prepare opensbi_info object */
> >       opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE;
> >       opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
> > -     opensbi_info.next_addr = uboot_entry;
> > +     opensbi_info.next_addr = os_entry;
> >       opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
> >       opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
> >       opensbi_info.boot_hart = gd->arch.boot_hart;
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-12  6:45     ` Rick Chen
@ 2022-12-12 15:03       ` Tom Rini
  2022-12-13  0:31         ` Sean Anderson
  2022-12-13  1:31         ` Rick Chen
  0 siblings, 2 replies; 21+ messages in thread
From: Tom Rini @ 2022-12-12 15:03 UTC (permalink / raw)
  To: Rick Chen; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> Hi Tom
> 
> > On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> > > On 12/7/22 01:23, Rick Chen wrote:
> > > > In RISC-V, it only provide normal mode booting currently.
> > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > to achieve this feature which will be call Fast-Boot mode. By
> > >
> > > Can you name this something different. We already have something called
> > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > >
> > > (Is this substantially different from falcon mode anyway?)
> >
> > I was kind of wondering if this is different, really, from Falcon Mode.
> > Falcon Mode didn't initially have to factor in other-firmware as that's
> > not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> > first read of this was that it seems like the RISC-V specific side of
> > doing Falcon Mode and dealing with the prior stage needs correctly.
> >
> 
> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
>  jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> flow in board_init_r() of common/spl/spl.c.
> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> RISC-V fast boot implementation.

Those sound like fairly minor challenges for the same fundamental
concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
pass along". We might need to do a little code re-factoring here. But
maybe also a little bit of explaining why we wouldn't be booting to the
OS directly but instead passing back to openSBI to do this? That's not
normally how RISC-V boots the OS, right? Or am I miss-understanding
something here?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-12  7:49   ` Rick Chen
@ 2022-12-12 15:52     ` Tom Rini
  2022-12-13  2:06       ` Rick Chen
  0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2022-12-12 15:52 UTC (permalink / raw)
  To: Rick Chen; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

[-- Attachment #1: Type: text/plain, Size: 4052 bytes --]

On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > On 12/7/22 01:23, Rick Chen wrote:
> > > In RISC-V, it only provide normal mode booting currently.
> > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > to achieve this feature which will be call Fast-Boot mode. By
> >
> > Can you name this something different. We already have something called
> > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> 
> I think fast boot is a behavior which shall be interpreted widely but
> not proprietary.
> Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> 
> >
> > (Is this substantially different from falcon mode anyway?)
> 
> Please see the explanations to Tom.
> 
> >
> > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > of default u-boot.itb after compiling. It initializes memory with
> > > the U-Boot SPL at the first stage, just like what a regular booting
> > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > booting time.
> > >
> > > Signed-off-by: Rick Chen <rick@andestech.com>
> > > ---
> > >   common/spl/Kconfig       | 14 ++++++++++++++
> > >   common/spl/spl_fit.c     |  3 ++-
> > >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > index 05181bdba3..8805aba1b7 100644
> > > --- a/common/spl/Kconfig
> > > +++ b/common/spl/Kconfig
> > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> > >         SBI_SCRATCH_DEBUG_PRINTS.
> > >
> > > +config SPL_OPENSBI_OS_BOOT
> >
> > Please use the same name for the config as for the description.
> >
> > > +     bool "openSBI Fast Boot"
> > > +     depends on SPL_OPENSBI
> > > +     help
> > > +       Enable this openSBI can jump to Linux Kernel directly.
> >
> > Can you put some of the explanation from the commit message here?
> 
> OK, I will move some messages here from commit messages.
> 
> >
> > > +
> > > +config SPL_OPENSBI_FIT_NAME
> > > +     string "SPL openSBI fit image name"
> > > +     depends on SPL_OPENSBI
> > > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > +     default "u-boot.itb"
> > > +     help
> > > +       This will help to generate different fit name accordingly.
> >
> > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> >
> > It looks like the code changes below do not use these configs. Can you
> > move them to the next patch so it is clearer that they are for binman?
> 
> I have saw this config, but it does't support SPL_RAM but only for filesystem
> That is why I don't leverage it.
> 
> I can prepare a patch as below if no other concerns:
> 
> config SPL_FS_LOAD_PAYLOAD_NAME
> string "File to load for U-Boot from the filesystem"
> depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> default "tispl.bin" if SYS_K3_SPL_ATF
> default "u-boot.itb" if SPL_LOAD_FIT
> default "linux.itb" if SPL_OPENSBI_OS_BOOT
> default "u-boot.img"
> help
>   Filename to read to load U-Boot when reading from filesystem.

But in the case you have it's for the output name, and not at all about
what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."
option, but should be under arch/riscv/Kconfig somewhere, since it's
changing the general riscv binman.dtsi file. And on a related note,
please make sure that 'make htmldocs' is happy with your documentation
changes as I think I see some spacing problems in 4/4.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-12 15:03       ` Tom Rini
@ 2022-12-13  0:31         ` Sean Anderson
  2022-12-13  0:42           ` Rick Chen
  2022-12-13  1:31         ` Rick Chen
  1 sibling, 1 reply; 21+ messages in thread
From: Sean Anderson @ 2022-12-13  0:31 UTC (permalink / raw)
  To: Tom Rini, Rick Chen; +Cc: Rick Chen, ycliang, u-boot, sjg, xypron.glpk

On 12/12/22 10:03, Tom Rini wrote:
> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
>> Hi Tom
>>
>>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
>>>> On 12/7/22 01:23, Rick Chen wrote:
>>>>> In RISC-V, it only provide normal mode booting currently.
>>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
>>>>> to achieve this feature which will be call Fast-Boot mode. By
>>>>
>>>> Can you name this something different. We already have something called
>>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
>>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't
>>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle
>>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
>>>>
>>>> (Is this substantially different from falcon mode anyway?)
>>>
>>> I was kind of wondering if this is different, really, from Falcon Mode.
>>> Falcon Mode didn't initially have to factor in other-firmware as that's
>>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
>>> first read of this was that it seems like the RISC-V specific side of
>>> doing Falcon Mode and dealing with the prior stage needs correctly.
>>>
>>
>> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
>> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
>>   jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
>> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
>> flow in board_init_r() of common/spl/spl.c.
>> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
>> RISC-V fast boot implementation.
> 
> Those sound like fairly minor challenges for the same fundamental
> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> pass along". We might need to do a little code re-factoring here. But
> maybe also a little bit of explaining why we wouldn't be booting to the
> OS directly but instead passing back to openSBI to do this? That's not
> normally how RISC-V boots the OS, right? Or am I miss-understanding
> something here?
> 

The usual process is

ROM -> SPL -> SBI -> U-Boot -> Linux

Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are
done booting". But the idea here is to load Linux instead of U-Boot. I think
this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is
enabled, I think it's reasonable for falcon mode to do exactly that. People
who want the SPL -> Linux path can disable SPL_OPENSBI.

--Sean

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-13  0:31         ` Sean Anderson
@ 2022-12-13  0:42           ` Rick Chen
  2022-12-13 16:24             ` Tom Rini
  0 siblings, 1 reply; 21+ messages in thread
From: Rick Chen @ 2022-12-13  0:42 UTC (permalink / raw)
  To: Sean Anderson; +Cc: Tom Rini, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

Hi Sean,

> On 12/12/22 10:03, Tom Rini wrote:
> > On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> >> Hi Tom
> >>
> >>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> >>>> On 12/7/22 01:23, Rick Chen wrote:
> >>>>> In RISC-V, it only provide normal mode booting currently.
> >>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> >>>>> to achieve this feature which will be call Fast-Boot mode. By
> >>>>
> >>>> Can you name this something different. We already have something called
> >>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> >>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't
> >>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle
> >>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> >>>>
> >>>> (Is this substantially different from falcon mode anyway?)
> >>>
> >>> I was kind of wondering if this is different, really, from Falcon Mode.
> >>> Falcon Mode didn't initially have to factor in other-firmware as that's
> >>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> >>> first read of this was that it seems like the RISC-V specific side of
> >>> doing Falcon Mode and dealing with the prior stage needs correctly.
> >>>
> >>
> >> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> >> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
> >>   jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> >> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> >> flow in board_init_r() of common/spl/spl.c.
> >> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> >> RISC-V fast boot implementation.
> >
> > Those sound like fairly minor challenges for the same fundamental
> > concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> > pass along". We might need to do a little code re-factoring here. But
> > maybe also a little bit of explaining why we wouldn't be booting to the
> > OS directly but instead passing back to openSBI to do this? That's not
> > normally how RISC-V boots the OS, right? Or am I miss-understanding
> > something here?
> >
>
> The usual process is
>
> ROM -> SPL -> SBI -> U-Boot -> Linux

In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as
M-mode to deal with SBI calls at run-time.
So the fast boot idea, I just want to bypass U-Boot and jump to Linux
directly and Linux still needs OpenSBI.
Hence SPL_OPENSBI can't be disabled here.

Rick

>
> Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are
> done booting". But the idea here is to load Linux instead of U-Boot. I think
> this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is
> enabled, I think it's reasonable for falcon mode to do exactly that. People
> who want the SPL -> Linux path can disable SPL_OPENSBI.
>
> --Sean

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-12 15:03       ` Tom Rini
  2022-12-13  0:31         ` Sean Anderson
@ 2022-12-13  1:31         ` Rick Chen
  1 sibling, 0 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-13  1:31 UTC (permalink / raw)
  To: Tom Rini; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

Hi Tom

> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> > Hi Tom
> >
> > > On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> > > > On 12/7/22 01:23, Rick Chen wrote:
> > > > > In RISC-V, it only provide normal mode booting currently.
> > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > > to achieve this feature which will be call Fast-Boot mode. By
> > > >
> > > > Can you name this something different. We already have something called
> > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > > >
> > > > (Is this substantially different from falcon mode anyway?)
> > >
> > > I was kind of wondering if this is different, really, from Falcon Mode.
> > > Falcon Mode didn't initially have to factor in other-firmware as that's
> > > not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> > > first read of this was that it seems like the RISC-V specific side of
> > > doing Falcon Mode and dealing with the prior stage needs correctly.
> > >
> >
> > Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> > When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
> >  jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> > Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> > flow in board_init_r() of common/spl/spl.c.
> > That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> > RISC-V fast boot implementation.
>
> Those sound like fairly minor challenges for the same fundamental
> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> pass along". We might need to do a little code re-factoring here. But
> maybe also a little bit of explaining why we wouldn't be booting to the
> OS directly but instead passing back to openSBI to do this? That's not
> normally how RISC-V boots the OS, right? Or am I miss-understanding
> something here?

Because RISC-V Linux runs in S-Mode, it needs OpenSBI which runs in
M-mode to handle SBI calls.
So it can not boot Linux (OS) directly from U-Boot SPL but passing
back to openSBI to do this.

Rick

>
> --
> Tom

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-12 15:52     ` Tom Rini
@ 2022-12-13  2:06       ` Rick Chen
  2022-12-13 16:27         ` Tom Rini
  0 siblings, 1 reply; 21+ messages in thread
From: Rick Chen @ 2022-12-13  2:06 UTC (permalink / raw)
  To: Tom Rini; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

> On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > > On 12/7/22 01:23, Rick Chen wrote:
> > > > In RISC-V, it only provide normal mode booting currently.
> > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > to achieve this feature which will be call Fast-Boot mode. By
> > >
> > > Can you name this something different. We already have something called
> > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> >
> > I think fast boot is a behavior which shall be interpreted widely but
> > not proprietary.
> > Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> >
> > >
> > > (Is this substantially different from falcon mode anyway?)
> >
> > Please see the explanations to Tom.
> >
> > >
> > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > > of default u-boot.itb after compiling. It initializes memory with
> > > > the U-Boot SPL at the first stage, just like what a regular booting
> > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > > booting time.
> > > >
> > > > Signed-off-by: Rick Chen <rick@andestech.com>
> > > > ---
> > > >   common/spl/Kconfig       | 14 ++++++++++++++
> > > >   common/spl/spl_fit.c     |  3 ++-
> > > >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > index 05181bdba3..8805aba1b7 100644
> > > > --- a/common/spl/Kconfig
> > > > +++ b/common/spl/Kconfig
> > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> > > >         SBI_SCRATCH_DEBUG_PRINTS.
> > > >
> > > > +config SPL_OPENSBI_OS_BOOT
> > >
> > > Please use the same name for the config as for the description.
> > >
> > > > +     bool "openSBI Fast Boot"
> > > > +     depends on SPL_OPENSBI
> > > > +     help
> > > > +       Enable this openSBI can jump to Linux Kernel directly.
> > >
> > > Can you put some of the explanation from the commit message here?
> >
> > OK, I will move some messages here from commit messages.
> >
> > >
> > > > +
> > > > +config SPL_OPENSBI_FIT_NAME
> > > > +     string "SPL openSBI fit image name"
> > > > +     depends on SPL_OPENSBI
> > > > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > +     default "u-boot.itb"
> > > > +     help
> > > > +       This will help to generate different fit name accordingly.
> > >
> > > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> > >
> > > It looks like the code changes below do not use these configs. Can you
> > > move them to the next patch so it is clearer that they are for binman?
> >
> > I have saw this config, but it does't support SPL_RAM but only for filesystem
> > That is why I don't leverage it.
> >
> > I can prepare a patch as below if no other concerns:
> >
> > config SPL_FS_LOAD_PAYLOAD_NAME
> > string "File to load for U-Boot from the filesystem"
> > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> > default "tispl.bin" if SYS_K3_SPL_ATF
> > default "u-boot.itb" if SPL_LOAD_FIT
> > default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > default "u-boot.img"
> > help
> >   Filename to read to load U-Boot when reading from filesystem.
>
> But in the case you have it's for the output name, and not at all about
> what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."

For SPL_RAM purpose,
it is just an output name to distinguish normal boot (u-boot.itb) and
fast boot (linux.itb) indeed.

But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination,
it can help to load linux.itb automatically from SD card.

> option, but should be under arch/riscv/Kconfig somewhere, since it's
> changing the general riscv binman.dtsi file. And on a related note,

I will fall back on the earlier changes and move
SPL_OPENSBI_OS_BOOT and SPL_OPENSBI_FIT_NAME to arch/riscv/Kconfig.

> please make sure that 'make htmldocs' is happy with your documentation
> changes as I think I see some spacing problems in 4/4.

Sorry about the spacing problems. I will check it.

Thanks,
Rick

>
> --
> Tom

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-13  0:42           ` Rick Chen
@ 2022-12-13 16:24             ` Tom Rini
  2022-12-14  2:01               ` Sean Anderson
  0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2022-12-13 16:24 UTC (permalink / raw)
  To: Rick Chen; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

[-- Attachment #1: Type: text/plain, Size: 3193 bytes --]

On Tue, Dec 13, 2022 at 08:42:47AM +0800, Rick Chen wrote:
> Hi Sean,
> 
> > On 12/12/22 10:03, Tom Rini wrote:
> > > On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> > >> Hi Tom
> > >>
> > >>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> > >>>> On 12/7/22 01:23, Rick Chen wrote:
> > >>>>> In RISC-V, it only provide normal mode booting currently.
> > >>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > >>>>> to achieve this feature which will be call Fast-Boot mode. By
> > >>>>
> > >>>> Can you name this something different. We already have something called
> > >>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > >>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > >>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > >>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > >>>>
> > >>>> (Is this substantially different from falcon mode anyway?)
> > >>>
> > >>> I was kind of wondering if this is different, really, from Falcon Mode.
> > >>> Falcon Mode didn't initially have to factor in other-firmware as that's
> > >>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> > >>> first read of this was that it seems like the RISC-V specific side of
> > >>> doing Falcon Mode and dealing with the prior stage needs correctly.
> > >>>
> > >>
> > >> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> > >> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
> > >>   jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> > >> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> > >> flow in board_init_r() of common/spl/spl.c.
> > >> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> > >> RISC-V fast boot implementation.
> > >
> > > Those sound like fairly minor challenges for the same fundamental
> > > concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> > > pass along". We might need to do a little code re-factoring here. But
> > > maybe also a little bit of explaining why we wouldn't be booting to the
> > > OS directly but instead passing back to openSBI to do this? That's not
> > > normally how RISC-V boots the OS, right? Or am I miss-understanding
> > > something here?
> > >
> >
> > The usual process is
> >
> > ROM -> SPL -> SBI -> U-Boot -> Linux
> 
> In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as
> M-mode to deal with SBI calls at run-time.
> So the fast boot idea, I just want to bypass U-Boot and jump to Linux
> directly and Linux still needs OpenSBI.
> Hence SPL_OPENSBI can't be disabled here.

So is the flow here:
a) ROM -> SPL -> SBI -> SPL -> Linux
or
b) ROM -> SPL -> SBI -> Linux

It's not clear to me, and I think that'll help figure out what's best
here. Since I kinda think we're looking at a more generic issue that we
see with newer architectures and maybe we already had to solve this (but
didn't name things well enough) for aarch64.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-13  2:06       ` Rick Chen
@ 2022-12-13 16:27         ` Tom Rini
  2022-12-14  0:49           ` Rick Chen
  0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2022-12-13 16:27 UTC (permalink / raw)
  To: Rick Chen; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

[-- Attachment #1: Type: text/plain, Size: 5116 bytes --]

On Tue, Dec 13, 2022 at 10:06:50AM +0800, Rick Chen wrote:
> > On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > > > On 12/7/22 01:23, Rick Chen wrote:
> > > > > In RISC-V, it only provide normal mode booting currently.
> > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > > to achieve this feature which will be call Fast-Boot mode. By
> > > >
> > > > Can you name this something different. We already have something called
> > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > >
> > > I think fast boot is a behavior which shall be interpreted widely but
> > > not proprietary.
> > > Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> > >
> > > >
> > > > (Is this substantially different from falcon mode anyway?)
> > >
> > > Please see the explanations to Tom.
> > >
> > > >
> > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > > > of default u-boot.itb after compiling. It initializes memory with
> > > > > the U-Boot SPL at the first stage, just like what a regular booting
> > > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > > > booting time.
> > > > >
> > > > > Signed-off-by: Rick Chen <rick@andestech.com>
> > > > > ---
> > > > >   common/spl/Kconfig       | 14 ++++++++++++++
> > > > >   common/spl/spl_fit.c     |  3 ++-
> > > > >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> > > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > > >
> > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > index 05181bdba3..8805aba1b7 100644
> > > > > --- a/common/spl/Kconfig
> > > > > +++ b/common/spl/Kconfig
> > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > > >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> > > > >         SBI_SCRATCH_DEBUG_PRINTS.
> > > > >
> > > > > +config SPL_OPENSBI_OS_BOOT
> > > >
> > > > Please use the same name for the config as for the description.
> > > >
> > > > > +     bool "openSBI Fast Boot"
> > > > > +     depends on SPL_OPENSBI
> > > > > +     help
> > > > > +       Enable this openSBI can jump to Linux Kernel directly.
> > > >
> > > > Can you put some of the explanation from the commit message here?
> > >
> > > OK, I will move some messages here from commit messages.
> > >
> > > >
> > > > > +
> > > > > +config SPL_OPENSBI_FIT_NAME
> > > > > +     string "SPL openSBI fit image name"
> > > > > +     depends on SPL_OPENSBI
> > > > > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > > +     default "u-boot.itb"
> > > > > +     help
> > > > > +       This will help to generate different fit name accordingly.
> > > >
> > > > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> > > >
> > > > It looks like the code changes below do not use these configs. Can you
> > > > move them to the next patch so it is clearer that they are for binman?
> > >
> > > I have saw this config, but it does't support SPL_RAM but only for filesystem
> > > That is why I don't leverage it.
> > >
> > > I can prepare a patch as below if no other concerns:
> > >
> > > config SPL_FS_LOAD_PAYLOAD_NAME
> > > string "File to load for U-Boot from the filesystem"
> > > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> > > default "tispl.bin" if SYS_K3_SPL_ATF
> > > default "u-boot.itb" if SPL_LOAD_FIT
> > > default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > default "u-boot.img"
> > > help
> > >   Filename to read to load U-Boot when reading from filesystem.
> >
> > But in the case you have it's for the output name, and not at all about
> > what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."
> 
> For SPL_RAM purpose,
> it is just an output name to distinguish normal boot (u-boot.itb) and
> fast boot (linux.itb) indeed.
> 
> But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination,
> it can help to load linux.itb automatically from SD card.

What part of the world is looking for the file named by
SPL_FS_LOAD_PAYLOAD_NAME ? (and this is related to what I just sent out,
asking about the boot flow)

> > option, but should be under arch/riscv/Kconfig somewhere, since it's
> > changing the general riscv binman.dtsi file. And on a related note,
> 
> I will fall back on the earlier changes and move
> SPL_OPENSBI_OS_BOOT and SPL_OPENSBI_FIT_NAME to arch/riscv/Kconfig.
> 
> > please make sure that 'make htmldocs' is happy with your documentation
> > changes as I think I see some spacing problems in 4/4.
> 
> Sorry about the spacing problems. I will check it.

OK, thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-13 16:27         ` Tom Rini
@ 2022-12-14  0:49           ` Rick Chen
  2022-12-14  1:54             ` Tom Rini
  0 siblings, 1 reply; 21+ messages in thread
From: Rick Chen @ 2022-12-14  0:49 UTC (permalink / raw)
  To: Tom Rini; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

Hi Tom,

> On Tue, Dec 13, 2022 at 10:06:50AM +0800, Rick Chen wrote:
> > > On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > > > > On 12/7/22 01:23, Rick Chen wrote:
> > > > > > In RISC-V, it only provide normal mode booting currently.
> > > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > > > to achieve this feature which will be call Fast-Boot mode. By
> > > > >
> > > > > Can you name this something different. We already have something called
> > > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > > >
> > > > I think fast boot is a behavior which shall be interpreted widely but
> > > > not proprietary.
> > > > Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> > > >
> > > > >
> > > > > (Is this substantially different from falcon mode anyway?)
> > > >
> > > > Please see the explanations to Tom.
> > > >
> > > > >
> > > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > > > > of default u-boot.itb after compiling. It initializes memory with
> > > > > > the U-Boot SPL at the first stage, just like what a regular booting
> > > > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > > > > booting time.
> > > > > >
> > > > > > Signed-off-by: Rick Chen <rick@andestech.com>
> > > > > > ---
> > > > > >   common/spl/Kconfig       | 14 ++++++++++++++
> > > > > >   common/spl/spl_fit.c     |  3 ++-
> > > > > >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> > > > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > > > >
> > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > index 05181bdba3..8805aba1b7 100644
> > > > > > --- a/common/spl/Kconfig
> > > > > > +++ b/common/spl/Kconfig
> > > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > > > >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> > > > > >         SBI_SCRATCH_DEBUG_PRINTS.
> > > > > >
> > > > > > +config SPL_OPENSBI_OS_BOOT
> > > > >
> > > > > Please use the same name for the config as for the description.
> > > > >
> > > > > > +     bool "openSBI Fast Boot"
> > > > > > +     depends on SPL_OPENSBI
> > > > > > +     help
> > > > > > +       Enable this openSBI can jump to Linux Kernel directly.
> > > > >
> > > > > Can you put some of the explanation from the commit message here?
> > > >
> > > > OK, I will move some messages here from commit messages.
> > > >
> > > > >
> > > > > > +
> > > > > > +config SPL_OPENSBI_FIT_NAME
> > > > > > +     string "SPL openSBI fit image name"
> > > > > > +     depends on SPL_OPENSBI
> > > > > > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > > > +     default "u-boot.itb"
> > > > > > +     help
> > > > > > +       This will help to generate different fit name accordingly.
> > > > >
> > > > > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> > > > >
> > > > > It looks like the code changes below do not use these configs. Can you
> > > > > move them to the next patch so it is clearer that they are for binman?
> > > >
> > > > I have saw this config, but it does't support SPL_RAM but only for filesystem
> > > > That is why I don't leverage it.
> > > >
> > > > I can prepare a patch as below if no other concerns:
> > > >
> > > > config SPL_FS_LOAD_PAYLOAD_NAME
> > > > string "File to load for U-Boot from the filesystem"
> > > > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> > > > default "tispl.bin" if SYS_K3_SPL_ATF
> > > > default "u-boot.itb" if SPL_LOAD_FIT
> > > > default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > default "u-boot.img"
> > > > help
> > > >   Filename to read to load U-Boot when reading from filesystem.
> > >
> > > But in the case you have it's for the output name, and not at all about
> > > what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."
> >
> > For SPL_RAM purpose,
> > it is just an output name to distinguish normal boot (u-boot.itb) and
> > fast boot (linux.itb) indeed.
> >
> > But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination,
> > it can help to load linux.itb automatically from SD card.
>
> What part of the world is looking for the file named by
> SPL_FS_LOAD_PAYLOAD_NAME ? (and this is related to what I just sent out,
> asking about the boot flow)

In the following commit, CONFIG_SPL_FS_LOAD_PAYLOAD_NAME has been
moved to Kconfig from ax25-ae350.h
That is why I try to add this change to load u-boot.itb or linux.itb
from SD card here

commit 4a11e34bc9c0f3818f3e847ac51c82d1c9bbb807
Author: Tom Rini <trini@konsulko.com>
Date:   Fri May 13 17:12:35 2022 -0400

    Convert CONFIG_SPL_FS_LOAD_PAYLOAD_NAME et al to Kconfig

...

+++ b/include/configs/ax25-ae350.h
@@ -11,10 +11,6 @@
 #define CONFIG_SPL_MAX_SIZE            0x00100000
 #define CONFIG_SPL_BSS_START_ADDR      0x04000000
 #define CONFIG_SPL_BSS_MAX_SIZE                0x00100000
-
-#ifdef CONFIG_SPL_MMC
-#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME                "u-boot.itb"
-#endif

>
> > > option, but should be under arch/riscv/Kconfig somewhere, since it's
> > > changing the general riscv binman.dtsi file. And on a related note,
> >
> > I will fall back on the earlier changes and move
> > SPL_OPENSBI_OS_BOOT and SPL_OPENSBI_FIT_NAME to arch/riscv/Kconfig.
> >
> > > please make sure that 'make htmldocs' is happy with your documentation
> > > changes as I think I see some spacing problems in 4/4.
> >
> > Sorry about the spacing problems. I will check it.
>
> OK, thanks.
>
> --
> Tom

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-14  0:49           ` Rick Chen
@ 2022-12-14  1:54             ` Tom Rini
  2022-12-14  2:14               ` Rick Chen
  0 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2022-12-14  1:54 UTC (permalink / raw)
  To: Rick Chen; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

[-- Attachment #1: Type: text/plain, Size: 6200 bytes --]

On Wed, Dec 14, 2022 at 08:49:03AM +0800, Rick Chen wrote:
> Hi Tom,
> 
> > On Tue, Dec 13, 2022 at 10:06:50AM +0800, Rick Chen wrote:
> > > > On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > > > > > On 12/7/22 01:23, Rick Chen wrote:
> > > > > > > In RISC-V, it only provide normal mode booting currently.
> > > > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > > > > to achieve this feature which will be call Fast-Boot mode. By
> > > > > >
> > > > > > Can you name this something different. We already have something called
> > > > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > > > >
> > > > > I think fast boot is a behavior which shall be interpreted widely but
> > > > > not proprietary.
> > > > > Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> > > > >
> > > > > >
> > > > > > (Is this substantially different from falcon mode anyway?)
> > > > >
> > > > > Please see the explanations to Tom.
> > > > >
> > > > > >
> > > > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > > > > > of default u-boot.itb after compiling. It initializes memory with
> > > > > > > the U-Boot SPL at the first stage, just like what a regular booting
> > > > > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > > > > > booting time.
> > > > > > >
> > > > > > > Signed-off-by: Rick Chen <rick@andestech.com>
> > > > > > > ---
> > > > > > >   common/spl/Kconfig       | 14 ++++++++++++++
> > > > > > >   common/spl/spl_fit.c     |  3 ++-
> > > > > > >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> > > > > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > > > > >
> > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > > index 05181bdba3..8805aba1b7 100644
> > > > > > > --- a/common/spl/Kconfig
> > > > > > > +++ b/common/spl/Kconfig
> > > > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > > > > >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> > > > > > >         SBI_SCRATCH_DEBUG_PRINTS.
> > > > > > >
> > > > > > > +config SPL_OPENSBI_OS_BOOT
> > > > > >
> > > > > > Please use the same name for the config as for the description.
> > > > > >
> > > > > > > +     bool "openSBI Fast Boot"
> > > > > > > +     depends on SPL_OPENSBI
> > > > > > > +     help
> > > > > > > +       Enable this openSBI can jump to Linux Kernel directly.
> > > > > >
> > > > > > Can you put some of the explanation from the commit message here?
> > > > >
> > > > > OK, I will move some messages here from commit messages.
> > > > >
> > > > > >
> > > > > > > +
> > > > > > > +config SPL_OPENSBI_FIT_NAME
> > > > > > > +     string "SPL openSBI fit image name"
> > > > > > > +     depends on SPL_OPENSBI
> > > > > > > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > > > > +     default "u-boot.itb"
> > > > > > > +     help
> > > > > > > +       This will help to generate different fit name accordingly.
> > > > > >
> > > > > > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> > > > > >
> > > > > > It looks like the code changes below do not use these configs. Can you
> > > > > > move them to the next patch so it is clearer that they are for binman?
> > > > >
> > > > > I have saw this config, but it does't support SPL_RAM but only for filesystem
> > > > > That is why I don't leverage it.
> > > > >
> > > > > I can prepare a patch as below if no other concerns:
> > > > >
> > > > > config SPL_FS_LOAD_PAYLOAD_NAME
> > > > > string "File to load for U-Boot from the filesystem"
> > > > > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> > > > > default "tispl.bin" if SYS_K3_SPL_ATF
> > > > > default "u-boot.itb" if SPL_LOAD_FIT
> > > > > default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > > default "u-boot.img"
> > > > > help
> > > > >   Filename to read to load U-Boot when reading from filesystem.
> > > >
> > > > But in the case you have it's for the output name, and not at all about
> > > > what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."
> > >
> > > For SPL_RAM purpose,
> > > it is just an output name to distinguish normal boot (u-boot.itb) and
> > > fast boot (linux.itb) indeed.
> > >
> > > But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination,
> > > it can help to load linux.itb automatically from SD card.
> >
> > What part of the world is looking for the file named by
> > SPL_FS_LOAD_PAYLOAD_NAME ? (and this is related to what I just sent out,
> > asking about the boot flow)
> 
> In the following commit, CONFIG_SPL_FS_LOAD_PAYLOAD_NAME has been
> moved to Kconfig from ax25-ae350.h
> That is why I try to add this change to load u-boot.itb or linux.itb
> from SD card here
> 
> commit 4a11e34bc9c0f3818f3e847ac51c82d1c9bbb807
> Author: Tom Rini <trini@konsulko.com>
> Date:   Fri May 13 17:12:35 2022 -0400
> 
>     Convert CONFIG_SPL_FS_LOAD_PAYLOAD_NAME et al to Kconfig
> 
> ...
> 
> +++ b/include/configs/ax25-ae350.h
> @@ -11,10 +11,6 @@
>  #define CONFIG_SPL_MAX_SIZE            0x00100000
>  #define CONFIG_SPL_BSS_START_ADDR      0x04000000
>  #define CONFIG_SPL_BSS_MAX_SIZE                0x00100000
> -
> -#ifdef CONFIG_SPL_MMC
> -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME                "u-boot.itb"
> -#endif

Yes, I made a best guess "what do I need to do to have zero size change"
migration of that option, along with most others. So, sorry, my original
question remains.  In real world usage, what is using that name? The
regular usage here is that SPL knows to read from FAT (or similar) that
name as a hard-coded default.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-13 16:24             ` Tom Rini
@ 2022-12-14  2:01               ` Sean Anderson
  2022-12-14  6:32                 ` Rick Chen
  0 siblings, 1 reply; 21+ messages in thread
From: Sean Anderson @ 2022-12-14  2:01 UTC (permalink / raw)
  To: Tom Rini, Rick Chen; +Cc: Rick Chen, ycliang, u-boot, sjg, xypron.glpk

On 12/13/22 11:24, Tom Rini wrote:
> On Tue, Dec 13, 2022 at 08:42:47AM +0800, Rick Chen wrote:
>> Hi Sean,
>>
>>> On 12/12/22 10:03, Tom Rini wrote:
>>>> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
>>>>> Hi Tom
>>>>>
>>>>>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
>>>>>>> On 12/7/22 01:23, Rick Chen wrote:
>>>>>>>> In RISC-V, it only provide normal mode booting currently.
>>>>>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
>>>>>>>> to achieve this feature which will be call Fast-Boot mode. By
>>>>>>>
>>>>>>> Can you name this something different. We already have something called
>>>>>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
>>>>>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't
>>>>>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle
>>>>>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
>>>>>>>
>>>>>>> (Is this substantially different from falcon mode anyway?)
>>>>>>
>>>>>> I was kind of wondering if this is different, really, from Falcon Mode.
>>>>>> Falcon Mode didn't initially have to factor in other-firmware as that's
>>>>>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
>>>>>> first read of this was that it seems like the RISC-V specific side of
>>>>>> doing Falcon Mode and dealing with the prior stage needs correctly.
>>>>>>
>>>>>
>>>>> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
>>>>> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
>>>>>    jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
>>>>> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
>>>>> flow in board_init_r() of common/spl/spl.c.
>>>>> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
>>>>> RISC-V fast boot implementation.
>>>>
>>>> Those sound like fairly minor challenges for the same fundamental
>>>> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
>>>> pass along". We might need to do a little code re-factoring here. But
>>>> maybe also a little bit of explaining why we wouldn't be booting to the
>>>> OS directly but instead passing back to openSBI to do this? That's not
>>>> normally how RISC-V boots the OS, right? Or am I miss-understanding
>>>> something here?
>>>>
>>>
>>> The usual process is
>>>
>>> ROM -> SPL -> SBI -> U-Boot -> Linux
>>
>> In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as
>> M-mode to deal with SBI calls at run-time.
>> So the fast boot idea, I just want to bypass U-Boot and jump to Linux
>> directly and Linux still needs OpenSBI.
>> Hence SPL_OPENSBI can't be disabled here.
> 
> So is the flow here:
> a) ROM -> SPL -> SBI -> SPL -> Linux
> or
> b) ROM -> SPL -> SBI -> Linux

The latter. The regular boot is

(M) Boot ROM loads SPL and executes it
(M) SPL loads SBI and U-Boot proper and executes SBI
(M) SBI performs initialization and executes U-Boot
(S) U-Boot loads Linux and executes it
(S) Linux boots

And this would change that to

(M) Boot ROM loads SPL and executes it
(M) SPL loads SBI and Linux and executes SBI
(M) SBI performs initialization and executes Linux
(S) Linux boots

So the idea here is to load Linux in SPL instead of U-Boot. But I think this is
the only way to go for platforms which use OpenSBI. Regular falcon mode would
require a Linux which runs in M-mode. So I don't think we need a separate config.

--Sean

> It's not clear to me, and I think that'll help figure out what's best
> here. Since I kinda think we're looking at a more generic issue that we
> see with newer architectures and maybe we already had to solve this (but
> didn't name things well enough) for aarch64.
> 




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-14  1:54             ` Tom Rini
@ 2022-12-14  2:14               ` Rick Chen
  0 siblings, 0 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-14  2:14 UTC (permalink / raw)
  To: Tom Rini; +Cc: Sean Anderson, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

Hi Tom,

> On Wed, Dec 14, 2022 at 08:49:03AM +0800, Rick Chen wrote:
> > Hi Tom,
> >
> > > On Tue, Dec 13, 2022 at 10:06:50AM +0800, Rick Chen wrote:
> > > > > On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > > > > > > On 12/7/22 01:23, Rick Chen wrote:
> > > > > > > > In RISC-V, it only provide normal mode booting currently.
> > > > > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > > > > > to achieve this feature which will be call Fast-Boot mode. By
> > > > > > >
> > > > > > > Can you name this something different. We already have something called
> > > > > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > > > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > > > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > > > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > > > > >
> > > > > > I think fast boot is a behavior which shall be interpreted widely but
> > > > > > not proprietary.
> > > > > > Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> > > > > >
> > > > > > >
> > > > > > > (Is this substantially different from falcon mode anyway?)
> > > > > >
> > > > > > Please see the explanations to Tom.
> > > > > >
> > > > > > >
> > > > > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > > > > > > of default u-boot.itb after compiling. It initializes memory with
> > > > > > > > the U-Boot SPL at the first stage, just like what a regular booting
> > > > > > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > > > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > > > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > > > > > > booting time.
> > > > > > > >
> > > > > > > > Signed-off-by: Rick Chen <rick@andestech.com>
> > > > > > > > ---
> > > > > > > >   common/spl/Kconfig       | 14 ++++++++++++++
> > > > > > > >   common/spl/spl_fit.c     |  3 ++-
> > > > > > > >   common/spl/spl_opensbi.c | 25 ++++++++++++-------------
> > > > > > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > > > index 05181bdba3..8805aba1b7 100644
> > > > > > > > --- a/common/spl/Kconfig
> > > > > > > > +++ b/common/spl/Kconfig
> > > > > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > > > > > >         Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS or
> > > > > > > >         SBI_SCRATCH_DEBUG_PRINTS.
> > > > > > > >
> > > > > > > > +config SPL_OPENSBI_OS_BOOT
> > > > > > >
> > > > > > > Please use the same name for the config as for the description.
> > > > > > >
> > > > > > > > +     bool "openSBI Fast Boot"
> > > > > > > > +     depends on SPL_OPENSBI
> > > > > > > > +     help
> > > > > > > > +       Enable this openSBI can jump to Linux Kernel directly.
> > > > > > >
> > > > > > > Can you put some of the explanation from the commit message here?
> > > > > >
> > > > > > OK, I will move some messages here from commit messages.
> > > > > >
> > > > > > >
> > > > > > > > +
> > > > > > > > +config SPL_OPENSBI_FIT_NAME
> > > > > > > > +     string "SPL openSBI fit image name"
> > > > > > > > +     depends on SPL_OPENSBI
> > > > > > > > +     default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > > > > > +     default "u-boot.itb"
> > > > > > > > +     help
> > > > > > > > +       This will help to generate different fit name accordingly.
> > > > > > >
> > > > > > > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> > > > > > >
> > > > > > > It looks like the code changes below do not use these configs. Can you
> > > > > > > move them to the next patch so it is clearer that they are for binman?
> > > > > >
> > > > > > I have saw this config, but it does't support SPL_RAM but only for filesystem
> > > > > > That is why I don't leverage it.
> > > > > >
> > > > > > I can prepare a patch as below if no other concerns:
> > > > > >
> > > > > > config SPL_FS_LOAD_PAYLOAD_NAME
> > > > > > string "File to load for U-Boot from the filesystem"
> > > > > > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> > > > > > default "tispl.bin" if SYS_K3_SPL_ATF
> > > > > > default "u-boot.itb" if SPL_LOAD_FIT
> > > > > > default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > > > default "u-boot.img"
> > > > > > help
> > > > > >   Filename to read to load U-Boot when reading from filesystem.
> > > > >
> > > > > But in the case you have it's for the output name, and not at all about
> > > > > what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."
> > > >
> > > > For SPL_RAM purpose,
> > > > it is just an output name to distinguish normal boot (u-boot.itb) and
> > > > fast boot (linux.itb) indeed.
> > > >
> > > > But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination,
> > > > it can help to load linux.itb automatically from SD card.
> > >
> > > What part of the world is looking for the file named by
> > > SPL_FS_LOAD_PAYLOAD_NAME ? (and this is related to what I just sent out,
> > > asking about the boot flow)
> >
> > In the following commit, CONFIG_SPL_FS_LOAD_PAYLOAD_NAME has been
> > moved to Kconfig from ax25-ae350.h
> > That is why I try to add this change to load u-boot.itb or linux.itb
> > from SD card here
> >
> > commit 4a11e34bc9c0f3818f3e847ac51c82d1c9bbb807
> > Author: Tom Rini <trini@konsulko.com>
> > Date:   Fri May 13 17:12:35 2022 -0400
> >
> >     Convert CONFIG_SPL_FS_LOAD_PAYLOAD_NAME et al to Kconfig
> >
> > ...
> >
> > +++ b/include/configs/ax25-ae350.h
> > @@ -11,10 +11,6 @@
> >  #define CONFIG_SPL_MAX_SIZE            0x00100000
> >  #define CONFIG_SPL_BSS_START_ADDR      0x04000000
> >  #define CONFIG_SPL_BSS_MAX_SIZE                0x00100000
> > -
> > -#ifdef CONFIG_SPL_MMC
> > -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME                "u-boot.itb"
> > -#endif
>
> Yes, I made a best guess "what do I need to do to have zero size change"
> migration of that option, along with most others. So, sorry, my original
> question remains.  In real world usage, what is using that name? The

In development, I will often enable SPL_MMC and SPL_FAT by 'make
menuconfig' manually.
It will boot faster and quickly than SPL_RAM for debugging.

It is wired to add  default "linux.itb" if SPL_OPENSBI_OS_BOOT here.
It shall be appear with an defconfig something like
ae350_rv[32|64]_spl_mmc_fastboot_defconfig which enables SPL_FAT and
SPL_MMC.
Sorry about this confusion.

Thanks,
Rick


> regular usage here is that SPL knows to read from FAT (or similar) that
> name as a hard-coded default.
>
> --
> Tom

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
  2022-12-14  2:01               ` Sean Anderson
@ 2022-12-14  6:32                 ` Rick Chen
  0 siblings, 0 replies; 21+ messages in thread
From: Rick Chen @ 2022-12-14  6:32 UTC (permalink / raw)
  To: Sean Anderson; +Cc: Tom Rini, Rick Chen, ycliang, u-boot, sjg, xypron.glpk

> On 12/13/22 11:24, Tom Rini wrote:
> > On Tue, Dec 13, 2022 at 08:42:47AM +0800, Rick Chen wrote:
> >> Hi Sean,
> >>
> >>> On 12/12/22 10:03, Tom Rini wrote:
> >>>> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> >>>>> Hi Tom
> >>>>>
> >>>>>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> >>>>>>> On 12/7/22 01:23, Rick Chen wrote:
> >>>>>>>> In RISC-V, it only provide normal mode booting currently.
> >>>>>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> >>>>>>>> to achieve this feature which will be call Fast-Boot mode. By
> >>>>>>>
> >>>>>>> Can you name this something different. We already have something called
> >>>>>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> >>>>>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't
> >>>>>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle
> >>>>>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> >>>>>>>
> >>>>>>> (Is this substantially different from falcon mode anyway?)
> >>>>>>
> >>>>>> I was kind of wondering if this is different, really, from Falcon Mode.
> >>>>>> Falcon Mode didn't initially have to factor in other-firmware as that's
> >>>>>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> >>>>>> first read of this was that it seems like the RISC-V specific side of
> >>>>>> doing Falcon Mode and dealing with the prior stage needs correctly.
> >>>>>>
> >>>>>
> >>>>> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> >>>>> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
> >>>>>    jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> >>>>> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> >>>>> flow in board_init_r() of common/spl/spl.c.
> >>>>> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> >>>>> RISC-V fast boot implementation.
> >>>>
> >>>> Those sound like fairly minor challenges for the same fundamental
> >>>> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> >>>> pass along". We might need to do a little code re-factoring here. But
> >>>> maybe also a little bit of explaining why we wouldn't be booting to the
> >>>> OS directly but instead passing back to openSBI to do this? That's not
> >>>> normally how RISC-V boots the OS, right? Or am I miss-understanding
> >>>> something here?
> >>>>
> >>>
> >>> The usual process is
> >>>
> >>> ROM -> SPL -> SBI -> U-Boot -> Linux
> >>
> >> In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as
> >> M-mode to deal with SBI calls at run-time.
> >> So the fast boot idea, I just want to bypass U-Boot and jump to Linux
> >> directly and Linux still needs OpenSBI.
> >> Hence SPL_OPENSBI can't be disabled here.
> >
> > So is the flow here:
> > a) ROM -> SPL -> SBI -> SPL -> Linux
> > or
> > b) ROM -> SPL -> SBI -> Linux
>
> The latter. The regular boot is
>
> (M) Boot ROM loads SPL and executes it
> (M) SPL loads SBI and U-Boot proper and executes SBI
> (M) SBI performs initialization and executes U-Boot
> (S) U-Boot loads Linux and executes it
> (S) Linux boots
>
> And this would change that to
>
> (M) Boot ROM loads SPL and executes it
> (M) SPL loads SBI and Linux and executes SBI
> (M) SBI performs initialization and executes Linux
> (S) Linux boots
>
> So the idea here is to load Linux in SPL instead of U-Boot. But I think this is
> the only way to go for platforms which use OpenSBI. Regular falcon mode would
> require a Linux which runs in M-mode. So I don't think we need a separate config.

Hi Sean,

Thanks for your explanation. It is very clear.

Hi Tom, Sean,

Do you have any further suggestions that I can improve or refine this patch ?

Thanks,
Rick

>
> --Sean
>
> > It's not clear to me, and I think that'll help figure out what's best
> > here. Since I kinda think we're looking at a more generic issue that we
> > see with newer architectures and maybe we already had to solve this (but
> > didn't name things well enough) for aarch64.
> >
>
>
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-12-14  6:32 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-07  6:23 [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Rick Chen
2022-12-07  6:23 ` [PATCH 2/4] riscv: dts: Support Fast-Boot Rick Chen
2022-12-07  6:23 ` [PATCH 3/4] riscv: ae350: Support Fast Boot Rick Chen
2022-12-07  6:23 ` [PATCH 4/4] doc: ae350: Add Fast Boot description Rick Chen
2022-12-09 13:48 ` [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT Sean Anderson
2022-12-09 22:07   ` Tom Rini
2022-12-12  6:45     ` Rick Chen
2022-12-12 15:03       ` Tom Rini
2022-12-13  0:31         ` Sean Anderson
2022-12-13  0:42           ` Rick Chen
2022-12-13 16:24             ` Tom Rini
2022-12-14  2:01               ` Sean Anderson
2022-12-14  6:32                 ` Rick Chen
2022-12-13  1:31         ` Rick Chen
2022-12-12  7:49   ` Rick Chen
2022-12-12 15:52     ` Tom Rini
2022-12-13  2:06       ` Rick Chen
2022-12-13 16:27         ` Tom Rini
2022-12-14  0:49           ` Rick Chen
2022-12-14  1:54             ` Tom Rini
2022-12-14  2:14               ` Rick Chen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.