On 09/25/2017 07:17 AM, Łukasz Majewski wrote:
Hi York,
If you don't mind, I would like to ask you for some help and clarification regarding your work.
Add jump_to_image_linux() for arm64. Add "noreturn" flag to armv8_switch_to_el2(). Add hooks to fsl-layerscape to enable falcon boot.
I'm trying to do the same on imx6q board (armv7).
Signed-off-by: York Sun york.sun@nxp.com
Changes in v2: Relace getenv_f() with env_get_f() after rebasing to latet master.
.../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 140 +++++++++++++++++++++ arch/arm/cpu/armv8/fsl-layerscape/spl.c | 29 +++++ arch/arm/include/asm/system.h | 2 +- arch/arm/lib/spl.c | 11 ++ 4 files changed, 181 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon new file mode 100644 index 0000000..282b19f --- /dev/null +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon @@ -0,0 +1,140 @@ +Falcon boot option +------------------ +Falcon boot is a short cut boot method for SD/eMMC targets. It skips loading the +RAM version U-Boot. Instead, it loads FIT image and boot directly to Linux. +CONFIG_SPL_OS_BOOT enables falcon boot. CONFIG_SPL_LOAD_FIT enables the FIT
^^^^^^ - this is a bit cumbersome, since it requires some stubfor dtb creation (but this can be fixed for boards not yet supporting dts u-boot configuration).
+image support (also need CONFIG_SPL_OF_LIBFDT, CONFIG_SPL_FIT and optionally +CONFIG_SPL_GZIP).
+To enable falcon boot, a hook function spl_start_uboot() returns 0 to indicate +booting U-Boot is not the first choice. The kernel FIT image needs to be put +at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. SPL mmc driver reads the header to +determine if this is a FIT image. If true, FIT image components are parsed and +copied or decompressed (if applicable) to their desitinations. If FIT image is +not found, normal U-Boot flow will follow.
This part is similar to the one for old, venerable uImage.
+An important part of falcon boot is to prepare the device tree. A normal U-Boot +does FDT fixups when booting Linux. For falcon boot, Linux boots directly from +SPL, skipping the normal U-Boot. The device tree has to be prepared in advance. +A command "spl export" should be called under the normal RAM version U-Boot. +It is equivalent to go through "bootm" step-by-step until device tree fixup is +done. The device tree in memory is the one needed for falcon boot. Falcon boot +flow suggests to save this image to SD/eMMC at the location pointed by macro +CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, with maximum size specified by macro +CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS. However, when FIT image is used for +Linux, the device tree stored in FIT image overwrites the memory loaded by spl +driver from these sectors. We could change this loading order to favor the +stored sectors. But when secure boot is enabled, these sectors are used for +signature header and needs to be loaded before the FIT image. So it is important +to understand the device tree in FIT image should be the one actually used, or +leave it abscent to favor the stored sectors. It is easier to deploy the FIT +image with embedded static device tree to multiple boards.
+Macro CONFIG_SYS_SPL_ARGS_ADDR serves two purposes. One is the pointer to load +the stored sectors to. Normally this is the static device tree. The second +purpose is the memory location of signature header for secure boot. After the +FIT image is loaded into memory, it is validated against the signature header +before individual components are extracted (and optionally decompressed) into +their final memory locations, respectivelly. After the validation, the header +is no longer used. The static device tree is copied into this location. So +this macro is passed as the location of device tree when booting Linux.
I've not yet go to this point -> Please look into below comments.
I'm just curious - how can I specify the DTBs precedence? I mean how to decide if one from FIT or from eMMC sector are used?
By the order of loading ARGS first, then FIT. If you have static device tree in FIT image, it can overwrite the image loaded from ARGS. For my testing, I have verified FIT image without device tree in which case the device tree is loaded from ARGS.
+components. Otherwise U-Boot cannot load them correctly.
+Generate FIT image with static device tree +------------------------------------------ +Example:
+/dts-v1/;
I'm trying to load fitImage (with kernel + 2 dtbs) from eMMC directly by SPL. The fitImage has been generated with OE-core recipe. The same results are with one generated with mkimage.
+/ {
- description = "Image file for the LS1043A Linux Kernel";
- #address-cells = <1>;
- images {
kernel@1 {description = "ARM64 Linux kernel";data = /incbin/("./arch/arm64/boot/Image.gz");type = "kernel";arch = "arm64";os = "linux";compression = "gzip";load = <0x80080000>;entry = <0x80080000>;^^^^ common/spl/spl_fit.c - function spl_load_fit_image() requires "data-offset" and "data-size" properties to be defined -otherwise we exit with -ENOENT.
I thought we fixed that. In my previous patch set I added FIT support. The data-offset is used for external data (i.e. data is outside of FIT structure, eg. U-Boot). For Linux FIT image, the data is embedded. See spl_load_fit_image().
Even when creating my fitImage with u-boot's mkimage those properties haven't been added.
Because data-offset is not used for embedded data.
};fdt@1 {description = "Flattened Device Tree blob";data = /incbin/("./fsl-ls1043ardb-static.dtb");type = "flat_dt";arch = "arm64";compression = "none";load = <0x90000000>;};ramdisk@1 {description = "LS1043 Ramdisk";data = /incbin/("./rootfs.cpio.gz");type = "ramdisk";arch = "arm64";os = "linux";compression = "gzip";load = <0xa0000000>;};- };
- configurations {
default = "config@1";config@1 {description = "Boot Linux kernel";kernel = "kernel@1";fdt = "fdt@1";ramdisk = "ramdisk@1";loadables = "fdt", "ramdisk";^^^ Isn't here loadables require "kernel", "fdt", "ramdisk" ?Could you share how have you managed to load fitImage from SPL? Maybe I'm missing some patches? Is there any "reference" repo, so I could see the "complete" work?
I put the FIT image at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR, see patch 7 in this series. With correct configuration, U-Boot SPL code looks for FIT image at this location. If not found, it continues to boot U-Boot RAM version as before. If found, falcon boot kicks in.
I have a temporary repo for debugging. See https://github.com/yorksun/u-boot/commits/test_patches. The code base has changed so this one will not be there for long.
York