[RAUC] Understanding u-boot integration

[RAUC] Understanding u-boot integration

[Philip Downer]

[-- Attachment #1.1: Type: text/plain, Size: 1105 bytes --]

After seeing a presentation on RAUC at FOSDEM I've been looking to
integrate it with a Yocto based i.mx6 embedded system that I'm working on.

Everything is pretty much working but I'm just trying to understand the
integration with u-boot, I've based my u-boot scripts on the one in contrib
from the RAUC repository. I've had to make some changes due to an old
version of u-boot and quirks of our setup, however my questions are about
the general process.

As I understand it, when the system boots, the first slot from BOOT_ORDER
will be selected, say slot A. Then BOOT_A_LEFT will be decremented from 3
to 2 and we will save the environment to nand flash. Is it then intended
that when the OS boots successfully it should change the BOOT_A_LEFT
variable in nand flash back to 3?

Following on from that, if I'm correct, this seems like a lot of writes to
nand flash. Writing to nand is also not that quick for us at 3.41 seconds
from within Linux, is there not a reasonable chance of corruption if the
system was reset during that write?

-- 
Philip Downer
+44 (0)7879 470 969
pdowner@prospero-tech.com

[-- Attachment #1.2: Type: text/html, Size: 1424 bytes --]

[-- Attachment #2: Type: text/plain, Size: 65 bytes --]

_______________________________________________
RAUC mailing list

Re: [RAUC] Understanding u-boot integration

[Enrico Joerns]

Hi Philip,

On 04/25/2017 03:43 PM, Philip Downer wrote:
> After seeing a presentation on RAUC at FOSDEM I've been looking to
> integrate it with a Yocto based i.mx6 embedded system that I'm working on.

great to hear that it inspired you to start working with RAUC.

> Everything is pretty much working but I'm just trying to understand the
> integration with u-boot, I've based my u-boot scripts on the one in
> contrib from the RAUC repository. I've had to make some changes due to
> an old version of u-boot and quirks of our setup, however my questions
> are about the general process.
>
> As I understand it, when the system boots, the first slot from
> BOOT_ORDER will be selected, say slot A. Then BOOT_A_LEFT will be
> decremented from 3 to 2 and we will save the environment to nand flash.
> Is it then intended that when the OS boots successfully it should change
> the BOOT_A_LEFT variable in nand flash back to 3?

Yes, this is exactly what it should behave like. This is required to 
prevent you from booting in a loop when userspace fails and the watchdog 
resets the board before you mark your boot as 'good'.

Resetting the boot counter can be done by calling

   rauc status mark-good

If you use meta-rauc with systemd, this is exactly what the 
`rauc-mark-good.service` does:

   [Unit]
   Description=Rauc Good-marking Service

   [Service]
   ExecStart=@BINDIR@/rauc status mark-good

   [Install]
   WantedBy=multi-user.target


In your setup, you should assure this service runs *after* all your 
critical services came up and you can be halfway sure that the system 
you booted is in a working state.

And to be honest, it seems this handling currently is everyting else 
than overdocumented...

> Following on from that, if I'm correct, this seems like a lot of writes
> to nand flash. Writing to nand is also not that quick for us at 3.41
> seconds from within Linux, is there not a reasonable chance of
> corruption if the system was reset during that write?

Well, this definetely depends on where you store your environment and 
how frequently you intend to reboot your system. It has to be noted that 
the environment (regardless whether in U-Boot or in Barebox) is not the 
best place to store such informations, as these 'environments' were 
designed with other use cases in mind.

If you care about these topics, you could have a look at the state and 
bootchooser framework of the Barebox bootloader:

http://www.barebox.org/doc/latest/user/state.html
http://barebox.org/doc/latest/user/bootchooser.html

Barebox state was explicitly designed for storing and manipulating data 
that has to be exchanged between the Bootloader and Linux. It has 
different storage strategies to deal with the different properties of 
the underlying storage technologies (EEPROM, eMMC, raw NAND, etc.) and 
manages redundancy and write atomicity.


Best regards

Enrico

-- 
Pengutronix e.K.                           | Enrico Jörns                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
RAUC mailing list