mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Konstantin Kletschke <konstantin.kletschke@inside-m2m.de>
To: barebox@lists.infradead.org
Subject: Howto implement bootchooser <-> rauc interaction
Date: Fri, 03 Dec 2021 13:40:56 +0100	[thread overview]
Message-ID: <9215c9815f25cc3328a05d6c9553ac36@inside-m2m.de> (raw)

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


             reply	other threads:[~2021-12-03 12:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 12:40 Konstantin Kletschke [this message]
2021-12-03 17:52 ` Trent Piepho
2021-12-05 22:55   ` Roland Hieber
2021-12-06  8:52     ` Konstantin Kletschke
2021-12-14 21:40     ` Konstantin Kletschke
2021-12-15 10:56       ` Ahmad Fatoum
2021-12-16 19:35         ` Konstantin Kletschke
2021-12-17 10:00           ` Ahmad Fatoum
2021-12-17 12:50             ` Konstantin Kletschke
2022-01-03 15:24         ` Roland Hieber
2021-12-06  8:30   ` Konstantin Kletschke
2021-12-14 21:28   ` Konstantin Kletschke
2021-12-15 10:50     ` Ahmad Fatoum
     [not found]       ` <297b3425baa118783dccb6446900fbfa@inside-m2m.de>
2021-12-16 19:42         ` Fwd: " Konstantin Kletschke
2021-12-17  9:46           ` Ahmad Fatoum
2021-12-17 12:43             ` Konstantin Kletschke
2021-12-17 13:08               ` Ahmad Fatoum
2021-12-17 14:21                 ` Konstantin Kletschke
2021-12-22 14:05                   ` Konstantin Kletschke
2022-01-05 17:50                     ` Ahmad Fatoum
2022-01-06  9:59                       ` Konstantin Kletschke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9215c9815f25cc3328a05d6c9553ac36@inside-m2m.de \
    --to=konstantin.kletschke@inside-m2m.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox