On 9/30/20 6:03 PM, Alex G. wrote:
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);
Hi! Me again! Do we have a (good) reason for this, or should I submit a
patch to remove this problematic code?
Alex
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
