RPi 4 not booting, want Secure Boot

Hi @TheYoctoJester

I have been evaluating mender OTA deployment, and trying to build an yocto image for raspberry pi 4, as then viewed this tutorial to build an image, Followed the steps, building it on Ubuntu 24.04 host, once my build got completed after several hours, the mender image and sdimg had huge size difference, please guide me as is something i missed out or doing anything wrong.

kas build ../kas/raspberrypi4-64.yml
2025-02-18 12:21:34 - INFO - kas 4.7 started
2025-02-18 12:21:34 - INFO - Using /home/user01/rpi_yocto_image/meta-mender-community as root for repository meta-mender-community
2025-02-18 12:21:34 - INFO - Repository poky already contains 7117d115eab7351ecf21388ec720a3bb5f4a9b30 as commit
2025-02-18 12:21:34 - INFO - Repository meta-openembedded already contains 3c293e14492f01e22a64004e2330fb620c27578a as commit
2025-02-18 12:21:34 - INFO - Repository meta-mender already contains 4c242af57ff0a00a4d44328896a5cd81c27c8c46 as commit
2025-02-18 12:21:34 - INFO - Repository meta-raspberrypi already contains 6df7e028a2b7b2d8cab0745dc0ed2eebc3742a17 as commit
2025-02-18 12:21:35 - INFO - Repository meta-lts-mixins already contains 66ceeebd047d7fdfc8668b300319a76da8ae257d as commit
2025-02-18 12:21:35 - INFO - Repository poky checked out to 7117d115eab7351ecf21388ec720a3bb5f4a9b30
2025-02-18 12:21:35 - INFO - Repository meta-openembedded checked out to 3c293e14492f01e22a64004e2330fb620c27578a
2025-02-18 12:21:35 - WARNING - Repo meta-mender is dirty - no checkout
2025-02-18 12:21:35 - INFO - Repository meta-raspberrypi checked out to 6df7e028a2b7b2d8cab0745dc0ed2eebc3742a17
2025-02-18 12:21:35 - INFO - Repository meta-lts-mixins checked out to 66ceeebd047d7fdfc8668b300319a76da8ae257d
2025-02-18 12:21:35 - INFO - /home/user01/rpi_yocto_image/meta-mender-community/rpi-build-image/build$ /home/user01/rpi_yocto_image/meta-mender-community/rpi-build-image/poky/bitbake/bin/bitbake -c build core-image-minimal
WARNING: Host distribution “ubuntu-24.04” has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Loading cache: 100% |##########################################################################################################################################################| Time: 0:00:03
Loaded 3344 entries from dependency cache.
Parsing recipes: 100% |########################################################################################################################################################| Time: 0:00:31
Parsing of 1968 .bb files complete (1941 cached, 27 parsed). 3344 targets, 126 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = “2.8.0”
BUILD_SYS = “x86_64-linux”
NATIVELSBSTRING = “universal”
TARGET_SYS = “aarch64-poky-linux”
MACHINE = “raspberrypi4-64”
DISTRO = “poky”
DISTRO_VERSION = “5.0.6”
TUNE_FEATURES = “aarch64 crc cortexa72”
TARGET_FPU = “”
meta-lts-mixins = “HEAD:66ceeebd047d7fdfc8668b300319a76da8ae257d”
meta-mender-core = “HEAD:4c242af57ff0a00a4d44328896a5cd81c27c8c46”
meta-mender-raspberrypi = “scarthgap:3ee37a7e9fe81d812acf485f74bed5c878014c12”
meta-oe = “HEAD:3c293e14492f01e22a64004e2330fb620c27578a”
meta-raspberrypi = “HEAD:6df7e028a2b7b2d8cab0745dc0ed2eebc3742a17”
meta
meta-poky
meta-yocto-bsp = “HEAD:7117d115eab7351ecf21388ec720a3bb5f4a9b30”

Sstate summary: Wanted 1 Local 0 Mirrors 0 Missed 1 Current 2301 (0% match, 99% complete)###################################################################### | ETA: 0:00:00
Removing 1 stale sstate objects for arch raspberrypi4_64: 100% |###############################################################################################################| Time: 0:00:00
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 4840 tasks of which 4834 didn’t need to be rerun and all succeeded.

Summary: There was 1 WARNING message.

