cancel
Showing results for 
Search instead for 
Did you mean: 

STM32MP15 ECO 5.0.0 optee build fails with errors and warnings

debugging
Lead

For a custom board configured in CubeMX   using

STM32MP157AAA3 , UART4, 512MB DDR3L, (4Gx16)  external crystal (HSE, LSE), and discrete power regulator, no PMIC,  device trees were generated with CubeMX

when compiling optree errors and warnings occur.

[1] Wrong CFG_DRAM_SIZE 1024MBytes, in device-tree: 512MBytes.  The TF-A and U-boot .dts files contain the same setting for memory and do not fail.

memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x20000000>;

When setting memory to 0x40000000 instead of 0x20000000 it passes. Why is this ?

[2] Warnings in files (not changed, default provided by ECO system). Audio/I2S is not even configured in CubeMX.

core/arch/arm/dts/stm32mp157.dtsi:20.21-35.5: Warning (avoid_unnecessary_addr_size): /soc/dsi@5a000000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" property
core/arch/arm/dts/stm32mp151.dtsi:416.22-428.5: Warning (unique_unit_address): /soc/spi@4000b000: duplicate unit-address (also used in node /soc/audio-controller@4000b000)
core/arch/arm/dts/stm32mp151.dtsi:441.22-453.5: Warning (unique_unit_address): /soc/spi@4000c000: duplicate unit-address (also used in node /soc/audio-controller@4000c000)
core/arch/arm/dts/stm32mp151.dtsi:739.22-751.5: Warning (unique_unit_address): /soc/spi@44004000: duplicate unit-address (also used in node /soc/audio-controller@44004000)

[3] The workshop requires to add nodes in the user section for pinctrl,  (uart4) and in user section for addons (uart4,vddcore, cpu0 , cpu1, power regulators) but all these additions cause an error that the device tree cannot be parsed.

Device tree attached.

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

I'm in the same situation (trying to get a custom board working with v5.0.0) so encountering the same issues.

I don't think this problem is related to CubeMX but rather to the way optee is compiled using the plat-stm32mp1 files.

This file sets the CFG_DRAM_SIZE variable based on the dts filename (i think, got no knowledge on .mk files) Given the custom boards don't use a known filename this sets it to 1024Mbytes.

 

ifneq ($(filter $(CFG_EMBED_DTB_SOURCE_FILE),$(flavorlist-512M)),)
CFG_DRAM_SIZE    ?= 0x20000000
endif

CFG_DRAM_BASE    ?= 0xc0000000
CFG_DRAM_SIZE    ?= 0x40000000

 

Unsure how that actually works, maybe ?= means it only sets it if not set yet? (otherwise the 'ifneg' would never work)

If I add my dts to the list of no cryp 512Mbytes, the error no longer shows. Haven't tried to boot with it though (not that far yet).

To replicate, first add this line at the end of the other flavors:

 

 flavor_dts_file-custom = <name of the dts> // replace the < > part with the filename

 

Then alter the section for no cryp 512

 

flavorlist-no_cryp-512M = $(flavor_dts_file-157A_DK1) \
                          $(flavor_dts_file-157D_DK1) \
                          $(flavor_dts_file-custom)

 

Regarding [3]

  • In the attached dts file the line 96 is } but should be }; (missing semicolon, somehow i made the same mistake with copy paste)
  • In that Lab-bringup on slide 28 it states that you need to add vddcore/vdd to the addon section but doesn't specify the node (code starts with { instead of a name). Thought it was odd because the subs don't start with $, so added them to root instead. Compiles fine, not sure if actually correct...

 

	/* USER CODE BEGIN root */
	aliases {
		serial0 = &uart4;
	};
	chosen {
		stdout-path = "serial0:115200n8";
	};
	vddcore: vddcore {
		compatible = "regulator-fixed";
		regulator-name = "vddcore";
		regulator-min-microvolt = <1350000>;
		regulator-max-microvolt = <1350000>;
		regulator-always-on;
	};
	vdd: vdd {
		compatible = "regulator-fixed";
		regulator-name = "vdd";
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
		regulator-always-on;
	};
	/* USER CODE END root */

 

To add another error to the list, compiling of optee ends with this error.

Missing stm32mp151a-board-mx-fw-config-optee.dtb file in folder: $FIP_DEPLOYDIR_FWCONF or '$FIP_DEPLOYDIR_ROOT/arm-trusted-firmware/fwconfig'

