Description
I’m building an OTA model-update demo on the Arduino UNO Q and would appreciate a sanity check on the architecture from people who know the Golioth OTA system well.
The board is unusual: it has two processors. A Qualcomm SoC running Debian Linux (owns the Wi-Fi, storage, and USB) sits alongside an STM32U585 running Zephyr, where my application and an ML model actually run. The two talk over an internal UART bridge. The catch is that the STM32 has no direct internet connection of its own, and on this board it can’t self-flash the normal way — programming the STM32 happens from the Linux side over an on-board OpenOCD/SWD path.
I have the local loop working already: the STM32 runs a Zephyr app with an on-device model, no cloud involved. The next step is delivering new versions over the air via Golioth.
Because the STM32 can’t reach the internet directly or self-update via MCUboot in the usual way, I see two possible architectures:
Path A: Linux-orchestrated (gateway): run the Golioth client on the Debian side, have it pull the update over Wi-Fi, then flash the STM32 from Linux using the OpenOCD path that already works. This reuses what I have, but it’s not the standard Zephyr+MCUboot Golioth flow.
Path B: MCU-direct: run the Golioth client and MCUboot on the STM32, with it reaching the internet through the Linux side acting as a network bridge. This matches the documented Zephyr tutorials, but requires bridging the MCU’s networking through the Linux SoC.
I’m leaning toward Path A since it fits the hardware, but I’d value the community’s view.
Two questions:
For a topology like this (Linux host + a downstream MCU it flashes locally), is the gateway/orchestrator pattern something Golioth supports well? Any reference examples of managing a “downstream” MCU this way?
For the payload: is it better to ship a full rebuilt firmware image each time, or to deliver just the model as a separate artifact? I understand Golioth’s OTA can handle non-firmware artifacts including ML models; curious whether people would start with full-firmware for simplicity or go straight to model-as-artifact.
Any pointers, gotchas, or examples much appreciated. Thanks
Expected Behavior
I’d like to deliver new firmware/model versions to the STM32 over the air via Golioth. Since the STM32 has no direct internet and can’t self-flash normally, I expect to use the Linux SoC as the update agent: the Golioth client runs on Linux, receives the release, and applies it to the STM32 over the on-board OpenOCD/SWD path. I’m hoping to confirm this “gateway / downstream MCU” pattern is supported and is the right approach here.
Actual Behavior
I haven’t started the Golioth integration yet, I’m seeking design guidance before committing. Today the local loop works (STM32 runs a Zephyr app with an on-device model, no cloud). What’s unclear is which OTA architecture fits a board where the networked processor (Linux) and the target processor (STM32) are separate, and the target can only be flashed from the Linux side.
Impact
This decision blocks the OTA phase of the project. Choosing the wrong architecture means either reworking a lot of firmware (if MCU-direct proves impractical on this board) or building an unsupported custom path. I want to pick the approach Golioth supports best for a Linux-host + downstream-MCU topology before investing in it.
Environment
Hardware: Arduino UNO Q Qualcomm QRB2210 (Debian Linux, Wi-Fi) + STM32U585 (Cortex-M33) running Zephyr. Sensor: X-NUCLEO-IKS4A1.
RTOS: Zephyr (mainline, v4.4-dev).
Constraints: STM32 has no direct network access; it is flashed from the Linux side via an on-board OpenOCD/SWD bridge (west flash / dfu-util do not work on this board).
Golioth: not yet integrated, evaluating Firmware SDK vs a Linux-side client.
Logs and Console Output
None
Attempts to Resolve
Design question, so “steps taken” = prep done before committing:
- Local loop works: STM32 runs a Zephyr app with an on-device model (no cloud).
- Have a working flash path from Linux to the STM32 over the on-board OpenOCD/SWD bridge what a Linux-orchestrated update would reuse.
- Reviewed the standard Zephyr + MCUboot Golioth flow; it doesn’t map cleanly here (STM32 has no direct internet, isn’t flashed the usual way).
- Scoped two options (Linux-orchestrated gateway vs MCU-direct via a Linux network bridge) and want guidance on which Golioth supports best before building.