Re: [RAUC] questions about RAUC

Re: [RAUC] questions about RAUC

[Enrico Jörns]

Hi Manuel,

Am Freitag, dem 02.12.2022 um 13:46 +0100 schrieb Manuel Duran Flores:
> Hello RAUC company!
> I'm Manuel Duran Flores, and I'm starting with the whole Yocto Project environment and the whole
> world of Embedded Linux and OTA updates. I found your website and I'm fascinated, congratulations
> for your work!

thank you!

> At the moment it is the best source of information I have seen about OTA updates. 

Good to hear :)

> I am working with a IMx6 NXP processor and I need to implement an OTA delta update solution. After
> reading a lot about different solutions, I realized which RAUC could be the best option for me,
> but I  really need help and I wonder if you can give me a little support. 

Let's see.

> OK, first of all, if I understood properly Saving Download Bandwidth with RAUC Adaptive Updates
> article, the adaptive update process could be enumerated in a summarized (and very simple) way by
> the following steps:
>  
>    1. We have an new image in whatever server and I want to performance an OTA adaptive update of
> my local image .

Yes. Not necessarily a server but somewhere should be an image, most probably generated by some
Linux building system like Yocto. 

>    2. RAUC generates the block hash index file that consists on the list of all the chunks of the
> new image.

Yes. But this is transparently done together with the step below (if enabled in your manifest).

>    3. Now we have the bundle created in remote. Is that true? (The image plus the block hash
> index)

Yes, you generate the bundle somewhere on your build machine (or build server) and the bundle will
contain both the original image as well as the generated hash index.

>    4. So, RAUC downloads the block hash index file and then performs the hashing and chunking
> operation in active and inactive slot, and generates the corresponding block hash index file of
> each one. Why are these operations performed in both slots? That is, active slot is working
> properly but with an old version of my software. So I understand that I will have to change this
> by the updated in the inactive slot, that is to say, the update will have to be done in the
> inactive slot, and when it finishes properly, I reboot my systm to the inactive slot. Why am I
> wrong? (Probably this is the most important question).

Not sure if I got what confuses you, but generally speaking you are right.

-> You run from the *active* slot(s) and update the *inactive* ones.

-> The hash is taken from the *active* slot too, since this is the software state that is probably
most close to what you gonna install. Remember that the software on your *inactive* slot of two
updates ago.

-> Also keep in mind that while writing to the inactive slot, the original hash index becomes less
and less usable since the original data is overriden.

>    5.  Then RAUC compares the first downloaded block hash index file with the obtained of each
> slot following the order that figures in the image of the article.  If some of them are different,
> then will be downloaded.

Exactly.

> 1. Could be an error in the order?

No, the hashes are generated in order during bundle generation and read and written in order during
installation.


> If you see the image the order is different than in the text.

I assume you refer to the images in the blog post?

That actually depends on in which direction you read the block device or the file. If you have a
look at the shown direction in which the bundle is read from bottom to top. But in the end this is
just a simplified illustration.

> 2.If a chunk of the active slot has to be downloaded and installed,  does the system stop working
> until installation finalizes?

No. If your system could not read from its storage while running it would not be bootable at all I
guess ;)

> That is my idea of all the process, but I have to be wrong in something.
> And last question: I am working with a NAND memory, does it mean that RAUC  can not be
> implemented?

RAUC of course works out of the box.

What the statement means is that you cannot use the optimization the blog article is about.
This would mean you would have to streaming the entire bundle into the NAND.

It also notes that supporting NAND is potentially possible but requires some extended
implementation. Not sure if this is what you wanna start with, but if there is really interest, the
two options on how to gain the feature are mentioned there ;)

> I hope you can help me. 
> Many thanks and congrats for you work once again.
> Kind regards,
>  Manuel

Maybe I could at least clarify some aspects.

Best regards

Enrico

> 
> 

-- 
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |