stm32mp: The purpose of "!tee_find_device()"

Alex G. mr.nuke.me at gmail.com
Thu Oct 1 01:03:38 CEST 2020


Hi

I'm trying to wrap my head around the purpose of the following lines in 
ft_system_setup():

	if (!CONFIG_IS_ENABLED(OPTEE) ||
	    !tee_find_device(NULL, NULL, NULL, NULL))
		stm32_fdt_disable_optee(blob);

My interpretation is "if optee is not running, delete the FDT node".
The problem is that tee_find_device() invokes device_probe(). This in 
turn does an SMC call. This call results in an abort and reboot if optee 
is not running in the first place.

So I don't think that tee_find_device() can be used as a check for "Is 
optee running?". Exhibit B: Outside of mach-stm32mp, tee_find_device() 
is used to obtain of a _working_ TEE node, not to ask if "is optee 
running?".


My problem is that trying to start linux with CONFIG_OPTEE=y will cause 
the bootm command to crash (log in appendix A):

	load mmc 0:7 $loadaddr boot/uImage
	load mmc 0:7 $fdt_addr_r boot/stm32mp157c-dk2.dtb
	load mmc 0:7 0xc8000000 boot/utee
	setenv bootm_boot_mode sec
	bootm 0xc8000000 - $fdt_addr_r

What is the intent of calling tee_find_device() in an FDT fixup 
function? Do you have any ideas how to make it not crash (short of 
commenting out the problem lines) ?

Alex


Appendix A: u-boot log after bootm command

## Booting kernel from Legacy Image at c8000000 ...
    Image Name:
    Created:      2020-09-28  20:58:56 UTC
    Image Type:   ARM Trusted Execution Environment Kernel Image 
(uncompressed)
    Data Size:    349276 Bytes = 341.1 KiB
    Load Address: fdffffe4
    Entry Point:  fe000000
    Verifying Checksum ... OK
    Loading Kernel Image
## Flattened Device Tree blob at c4000000
    Booting using the fdt blob at 0xc4000000
    Loading Device Tree to cffef000, end cffff5e2 ... OK
<BOARD RESETS WITHOUT USER INPUT>
U-Boot SPL 2020.10-rc4 (Sep 20 2020 - 23:46:47 +0000)
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board


More information about the U-Boot mailing list