Support raspberry pi 4 about iot-hub-device-update HOT 12 CLOSED

Hello,

Adding some responses for your questions below:

1. How to build the Yocto image to flash the Raspberry Pi device for image updates:

• Here is how to build a Yocto image: https://www.yoctoproject.org/docs/2.2/yocto-project-qs/yocto-project-qs.html for reference agent to do image based updating (not required for package updating or simulator agent).
• Once you have successfully built the image for Raspberry Pi4 using the Yocto build system, if you still need our recipes of the meta layer that we added on top let us know.

2. The output of https://github.com/Azure/iot-hub-device-update/blob/main/docs/agent-reference/how-to-build-agent-code.md will be a binary of device agent.

3. You can see how we build our project using https://github.com/Azure/iot-hub-device-update/blob/367b880baf43294f8b127612f7687e1247d50c79/CMakeLists.txt and use that as a reference and try to integrate our project/code into your “pi-gen” build process.

4. The prebuild package from https://github.com/Azure/iot-hub-device-update/releases/download/0.6.0/deviceupdate-agent-0.6.0-public-preview-Linux.deb is to do a package based update by following Device Update for Azure IoT Hub tutorial using these https://docs.microsoft.com/en-us/azure/iot-hub-device-update/device-update-ubuntu-agent instructions, it is for Ubuntu 18.04 AMD 64.

from iot-hub-device-update.

I'm hearing a number of different questions here, so before I provide answers, I'd like to better understand what your scenario is. The title reads "support raspberry pi 4", but you do mention "raspberry pi 3" above. Are you specifically looking whether or not RPi4 is supported? I also see questions about how to build and run the agent, and also perhaps how to incorporate into a yocto image as we did?

Note that that ADU client is considered a reference client, where a customer would use that as a starting point for their implementation, so there's nothing that requires you to use SWUpdate, for example. The yocto images that are provided are for convenience as well (to provide a quick way to get up and running for testing), but if you're familiar with building a RPi yocto image, we're not doing anything unique. We build the binaries, and then pass them to a yocto recipe file (with appropriate BBLAYERS) to create an image.

If you just want to try building the ADU client and start testing it, you can build in simulator mode, copy it to a raspberry pi and run it, without the need for a full yocto image. Documentation for simulator mode is in the "docs" folder of the github repo.

from iot-hub-device-update.

Hello, thank you for your question.
Are you using Raspberry-pi 4 only for testing? Our source code should work on Raspberry-Pi4 but we have not validated it yet. If you are open to it please clone our repo, build locally and test it on your Raspberry-Pi4. Let us know if it worked for you.

from iot-hub-device-update.

I am using Rapberry Pi for my own small project, it's a real device, not testing.
I'd love to build the image for it with device update agent, but I don't understand how the image is made.

Could you please point me in the direction of a guide explaining how to build the image? I see how to build the agent itself - https://github.com/Azure/iot-hub-device-update/blob/main/docs/agent-reference/how-to-build-agent-code.md , but it does not say anything about raspberry pi. I take it is that output of that guide will be binary of device agent?
One confusing thing about it is that there are three options - "simulator agent", "reference agent integrated with Delivery Optimization for downloads but still mocks the Install and Apply actions" and "agent package for package based updating via APT Manifest". None of those look like they are supposed to be updating Raspberry Pi from image...

If you have a guide explaining how raspberry pi 3 image was made, that would be very nice.

At first I was looking in the direction of "pi-gen" tool, that can produce Raspberry PI OS images and somehow integrate build of device update agent inside of pi-gen process (that does not work right away, because their build is done from debian docker image, not Ubuntu, which device update building requires), but I'm not sure if that would actually work and which options I'm supposed to pass to build.sh to get something that would work in Raspberry PI OS. "Simulator" is surely not the one and neither is "reference agent... mocks the Install and Apply actions" - I need Install and Apply actions probably to actually do something. "Agent package for package based updating" is alternative I'm currently inclining to, but I think that image based update should be better.

from iot-hub-device-update.

One more problem I faced with this guide - https://github.com/Azure/iot-hub-device-update/blob/main/docs/agent-reference/how-to-build-agent-code.md is that it does say how to install "Device Update Agent" right from the build, but it does not say what to do if I need to install that build to another system, not the one, where build is happening. Normally I'd expect build to happen in CI and then result of it should be packaged in file, which is then passed to devices somehow and installed there. This is a part which I'm also struggling with when I'm trying to use this device update system. Could you please clarify how that could be done somehow? If I knew how the result of build could be installed on any linux system, this would probably simplify things somewhat.
Also note that system where I'm building this and the one where it would run have different architectures. Raspberry is arm and my laptop (and CI) would be likely amd64. Guide does not say anything about how to choose target architecture unfortunately. That makes it more confusing. Is there any way to configure that?

from iot-hub-device-update.

