How to use swupdate.bbclass?

[Bjørn Forsman]

Hi Stefano,

Do you have a small example on how to use the swupdate.bbclass? I've
played around with it for a while now, but I still don't grok it. (And
I didn't find any documentation.)

What I have now is a custom image recipe where I added this to the
bottom of the file:

SRC_URI += "file://sw-description" # my sw-description file is in
<recipedir>/files/sw-description
SWUPDATE_IMAGES = "${PN}"
SWUPDATE_IMAGES_FSTYPES = "ext4"
#cp somehow/get/the/path/to/sw-description ${WORKDIR}/sw-description
inherit swupdate

Question 1:
I guess this is a generic OpenEmbedded question, but I couldn't figure
out how to install sw-description into ${WORKDIR}, like
swupdate.bbclass expects. Well, at least without some do_*
prepend/append tricks, AFAIK.

Question 2:
swupdate.bbclass copies ${WORKDIR}/sw-description to
${S}/sw-description. If I'm supposed to manually copy sw-description
to ${WORKDIR}, I might as well copy it to ${S} directly. Hence I feel
I've missed something essential here.

Question 3:
When running "bitbake -c listtasks myimage", I see the "do_swuimage"
task. I can run "bitbake -c swuimage myimage". Is this the intended
use case? I expected "bitbake myimage" to automatically do the
swuimage task, but it doesn't. Again, I must be missing something here
:-)

Best regards,
Bjørn Forsman

[Stefano Babic]

Hi Bjorn,

On 13/11/2015 14:18, Bjørn Forsman wrote:
> Hi Stefano,
>
> Do you have a small example on how to use the swupdate.bbclass? I've
> played around with it for a while now, but I still don't grok it. (And
> I didn't find any documentation.)
>

I have already tried to explain this in a previous thread - it looks
like I was not able to be very clear.

I wrote:

"I agree that an example would be nice, but it should be bound with a
hardware, and I preferred to let meta-swupdate hardware-independent. But
maybe some examples with a well known board (beaglebone, raspi) can help.

I try to explain here:

I usually put the receipe for the compound image (.swu) in my
application meta (not in meta-swupdate). Let's say we have a
compound-image.bb (recipes-extended/images/compound.bb), it can look
like as:

# Note: sw-description is mandatory
SRC_URI = "file://sw-description \
<additional files listed in sw-description but not generated> \
"

inherit swupdate

LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \

file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

# IMAGE_DEPENDS: list of Yocto images that contains a root filesystem
# it will be ensured they are built before creating swupdate image
IMAGE_DEPENDS = "core-image <other dependencies>"

# SWUPDATE_IMAGES: list of images that will be part of the compound image
# the list can have any binaries - images must be in the DEPLOY directory
SWUPDATE_IMAGES = "core-image \

<kernel, dtb, additional images,...>
"

# Images can have multiple formats - define which image must be
# taken to be put in the compound image
SWUPDATE_IMAGES_FSTYPES[core-image] = ".ubifs"


Last one is to select the image in case we have multiple formats.

If I can explain the usage here, I will try to put it in the
documentation somewhere."

Last sentence is still valid. I plan also to add an example for the
beaglebone, when I get enough time to do it.

> What I have now is a custom image recipe where I added this to the
> bottom of the file:
>
> SRC_URI += "file://sw-description" # my sw-description file is in
> <recipedir>/files/sw-description

This is ok.

> SWUPDATE_IMAGES = "${PN}"

I do not understand. ${PN} contains the name of the package, but in this
case there is no package - it is an image as core-image-*.

In SWUPDATE_IMAGES you should put the list of deployed images that you
want to be part of the compound image. This is an example I did to test
with beaglebone, I do not know if it works anymore - but what I use in
my projects is very similar:


DESCRIPTION = "Example Compound image for beaglebone "
SECTION = ""

# Note: sw-description is mandatory
SRC_URI = "file://sw-description \
"
inherit swupdate

LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \

file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

# IMAGE_DEPENDS: list of Yocto images that contains a root filesystem
# it will be ensured they are built before creating swupdate image
IMAGE_DEPENDS = ""

# SWUPDATE_IMAGES: list of images that will be part of the compound image
# the list can have any binaries - images must be in the DEPLOY directory
SWUPDATE_IMAGES = " \
core-image-full-cmdline \
"

# Images can have multiple formats - define which image must be
# taken to be put in the compound image
SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ext3"

COMPATIBLE = "beaglebone"


> SWUPDATE_IMAGES_FSTYPES = "ext4"

See my example. You can select the format for each single image.

> #cp somehow/get/the/path/to/sw-description ${WORKDIR}/sw-description
> inherit swupdate
>
> Question 1:
> I guess this is a generic OpenEmbedded question, but I couldn't figure
> out how to install sw-description into ${WORKDIR}, like
> swupdate.bbclass expects. Well, at least without some do_*
> prepend/append tricks, AFAIK.

No, you do not need it. bitbake searches in directory with the same name
of the package. For example, I named the recipe I showed here
"recipes-extended/images/bbb-swu-image.bb", and sw-description is put
into recipes-extended/images/bbb-swu-image/beaglebone/sw-description

>
> Question 2:
> swupdate.bbclass copies ${WORKDIR}/sw-description to
> ${S}/sw-description.

Yes.

> If I'm supposed to manually copy sw-description
> to ${WORKDIR}, I might as well copy it to ${S} directly. Hence I feel
> I've missed something essential here.

You are not supposed to do something manually. The build process should
do it for you automatically. If not, well, we can use a shell script...

And if not, it means there is a bug to be fixed.

> Question 3:
> When running "bitbake -c listtasks myimage", I see the "do_swuimage"
> task. I can run "bitbake -c swuimage myimage". Is this the intended
> use case? I expected "bitbake myimage" to automatically do the
> swuimage task, but it doesn't. Again, I must be missing something here
> :-)

One issue is that you have an empty list for subimages to be part of the
compuond image. I am expecting something like:

SWUPDATE_IMAGES = "your-root-fs-image \
some-other-results-in-tmp-deploy \
uImage"

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

[Bjørn Forsman]

On 13 November 2015 at 14:37, Stefano Babic <sba...@denx.de> wrote:
> Hi Bjorn,
>
> On 13/11/2015 14:18, Bjørn Forsman wrote:
>> Hi Stefano,
>>
>> Do you have a small example on how to use the swupdate.bbclass? I've
>> played around with it for a while now, but I still don't grok it. (And
>> I didn't find any documentation.)
>>
>
> I have already tried to explain this in a previous thread - it looks
> like I was not able to be very clear.

I missed that thread, sorry. Thanks for the quick and detailed reply!
(I'll re-read it now and see if I can get my recipe to work.)

Best regards,
Bjørn Forsman

[Bjørn Forsman]

Hi Stefano,

Now I have something that works!

I think my biggest mistake was trying to use a single recipe for both
my regular image _and_ the .swu image. (I guess I didn't communicate
that well in the previous post.)

Now I have these two files:

### file: myimage.bb
... regular image recipe stuff

### file: myimage-swu.bb
SUMMARY = "My compound swupdate image (*.swu)."
LICENSE = "MIT"

SRC_URI = "file://sw-description"
inherit swupdate

IMAGE_DEPENDS = "myimage"
SWUPDATE_IMAGES = "myimage"
SWUPDATE_IMAGES_FSTYPES[myimage] = ".ext4"

Thanks again!

Best regards,
Bjørn Forsman