1Falcon boot option 2------------------ 3Falcon boot is a short cut boot method for SD/eMMC targets. It skips loading the 4RAM version U-Boot. Instead, it loads FIT image and boot directly to Linux. 5CONFIG_SPL_OS_BOOT enables falcon boot. CONFIG_SPL_LOAD_FIT enables the FIT 6image support (also need CONFIG_SPL_OF_LIBFDT, CONFIG_SPL_FIT and optionally 7CONFIG_SPL_GZIP). 8 9To enable falcon boot, a hook function spl_start_uboot() returns 0 to indicate 10booting U-Boot is not the first choice. The kernel FIT image needs to be put 11at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. SPL mmc driver reads the header to 12determine if this is a FIT image. If true, FIT image components are parsed and 13copied or decompressed (if applicable) to their destinations. If FIT image is 14not found, normal U-Boot flow will follow. 15 16An important part of falcon boot is to prepare the device tree. A normal U-Boot 17does FDT fixups when booting Linux. For falcon boot, Linux boots directly from 18SPL, skipping the normal U-Boot. The device tree has to be prepared in advance. 19A command "spl export" should be called under the normal RAM version U-Boot. 20It is equivalent to go through "bootm" step-by-step until device tree fixup is 21done. The device tree in memory is the one needed for falcon boot. Falcon boot 22flow suggests to save this image to SD/eMMC at the location pointed by macro 23CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, with maximum size specified by macro 24CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS. However, when FIT image is used for 25Linux, the device tree stored in FIT image overwrites the memory loaded by spl 26driver from these sectors. We could change this loading order to favor the 27stored sectors. But when secure boot is enabled, these sectors are used for 28signature header and needs to be loaded before the FIT image. So it is important 29to understand the device tree in FIT image should be the one actually used, or 30leave it absent to favor the stored sectors. It is easier to deploy the FIT 31image with embedded static device tree to multiple boards. 32 33Macro CONFIG_SYS_SPL_ARGS_ADDR serves two purposes. One is the pointer to load 34the stored sectors to. Normally this is the static device tree. The second 35purpose is the memory location of signature header for secure boot. After the 36FIT image is loaded into memory, it is validated against the signature header 37before individual components are extracted (and optionally decompressed) into 38their final memory locations, respectively. After the validation, the header 39is no longer used. The static device tree is copied into this location. So 40this macro is passed as the location of device tree when booting Linux. 41 42Steps to prepare static device tree 43----------------------------------- 44To prepare the static device tree for Layerscape boards, it is important to 45understand the fixups in U-Boot. Memory size and location, as well as reserved 46memory blocks are added/updated. Ethernet MAC addressed are updated. FMan 47microcode (if used) is embedded in the device tree. Kernel command line and 48initrd information are embedded. Others including CPU status, boot method, 49Ethernet port status, etc. are also updated. 50 51Following normal booting process, all variables are set, all images are loaded 52before "bootm" command would be issued to boot, run command 53 54spl export fdt <address> 55 56where the address is the location of FIT image. U-Boot goes through the booting 57process as if "bootm start", "bootm loados", "bootm ramdisk"... commands but 58stops before "bootm go". There we have the fixed-up device tree in memory. 59We can check the device tree header by these commands 60 61fdt addr <fdt address> 62fdt header 63 64Where the fdt address is the device tree in memory. It is printed by U-Boot. 65It is useful to know the exact size. One way to extract this static device 66tree is to save it to eMMC/SD using command in U-Boot, and extract under Linux 67with these commands, repectively 68 69mmc write <address> <sector> <sectors> 70dd if=/dev/mmcblk0 of=<filename> bs=512 skip=<sector> count=<sectors> 71 72Note, U-Boot takes values as hexadecimals while Linux takes them as decimals by 73default. If using NAND or other storage, the commands are slightly different. 74When we have the static device tree image, we can re-make the FIT image with 75it. It is important to specify the load addresses in FIT image for every 76components. Otherwise U-Boot cannot load them correctly. 77 78Generate FIT image with static device tree 79------------------------------------------ 80Example: 81 82/dts-v1/; 83 84/ { 85 description = "Image file for the LS1043A Linux Kernel"; 86 #address-cells = <1>; 87 88 images { 89 kernel { 90 description = "ARM64 Linux kernel"; 91 data = /incbin/("./arch/arm64/boot/Image.gz"); 92 type = "kernel"; 93 arch = "arm64"; 94 os = "linux"; 95 compression = "gzip"; 96 load = <0x80080000>; 97 entry = <0x80080000>; 98 }; 99 fdt-1 { 100 description = "Flattened Device Tree blob"; 101 data = /incbin/("./fsl-ls1043ardb-static.dtb"); 102 type = "flat_dt"; 103 arch = "arm64"; 104 compression = "none"; 105 load = <0x90000000>; 106 }; 107 ramdisk { 108 description = "LS1043 Ramdisk"; 109 data = /incbin/("./rootfs.cpio.gz"); 110 type = "ramdisk"; 111 arch = "arm64"; 112 os = "linux"; 113 compression = "none"; 114 load = <0xa0000000>; 115 }; 116 }; 117 118 configurations { 119 default = "config-1"; 120 config-1 { 121 description = "Boot Linux kernel"; 122 kernel = "kernel"; 123 fdt = "fdt-1"; 124 ramdisk = "ramdisk"; 125 loadables = "fdt", "ramdisk"; 126 }; 127 }; 128}; 129 130The "loadables" is not optional. It tells SPL which images to load into memory. 131 132Falcon mode with QSPI boot 133-------------------------- 134To use falcon mode with QSPI boot, SPL needs to be enabled. Similar to SD or 135NAND boot, a RAM version full feature U-Boot is needed. Unlike SD or NAND boot, 136SPL with QSPI doesn't need to combine SPL image with RAM version image. Two 137separated images are used, u-boot-spl.pbl and u-boot.img. The former is SPL 138image with RCW and PBI commands to load the SPL payload into On-Chip RAM. The 139latter is RAM version U-Boot in FIT format (or legacy format if FIT is not 140used). 141 142Other things to consider 143----------------------- 144Falcon boot skips a lot of initialization in U-Boot. If Linux expects the 145hardware to be initialized by U-Boot, the related code should be ported to SPL 146build. For example, if Linux expect Ethernet PHY to be initialized in U-Boot 147(which is not a common case), the PHY initialization has to be included in 148falcon boot. This increases the SPL image size and should be handled carefully. 149If Linux has PHY driver enabled, it still depends on the correct MDIO bus setup 150in U-Boot. Normal U-Boot sets the MDC ratio to generate a proper clock signal. 151