# Hailo Hummingboard bricked after SWUpdate **URL:** \ **Category:** Uncategorized\ **Tags:** yocto\ **Created:** [April 3, 2026, 7:55pm UTC](https://community.solid-run.com/t/hailo-hummingboard-bricked-after-swupdate/1123 "2026-04-03T19:55:45Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![santiagobarros](https://avatars.discourse-cdn.com/v4/letter/s/5e9695/32.png) [@santiagobarros](https://community.solid-run.com/u/santiagobarros)\ **Post date:** [April 3, 2026, 7:55pm UTC](https://community.solid-run.com/t/hailo-hummingboard-bricked-after-swupdate/1123/1 "2026-04-03T19:55:45Z")
**# 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. ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [April 7, 2026, 9:00am UTC](https://community.solid-run.com/t/hailo-hummingboard-bricked-after-swupdate/1123/2 "2026-04-07T09:00:10Z")
We are looking into this and will post back soon. ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [April 7, 2026, 10:18am UTC](https://community.solid-run.com/t/hailo-hummingboard-bricked-after-swupdate/1123/3 "2026-04-07T10:18:57Z")
> [@santiagobarros](#): > > customer\_certificate.bin This is a dummy certificate. If you are using secure builds then please open a proper support ticket at [support@solid-run.com](mailto:support@solid-run.com) and we will have Hailo generate you a valid certificate. Regarding the Hailo board tools. Unfortunately from version to version Hailo can introduce incompatibility between tools and the firmwares. The meta-layer should be building the specific version you need and the .whl needs to be installed into a venv and used.