This is the list of image been generated:
104857600 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.bootimg
394264576 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.ext3
394264576 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.ext4
4025 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.manifest
472402 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.spdx.tar.zst
50270208 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.tar
387298 Feb 14 19:34 core-image-minimal-raspberrypi4-64-20250214133511.testdata.json
5120 Feb 15 10:54 core-image-minimal-raspberrypi4-64-20250215052340.bootstrap-artifact
134217728 Feb 15 10:54 core-image-minimal-raspberrypi4-64-20250215052340.dataimg
36365312 Feb 15 10:54 core-image-minimal-raspberrypi4-64-20250215052340.mender
1056964608 Feb 15 10:54 core-image-minimal-raspberrypi4-64-20250215052340.sdimg

Hi @parag,

That sounds about correct.

The .sdimg file is the full device image for provisioning, so the one you will flash to the SD card. It is about 1GB in size by default, and includes boot and data partitions, as well as the two root filesystem partitions A and B.
The .mender file is an Artifact for deploying through the Mender Client, either using the management server or locally. It contains “only” one root filesystem, which will be written to the currently inactive root partition and then used after reboot. Its size being around 300MByte sounds about right too.

So to me the build seems to be good, are you experiencing any problems when running the resulting images on your device?

Greetz,
Josef

Thanks for your response @TheYoctoJester, currently flashed image is “2024-10-22-raspios-lite-raspberrypi4_bookworm_64bit-mender-convert-4.3.0.img” on raspberry pi 4 then deployed above generated image using deployment manager deployment fails and errors :

2025-02-20 06:55:50.162 +0000 UTC info: Running Mender client 5.0.0
2025-02-20 06:55:50.162 +0000 UTC info: Deployment with ID 4046823d-eb22-47f4-b302-f262f1afbd1b started.
2025-02-20 06:55:50.163 +0000 UTC info: Sending status update to server
2025-02-20 06:55:50.685 +0000 UTC info: Installing artifact…
2025-02-20 06:56:03.698 +0000 UTC info: Update Module output (stdout): ================ STATISTICS ================
2025-02-20 06:56:03.699 +0000 UTC info: Update Module output (stdout): Blocks written: 0
2025-02-20 06:56:03.699 +0000 UTC info: Update Module output (stdout): Blocks omitted: 376
2025-02-20 06:56:03.699 +0000 UTC info: Update Module output (stdout): Bytes written: 0
2025-02-20 06:56:03.699 +0000 UTC info: Update Module output (stdout): ============================================
2025-02-20 06:56:03.75 +0000 UTC info: Sending status update to server
2025-02-20 06:56:04.4 +0000 UTC info: Sending status update to server
2025-02-20 06:56:04.664 +0000 UTC info: Calling reboot command and waiting for system to restart.
2025-02-20 06:56:04.784 +0000 UTC info: Termination signal received, shutting down gracefully
2025-02-20 06:56:18.178 +0000 UTC info: Running Mender client 5.0.0
2025-02-20 06:56:18.189 +0000 UTC info: The update client daemon is now ready to handle incoming deployments
2025-02-20 06:56:18.554 +0000 UTC error: Process returned non-zero exit status: ArtifactVerifyReboot: Process exited with status 1
2025-02-20 06:56:19.246 +0000 UTC info: Calling reboot command and waiting for system to restart.
2025-02-20 06:56:19.384 +0000 UTC info: Termination signal received, shutting down gracefully
2025-02-20 06:56:33.099 +0000 UTC info: Running Mender client 5.0.0
2025-02-20 06:56:33.107 +0000 UTC info: The update client daemon is now ready to handle incoming deployments
2025-02-20 06:56:33.594 +0000 UTC info: Sending status update to server

then flashed above generated sdimg and turned device ON it boots logs upto Starting kernel and then device screen gets blackout not able to figure out issue.

Hi @parag,

I guess you are mixing up one too many things here. So I’ll leave out the deploying a Yocto build to a device currently running Raspberry Pi OS for now, there might be issues hidden.

For the .sdimg just getting “blackout”, my guess is that it actually boots nicely and opens a terminal on the UART. The core-image-minimal build is, as its name says, really minimal and will not start a graphical UI. I’d suggest to attach a UART adapter and checking the output there. Alternatively, build core-image-base or some other bigger image, like core-image-weston.

Greetz,
Josef

