Showing results for 
Search instead for 
Did you mean: 

STM32MP157C-DK2 (non-secure?) boot

A quick grep through the latest and greatest release shows this:

$ grep -r STM32MP157C-DK2 . | grep machine
./meta-st/meta-st-stm32mp/conf/machine/stm32mp1-disco.conf:#@DESCRIPTION: [EXAMPLE] STM32MP157C-DK2 board ONLY with Trusted boot and SDcard support
./meta-st/meta-st-stm32mp/conf/machine/stm32mp1-disco.conf:M4_BOARDS = "STM32MP157C-DK2"
./meta-st/meta-st-stm32mp-addons/conf/machine/examples/stm32mp1-disco-mx.conf.sample:#@DESCRIPTION: [STM32CubeMX-EXAMPLE] STM32MP157C-DK2 board ONLY with Trusted boot and SDcard support
./meta-st/meta-st-stm32mp-addons/conf/machine/examples/stm32mp1-disco-mx.conf.sample:CUBEMX_PROJECT = "mx/STM32MP157C-DK2/my-demo/DeviceTree/my-demo"

So I am wondering if/how it's possible to have a kernel/device tree/rootfs which is not signed.

My ideal setup grabs (unsigned) kernel/device tree from tftp and passes to the kernel the kernel command line to boot over nfs (unsigned as well).

If this possible at all here with an unsigned kernel/device tree/rootfs?

If so, can you please elaborate a bit how?

My understanding is, that instead of U-Boot SPL TF-A is used, which loads a signed kernel and device tree (as a matter of fact there seem to be 3 device trees).

Now, I could imagine, that without burning the proper fuses, you could still load unsigned stuff (and the errors are ignored).




Accepted Solutions

To answer my own question:

Yes of course you can use non-secure boot since the hardware allows this unless you disable it by hardware fuses.

This is how it can be done software-wise:

machine config:

wks file:

In addition, I use upstream u-boot, kernel, and poky here.

View solution in original post

Principal III

There is no need to sign any code as long as you leave the device "open" (don't fuse OTP WORD0 bit 6). See and

Moreover, the Linux kernel is always loaded by U-Boot, both are outside the secure world and open source. So loading and running unsigned Linux kernels is normal and expected behaviour. (edited).

Thanks for the reply.

From the hardware point of view I kind of understand. But how do you do that with yocto?

I did something like this:

DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/
bitbake st-image-core

Now I need to use some magic script to create an SD card image

   ./ <FlashLayout file>

And these seems to be be my choice for the flash layouts:

tree -L 1 flashlayout_st-image-core
├── deleteall
├── extensible
├── optee
└── trusted

Do I need to build something differently for non secure boot?

What's the choice for the flash layout file?

It's not obvious to me what to choose.



I had a look here[1] and it says:

The Basic boot chain

ROM code


SSBL (U-Boot)

OS (Linux)

TrustZone (PSCI from U-Boot)

defconfig_file : stm32mp15_basic_defconfig


So it looks like it's a compile time option as well.

in the machine configuration you can see something like this:

# =========================================================================
# u-boot
# =========================================================================
EXTRA_IMAGEDEPENDS += "virtual/bootloader"
# Define default U-Boot config
UBOOT_CONFIG += "${@bb.utils.contains('BOOTSCHEME_LABELS', 'trusted', 'trusted', '', d)}"
UBOOT_CONFIG += "${@bb.utils.contains('BOOTSCHEME_LABELS', 'optee', 'optee', '', d)}"
# The 'basic' config is only available for stm32mp1 machines
UBOOT_CONFIG_append_stm32mp1common = " basic "
# Define u-boot defconfig and binary to use for each UBOOT_CONFIG
UBOOT_CONFIG[basic]   = "stm32mp15_basic_defconfig,,u-boot.img"
UBOOT_CONFIG[trusted] = "stm32mp15_trusted_defconfig,,u-boot.stm32"
UBOOT_CONFIG[optee]   = "stm32mp15_trusted_defconfig,,u-boot.stm32

Which, I guess, means that via BOOTSCHEME_LABELS you can pick trusted or optee, but basic is there by default.

And indeed some "basic" u-boot stuff is being built:

find | grep basic | grep stm32mp157c

But it's not used anywhere?

flashlayout_st-image-core$ grep -r basic .

For the stm32mp1-disco machine I could use wks/wic files, but, as already mentioned above, only with trusted or optee boot.


the ST ecosystems version 2 and higher are only supporting the trusted bootchain. That does not force you to sign the bootloaders as long as you don't fuse the OTB bit which closes the device.

So for your use case the trusted bootchain without closing the device should work fine. The only difference will be using TF-A instead of U-Boot SPL and both TF-A and U-Boot (as SSBL) will need the stm32 header prepending the binary.

ST Employee

Hi @Community member​ ,

U-boot SPL ( so call Basic boot ) is only there for usage in DDR Tuning TOOL.

It can not more be used to boot OpenSTL.

Trusted boot chain does not mean Secure boot.

You can flash "trusted" image built by Yocto as is in your DK2 without any issue.


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 would like to load kernel/device tree (unsigned) over tftp and mount the rootfs over nfs. My understanding is, that this will not work and I don't understand why. It does not seem to be a hardware limitation due to the fuse.

Hi @Community member​ ,

Ok this is complete different need.

For such please have a look here :


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.

OK something like that. I assume with a "trusted" image. Does this mean I will need to sign uImage and device tree?