purpose of swupdate-image.bb recipe

[ya...@ieee.org]

is this the recipe which is to be (or can be) used for single-copy mode to generate the cpio.gz?

if so, why is the IMAGE_FSTYPES set to ext4.gz.u-boot?

--Randy

[Stefano Babic]

On 06/08/2018 17:35, ya...@ieee.org wrote:
> is this the recipe which is to be (or can be) used for single-copy mode to generate the cpio.gz?

No. For what is cpio.gz ?

>
> if so, why is the IMAGE_FSTYPES set to ext4.gz.u-boot?

It generates a Ramdisk to be used as rescue system as compressed ext4.

If you are looking how to generate the SWU images, check the examples in
meta-.swupdate-boards:

https://github.com/sbabic/meta-swupdate-boards/blob/master/recipes-extended/images/update-image.bb

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[ya...@ieee.org]

the linux kernel bundles a blank cpio.gz which is loaded into an initramfs during early initialization, but since there is no init, linux then boots the normal rootfs (e.g., on ext4).

you can instead bundle your own cpio.gz with the kernelwhich has, at a minimum, an init script or program. it is from this initramfs-based rootfs i thought was intended to do the swupdate for a single-copy mode update.

[Stefano Babic]

Og course, but this fight with the way this is implemented in OE.
INITRAMFS is set globally, and kernel will always bundle the SWUpdate's
rescue. This is unwanted: just the rescue image should contain the
ramdisk, but the production image shouln't. Leaving the ramdisk outside
of the kernel (the old method) gives more flexibility. Of course,
everybody can overload the IMAGE_FSTYPES rule and bound the SWUpdate
image with the kernel (I do this in a fitImage), depending on project's
requirement.

[ya...@ieee.org]

Why do you say this is unwanted? Because it takes extra boot time? I've never done a "pivot" so I don't know how long it takes switch to the new rootfs (the normal one on an ext4, e.g.).

The only way I see to get a custom image is to modify uboot to load the cpio.gz into memory and also add to the device tree the chosen node:

/ {
chosen {
linux,initrd-start = <0x82000000>;
linux,initrd-end = <0x82800000>;
};
};

How would you load the generated image from your swupdate-image recipe?

Perhaps I'm missing something.

--Randy

[ya...@ieee.org]

Yes, I was always going to boot the rescue, then check some inter-boot variable (probably just a special file on the fat32 partition) to see if we actually need to do a swupdate. if not, pivot to the normal rootfs.

--Randy

[ya...@ieee.org]

On Monday, August 6, 2018 at 1:53:57 PM UTC-4, ya...@ieee.org wrote:
> Yes, I was always going to boot the rescue, then check some inter-boot variable (probably just a special file on the fat32 partition) to see if we actually need to do a swupdate. if not, pivot to the normal rootfs.

To clarify, I was only going to have one linux kernel, the one that contained the custom, bundled cpio.gz.

[Stefano Babic]

The rescue image for the single-copy approach is generally separated
from the rest of system. If possible, it is also stored on a separate
storage to let restore the system even in worst cases. You are embedded
the rescue image as part of the production system because you want to
put it into the production kernel. What happens if an update is broken
or interrupted during an update of the kernel ? The rescue image will be
broken, too.

> The only way I see to get a custom image is to modify uboot to load the cpio.gz into memory and also add to the device tree the chosen node:
>
> / {
> chosen {
> linux,initrd-start = <0x82000000>;
> linux,initrd-end = <0x82800000>;
> };
> };
>
> How would you load the generated image from your swupdate-image recipe?
>
> Perhaps I'm missing something.
>