[PATCH v2 1/2] ARM: bootm: Add support for starting Linux through OpTee-OS on ARMv7a

[Tom Rini]

On Tue, Sep 09, 2025 at 05:02:27AM +0200, Marek Vasut wrote:
> On 6/30/25 7:18 AM, Heinrich Schuchardt wrote:
> > Am 30. Juni 2025 02:08:05 MESZ schrieb Marek Vasut <marek.vasut at mailbox.org>:
> > > Add support for jumping to Linux kernel through OpTee-OS on ARMv7a.
> > > This is only supported if U-Boot runs in PL1 secure. This change adds
> > > two components, one is fitImage OpTee-OS loadable handler, which makes
> > > a note of OpTee-OS being loaded and stores the load address for later
> > > jump to it. The second part is the actual jump to Linux through OpTee-OS.
> > > The jump through OpTee-OS requires set up of multiple CPU registers, r1
> > > and r2 are passed through, r0 and r3 have to be set to 0, lr is set to
> > > Linux kernel entry point. This setup is done by new assembler function
> > > boot_jump_linux_via_optee().
> > > 
> > > The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC
> > > configuration write, this cannot be moved easily, hence the ifdef.
> > 
> > Hello Marek,
> > 
> > Could you, please, add a documentation change to the series. This would allow reviewers to test your proposal.
> 
> The fitImage TEE bundling is already documented in the fit spec:
> 
> https://fitspec.osfw.foundation/
> 
> This here is an application:
> 
> "
> /dts-v1/;
> / {
> 	...
> 	images {
> 		...
> 		tee-1 {
> 			description = "OP-TEE";
> 			data = /incbin/ ("/optee_os/out/arm-plat-stm32mp1/core/tee-raw.bin") ;
> 			type = "tee";
> 			arch = "arm";
> 			compression = "none";
> 			os = "tee";
> 			load = <0xde000000>;
> 			entry = <0xde000000>;
> 			...
> 		};
> 	};
> 
> 	configurations {
> 		default = "conf-1";
> 		conf-1 {
> 			...
> 			loadables = "tee-1";
> 			...
> 		};
> 	};
> };
> "
> 
> "
> $ mkimage -E -f fit-image.its fitImage
> "
> 
> I can add that part to STM32 board docs ?
> 
> > Furthermore, please, provide tests on QEMU.
> The test would require booting Linux, how do you propose we test that in CI

For this part, it's something we've talked about off-and-on, and part of
the answer is caching in the container some set of very small but still
useful for boot testing stock images. That said, it's still a lot of
effort and a good question as to what is really being tested in each
case there (and in turn how worthwhile it is).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250909/669a2239/attachment.sig>