Hey Marko! I couldnt find any past post about couple of topics:
Hey @ash.vetchip,
Here are the answers to your questions:
Do you have any guidelines on how to use Golioth SDK with TF-M?
We currently do not provide separate guidelines specifically for TF-M, as Trusted Firmware-M itself is the reference implementation of ARM’s Platform Security Architecture (PSA).
Our examples, including those for the nRF9160 DK, are built to run in the non-secure domain. During the build process, the trusted TF-M firmware is automatically included, ensuring that both the non-trusted application firmware and the secure TF-M firmware are part of the final hex file. This provides Security by Separation, where sensitive tasks are handled in the secure domain and isolated from general application code.
The _ns build target specifically compiles the application to operate in the non-secure domain, effectively isolating it from secure processes. While the secure domain can still manage essential operations, like cryptographic functions or modem operations, the non-secure application only interacts with these secure resources indirectly through controlled APIs.
This architecture also affects how applications interact with the LTE modem on the nRF9160. The modem, which operates under secure services, is accessed using secure APIs. The _ns build allows the non-secure application to communicate with the modem indirectly through these interfaces, allowing network communications without granting direct access to sensitive modem functions.
Overall, this setup ensures that critical tasks remain isolated, while non-secure applications can still leverage secure services safely. This approach strengthens security boundaries, enhancing IoT and cellular application security on Nordic devices.
Nordic’s documentation offers comprehensive details on the Trusted Firmware-M.
Does your application need specific secure services that you can share?
Do you have any guidelines or suggestions on managing FOTA on ‘Co Processor’ scenarios like in Thingy91’s nRF9160+nRF52840? How would you manage updates on nRF52840?
In multi-MCU systems, the main and auxiliary MCUs can vary significantly in architecture, vendor, and communication protocols. For example, you might have an ARM Cortex-M paired with an ESP32, each handling firmware updates, communication, and memory management differently. These variations make it challenging to create a one-size-fits-all solution.
In the Golioth Console, you can create separate firmware packages for different targets, such as main (nRF9160) and auxiliary (nRF52840) MCUs. When setting up a Deployment within a Cohort, you can include both packages, allowing connected devices to download each package individually for coordinated updates across MCUs.
The Golioth SDK includes a public API for the OTA service to download individual components of a Deployment. The golioth_ota_download_component method can be used alongside OTA manifest APIs and supports custom firmware update mechanisms, including multi-artifact updates.
The actual process of transferring the image to the auxiliary MCU is left to the application, and we offer an example in Golioth Labs to guide you:
multi-mcu-fw-update: In this example, the main MCU (nRF9160 DK) runs an SMP client and downloads the firmware image for the auxiliary MCU (nRF52840 DK). The nRF52840 runs the SMP Server, and the firmware is transferred over UART, demonstrating the update process between primary and auxiliary processors.
The multi-MCU example currently uses an earlier SDK version and does not yet incorporate golioth_ota_download_component method. For an implementation reference, check out the multi-artifact-download example.