OSD32MP15x custom device tree
Forums › Devices › OSD32MP15x › OSD32MP15x custom device tree
- This topic has 10 replies, 3 voices, and was last updated 4 years, 3 months ago by
Neeraj Dantu.
- AuthorPosts
- July 21, 2020 at 6:25 am #10376
Hello I try to create my own device tree files based on this tutorial:
https://octavosystems.com/octavosystems.com/wp-content/uploads/2019/06/STM32MP1-CubeMX-Tutorial-for-OSD32MP15x.pdfAfter downloading the source files and copying the STM32CubeMX dts/dtsi files I tried this command:
“make -f $PWD/../Makefile.sdk all DEVICE_TREE=stm32mp157c-osd32mp157c-512m-baa_minimalconfig-mx”
with and without the ” around the name.But the compilation fails with following:
Device Tree Source is not correctly specified.
Please define ‘CONFIG_DEFAULT_DEVICE_TREE’
or build with ‘DEVICE_TREE=’ argumentmake[3]: *** [/home/akira/Downloads/stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24/sources/arm-ostl-linux-gnueabi/u-boot-stm32mp-2020.01-r0/u-boot-stm32mp-2020.01/dts/Makefile:28: arch/arm/dts/stm32mp157c-osd32mp157c-512m-baa_minimalconfig-mx.dtb] Error 1
make[2]: *** [/home/akira/Downloads/stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24/sources/arm-ostl-linux-gnueabi/u-boot-stm32mp-2020.01-r0/u-boot-stm32mp-2020.01/Makefile:1087: dts/dt.dtb] Error 2
make[2]: Leaving directory ‘/home/akira/Downloads/stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24/sources/arm-ostl-linux-gnueabi/u-boot-stm32mp-2020.01-r0/build-basic’
make[1]: *** [Makefile:167: sub-make] Error 2
make[1]: Leaving directory ‘/home/akira/Downloads/stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24/sources/arm-ostl-linux-gnueabi/u-boot-stm32mp-2020.01-r0/u-boot-stm32mp-2020.01’
cp: cannot stat ‘/home/akira/Downloads/stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24/sources/arm-ostl-linux-gnueabi/u-boot-stm32mp-2020.01-r0/u-boot-stm32mp-2020.01/../build-basic/u-boot.img’: No such file or directoryCompiling the stm32mp157c-dk2 files is working so I am pretty sure it is a configuration and no tool problem.
What am I missing? - July 21, 2020 at 11:41 am #10379
Hey Tobias,
The tutorial describes the procedure for OpenST Linux v1.1/1.2. The application note needs to be updated to use v2.0. Until then, we suggest you use v1.2 for your development if you want to follow the application note. You can also make the developer package compile your device tree a different way:
1. Add the target file dtb name to <u-boot directory>/arch/arm/dts/Makefile
2. Add target board name to DEVICE_TREE variable in $PWD/../Makefile.sdk
You should not have to add the target board device tree name to the make command if you do the above.
Best,
Neeraj
- July 23, 2020 at 7:57 am #10383
Thank you so far this part of starting a customized linux and fsbl is working now.
Next part I am troubling with is getting the tf-a compiled with current SDK.
After adding the dts/dtsi files from CubeMX to the TFA-SOURCE/fdts dir and appending
“stm32mp157c-osd32mp157c-512m-baa_minimalconfig-mx” to the Makefile.sdk TFA_DEVICETREE variable I get:
fdts/stm32mp157c-osd32mp157c-512m-baa_minimalconfig-mx.dts:21:10: fatal error: dt-bindings/power/stm32mp1-power.h: No such file or directory
21 | #include <dt-bindings/power/stm32mp1-power.h>There is a debug-tf-a-stm32mp157c-osd32mp157c-512m-baa_minimalconfig-mx-trusted.stm32 file in ../build-trusted/ folder but I miss the release file and I am not sure neither the error “can be ignored” nor how to fix it.
Is there any solution not downgrading the SDK and sources?
- July 31, 2020 at 10:22 am #10464
Tobias,
Please check on your version of the CubeMX software you are using. CubeMX version 5.6 is not compatible with the developer package 2.0. Version 6.0 works with the new developer package.
Best,
Neeraj
- August 3, 2020 at 10:04 am #10468
The tutorial describes the procedure for OpenST Linux v1.1/1.2. The application note needs to be updated to use v2.0. Until then, we suggest you use v1.2 for your development if you want to follow the application note.
In section 5.1 of the ST Developer Wiki Page it has a link to en.SDK-x86_64-stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24.tar.xz. Is this the correct SDK for 1.2? Because 20-06-24 is associated with 2.0 and 20-02-19 with 1.2, but I can’t find a link for the SDK at version 1.2.
- August 3, 2020 at 10:29 am #10469
I think I found it under the Yocto_SDK: https://my.st.com/content/my_st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32-mpu-openstlinux-distribution/stm32mp1dev.license=1596456640621.product=Yocto_SDK.version=1.2.0.html – is that the correct version?
- August 3, 2020 at 10:45 am #10470
On the ST Download area there is an ComboBox where you can select the version if you don’t want the current version.
- August 3, 2020 at 11:05 am #10471
I upgraded my CubeMX to version 6 today.
Now I can compile everything and it is working with the exception of “das U-Boot”.
If I write my new stm32 file to partition 3 I got the u-boot output:CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1) !!!why ev1 I double checked I selected dk2 in CubeMx?
Board: MB1272 Var2 Rec.C-01
DRAM: ERROR: Illegal access to 0xfdafffb0 in:
ERROR: Non-Secure
ERROR: Privilege
ERROR: Read
PANIC at PC: 0x2ffefeb5Exception mode=0x00000016 at: 0xfffffffc
I do not know why I am getting an error corresponding to ev1 board and not dk2 board which I selected as a basis in CubeMX.
Also I just selected the default values and just exported the dts and dtsi files.
Are there any ideas what I did wrong and more important how to fix this? - August 4, 2020 at 3:54 pm #10485
Tobias,
Please check the binary file you are flashing for u-boot. From the boot log, it looks like you are using the EV1 binary file and not the board specific one you have created. The U-boot SDK does build multiple binaries for multiple boards based on the configuration in Makefile.sdk.
Please also check the board name printed on the output of the FSBL(First stage bootloader) to be the DK-2 and not EV-1. If it is not what you expect, you may not have flashed the right FSBL as well.
Also make sure you have 2 partitions (ssbl1 and ssbl2) programmed with the u-boot you generated.
Best,
Neeraj
- August 5, 2020 at 3:47 am #10489
Tobias, the name of my dts file from CubeMX is stm32mp157c-osd32mp1-mx.dts. I use that for the TFA_DEVICETREE in the make command:
12~/stm32mp1-openstlinux-5.4-dunfell-mp1-20-06-24/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-2.2.r1-r0/tf-a-stm32mp-2.2.r1/arm-trusted-firmware$make -f $PWD/../../Makefile.sdk TFA_DEVICETREE=<strong>stm32mp157c-osd32mp1-mx</strong> TF_A_CONFIG=trusted ELF_DEBUG_ENABLE='1' allUnder /tf-a-stm32mp-2.2.r1-r0/tf-a-stm32mp-2.2.r1/build/trusted I then get tf-a-stm32mp157c-osd32mp1-mx-trusted.stm32. And use that in the tsv file to flash:
12#Opt Id Name Type IP Offset Binary- 0x01 fsbl1-boot Binary none 0x0 tf-a-stm32mp157c-osd32mp1-mx-trusted.stm32I am still getting an error when flashing though:
Error: Start operation failed at partition 0x01
Error: TSV flashing service failed
- August 5, 2020 at 6:36 pm #10495
Coder,
A couple of things you can try from this thread: https://community.st.com/s/question/0D50X0000B6PIH1/stm32mp157cdk2-flash-didnt-work
1. Use the Windows GUI programmer
2. Add timeout to the programmer command
You could also use ‘dd’ to flash individual partitions on to the SD card.
Can you verify the USB connection between the computer and the target board?
Best,
Neeraj
- AuthorPosts
- You must be logged in to reply to this topic.