# Custom Yocto Build Breaks Secure Boot — How to Deploy Custom Firmware?
**Board:** SolidRun HummingBoard IIoT with Hailo-15 SOM (Rev 1.1)
**BSP:** meta-solidrun-arm-hailo @ d8ef539 (kirkstone branch)
**SCU Firmware:** v1.7.0 [1018a069], SCMI v0.47.2
## Summary
We built a custom Yocto image from the open-source BSP (`meta-solidrun-arm-hailo` kirkstone branch, commit `d8ef539`) using `bitbake core-image-minimal` and `bitbake hailo-update-image`. We flashed the resulting `.swu` via the U-Boot SWUpdate menu option. SWUpdate completed successfully (all three phases: `init-partitions-single`, `init-scu-bl`, `copy-a`), but the board failed to boot afterward.
We need guidance on how to properly deploy custom Yocto builds to the HummingBoard IIoT without breaking the secure boot chain.
## What Happened
### 1. SWUpdate succeeded but board won’t boot
After SWUpdate completed and the board rebooted, the SCU rejects the certificate:
```
[ 0.035829] SCU-FW v1.7.0 [1018a069] (based on SCP-Firmware v2.14.0 [98f81610], Hailo SCMI v0.47.2)
[ 0.038156] [FWK] Module initialization complete!
[ 0.150112] [CC] loading customer chain failed: The customer certificate that was loaded is for development (internal code 0)
[ 0.150826] [FWK] Process event ([EVT 45:1]: [MOD 45] → [MOD 45]) (-18)
[ 0.379275] [UART] scu config loading timeout reached - flushed uart buffer
```
The board boot-loops endlessly. The SCU never reaches SPL or U-Boot. Y-modem mode (DIP pin 3+6) also fails because the SCU dies before starting the AP cores.
### 2. Root cause
The custom Yocto build (`bitbake hailo-update-image`) generates a **development `customer_certificate.bin`** that the production SCU firmware rejects. The `.swu` package includes this certificate and writes it to QSPI, replacing the production certificate that was there originally.
### 3. We cannot use the official recovery tool
The `uart_boot_fw_loader` from both `hailo15_board_tools` v1.6.0 and v1.7.0 fails with version incompatibility when trying to recover via UART boot mode (DIP pin 1+6):
```
$ uart_boot_fw_loader --serial-device-name /dev/cu.usbserial-DQ00G3A2 --firmware hailo15_uart_recovery_fw.bin
UART recovery firmware version which is now loaded: 1.4
Error: Incompatibility between the loaded UART recovery firmware version (4261855232.2558950939) and the script version (1.4)
```
The garbled version numbers suggest a protocol mismatch between the tool and the SCU.
### 4. How we recovered
We wrote a custom Python script that:
- Implements the UART boot protocol directly at 57600 baud (with proper 2-second delay and ACK handling)
- Bypasses the `uart_boot_fw_loader` version check
- Talks directly to the recovery agent at 115200 baud using raw opcodes
- Writes all 7 QSPI files (SCU BL, SCU BL config, SCU FW, U-Boot DTB, customer certificate, U-Boot env, U-Boot SPL) from the prebuilt `2025-12-02_d8ef539` release
- Then we used Y-modem + flashing ramdisk + bmaptool to restore the eMMC
The board is now recovered and running the stock prebuilt image.
### 5. Even without SWUpdate, custom builds won’t boot
We also discovered that even if we had used the “flashing ramdisk + bmaptool” method instead of SWUpdate, the custom-built fitImage would have been rejected by the SPL:
```
## Checking hash(es) for config config_1 … sha256,rsa3072:customer- error!
Verification failed for ’
```
The fitImage is signed with the development key during `bitbake`, but the QSPI has the production certificate. They don’t match, so SPL rejects the kernel.
## Questions
1. **How should customers deploy custom Yocto builds to the HummingBoard IIoT?** The open-source BSP generates a development signing key that is incompatible with the production SCU firmware. Is there a way to build with the production signing key, or to disable secure boot verification?
2. **Can the SWUpdate `sw-description` be modified to skip writing `customer_certificate.bin` to QSPI?** This would allow updating the rootfs, kernel, and bootloader without breaking the certificate chain. If so, what’s the recommended approach?
3. **Is there a newer version of `hailo15_board_tools`** that works with SCU v1.7.0? Both v1.6.0 and v1.7.0 fail with version incompatibility errors on our boards.
4. **What is the recommended development workflow** for iterating on kernel changes, device tree modifications, and custom recipes on this platform?
## Environment
```
BSP: meta-solidrun-arm-hailo @ d8ef539 (kirkstone branch)
meta-hailo-soc @ dfbb55461fe16cae58a27105d69026a9bd57181e
meta-hailo @ 676702aecba552c2f73b852810a6d7a9a70884d0
Build commands: bitbake core-image-minimal && bitbake hailo-update-image
Build host: Ubuntu 22.04, x86_64, 12 cores, 8GB RAM
Board: HummingBoard IIoT, Hailo-15 SOM Rev 1.1 (TLV: V11)
SOM: 4GB LPDDR4, 64GB eMMC
SCU: v1.7.0 [1018a069]
Prebuilt release: 2025-12-02_d8ef539 (working)
Custom build: same BSP commit d8ef539 (breaks secure boot)
```
Thank you for any guidance.