CubeMX didn't generate a fw-config-optee.dts so no idea what it should be.

View solution in original post

7 REPLIES 7
Olivier GALLIEN
ST Employee

Hi @debugging ,

Which workshop are you referring to? I'm afraid you found some obsolete material somewhere on the web :pensive_face: 

We need to do clean-up. 

Before addressing the DDR size question, I would like to check the rest of your DTS and for that I would need to understand how you manage your transition from previous ecosystem ( which one? can you share a working boot log from which we can get usefull information) to the new DV5.0

Were you aware and did you follow what is advice in : 

FAQ : STM32MP1 – How to migrate STM32CubeMx project from an old ecosystem to a new one?

It's a kind of 3-way merge using : 

 - new custom DTS with latest CubeMX version

- DTS of ST-board close to your design (EV1 in your case) generated with same CubeMX version

- legacy working custom DTS on old ecosystem 

This for all BSP component at first. 

Then 

FAQ: STM32MP1 How to bring up STM32MP1

could also be worth to browse to avoid classic pitfall. 

Please let know if above material is usefull and maybe help you to secure some part of your development.

Else please provide complete set of BSP DTS + build or execution log you may have. 

I will come later around Discrete power specificity and OPTEE adaptation to DDR size 

Olivier 

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
debugging
Lead

Just started from scratch on this  working board. The device tree error were fixed with some changes except for this memory error and 0x4000000 does not seem the correct value. .Did all the steps from the configuration in CubeMX to  the DT. Worked thought all the links mentioned, and BTW many links those articles are still broken. The workshop was mentioned in the link provided: "For additional guidance, there is a lab Lab-BringUpFromPartNumber to get used with this device tree creation process"  Assume it shouldn't be quite old at is is based on V5.

The  key question is here why CubeMX generated the files, but Optee value needs to be changed compared to TF-A and u-boot for the compilation to pass.

Starting log form working boot.

U-Boot SPL 2018.11-stm32mp-r2.2
Model: Board
RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.44
Trying to boot from MMC2
prop pinctrl-0 index 0 invalid phandle

U-Boot 2018.11-stm32mp-r2.2 (May 01 2020 - 07:03:50 +0000)

CPU: STM32MP157AAA Rev.B
Model: Board
Board: stm32mp1 in basic mode
Watchdog enabled
DRAM: 512 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz

.... To Linux prompt

Linux 4.19.43 #1 SMP PREEMPT Sat May 23 03:35:22 UTC 2020 armv7l armv7l armv7l GNU/Linux

Olivier GALLIEN
ST Employee

Hi @debugging ,

Just to confirm my understanding.

 

trace of success boot you provide are the legacy one based on so call DV1.x ( Uboot SPL ! ) the first ever on STM32MP15.

While you are trying DV5 with CubeDT generated by CubeMX you are facing OPTEE compilation error/inconsistency around DDR size parameter right ? 

Did you manage to specify DDR density in CubeMX ? 

OlivierGALLIEN_0-1694531388137.png

Please have a look to this new release wiki page around DDR size adaptation (reduction in this case) in BSP and let me know if it can bring some light for OPTEE :

How to configure a 256MB DDR mapping from STM32 MPU Distribution Package - stm32mpu

Else, please share your last version of DTS. 

Thanks

Olivier 

 

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

I'm in the same situation (trying to get a custom board working with v5.0.0) so encountering the same issues.

I don't think this problem is related to CubeMX but rather to the way optee is compiled using the plat-stm32mp1 files.

This file sets the CFG_DRAM_SIZE variable based on the dts filename (i think, got no knowledge on .mk files) Given the custom boards don't use a known filename this sets it to 1024Mbytes.

 

ifneq ($(filter $(CFG_EMBED_DTB_SOURCE_FILE),$(flavorlist-512M)),)
CFG_DRAM_SIZE    ?= 0x20000000
endif

CFG_DRAM_BASE    ?= 0xc0000000
CFG_DRAM_SIZE    ?= 0x40000000

 

Unsure how that actually works, maybe ?= means it only sets it if not set yet? (otherwise the 'ifneg' would never work)

If I add my dts to the list of no cryp 512Mbytes, the error no longer shows. Haven't tried to boot with it though (not that far yet).

To replicate, first add this line at the end of the other flavors:

 

 flavor_dts_file-custom = <name of the dts> // replace the < > part with the filename

 

Then alter the section for no cryp 512

 

