Howto implement bootchooser <-> rauc interaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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@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










_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux