U-boot errors when using SecureBoot with Arria10

[ChristianMS]

Hello,
We just want to boot to Arria10 with signed U-Boot and kernel. We are using yocto kirkstone (4.0.26), when we activate Secure Boot, we encountered different problems.

• With U-Boot 2021.07, U-Boot SPL complains about FIT structure, and refused to check signature the FIT signature of the U-Boot 2nd stage.
• With U-Boot 2024.04, U-Boot SPL succeed in checking U-Boot 2nd stage signature but crashed when jumping to second stage.

Does anyone succeed to use Secure Boot on Arria10 ? Could you provide us links / scripts / help ?
Thank you Christian & Baptiste.

Please found some details juste below:

Try with U-Boot 2021.07

SPL check signature => KO

So we enabled U-Boot FIT_SPL_SIGNATURE support, but the SPL of U-Boot 2021.07 complains about formatting error (wrong padding), but the U-Boot FIT image was generated with mkimage with the -E option (External binaries) and checked OK with the fit_check_sign tool.

SPL load FIT without checking signature in the SPL => OK

If we temporarily remove the signature check of the SPL (CONFIG_SPL_LOAD_FIT=y and without CONFIG_FIT_SIGNATURE ), the SPL can load the FIT without error, then jump to the U-Boot 2nd stage.

With CONFIG_FIT_SIGNATURE=y, the signature of the kernel FIT is verified by the U-Boot 2nd stage, then jump to the kernel sucessfully.

Observation:

With U-Boot 2021.07 SPL, the U-Boot FIT is loaded in the OCRAM, then the external binary U-Boot firmware is loaded to SDRAM (according load attribute), and the external binary flat FDT is load juste after the U-Boot.

Try with U-Boot 2024.04

U-Boot 2nd stage => KO

With CONFIG_FIT_SPL_SIGNATURE=y, the U-Boot FIT image is loaded directly to SDRAM, the FIT signature is correctly checking the U-Boot FIT image, the U-Boot seccond stage is loaded to SDRAM and Flat FDT is copied just after the U-Boot 2nd stage, but when SPL jump to entry address of the U-Boot 2nd stage, the console becomes silent, then watchdog is triggered after a few seconds .

U-Boot SPL 2024.04 (Jun 06 2025 - 15:04:18 +0000)
DDRCAL: Success
WDT: Started watchdog@ffd00300 with servicing every 1000ms (10s timeout)
Trying to boot from MMC1
## Loading standalone from FIT Image at 01000000 ...
External Data
Using 'conf' configuration
Could not find subimage node type 'standalone' fit_addr=1000000 cfg_noffset=652 ph_type=1
## Loading firmware from FIT Image at 01000000 ...
External Data
Using 'conf' configuration
Trying 'u-boot' firmware subimage
Description: U-Boot (32-bit)
Created: 2011-04-05 23:00:00 UTC
Type: Firmware
Compression: uncompressed
External Data
Data Start: 0x01000638
Data Size: 515560 Bytes = 503.5 KiB
Architecture: ARM
OS: U-Boot
Load Address: 0x00500000
Hash node: 'hash-1'
Hash algo: sha256
Hash value: 06b7a8bc53fe2608bc6b194646300adaf20d6ef4da95f647d25f31a47fe3fce4
Hash len: 32
External Data
Loading firmware from 0x01000638 to 0x00500000
SPL: payload image: U-Boot load addr: 0x500000 size: 515560
## Loading fdt from FIT Image at 01000000 ...
Using 'conf' configuration
Trying 'fdt' fdt subimage
Description: U-Boot DTB
Created: 2011-04-05 23:00:00 UTC
Type: Flat Device Tree
Compression: uncompressed
External Data
Data Start: 0x0107e420
Data Size: 24328 Bytes = 23.8 KiB
Architecture: ARM
Can't get 'load' property from FIT 0x01000000, node: offset 384, name fdt (FDT_ERR_NOTFOUND)
Hash node: 'hash-1'
Hash algo: sha256
Hash value: 2a447139bbea6e0349ee861229a78cfe5c4141a4d31ca5dcb09fe3f3aad392e2
Hash len: 32
External Data
Can't get 'load' property from FIT 0x01000000, node: offset 384, name fdt (FDT_ERR_NOTFOUND)
Relocating FDT from 107e420 to 57dde8
Jumping to U-Boot...
SPL malloc() used 0x1054 bytes (4 KB)
image entry point: 0x500000