I also considered just using prebuilt package here - https://github.com/Azure/iot-hub-device-update/releases/download/0.6.0/deviceupdate-agent-0.6.0-public-preview-Linux.deb
, but this one is also confusing me - it does not say what architecture build is for. Is it arm64? Is it amd64?

from iot-hub-device-update.

From what you are saying I take that yocto is the required way to build image like the one you have provided for raspberry pi 3?
What I don't understand right now is how is device update agent build is incorporated into yocto image build. Should it take prebuilt binary somehow (I could just build the agent in docker container)?
I'll try making stuff with yocto and update on that later..

I'm not really sure that image produced by pi-gen would include stuff that image updating by agent would require. Agent needs SWUpdate, right? Is it actually present in pi-gen? I could not find any info on that unfortunately..

from iot-hub-device-update.

The title reads "support raspberry pi 4", but you do mention "raspberry pi 3" above

I saw that there is an image for raspberry pi 3 in the release, but could not find any info on how it was created, I figured that if I'm to make image for rpi4, instructions on how rpi3 image was created could help me. So far I did not get any instructions aside from using Yocto, which I am in progress of doing.

. Are you specifically looking whether or not RPi4 is supported?

This is important question, yes. But mostly I think that the project should not only have rpi3 image, but also instructions how to make one and there should be prebuilt image for rpi4 as well.

I also see questions about how to build and run the agent, and also perhaps how to incorporate into a yocto image

I think that guide explaining how rpi3 image was build would already cover this.

Note that that ADU client is considered a reference client, where a customer would use that as a starting point for their implementation

Could the agent be used without any code modifications?

there's nothing that requires you to use SWUpdate

I'd like to minimize efforts and use something that is already working.

The yocto images that are provided are for convenience as well (to provide a quick way to get up and running for testing), but if you're familiar with building a RPi yocto image, we're not doing anything unique. We build the binaries, and then pass them to a yocto recipe file (with appropriate BBLAYERS) to create an image.

It would be nice if that was documented step by step.

If you just want to try building the ADU client and start testing it, you can build in simulator mode, copy it to a raspberry pi and run it, without the need for a full yocto image

I need to actually update device, not simulate update.

from iot-hub-device-update.

We will consider supplying a Raspberry Pi4 image in the future, but currently we are using Raspberry Pi3 devices here, hence the reference image we provide.

You ask "Could the agent be used without any code modifications?". Yes, if the reference agent implementation is being used in an environment which matches that which the reference agent was designed for (raspberry pi 3 using swupdate or apt updating), then yes, it will work without any code modifications.

Do you have access to a raspberry pi 3? If so, you can use our pre-built images to evaluate ADU very quickly and easily. This is the recommended approach for evaluating Device Update for IoT Hub .

If you're looking for a prebuilt image to use in a production environment, we do not supply one, nor is the reference client or the yocto image we provide suitable for that purpose.

from iot-hub-device-update.

Do you have access to a raspberry pi 3?

No. I don't think that I will be choosing older hardware because of software right now.

If you're looking for a prebuilt image to use in a production environment, we do not supply one, nor is the reference client or the yocto image we provide suitable for that purpose.

Why "reference client" is not suitable? I understand that it can update rpi device without any code modifications. Updating device is its only purpose or am I missing something?

We will consider supplying a Raspberry Pi4 image in the future, but currently we are using Raspberry Pi3 devices here, hence the reference image we provide.

This would be nice, but also if there was a guide explaining how you created images, then it could just be replicated with adjustments for rpi4. I think providing a guide would be better than just prebuilt image (though image is also nice).

from iot-hub-device-update.

"No. I don't think that I will be choosing older hardware because of software right now.

The suggestion isn't to permanently build on older hardware, it's to evaluate our product on a Raspberry Pi 3 as that's currently what we provide an image for. Do you have an existing product that you're considering integrating Device Update for IoT Hub into? Is your product currently limited to running on a Raspberry Pi 3?

Are you currently using yocto to build your device image? Can you provide some details (e.g. a website) as to your product - we'd like to ensure that we can help you integrate into your product most effectively, and as I mentioned earlier, we use yocto as an example, but that's certainly not the only way to integrate Device Update.

from iot-hub-device-update.

Do you have an existing product that you're considering integrating Device Update for IoT Hub into?

No, I wanted to start with the device update right away.

Is your product currently limited to running on a Raspberry Pi 3?

No particular limitations so far, this is only beginning of the project, but I already have rpi4 device to start working.

Are you currently using yocto to build your device image? Can you provide some details (e.g. a website) as to your product

It does not exist yet. I wanted to start with device update, so that there was a pipeline constantly updating test device without need of flashing it manually (after initial flash is done). It looks to me now, that the device update agent is still in very early phase and I'd probably use a different approach for updating until this is out of alpha. Thanks for help anyway!

from iot-hub-device-update.