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
