Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

Hi All,

finally I managed to integrate rauc and barebox-state into my yocto 
build. I am not sure
completely yet if this is done properly, though. I want to make this
bootchoser-alternate-rootfs-switchover-thingy working properly with 
bootchooser detecting
reset cause and additionally rauc/barebox-state marking successful 
boots.

The documentation looks very good and comprehensive overall but may be 
its me not getting
the part how and where the shared data is properly stored.

Please let me briefly explain what I already have (targets mmc1.1 and 
mmc1.2 are bootloader
spec entries):

bootchoser variables defined in barebox (preliminary in nv namespace, 
does it need to go
elsewhere?):

barebox at TI AM335x BeagleBone black:/ nv
   allow_color: true
   autoboot_timeout: 3
   boot.default: bootchooser insidem2m
   bootchooser.last_chosen: 2
   bootchooser.retry: 1
   bootchooser.system1.boot: mmc1.1
   bootchooser.system1.default_attempts: 3
   bootchooser.system1.default_priority: 21
   bootchooser.system1.priority: 21
   bootchooser.system1.remaining_attempts: 0
   bootchooser.system2.boot: mmc1.2
   bootchooser.system2.default_attempts: 3
   bootchooser.system2.default_priority: 20
   bootchooser.system2.priority: 20
   bootchooser.system2.remaining_attempts: 1
   bootchooser.targets: system1 system2
   user: none

barebox at TI AM335x BeagleBone black:/ bootchooser -i
Good targets (first will be booted next):
system2
     id: 2
     priority: 20
     default_priority: 20
     remaining attempts: 1
     default attempts: 3
     boot: 'mmc1.2'

Disabled targets:
system1
     id: 1
     priority: 21
     default_priority: 21
     remaining attempts: 0
     default attempts: 3
     boot: 'mmc1.1'
     disabled due to remaining attempts = 0

last booted target: system2

When linux is booted rauc complains:

(rauc:396): rauc-WARNING **: 08:32:31.311: Failed getting primary slot: 
Failed getting primary slot: No content to read

EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: 
(null)
rauc-Message: 08:32:31.729: rauc status: 
GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code30: 
Failed marking 'rootfs.1' as good: Failed to run barebox-state: Child 
process exited with code 1

# rauc status

(rauc:583): rauc-WARNING **: 08:33:46.622: Failed getting primary slot: 
Failed getting primary slot: No content to read

=== System Info ===
Compatible:  insidem2m-s
Variant:
Booted from: rootfs.1 (system2)

=== Bootloader ===
Activated: (null) ((null))

=== Slot States ===
o [rootfs.1] (/dev/mmcblk0p3, ext4, booted)
	bootname: system2
	mounted: /
	boot status: bad

o [rootfs.0] (/dev/mmcblk0p2, ext4, inactive)
	bootname: system1
	boot status: bad



# barebox-state -d
Neither /aliases/state nor /state found


# cat /proc/cmdline
bootchooser.active=system2 console=ttyO0,115200n8 root=/dev/mmcblk0p3 
rootfstype=ext4 rootwait


This is /etc/rauc/system.conf:

# cat /etc/rauc/system.conf
[system]
compatible=insidem2m-s
bootloader=barebox

[keyring]
path=ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system1

[slot.rootfs.1]
device=/dev/mmcblk0p3
type=ext4
bootname=system2





Actually I fully understand that rauc/barebox-state has no info where to 
store its marking to
be read later for barebox. Even /boot/ is not mounted with the barebox 
environment in it
(/dev/mmcblk0p1 vfat carries bootloader images and barebox.env). Is it 
possible to utilize
that for interaction?

Is it a must to utilize the barebox-state framework for this? I read 
very much about this but
everytime it is referenced as a device tree extension which is provided 
as an example in arch/arm/dts/state-example.dtsi. Every doc or walk 
through refers to a device tree.
But - sorry - does this go into the barebox device tree? Or into the 
kernel device tree?
Or both?

Both parts needs to be informed but how does userspace 
rauc/barebox-state access stuff
provided by device tree?
I could easily utilize the I2C EEPROM on my Beaglebone Black for this 
but how should this
look like for barebox and kernel?


Kind Regards
Konstantin