STM32MP157C-DK2 (non-secure?) boot

[ReliableEmbeddedSystems]

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

Thanks,

Robert

[KnarfB]

There is no need to sign any code as long as you leave the device "open" (don't fuse OTP WORD0 bit 6). See https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview and https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot.

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

[ReliableEmbeddedSystems]

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/envsetup.sh
 
bitbake st-image-core

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

Help:
 ./create_sdcard_from_flashlayout.sh <FlashLayout file>

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

tree -L 1 flashlayout_st-image-core
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.

Thanks,

Robert

[ReliableEmbeddedSystems]

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

The Basic boot chain

ROM code

FSBL (U-Boot SPL)

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
./stm32mp1/bootloader/u-boot-spl.elf-stm32mp157c-ed1-basic
./stm32mp1/bootloader/u-boot-stm32mp157c-ev1-basic.elf
./stm32mp1/bootloader/u-boot-spl.elf-stm32mp157c-ev1-basic
./stm32mp1/bootloader/u-boot-stm32mp157c-ed1-basic.elf
./stm32mp1/bootloader/u-boot-stm32mp157c-dk2-basic.img
./stm32mp1/bootloader/u-boot-stm32mp157c-dk2-basic.elf
./stm32mp1/bootloader/u-boot-stm32mp157c-ev1-basic.img
./stm32mp1/bootloader/u-boot-spl.stm32-stm32mp157c-ed1-basic
./stm32mp1/bootloader/u-boot-spl.stm32-stm32mp157c-dk2-basic
./stm32mp1/bootloader/u-boot-stm32mp157c-ed1-basic.img
./stm32mp1/bootloader/u-boot-spl.elf-stm32mp157c-dk2-basic
./stm32mp1/bootloader/u-boot-spl.stm32-stm32mp157c-ev1-basic

But it's not used anywhere?

flashlayout_st-image-core$ grep -r basic .

[Olivier GALLIEN]

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.

Olivier

[ReliableEmbeddedSystems]

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.

[Olivier GALLIEN]

Hi @Community member​ ,

Ok this is complete different need.

For such please have a look here :

https://wiki.st.com/stm32mpu/wiki/How_to_boot_the_kernel_via_TFTP_from_U-Boot

Olivier

[ReliableEmbeddedSystems]

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:

https://gitlab.com/meta-layers/meta-u-boot-wic-bsp/-/blob/master/conf/machine/stm32mp157c-dk2.conf

wks file:

https://gitlab.com/meta-layers/meta-u-boot-wic-bsp/-/blob/master/wic/stm32mp157c-dk2-sd-card.wks.in

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