Re: [PATCH V2] doc: falcon: riscv: Falcon Mode boot on RISC-V
On 11/2/23 13:10, Randolph wrote: Add documentation to introduce the Falcon Mode on RISC-V. In this mode, the boot sequence is SPL -> OpenSBI -> Linux kernel. Signed-off-by: Randolph --- doc/develop/falcon.rst | 159 + 1 file changed, 159 insertions(+) diff --git a/doc/develop/falcon.rst b/doc/develop/falcon.rst index 2f25fc8532..b553f0d0ea 100644 --- a/doc/develop/falcon.rst +++ b/doc/develop/falcon.rst @@ -256,3 +256,162 @@ the following command: Falcon Mode was presented at the RMLL 2012. Slides are available at: http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf + +Falcon Mode Boot on RISC-V +-- + +Introduction + Thank you for documenting this. In HTML we want this to be a title. The underscore type controls the title level. Please, use for the underline. Same below. + +In the RISC-V environment, OpenSBI is required to enable a supervisor mode %s/mode/mode binary/ +to execute certain privileged operations. The typical boot sequence on +RISC-V is SPL -> OpenSBI -> U-Boot -> Linux kernel. SPL will load and start +the OpenSBI initializations, then OpenSBI will bring up the next image, U-Boot. %s/U-Boot/U-Boot proper/ +The OpenSBI binary must be prepared in advance of the U-Boot build process +and it will be packed together with U-Boot into a file called u-boot.itb. + +The Falcon Mode on RISC-V platforms is a distinct boot process. Borrowing %s/processs/sequence/ +ideas from the U-Boot Falcon Mode on ARM, it skips the U-Boot proper phase +in the normal boot process and allows OpenSBI to load and start the Linux +kernel. Its boot sequence is SPL -> OpenSBI -> Linux kernel. The OpenSBI +binary and Linux kernel binary must be prepared prior to the U-Boot build +process and they will be packed together as linux.itb in this process. %s/linux.itb/a FIT image named linux.itb/ + +CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT enables the Falcon Mode boot on RISC-V. +This configuration tells OpenSBI that Linux kernel is its next OS image and %s/configuration/configuration setting/ +makes it load and start the kernel afterwards. + +Note that the Falcon Mode boot bypasses a lot of initializations by U-Boot. +If the Linux kernel expects hardware initializations by U-Boot, make sure to +port the relevant code to the SPL build process. + +Configurations %s/Configurations/Configuration/ +-- + +CONFIG_SPL_LOAD_FIT_ADDRESS +Specifies the address to load u-boot.itb in a normal boot. When the Falcon +Mode boot is enabled, it specifies the load address of linux.itb. + +CONFIG_SYS_TEXT_BASE +Specifies the address of the text section for a u-boot proper in a normal +boot. When the Falcon Mode boot is enabled, it specifies the text section +address for the Linux kernel image. + +CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT +Activates the Falcon Mode boot on RISC-V. + +Function that a board must implement + + +Initially, SPL places the FDT blob right after the kernel. As the kernel does +not include the BSS section in its size calculation, SPL ends up placing the +FDT blob within the BSS section of the kernel. This may cause the FDT blob to +be cleared during kernel BSS initialization. To avoid the issue, be sure to +move the FDT blob out of the kernel first. + +void spl_perform_fixups(struct spl_image_info *spl_image) +required, necessary action to move the FDT blob out of the Linux kernel BSS +section Shouldn't we have a generic function for this? Why should we want duplicate code? + +Example for Andes AE350 Board +- + +A FDT blob is required to boot the Linux kernel from the SPL. Andes AE350 +platforms generally come with a builtin dtb. If you want to load a custom DTB, +follow the steps below: + +1. Load the custom DTB to SDRAM:: + +=> fatload mmc 0:1 0x2000 user_custom.dtb + +2. Set the SPI speed:: + +=> sf probe 0:0 5000 0 + +3. Erase sectors from the SPI Flash:: + +=> sf erase 0xf 0x1 + +4. Write the FDT blob to the erased sectors of the Flash:: + +=> sf write 0x2000 0xf 0x1 + +Console Log of AE350 Falcon Mode Boot +- + Please, indent following log and precede it by '::' Best regards Heinrich +U-Boot SPL 2023.01-00031-g777ecdea66 (Oct 31 2023 - 18:41:36 +0800) +Trying to boot from RAM + +OpenSBI v1.2-51-g7304e42 + _ _ + / __ \ / | _ \_ _| + | | | |_ __ ___ _ __ | (___ | |_) || | + | | | | '_ \ / _ \ '_ \ \___ \| _ < | | + | |__| | |_) | __/ | | |) | |_) || |_ + \/| .__/ \___|_| |_|_/|/_| +| | +|_| + +Platform Name : andestech,ax25 +Platform Features : medeleg +Platform HART Count : 1 +Platform IPI Device : andes_plicsw +Platform Timer
[PATCH V2] doc: falcon: riscv: Falcon Mode boot on RISC-V
Add documentation to introduce the Falcon Mode on RISC-V. In this mode, the boot sequence is SPL -> OpenSBI -> Linux kernel. Signed-off-by: Randolph --- doc/develop/falcon.rst | 159 + 1 file changed, 159 insertions(+) diff --git a/doc/develop/falcon.rst b/doc/develop/falcon.rst index 2f25fc8532..b553f0d0ea 100644 --- a/doc/develop/falcon.rst +++ b/doc/develop/falcon.rst @@ -256,3 +256,162 @@ the following command: Falcon Mode was presented at the RMLL 2012. Slides are available at: http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf + +Falcon Mode Boot on RISC-V +-- + +Introduction + + +In the RISC-V environment, OpenSBI is required to enable a supervisor mode +to execute certain privileged operations. The typical boot sequence on +RISC-V is SPL -> OpenSBI -> U-Boot -> Linux kernel. SPL will load and start +the OpenSBI initializations, then OpenSBI will bring up the next image, U-Boot. +The OpenSBI binary must be prepared in advance of the U-Boot build process +and it will be packed together with U-Boot into a file called u-boot.itb. + +The Falcon Mode on RISC-V platforms is a distinct boot process. Borrowing +ideas from the U-Boot Falcon Mode on ARM, it skips the U-Boot proper phase +in the normal boot process and allows OpenSBI to load and start the Linux +kernel. Its boot sequence is SPL -> OpenSBI -> Linux kernel. The OpenSBI +binary and Linux kernel binary must be prepared prior to the U-Boot build +process and they will be packed together as linux.itb in this process. + +CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT enables the Falcon Mode boot on RISC-V. +This configuration tells OpenSBI that Linux kernel is its next OS image and +makes it load and start the kernel afterwards. + +Note that the Falcon Mode boot bypasses a lot of initializations by U-Boot. +If the Linux kernel expects hardware initializations by U-Boot, make sure to +port the relevant code to the SPL build process. + +Configurations +-- + +CONFIG_SPL_LOAD_FIT_ADDRESS +Specifies the address to load u-boot.itb in a normal boot. When the Falcon +Mode boot is enabled, it specifies the load address of linux.itb. + +CONFIG_SYS_TEXT_BASE +Specifies the address of the text section for a u-boot proper in a normal +boot. When the Falcon Mode boot is enabled, it specifies the text section +address for the Linux kernel image. + +CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT +Activates the Falcon Mode boot on RISC-V. + +Function that a board must implement + + +Initially, SPL places the FDT blob right after the kernel. As the kernel does +not include the BSS section in its size calculation, SPL ends up placing the +FDT blob within the BSS section of the kernel. This may cause the FDT blob to +be cleared during kernel BSS initialization. To avoid the issue, be sure to +move the FDT blob out of the kernel first. + +void spl_perform_fixups(struct spl_image_info *spl_image) +required, necessary action to move the FDT blob out of the Linux kernel BSS +section + +Example for Andes AE350 Board +- + +A FDT blob is required to boot the Linux kernel from the SPL. Andes AE350 +platforms generally come with a builtin dtb. If you want to load a custom DTB, +follow the steps below: + +1. Load the custom DTB to SDRAM:: + +=> fatload mmc 0:1 0x2000 user_custom.dtb + +2. Set the SPI speed:: + +=> sf probe 0:0 5000 0 + +3. Erase sectors from the SPI Flash:: + +=> sf erase 0xf 0x1 + +4. Write the FDT blob to the erased sectors of the Flash:: + +=> sf write 0x2000 0xf 0x1 + +Console Log of AE350 Falcon Mode Boot +- + +U-Boot SPL 2023.01-00031-g777ecdea66 (Oct 31 2023 - 18:41:36 +0800) +Trying to boot from RAM + +OpenSBI v1.2-51-g7304e42 + _ _ + / __ \ / | _ \_ _| + | | | |_ __ ___ _ __ | (___ | |_) || | + | | | | '_ \ / _ \ '_ \ \___ \| _ < | | + | |__| | |_) | __/ | | |) | |_) || |_ + \/| .__/ \___|_| |_|_/|/_| +| | +|_| + +Platform Name : andestech,ax25 +Platform Features : medeleg +Platform HART Count : 1 +Platform IPI Device : andes_plicsw +Platform Timer Device : andes_plmt @ 6000Hz +Platform Console Device : uart8250 +Platform HSM Device : andes_smu +Platform PMU Device : andes_pmu +Platform Reboot Device: atcwdt200 +Platform Shutdown Device : --- +Firmware Base : 0x0 +Firmware Size : 196 KB +Runtime SBI Version : 1.0 + +Domain0 Name : root +Domain0 Boot HART : 0 +Domain0 HARTs : 0* +Domain0 Region00 : 0x-0x0003 () +Domain0 Region01 : 0xe600-0xe60f (I,R) +Domain0 Region02 :