flavorlist-no_cryp-512M = $(flavor_dts_file-157A_DK1) \
                          $(flavor_dts_file-157D_DK1) \
                          $(flavor_dts_file-custom)

 

Regarding [3]

  • In the attached dts file the line 96 is } but should be }; (missing semicolon, somehow i made the same mistake with copy paste)
  • In that Lab-bringup on slide 28 it states that you need to add vddcore/vdd to the addon section but doesn't specify the node (code starts with { instead of a name). Thought it was odd because the subs don't start with $, so added them to root instead. Compiles fine, not sure if actually correct...

 

	/* USER CODE BEGIN root */
	aliases {
		serial0 = &uart4;
	};
	chosen {
		stdout-path = "serial0:115200n8";
	};
	vddcore: vddcore {
		compatible = "regulator-fixed";
		regulator-name = "vddcore";
		regulator-min-microvolt = <1350000>;
		regulator-max-microvolt = <1350000>;
		regulator-always-on;
	};
	vdd: vdd {
		compatible = "regulator-fixed";
		regulator-name = "vdd";
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
		regulator-always-on;
	};
	/* USER CODE END root */

 

To add another error to the list, compiling of optee ends with this error.

Missing stm32mp151a-board-mx-fw-config-optee.dtb file in folder: $FIP_DEPLOYDIR_FWCONF or '$FIP_DEPLOYDIR_ROOT/arm-trusted-firmware/fwconfig'

CubeMX didn't generate a fw-config-optee.dts so no idea what it should be.

debugging
Lead
 
The dump from u-boot  provided was for a WORKING boot on the SAME board, that indeed used ECO 1.0, to show the values of the memory etc . that was only for reference and NOT the image generated by ECO 5.0.
 
That was the wiki update and the link to the .mk file that was crucially missing for OPTEE.
BTW the WIKI states
INFO:    BL2: Loading image id 21
I think those are old and not correct for ECO 5.0 In my case using  ECO 5.0 TF-A loads ID #1 , then #4 and then #8.
 
For OP-TEE, In my case I had to change to:
CFG_DRAM_SIZE ?= 0x20000000
in the .mk file
and not change the DT. (Keep it as generated by CubeMX):
memory@c0000000 {
device_type = "memory";
reg = <0xc0000000 0x20000000>;
}
 
The question is, why was the OPTEE file not correctly configured for the DRAM memory
size as set in CubeMX ?
 
If that is a bug, it may  have a special WIKI page for such bug.
In contrast, TF-A sets the correct value:
#define DDR_SIZE 0x20000000 /* 512MB */
 
Here are the DDR settings, confirmed by the manufacturer of the board.:
debugging_0-1694614000677.png
Please advise what the reserved area and size should be in the OP-TEE DT for 512MB  on STM32MP157 ? 0xdd or 0xcd ?
 
  optee_framebuffer: optee-framebuffer@cd000000 {
                       /* Secure framebuffer memory */
                       reg = <0xcd000000 0x1000000>;
                       st,protreg = <TZC_REGION_S_RDWR 0>;
               };
debugging
Lead

 

@michiel.tjampens   if you are using the .sdk  makefiles, then would advise not, I ran also in these issues of not finding the files. It drove me mad for over two weeks. The way to do it is to build the TF-A, OP-TEE , U-boot not using the sdk makefiles. The sdk development kit makefiles seemed to have been designed for ST's own boards to make it easier to build but when using them for custom boards its not working. The wiki pages to list those "make: commands as an alternative but don't point out to use them for custom boards.

Follow this : https://wiki.st.com/stm32mpu/wiki/How_to_configure_OP-TEE

Hope this helps others to save their hair. :)   Also start fresh from CubemMX for the DT generation for the hardware of the specific board,  memory, clock, XTAL, GPIO and take a look at the workshop for clock configuration in MX.  I am currently still stuck at TF-A/BL2 loading BL32, but that is another topic.

debugging
Lead

for the  OP-TEE memory size error, Michiel's anwser the the right one. it is strange why not more people bump into these issues and post on the community. Perhaps most are ST's partners and get all such information from ST support ?

the cause was that the conf.mk file was set by default by ECO system to 1GB. The OP-TEE build does create a  conf file at compile time, but does not use the correct board values. it is very important to see the correct settings in conf.mk, This should be part of the wiki HOW TO CONFIGURE OP-TEE. There isn't much information how to configure conf.mk correctly.

CFG_DRAM_SIZE    ?= 0x200000