| Message ID | 20210907132240.2987302-5-adrian.freihofer@siemens.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | swupdate-common: get do_swuimage vardeps | expand |
Hi Adrian, On 07.09.21 15:22, Adrian Freihofer wrote: > This introduces a new variable IMAGE_FSTYPE_SWU which most probably > needs to be overridden by the image. The main purpose is to ensure the > image artifact is available when do_swuimage runs. If the user for > example would set the IMAGE_FSTYPES to ext4.gz but include the ext4 into > the swu file it does not work because the ext4 image gets immediately > deleted if it is not explicitely requested. This is true, but...it is an error in the recipe. For this case, IMAGE_FSTYPES = "ext4 ext4.gz". In the example above, do_swuimage stops and raises the error that the .ext4 file is not found. This seems to try to fix an error that the user has written. > > It's also more convenient to set a variable instead of the dealing with > the VarFlags. This is true, but I have already used a lot VarFlags... > --- > classes/swupdate-image.bbclass | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/classes/swupdate-image.bbclass b/classes/swupdate-image.bbclass > index ae4beeb..2b00727 100644 > --- a/classes/swupdate-image.bbclass > +++ b/classes/swupdate-image.bbclass > @@ -8,6 +8,22 @@ > # The generated output file is an swu archive ready to be uploaded to a device running > # swupdate. > > + > +# Define the image type included in the swu file for this image > +IMAGE_FSTYPE_SWU ??= "ext4" This is used on most eMMC based systems, but I see also a raising number with btrfs, and many other systems have different filesystems. I understand that variable is not overwritten, but on the other side it can lead to bigger misunderstanding. If for example a system runs on raw NAND, and filesystem should be UBI, the rule above overwrite the missing setup, the filesystem is created (of course !), the SWU is ready, and issue raises just when the SWU is tested. I guess (well, I do not want to test this..), that SWUpdate is successful, because it writes an image to an UBI volume, but of course the device does not boot anymore. IMHO it is better to raise a build error if something was not correctly set or is missing. If we want such kind of automatismus, it could be done with IMAGE_FSTYPES and set SWUPDATE_IMAGES_FSTYPES with a rule, for example the first found filessystem raising a warning because SWUPDATE_IMAGES_FSTYPES was not set. > + > +# Add the image type of this image explicitely otherwise the artifacts > +# gets deleted before do_swuimage task runs > +IMAGE_FSTYPES_append = " ${IMAGE_FSTYPE_SWU}" > + > + > +python() { > + # Define the image type which should be included into the swu file > + image = d.getVar('IMAGE_LINK_NAME') > + image_type = d.getVar('IMAGE_FSTYPE_SWU') > + d.setVarFlag('SWUPDATE_IMAGES_FSTYPES', image, '.' + image_type) > +} > + > inherit swupdate-common.bbclass > > S = "${WORKDIR}/${PN}" > Best regards, Stefano
diff --git a/classes/swupdate-image.bbclass b/classes/swupdate-image.bbclass index ae4beeb..2b00727 100644 --- a/classes/swupdate-image.bbclass +++ b/classes/swupdate-image.bbclass @@ -8,6 +8,22 @@ # The generated output file is an swu archive ready to be uploaded to a device running # swupdate. + +# Define the image type included in the swu file for this image +IMAGE_FSTYPE_SWU ??= "ext4" + +# Add the image type of this image explicitely otherwise the artifacts +# gets deleted before do_swuimage task runs +IMAGE_FSTYPES_append = " ${IMAGE_FSTYPE_SWU}" + + +python() { + # Define the image type which should be included into the swu file + image = d.getVar('IMAGE_LINK_NAME') + image_type = d.getVar('IMAGE_FSTYPE_SWU') + d.setVarFlag('SWUPDATE_IMAGES_FSTYPES', image, '.' + image_type) +} + inherit swupdate-common.bbclass S = "${WORKDIR}/${PN}"