(Aspeed2600) Booting with a SPL loading U-boot fitImage

[Klaus Heinrich Kiwi]

On 3/1/2021 4:25 PM, Klaus Heinrich Kiwi wrote:
> Has anyone been able to successfully bring-up U-boot proper as a fitImage from the SPL, when using U-boot from the 2019.4 Aspeed SDK?


I spent a bit more time reading through the Aspeed SDK U-boot code and I think this is simply not implemented, and actually might explain why a Legacy Uboot image loads, even if Legacy Image is not enabled in the config...

So arch/arm/mach-aspeed/ast2600/utils.S defines the ast2600 ast_bootmode() to be one of 'AST_BOOTMODE_UART', 'AST_BOOTMODE_SPI' or 'AST_BOOTMODE_EMMC' based on hw strapping info and arch/arm/mach-aspeed/ast2600/spl.c:spl_boot_device() uses that to instruct the SPL which (of these 3 methods) to use...

The SPL is being built with multiple (redundant?) image loaders:

0000e5d0 D _u_boot_list_2_spl_image_loader_2_aspeed_spl_mmc_load_image0ASPEED_BOOT_DEVICE_MMC
0000e5dc D _u_boot_list_2_spl_image_loader_2_aspeed_spl_ram_load_image0ASPEED_BOOT_DEVICE_RAM
0000e5e8 D _u_boot_list_2_spl_image_loader_2_aspeed_spl_ymodem_load_image0ASPEED_BOOT_DEVICE_UART
0000e5f4 D _u_boot_list_2_spl_image_loader_2_spl_mmc_load_image0BOOT_DEVICE_MMC1
0000e600 D _u_boot_list_2_spl_image_loader_2_spl_mmc_load_image0BOOT_DEVICE_MMC2
0000e60c D _u_boot_list_2_spl_image_loader_2_spl_mmc_load_image0BOOT_DEVICE_MMC2_2
0000e618 D _u_boot_list_2_spl_image_loader_2_spl_ram_load_image0BOOT_DEVICE_RAM
0000e624 D _u_boot_list_2_spl_image_loader_2_spl_ymodem_load_image0BOOT_DEVICE_UART

But the ast_bootmode() causes only the aspeed_spl_*_load_image() to be really used.

And if we compare the aspeed versions (from arch/arm/mach-aspeed/ast2600/spl_boot.c) with the common versions (common/spl/spl_mmc.c), we clearly see that the common version has the infrastructure to detect and load the FIT, while the aspeed version is simply loading the raw contents of the mmc into RAM and setting the entry point to it's start (that means: treating the mmc contents as a legacy u-boot image regardless).

I guess that the amount of coding required to catch-up 'aspeed_secboot_spl_*_load_image' with the necessary SPL_LOAD_FIT infrastructure is not trivial, so I'm hoping that the other way around (using the common infrastructure) is easier - Joel, Ryan, any comments?

It would also help in avoiding redundant symbols, since the way it is we cannot fit everything we need in the SPL + SPL DTB in 64KB anyway...

  -Klaus

-- 
Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>