I remove the signature verification by SPL (CONFIG_FIT_SIGNATURE=y and without CONFIG_FIT_SPL_SIGNATURE), but it still won't boot.

I look the Golden System Reference Design (GSRD). It uses the same U-Boot version from the same repository altera u-boot-socfpga, but the GSRD  is using legacy image (type firmware), that boots correctly, but cannot be signed.

[ChunHsienN_Altera]

Hi,

Have you read the AN 759: Using Secure Boot in Intel® Arria® 10 SoC Devices and see if that helps? The AN was updated for 20.4, I'll check if there is an updated version for newer U-Boot.

Thanks!

[ChristianMS]

Thank you for your answer, unfortunately I have already read this document.

It seems that it does not mention U-Boot versions validated with Arria10 Secure Boot support.

Are there recommended and validated versions of U-Boot for using Secureboot with Arria10?

[ChunHsienN_Altera]

Hi,

The AN was created based on U-Boot v2020.10, as documented in https://www.intel.com/content/www/us/en/docs/programmable/683060/20-4/creating-a-signed-first-stage-boot-loader.html

I'll let you know if I found a newer validated version.

Thanks!

[ChunHsienN_Altera]

Hi,

Unfortunately I can't find a newer validated U-Boot version.

From the v2024.04 log, it was complaining "Can't get 'load' property from FIT 0x01000000", common causes could be the FIT image missing the load property for the fdt node, incorrect/corrupted FIT image or the boot script referencing the wrong FIT sub image.

Please try to inspect from these various aspects.

Thanks!

[Jeet14]

Hi,

Let me know if you have any further query on this?

Regards

Tiwari

[ChristianMS]

Hi,

Thank you for your help. We have re-read the links you gave us (AN759), and mostly the chapter dedicated to secure boot.

We've try to follow the AN759 instructions to recompile u-boot in version 2020.10, and also in version 2021.07 and 2024.04, without secureboot process.

Unfortunately, the application note AN759 only explain how to embed the signature of SPL, so that BootROM can authenticate the SPL binary blob.

It does not contain any information about :

- how to embed public key in the SPL

- how to embed signature into u-boot

   so that SPL can authenticate the u-boot second stage (legacy or FIT image).

Neither it contains any information about :

- how to embed public key in the u-boot secondary stage

- how to embed signature into Linux kernel FIT image

   so that u-boot secondary stage can authenticate the Linux kernel and its flat devicetree (legacy or FIT image).

The problems started when we activate secureboot in u-boot configuration file, by using FIT_SPL_SIGNATURE and CONFIG_FIT_SIGNATURE options, as explain in our first message.

We are still searching for a solution for a full secure-boot process, not only SPL authentication by BootROM as described in AN759, but also U-Boot and kernel authentication.

Regards

     Christian & Baptiste

[SueC_Altera]

Hi Christian and Baptiste,

Once the HPS is in an authenticated SPL, all further authentication is expected to be done by U-boot standard libraries and has never been dependent on Altera code. Please see this U-Boot article on FIT signature verification: U-Boot FIT Signature Verification — Das U-Boot unknown version documentation . 

The process is:

• The Arria 10 ROM handles authentication of SPL
• SPL uses built-in libraries to authenticate U-boot & uboot DT
• U-boot uses those same libraries to authenticate the kernel & linux DT

 Regards,

Sue

[ChristianMS · Accepted solution]

Hi Support team,

Good news, we found why the sign FIT of U-Boot failed. The FIT loading strategy changed since 2021.07.

In old U-Boots, FIT is load into the OCRAM then external binaries are loaded to RAM to 0x1000040.

In recent U-Boots, FIT included external binaries is fully loaded to RAM at 0x1000000, then U-Boot binary and Flat DTB are loaded to the load address (0x500000) mentionned in the FIT (it was not possible to keep the same address, in order to avoid overlap).

The jump to U-Boot failed because we forgot to change the load address of U-Boot in the U-Boot configuration. As a result, U-Boot was compiled to execute at an address different from the one to which it was copied.

So just by setting CONFIG_TEXT_BASE=0x00500000, compile and flash. then U-Boot 2024.04 correctly boot.

Thank you for your support. You can close this topic.

[SueC_Altera]

Thanks for sharing your solution, Christian!