2021-01-04 11:48 PM
I've attempted to build my own u-boot image based on the trusted defconfig and a dk1 device tree, i.e.
$ make stm32mp15_basic_defconfig
$ make DEVICE_TREE=stm32mp157a-dk1 all
The build worked successfully, however when I attempted to use the `u-boot.stm32` image it failed to flash/boot. Getting the older fsbl working to flash my image into the ssbl ended up with failing messages:
stm32_smc: Failed to exec in secure mode (err = -3)
stm32_smc: Failed to exec in secure mode (err = -3)
stm32_smc: Failed to exec in secure mode (err = -3)
stm32_smc: Failed to exec in secure mode (err = -3)
stpmic1_read: failed to read register 0x22 : -110stpmic1_read: failed to read register 0x22 : -110stpmic1_read: failed to read register 0x22 : -110stpmic1_read: failed to read register 0x22 : -110Can't enable vdda-supply: -110
stpmic1_read: failed to read register 0x22 : -110stpmic1_read: failed to read register 0x22 : -110stpmic1_read: failed to read register 0x22 : -110stpmic1_read: failed to read register 0x22 : -110Can't enable vdda-supply: -110
Clearly the build wasn't secure so it couldn't be booted. I attempted to fix this via the STM32MP_KeyGen_CLI.exe and STM32MP_SigningTool_CLI.exe. I generated keys based on a test password that I created, then signed my u-boot image and flashed that instead.
After flashing, I attempted to boot and ran into a different error:
NFO: PMIC version = 0x10
INFO: Using SDMMC
INFO: Instance 1
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.2-r2.0(debug):v2.2-dirty
NOTICE: BL2: Built : 13:36:23, Oct 22 2019
INFO: Using crypto library 'stm32_crypto_lib'
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 533000Khz
INFO: Memory size = 0x20000000 (512 MB)
INFO: BL2 runs SP_MIN setup
INFO: BL2: Loading image id 4
INFO: Loading image id=4 at address 0x2ffeb000
INFO: Image id=4 loaded: 0x2ffeb000 - 0x2ffff000
INFO: BL2: Loading image id 5
INFO: Loading image id=5 at address 0xc0100000
INFO: STM32 Image size : 810794
INFO: Image id=5 loaded: 0xc0100000 - 0xc01c5f2a
INFO: Check signature on Open device
Basically the DK hangs here at "check signature". I'm guessing because I generated it incorrectly somehow, or it was looking for something specific.
Are there any instructions on the correct way to "sign" a u-boot image to be used by the DK1?
Thanks.
-Mike
2021-01-05 12:58 AM
Hi @MWors.1 ,
If not already done I advise you to read https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot
Olivier
2021-01-07 06:38 AM
@Community member Thanks for your response.
So if I'm reading this page correctly, the DK1, which has a STM32MP157A, can't actually do secure boot.
Cortex-A7 Cortex-M4 GPU Display CAN
STM32MP157 Dual Yes Yes TFT/DSI Yes
Security Cortex-A7 frequency
STM32MP15xA Basic 650 MHz[2]
Does this mean u-boot images for it should be created with the "basic" defconfig instead of the "trusted" one?
-Mike
2021-01-07 06:44 AM
Hi @MWors.1 ,
Yes you are right STM32MP15xA do not support secure boot.
From ecosystem V2.x we are no longer supporting so call "basic" boot but only "trusted" (using TF-A) .. but this does not mean Secure.
"Trusted" boot chain allow security but not enable it by default.
Hope it's clearer.
Olivier
2021-01-10 11:30 PM
@Community member
Prior to this discussion, I attempted to flash a base_defconfig, signed by the STM32MP_SigningTool_CLI.exe to my DevKit. After attempting this flash, it seems the board can't be flashed back to the original settings. Below is the log when I try to use the flash tool to return to the previous working configuration:
PS C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin> ./STM32_Programmer_CLI.exe -c port=usb1 -w FlashLayout_sdcard_stm32mp157a-dk1-trusted.tsv
-------------------------------------------------------------------
STM32CubeProgrammer v2.5.0
-------------------------------------------------------------------
USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
SN : 001C002E3438511538333630
FW version : 0x0110
Device ID : 0x0500
Device name : STM32MP1
Device type : MPU
Device CPU : Cortex-A7
Start Embedded Flashing service
Memory Programming ...
Opening and parsing file: tf-a-stm32mp157a-dk1-serialboot.stm32
File : tf-a-stm32mp157a-dk1-serialboot.stm32
Size : 237896 Bytes
Partition ID : 0x01
Download in Progress:
██████████████████████████████████████████████████ 100%
File download complete
Time elapsed during download operation: 00:00:00.503
RUNNING Program ...
PartID: :0x01
Start operation done successfully at partition 0x01
Flashlayout Programming ...
██████████████████████████████████████████████████ 100%
Running Flashlayout Partition ...
Flashlayout partition started successfully
Memory Programming ...
Opening and parsing file: u-boot-stm32mp157a-dk1-trusted.stm32
File : u-boot-stm32mp157a-dk1-trusted.stm32
Size : 902798 Bytes
Partition ID : 0x03
Download in Progress:
██████████████████████████████████████████████████ 100%
File download complete
Time elapsed during download operation: 00:00:01.002
RUNNING Program ...
PartID: :0x03
reconnecting the device ...
USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : USB download gadget@Device ID /0x500, @Revision ID /0x2000, @Name /STM32MP157AAC Rev.B,
SN : 001C002E3438511538333630
FW version : 0x0110
Device ID : 0x0500
Start operation done successfully at partition 0x03
Error:
Error: unable to get the associate alternate setting of partition ID: 0xf1
Error: please make sure that your alternate settings have string descriptors with the right format
Error: unable to upload data from virtual partition
Received PhaseID == 0xFF, system is going to reboot
Is there anyway to recover this board?
2021-01-11 12:18 AM
Hi @MWors.1 ,
Can you please share the UART console output during flash operation ?
Thanks
Olivier
2021-01-11 12:33 AM
Hi @Community member
Oddly enough, once I connected the uUSB to capture the output via TeraTerm, the flash succeeded. I changed nothing except attaching my USB to CN11 and starting up TeraTerm. So.. apparently that was all I needed.. I'm not sure why that was required to flash the board in this state.
I've since removed the uUSB and tried to go back to my standard flashing procedure, and now that works as expected again.
Any clue what attaching the uUSB to the DK changed?
2021-01-11 12:56 AM
Hi @MWors.1
Good news.
This behavior remind me a quite old bug due to ST-Link firmware.
Can you check installed version and upgrade ?
Olivier
2021-01-11 06:51 AM
Looks like it's version 2.1.0:
Not sure if this is the best way to check, or if there's a good way to upgrade. Any advice here would be helpful.
Thanks.
-Mike
2021-01-13 05:47 AM
Hi @MWors.1 ,
Sorry I thought i have reply but I should have forget to click on "reply" or else :\
I meant ST-Link firmware version on target.
With STM32CubeProg once connected with ST-Link you might see firmware version and firmware upgrade button
Olivier