Thanks for suggestion @TheYoctoJester

  1. Gave try with uart adapter boot was successfull, but problem now with login credential incorrect used default raspberrypi4-64 login:pi and passwd: raspberry ,also as “root” without password still unsuccessfull, as suggested in this post here .

  2. As suggest generated the core-image-base still the device screen get blackout.

Hi @TheYoctoJester,

Want to understand the sdimg creation, the goal is execute the chain of trust on raspberry pi 4, on raspberry pi 4 the secure boot is enabled and want to run the signed and encrypted image on it with secure boot enable, so how an i go forward signing the and encrypting it, also just to give a try with the secure boot is enabled on raspberry pi, with the unsigned sdimg tried to boot pi4 the error logs i got were

Loading boot.img …
[sdcard] boot.img not found
Error 6 loading boot.img

it’s trying to find boot.img on sdcard, i did not find any boot.img getting generated under build, need help to understand and going forward with it.

Note: to enable secure boot followed this link secure boot

Hello everyone,

can anyone guide me with how to boot yocto sdimg on secure boot enabled raspberry pi 4, stuck with the above mentioned issue. Has anyone tried this before please share any reference if available.

Hi @parag,

I really cannot follow your question. The only thing that I can isolate is that you want to use a form of secured boot on the Raspberry Pi 4, and that you linked to some document.

Neither can I understand which steps you took, which settings you made, nor at which stage of the process.

So in general, the Yocto-based workflow is creating the .sdimg file using the wic tool, and will incorporate the standard firmware files as provided by Raspberry Pi. If you want to modify those, you need to do so either though adjusting the corresponding recipes or ROOTFS_POSTPROCESS_COMMAND.

If you provide details, maybe somebody can actually help.

Greetz,
Josef

Thanks for replying @TheYoctoJester, apologies for framing question incorrectly,

Basically goal is to create a signed and encrypted yocto image for raspberry pi 4
secondly enabling the secure boot on raspberry pi device, following steps to enable secure boot on raspberry pi 4.

This is code raspberry by usboot code GitHub - raspberrypi/usbboot: Raspberry Pi USB booting code, moved from tools repository.

On linux host machine installed prerequisites
sudo apt install git libusb-1.0-0-dev pkg-config build-essential

  1. git clone GitHub - raspberrypi/usbboot: Raspberry Pi USB booting code, moved from tools repository

  2. cd usbboot/

  3. make

  4. generate a private key:1. sudo apt install python3-pycryptodome
    2. cd $HOME
    3. openssl genrsa 2048 > private.pem
    4. openssl rsa -in private.pem -out public.pem -pubout -outform PEM

  5. secure boot the device This Readme gives the exact steps usbboot/secure-boot-recovery/README.md at master · raspberrypi/usbboot · GitHub,
    copied the public.pem to secure-boot-recovery, as its in evaluation so skipped the last part (Locking secure-boot mode) to permanent secure boot config as its irreversible.

  6. Now to verify the secure boot enable: 1. cd usbboot/secure-boot-example
    2. ./sign.sh /path/to/private.pem
    //for rpiboot mode connect configured rpi boot pin for raspberry pi 4
    3. ../rpiboot -d .

Now the device boots with in secure boot mode only if the boot.img is signed correctly private.pem it will proceed or fails while verification.

Just to check how the yocto based sdimg unsigned goes with enabled secure boot raspberry pi, so on boot up its giving error

Loading boot.img …
[sdcard] boot.img not found
Error 6 loading boot.img

Now my confusion is how this go with yocto based image as i could not found boot.img getting generated so which image to sign and how will it work in this scenario.

Hi @parag,

Ok, now I understand what you’re talking about. But in a nutshell, this is everything but trivial. You would need at least those things:

  • modified u-boot which is signed, has secure boot enabled and all console interactions disabled
  • accordingly signed kernel
  • accordingly signed root file system
  • a secure element to store all the key material (TPM?)
  • all shells locked down and disabled
    plus all the things that come with it.

So while I think it can be done, I’d guess this is a multi-day to multi-week effort for somebody who’s already experienced and familiar with all the technology involved. For somebody just starting out, I guess it’s a massive challenge about the dimension of at least a bachelor thesis.

If you “just want it” because you like secure boot, then you can treat it as a personal endeavor.
If you want it because you want to secure a product device fleet, then your best bet is to just hire somebody who sets this up.

Please note: secure boot isn’t just about a few configuration items here and there. Once you go to product with it, it will affect literally your whole software and provisioning process pipeline.

Greetz,
Josef