I have been working on a secure boot on the Cyclone V, and to that end got the DE10-nano board, and am trying to implement the cyclone V soc secure boot example
I have, I believe, followed the instructions correctly, however, the interesting part of the boot is failing. That is, I generated a uboot payload, signed it, and then burned the signature and the payload as part of the JIC file. When the system boots, I get the following:
U-Boot SPL 2013.01.01 (Dec 16 2021 - 11:16:14)
BOARD : Altera SOCFPGA Cyclone V Board
CLOCK: EOSC1 clock 25000 KHz
CLOCK: EOSC2 clock 25000 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 800 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 50000 KHz
CLOCK: QSPI clock 3125 KHz
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 1024 MiB
INIT: MPL build: Oct 6 2021 09:44:47
INIT: Initializing board.
INIT: MPU clock = 800 MHz
INIT: DDR clock = 400 MHz
INIT: Initializing successful.
SBOOT: Auth Fail - Error 6
And of course at this point it does not run the uboot, rather it hangs. I followed the code to see what the issue is, and I get this:
Calling stack of failure:
In mbedtls_ecdsa_verify, which is what failed, this is the line which failed
* Step 8: check if v (that is, R.X) is equal to r
if( mbedtls_mpi_cmp_mpi( &R.X, r ) != 0 )
ret = MBEDTLS_ERR_ECP_VERIFY_FAILED;
Now, the signature and the uboot payload were both generated by the process as shown in step 2 of the demo, that is:
- Generate the payload executable. In our case this will be u-boot, so that will be generated next. In an embedded command shell, move to the software/spl_bsp directory and execute “make uboot” to generate a u-boot executable file.
- Sign and package the payload executable ready for storing in flash memory by changing to the software/uboot_payload directory and executing “./encrypt_payload.sh”
I did exactly that, and in fact, after receiving the error, went and verified that both the signature and the signed payload were correctly burned (by doing memory dumps and comparing them to the original hex files generated in step 2).
A few other issues which may help pinpoint the problem. When simply powering on the board without using the debugger, no serial output at all happens. In order to get as far as I have, and see the AUTH Fail, I had to connect the debugger and run from HPS start. I expect I have some issue with waiting for the FPGA as well, and perhaps it is connected.
Has anyone experienced the same thing, or have an idea why this could be happening?
Serial messages from MPL and U-Boot by default are output to the UART-USB connector (the connector next to the ethernet socket), not from JTAG USB, and you need to run a serial console tool, e.g. PuTTY (https://www.putty.org/).
I also noticed that your output is reversed, i.e. it starts execution with U-Boot, but MPL needs to execute first, which then reads the payload (U-Boot) bytes from flash memory and checks the signature. If correct then it will load it into RAM and jump to it.
I would like to know did you do any additional changes when following the secure boot example from Rocketboards?
This is Steve Burck, I'm writing from Elhanan Sharon's account (local distributor embedded FAE).
Confirming we did a change in the design. Details following.
The original RocketBoards link used a revision A of the DE10-Nano board, which was the valid version of that time
We acquired recently the same board, purely for this mission.
However the only version available for purchase is version C.
The differences between version A and version C of the Terasic DE10-Nano board are depicted in the attached file of
Notice on page 2, under bullet "Board Revision" the table of the differences between the versions of the board.
One can notice the original version A had an EPCS 128Mb device, while version C has EPCS 64Mb compatible device.
So, we had no choise but to change the design to support the EPCS 64Mb device.
This was the only change we made.
I was asking around regarding the secureboot signature read errors.
I get to a point where the CycloneV secure boot is no longer a supported feature.
Therefore, there will be no engineering support from the security team to work/troubleshoot on this particular feature.
Sorry to inform about that.