<div dir="ltr"><div>FB/Verified-boot uses u-boot proper fit-image to reuse the fit sign and verification code to load and verify u-boot and subordinate keys.</div><div>the booting and verify process is:</div><div>SPL : <br></div><div> 1. verify  subordinate-keys within the u-boot proper fitimage. <br></div><div> 2. use the verified subordinate-keys to verify the u-boot and load it.<br></div><div>U-boot proper: <br></div><div>  1. use subordinate-keys verify os ( kernel, rootfs and fdt).</div><div><br></div><div>Refer to code below for how to create the u-boot proper fit-image.<br></div><div dir="ltr"><a href="https://github.com/facebook/openbmc/blob/helium/meta-aspeed/classes/kernel_fitimage.bbclass">https://github.com/facebook/openbmc/blob/helium/meta-aspeed/classes/kernel_fitimage.bbclass</a></div><div><br></div><div>Refer to code below for SPL verify and load u-boot proper fit. This is quite a hack, not using the SPL image loading framework.<br></div><div><a href="https://github.com/facebook/openbmc-uboot/blob/2fcac0176e5542a47e06e15d5052e6fb78c7432e/board/aspeed/ast-g5/ast-g5-spl.c#L483">https://github.com/facebook/openbmc-uboot/blob/2fcac0176e5542a47e06e15d5052e6fb78c7432e/board/aspeed/ast-g5/ast-g5-spl.c#L483</a></div><div><br></div><div>BRs</div><div>Dan <br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 2, 2021 at 5:21 AM Klaus Heinrich Kiwi <<a href="mailto:klaus@linux.vnet.ibm.com">klaus@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 3/2/2021 4:54 AM, Dan Zhang wrote:<br>
<br>
> I think within A FIT image, the u-boot binary is not located at your entry point 0x81000000,<br>
> it is behind the fit header, somewhere. This means the entry_point and load_addr is not the same as spl_boot.c defined.<br>
> spl_image->entry_point= CONFIG_ASPEED_UBOOT_DRAM_BASE;<br>
> spl_image->load_addr= CONFIG_ASPEED_UBOOT_DRAM_BASE;<br>
> Also, the u-boot code itself before relocation is position aware ( SYS_TEXT_BASE must be set to 0x81000000, as your second try works). This means the entry_point shall be the same as SYS_TEXT_BASE.<br>
<br>
I think it's not that simple. See my answer (to myself) in this same thread with new information.<br>
<br>
> In fb/OpenBMC, verified boot implementation, use mkimage option:<br>
>    -p => place external data at a static position,<br>
> thus we specify the somewhere to a static offset , then you can set the entry_point = load_addr + offset.<br>
<br>
Verified boot should work if you are having u-boot proper validating the Linux Kernel fitimage, but I don't see how the Aspeed 2600 SPL would be able to load and verify the u-boot proper fitimage - the code simply isn't there..<br>
<br>
It seems to me that the SPL_LOAD_FIT code should handle recognizing the fitimage, moving it's 'loadables' images into memory and setting the entry point accordingly.<br>
<br>
  -Klaus<br>
</blockquote></div></div>