[PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
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;
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"; + }; }; }; };
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
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 #
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);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;
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.
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
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?
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
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
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.
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.
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.
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
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_OPENSBIhelpEnable 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_OPENSBIdefault "linux.itb" if SPL_OPENSBI_OS_BOOTdefault "u-boot.itb"helpThis 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;
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_OPENSBIhelpEnable 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_OPENSBIdefault "linux.itb" if SPL_OPENSBI_OS_BOOTdefault "u-boot.itb"helpThis 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.
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_OPENSBIhelpEnable 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_OPENSBIdefault "linux.itb" if SPL_OPENSBI_OS_BOOTdefault "u-boot.itb"helpThis 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
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_OPENSBIhelpEnable 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_OPENSBIdefault "linux.itb" if SPL_OPENSBI_OS_BOOTdefault "u-boot.itb"helpThis 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.
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_OPENSBIhelpEnable 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_OPENSBIdefault "linux.itb" if SPL_OPENSBI_OS_BOOTdefault "u-boot.itb"helpThis 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
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.
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
participants (4)
-
Rick Chen -
Rick Chen -
Sean Anderson -
Tom Rini