Re: CIP IRC weekly meeting today


Akihiro Suzuki
 

Hi Christian,

This is because SWUpdate is designed around a multi-process model with
IPC among the processes via sockets. This has, as one example, the
benefit that one can run the multiple components of SWUpdate with
different privileges. Apart from this, there's a clean interface also
imposed on the code structure which helps the modularization of the
source code.
I understand. Thank you for the explanation.

Ah, OK. This is the "official" in the sense of exemplary implemented way
how to do round-robin A/B firmware update. That said, this is in my very
personal opinion a bit too involved and spread out over too many places.
That was also one reason I brought forward the Lua handler feature that
allows you to implement a handler in Lua. Lua handlers are feature-wise
on par with C handlers by now, i.e., they are equally powerful. So, you
can write a Lua handler that does the target partition round-robin
calculation, flashing, and updating of the bootloader environment in one
place. The sw-description becomes simpler as well since you don't need
to specify the A/B layout there but instead the Lua handler will take
care of this.
That makes sense.
I thought that the A/B update way adopted by meta-swupdate-boards was
a little difficult to understand and not very flexible.
I would like to use Lua handler to implement the flexible A/B update
which can be used in various situations.

Best regards,
Suzuki

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Christian
Storm
Sent: Friday, March 29, 2019 10:22 PM
To: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

Hi Suzuki,


I'm sorry to bother you.
You're always welcome.


Looks good as / is mounted ro. Question is whether this is done via
a
remount,ro or whether it's ro right from the start?
I didn't remount / with ro manually,
but I have found that /proc/cmdline of the booted BBB includes "rw"
as follows:

root@beaglebone:~# cat /proc/cmdline
console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 rw
rootfstype=ext4 rootwait

This is because "args_mmc" (the environment variable of u-boot) was
not changed
even though I had built the rootfs with "read-only-rootfs" option in
poky.
(Although "/" in /etc/fstab was changed from "rw" to "ro" by the option)

The "args_mmc" was as follows:

args_mmc=run finduuid;setenv bootargs console=${console}
${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}

When I changed "rw" on args_mmc to "ro" and booted the BBB, /proc/cmdline
was changed as follows:

root@beaglebone:~# cat /proc/cmdline
console=ttyO0,115200n8 root=PARTUUID=770dcaeb-02 ro
rootfstype=ext4 rootwait

Because of this, the rootfs came to able to be mounted with ro from
the start.
Actually, I booted the BBB on several times,
and I checked that there were no changes in the partition.
Of course the binary delta update was successful with this
configuration.
It seems for me that this issue has been resolved.
Thank you for your great help!
That sounds good! Glad I could help here.


BTW, I have found the cause of the ext4 error messages.
This is because "/run/utmp" and "/run/mount" were created
before "/" was remounted automatically with ro according to /etc/fstab
in the boot process.
Their inodes were created but they were overwritten by zero by the binary
delta update.
But the inode of /run, their parent directory, was not overwritten by
the update,
and the dentries of "utmp" and "mount" remained inside the inode of
/run.
So the ext4 error messages were shown.
Currently, "utmp" and "mount" are not created because I can boot the
rootfs with "ro" from the start.
So this issue does not occur.
Sounds reasonable, good to have it sorted out.


Well, how did you instruct SWUpdate to choose "copy1" or "copy2"?
Sorry for the lack of explanation.
I used the method adopted by meta-swupdate-boards.
The important file is the following startup script of swupdate.
<https://github.com/sbabic/meta-swupdate-boards/blob/master/recipes-
support/swupdate/swupdate/beaglebone/swupdate>
The script checks the current rootfs partition and executes swupdate
with "-e stable,copy{1|2}" as follows:

root@beaglebone:~# cat /etc/init.d/swupdate
#! /bin/sh
-------- (snip) --------
DAEMON=/usr/bin/swupdate
-------- (snip) --------
rootfs=`mount | grep "on / type" | cut -d':' -f 2 | cut -d' ' -f
1`

if [ $rootfs == '/dev/mmcblk1p2' ];then
selection="-e stable,copy2"
else
selection="-e stable,copy1"
fi
-------- (snip) --------
exec $DAEMON -v -H beaglebone:1.0 ${selection} -f
/etc/swupdate.cfg -u "$EXTRA_ARGS" -w "" &
-------- (snip) --------

If the BBB is booted from /dev/mmcblk1p2, swupdate is executed with
"-e stable,copy2" as follows:

root@beaglebone:~# ps aux | grep swupdate
root 500 0.0 0.2 1704 1164 ? S 13:15
0:00 /usr/bin/swupdate-progress -w -p -r
root 501 0.2 1.2 49456 6504 ? Sl 13:15
0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f
/etc/swupdate.cfg -u -w
root 522 0.2 0.7 31016 3868 ? Sl 13:15
0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f
/etc/swupdate.cfg -u -w
root 524 0.0 0.9 24200 4840 ? S 13:15
0:00 /usr/bin/swupdate -v -H beaglebone 1.0 -e stable,copy2 -f
/etc/swupdate.cfg -u -w
root 551 0.0 0.2 1884 1040 ttyO0 S+ 13:19
0:00 grep swupdate
(I'm not sure why /usr/bin/swupdate is running with 3 processes)
This is because SWUpdate is designed around a multi-process model with
IPC among the processes via sockets. This has, as one example, the
benefit that one can run the multiple components of SWUpdate with
different privileges. Apart from this, there's a clean interface also
imposed on the code structure which helps the modularization of the
source code.


If you update now, the rule described in the "copy2" section in
sw-description is used.
In the sw-description which was attached in my previous email,
the update target in the "copy2" section is /dev/mmcblk1p3.
Besides, bootcmd_legacy_mmc1 (the environment variable of u-boot)
is modified to use /dev/mmcblk1p3 as the next boot target.
If the BBB is booted from /dev/mmcblk1p3, the "copy1" section is used.
In the "copy1" section, the update and next boot target are
/dev/mmcblk1p2.

Ah, OK. This is the "official" in the sense of exemplary implemented way
how to do round-robin A/B firmware update. That said, this is in my very
personal opinion a bit too involved and spread out over too many places.
That was also one reason I brought forward the Lua handler feature that
allows you to implement a handler in Lua. Lua handlers are feature-wise
on par with C handlers by now, i.e., they are equally powerful. So, you
can write a Lua handler that does the target partition round-robin
calculation, flashing, and updating of the bootloader environment in one
place. The sw-description becomes simpler as well since you don't need
to specify the A/B layout there but instead the Lua handler will take
care of this.



Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M√ľnchen, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

Join cip-dev@lists.cip-project.org to automatically receive all group messages.