Is there an option to download packages using the Torizon Cloud API?
My usecase is the following:
We are using TorizonCore Builder to build our OS. We also created a subsystem for the cortex M7.
The binary .elf file for the M7 is deployed to Torizon Cloud, so that we can update it OTA.
What I still need to do is adding the .elf file to our TorizonCore Builder setup so that the binary is included in the TEZI image. That is why I am wondering if I can download the .elf binary from Torizon Cloud, so that I can add it to the TEZI package.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello there!
Based on the available documentation, while the Torizon Cloud API offers endpoints for managing packages, including listing and uploading them (1), there isn’t a directly documented endpoint for downloading packages from Torizon Cloud.
However, when you push packages to Torizon Cloud, you have the option to specify custom URIs for packages (2). This means you might be able to store your .elf file at an accessible location and reference it via a URI when creating updates.
For integrating with TorizonCore Builder, you can configure inputs and outputs in the tcbuild.yaml file (3). The system expects specific file types and references, and there have been reported issues with handling binary files directly (4).
Given the current documentation, you might consider maintaining your .elf file in a separate repository that both your Torizon Cloud deployment and TorizonCore Builder setup can access. Additionally, visiting the Toradex Community can provide further insights and support from other users.
If you need a general approach for managing binary files with TorizonCore Builder, feel free to ask!
Just to understand, so you uploaded a binary file to Torizon Cloud. You now want to download the same binary file from Torizon Cloud to use in TorizonCore Builder.
But, if you uploaded this binary in the first place, does this not mean you have access to it already? It just seems kind of strange to access the binary file by downloading it via Torizon Cloud, when it was you who uploaded it to begin with.
Is there a reason you’re trying to do this in this way?
Furthermore, I don’t believe there is a public API to download the packages which is also why I’m trying to understand your reasoning here.
We have one repository for the cortex M7 that creates the binary file. In another repository we use the TorizonCore Builder to create the Torizon OS.
Since we need to push the M7 binary to the Torizon Cloud anyway, I though I could use it as storage and also download from there. I guess we will use some other cloud service then.
Additionally, I would rather say that as a customer I actually would like to download the TEZI image from Torizon rather that having to build it myself.
In my view, Torizon is “the single point of truth” wen it comes to image-packages.
There is the place in which the devices will get the binaries, therefore also the TEZI image should come from there and since the components are all already there, you could create the image server-side.
Our pipelines will upload the various components, and then I expect to be able to get a TEZI image via API.
Only in this way I can be sure (without extra SW at our side) that TEZI and OTA update files content are always in sync.
As Ian mentioned, now we are forced to store the partial components “somewhere” in order to create a full image, and we need to make sure everything is consistent “somehow”.
To be honest this specific use-case you are describing is the first time we’ve gotten feedback that someone would like to use Torizon Cloud in this way. While this isn’t something we may have right now your feedback is valuable and we’d still like to understand your needs as best as we can.
If you don’t mind, I’d like to ask/discuss some points with you to better understand your use-case and perspectives.
As I understand currently you have one code repository that contains the sources to build an elf binary for the M7. You have another separate code repository to produce a customized Torizon OS image using TorizonCore Builder. You want to create a CI/CD pipeline that does the following:
Build your M7 elf binary from repository 1
Push this binary to Torizon Cloud to be used in subsystem updates
Build a customized Torizon OS with TorizonCore Builder from repository 2
This custom OS should contain the binary built from repository 1
Now this kind of CI/CD pipeline is relatively common with most CI/CD tools like Gitlab/Github pipelines. Generally saying you have one stage of a pipeline that produces an artifact (i.e. elf binary), that then passes the artifact to another stage of the pipeline (TorizonCore Builder). This is why I initially questioned the sort of roundabout way of getting the binary via downloading it from Torizon Cloud.
I see now that in your own words you sought to use Torizon Cloud as a “source of truth” for your software. You mention the following:
we are forced to store the partial components “somewhere” in order to create a full image, and we need to make sure everything is consistent “somehow”.
Could you elaborate on this. Is this specifically about software storage and version/release management? I would like to understand your perspective on this and what you envisioned.
To be clear, I’m not saying Torizon Cloud will never provide something like this, but it’s not something that it was designed for in the present moment. From how I understand your needs, it sounds like you want some kind of CI/CD release management tool. While Torizon Cloud in it’s current state is more of a software update management tool, with some remote device management features as well.
Finally, was this idea to use Torizon Cloud for this use-case something devised by your team, or was it something we at Toradex suggested? I wanna make sure we didn’t mistakenly give an incorrect impression regarding what Torizon Cloud is at some point.
