From mboxrd@z Thu Jan  1 00:00:00 1970
From: Etienne Carriere <etienne.carriere@linaro.org>
Date: Fri, 30 Oct 2020 09:28:24 +0100
Subject: stm32mp: The purpose of "!tee_find_device()"
In-Reply-To: <bdf285bd-7540-b7cf-989f-0f24594c6940@gmail.com>
References: <fd5e7932-11b9-3a06-0169-ddf13e91ffee@gmail.com>
 <bdf285bd-7540-b7cf-989f-0f24594c6940@gmail.com>
Message-ID: <CAN5uoS-EoT7aUC1OEmeLv46SUzRFHe_nnr6T8Pvq+9VWc6RV8w@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thu, 29 Oct 2020 at 15:33, Alex G. <mr.nuke.me@gmail.com> wrote:
>
> 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?

The scheme is the generic U-Boot implementation do copy OP-TEE
related nodes when found in its FDT to the FDT provided to Linux.
(called from common/image-fdt.c)

However stm32mp1 can be used with or without OP-TEE installed. To
get a generic stm32mp1/U-Boot image that support both configurations
(with and w/o OP-TEE installed), U-Boot FDT and config for this plaform
do enable OP-TEE but, at u-boot runtime, if we find OP-TEE's not present,
we remove the FTD node so that Linux does get it and expect OP-TEE
is present.

> > Do you have any ideas how to make it not crash (short of
> > commenting out the problem lines) ?

The crash seems due to that there is no secure monitor by the time
you have this sequence called. Secure monitor is the code that
handles the SMC. If none installed, SMCs ends nowhere and
likely badly crash the systel. If OP-TEE is not running but there
is a secure monitor loaded, it should not crash.

It seems to me that U-Boot does set up a secure monitor for
PSCI minimal support, so the U-Boot PSCI stack should
nicely handle the SMC to report that there is no OP-TEE installed.
Enabling CONFIG_ARMV7_PSCI should fix the issue I think.

Regards,
Etienne

> >
> > 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