2021-05-27 10:48 AM
Hi, Everybody!
Referring to this issue:
PatrickF suggested to manually configure U-BOOT for my board. I have downloaded tf-a sources patched it, of course installed and configured SDK and trying to do all according to it's README.HOW_TO.txt file.
As I have my specific DT I need to specify it in makefile parameters:
README.HOW_TO.txt has this example:
make -f $PWD/../Makefile.sdk TFA_DEVICETREE=stm32mp157c-ev1 TF_A_CONFIG=trusted ELF_DEBUG_ENABLE='1' all
But in fact TFA_DEVICETREE var-name should be TF_A_DEVICETREE. Is this correct?
Then, file format. We have .stm32, also .fip file format avaialble
I can compile both .stm32 tf-a and u-boot, but u-boot fail to start with following error:
NOTICE: CPU: STM32MP157DAB Rev.Z
NOTICE: Model: STMicroelectronics STM32MP157A-DK1 STM32CubeMX board
INFO: Reset reason (0x14):
INFO: Pad Reset from NRST
INFO: PMIC version = 0x21
INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe3000
INFO: FCONF: Reading firmware configuration information for: stm32mp_io
INFO: Using USB
INFO: Instance 2
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.4-r1.0(debug):
NOTICE: BL2: Built : 11:12:52, May 27 2021
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 533000Khz
WARNING: Couldn't find property st,phy-cal in dtb
INFO: Memory size = 0x20000000 (512 MB)
INFO: DFU USB START...
INFO: phase ID :0, Manifestation 0 at c00001d9
INFO: phase ID :3, Manifestation 3 at c80e1fa2
ERROR: FIP Header check failed for phase 3
ERROR: usb_core_ctl_error : Send an ERROR
INFO: handle USB : Suspend int
INFO: USB Suspend mode
Then I'm trying to compile tf-a with fip option, but it fails with following error:
make -f ../Makefile.sdk TF_A_CONFIG=trusted TF_A_DEVICETREE=stm32mp157a-stm32mp151-dk1-mx fip
fiptool-stm32mp config:
optee:
bl32 config value: optee
trusted:
bl32 config value: tfa
FIP_DEVICETREE: stm32mp157a-stm32mp151-dk1-mx
FIP_DEPLOYDIR_FIP : /home/screep/Distribution-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/FIP_artifacts//fip
FIP_DEPLOYDIR_TFA : /home/screep/Distribution-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-2.4.r1-r0/tf-a-sources/../deploy/bl32
FIP_DEPLOYDIR_FWCONF: /home/screep/Distribution-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-2.4.r1-r0/tf-a-sources/../deploy/fwconfig
FIP_DEPLOYDIR_OPTEE : /home/screep/Distribution-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/FIP_artifacts//optee
FIP_DEPLOYDIR_UBOOT : /home/screep/Distribution-Package/stm32mp1-openstlinux-5.10-dunfell-mp1-21-03-31/sources/arm-ostl-linux-gnueabi/FIP_artifacts//u-boot
Missing stm32mp157a-stm32mp151-dk1-mx-fw-config-optee.dtb file in folder: $FIP_DEPLOYDIR_FWCONF or '$FIP_DEPLOYDIR_ROOT/arm-trusted-firmware/fwconfig'
Why optee? I don;t need optee.
Can anybody help me with correct sequence compiling tf-a and u-boot starting from source download and finishing with success kernel load...
Thank you in advance
Looking forward for your reply
2021-06-02 05:30 AM
Hi,
I see you already play with OTP for eMMC (not checked in details).
The main issue I see is that you try secure boot (https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_secure_boot) and this fail (==> < @ 16398676 | [ERR ] - BOOTCORE_AuthWrongImageChecksum >)
Whereas your device (STM32MP157DAB does not support secure boot).
Secure boot is usually disabled by default during build process.
Please check some issue linked to signing tool (which add the header) during TF-A build.
As I'm not really used to secure boot, on my side, I will check what could be the mistake which lead to unwanted secure boot setting.
Regards
2021-06-02 05:40 AM
2021-06-02 05:47 AM
2021-06-02 05:53 AM
Hi,
yes, but usually not possible remove it in the header using signing tool on an already signed binary.
One hack could be to remove the header (256 first bytes) using an hex editor and manually use signing tool with "-of 0"
Need to have public/private key pair (e.g. using keygen), even if not used
e.g. on W10:
STM32MP_SigningTool_CLI.exe -bin <your_app.bin> -la 0x2ffc2400 -ep 0x2ffc2500 -t fsbl -o <your_app_signed.bin> -pubk <publicKey.pem> -prvk <privateKey.pem> -pwd <key_pwd> -iv 1 -of 0
Best would be to find where during the build process you enable the secure boot.
Regards,
2021-06-02 06:00 AM
2021-06-02 07:19 AM
2021-06-02 08:11 AM
Hi,
I have no clues, if you cannot get BootROM log, this could mean the BootROM has started TF-A code (and so debug was not enabled as it is in case of error).
PA13 at 9600bps could mean an unrecoverable error occurred (e.g. exception taken by bootROM, e.g. TF-A is started but fail to initialize its context, e.g. illegal instruction, abort, etc...)
I would suspect some HW issue which make NAND data read not reliable. Could you check power and signal integrity on your board ?
Is the error/behavior always the same after few reboot (power down/up) ?
Did you have another Flash (e.g. SD-Card, eMMC) on the system where you can test same TF-A ? You could even test it on another platform like DK2 or EV1 (it would likely crash, but maybe with some UART log if you are using same pins).
Regards.
2021-06-02 09:10 AM
2021-06-03 02:34 AM
Hi,
First try to understand why during TF-A generation, the checksum is badly generated (all should be automatic). Please double check your sequences Vs https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package#TF-A_-_regenerate_TF-A
Maybe for further analyzing, dump here the header (256 first bytes) as 32-bits hex words (or send me in a private message the zipped binary file).
Ultimately, when checksum is ok without hacked image and you still get 'bootfailed' message with debug disable (bo trace log), this issue may be linked to your Serial-NAND Flash which cannot be auto-detected by BootROM, and so need custom OTP WORD9 settings.
Seems the MT29F1G01ABAFDWB flash has a plane select (even if stated 'dummy' for 1Gb devices), which might need to setup WORD9 = 0x80204000 (please double check the value with your memory datasheet and https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#OTP_WORD_9_-_NAND_configuration).
As OTP burning is not recoverable and could 'brick' the device, only try this if you have a way to replace the device (e.g. socket).
Regards.
2021-06-03 09:03 AM