Looking fo rexample of using `meta-swupdate` for x86-64/GRUB platform

[Dmitri Toubelis]

Hi,

I'm trying get hang of the swupdate and ae if I can use it for our projects. We build images for our IoT devices for variety of different platforms and we need something that can work on all of them.

1. I attempted to incorporate SWupdate in our x86-64/GRUB based image (this is our reference image that we can easily test in VM) and hit a roadblock almost right away - it seems that meta-swupdate demands `u-boot-fw-utils` which are not applicable to the target platform. This is the error:

ERROR: Nothing PROVIDES 'u-boot-fw-utils' (but /srv/yocto/yocto-morty/meta-swupdate/recipes-support/swupdate/swupdate_2017.01.bb DEPENDS on or otherwise requires it)

ERROR: u-boot-fw-utils was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the intel-corei7-64 machine configuration.

ERROR: Required build target 'swupdate' has no buildable providers.

Missing or unbuildable dependency chain was: ['swupdate', 'u-boot-fw-utils']

2. My second attempt was to create .bbappend file and overwrite `defconfig` file with one generated by `make menuconfig` but it this didn't help at all. It looks like the defconfig file is taken not from ${WORKDIR} but directly from recipe, so I could not find any way of overriding it short of patching project files.

So, right now I'm scratching my head and I would like to ask the following:

1. What is the recommended way to go about swupdate recipe customizations (I found examples for raspberry-pi but bit for x86-64/grub)

2. Could anyone share an example of a project that uses swupdate for x86/GRUB platform.

Regards,

-Dmitri

[Stefano Babic]

Hi Dmitri,

On 26/01/2018 17:28, Dmitri Toubelis wrote:
> Hi,
>
> I'm trying get hang of the swupdate and ae if I can use it for our
> projects. We build images for our IoT devices for variety of different
> platforms and we need something that can work on all of them.
>

ok

> 1. I attempted to incorporate SWupdate in our x86-64/GRUB based image
> (this is our reference image that we can easily test in VM) and hit a
> roadblock almost right away - it seems that meta-swupdate demands
> `u-boot-fw-utils` which are not applicable to the target platform. This
> is the error:

It requires u-boot-fw-utils is CONFIG_UBOOT is set

>
> ERROR: Nothing PROVIDES 'u-boot-fw-utils' (but
> /srv/yocto/yocto-morty/meta-swupdate/recipes-support/swupdate/swupdate_2017.01.bb
> DEPENDS on or otherwise requires it)
> ERROR: u-boot-fw-utils was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG
> must be set in the intel-corei7-64 machine configuration.
> ERROR: Required build target 'swupdate' has no buildable providers.
> Missing or unbuildable dependency chain was: ['swupdate', 'u-boot-fw-utils']

You are also building an older version of SWUpdate, I think dependency
with bootloader were fixed in later meta-swupdate. u-boot-fw-utils is
just required if your target has set CONFIG_UBOOT.

>
> 2. My second attempt was to create .bbappend file and overwrite
> `defconfig`

You *need* this.

>file with one generated by `make menuconfig` but it this
> didn't help at all. It looks like the defconfig file is taken not from
> ${WORKDIR} but directly from recipe, so I could not find any way of
> overriding it short of patching project files.

This is not true - in meta-swupdate-boards, there are examples for board
specific defconfig (raspberry and bbb).

You should have a bug somewhere.

>
> So, right now I'm scratching my head and I would like to ask the following:
>
> 1. What is the recommended way to go about swupdate recipe
> customizations (I found examples for raspberry-pi but bit for x86-64/grub)

I do not know if this helps, but I can tell you what I do for a custom
project:

- I add swupdate_%.bbappend that adds at least defconfig and maybe the
startup script if I need to start it in a different way.
- I add recipes for the SWU images

True, there is no example for x86-grub. Nevertheless, it works in this
configuration, too.

>
> 2. Could anyone share an example of a project that uses swupdate for
> x86/GRUB platform.

I have not such as example that I am allowed to share, sorry.

Anyway, it seems to me that it is enough that you set
CONFIG_BOOTLOADER_GRUB in your defconfig (you have to find why your
custom defconfig is not taken first). I would also suggest you use
current development instead of older versions.

Current recipe (recipes-support/swupdate/swupdate.inc) in master contains:

if 'CONFIG_UBOOT=y\n' in features:
depends = d.getVar('DEPENDS', False)
d.setVar('DEPENDS', depends + ' u-boot-fw-utils')

if CONFIG_UBOOT is not set, no u-boot-fw-utils is required.

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

[Dmitri Toubelis]

Hi Stefano,

Thank you for quick reply. I was using `morty` branch  of  `meta-swupdate` since this would be consistent with version of `bitbake`. Now I've switched to `master` and this particular problem went away. However, now I'm getting this:

ERROR: /srv/yocto/yocto-morty/meta-swupdate/recipes-extended/images/swupdate-image.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'ext4.gz.u-boot' - possibly invalid type name or missing support class

ERROR: Failed to parse recipe: /srv/yocto/yocto-morty/meta-swupdate/recipes-extended/images/swupdate-image.bb

It looks like there are new image types defined somewhere in this layer but they explicitly referring to `u-boot` and something is not working still. Would you have any ideas?

Regards,

-Dmitri

[Stefano Babic]

Hi Dmitri,

On 26/01/2018 21:37, Dmitri Toubelis wrote:
> Hi Stefano,
>
> Thank you for quick reply. I was using `morty` branch  of 
> `meta-swupdate` since this would be consistent with version of
> `bitbake`. Now I've switched to `master` and this particular problem
> went away. However, now I'm getting this:
>
> ERROR:
> /srv/yocto/yocto-morty/meta-swupdate/recipes-extended/images/swupdate-image.bb:
> No IMAGE_CMD defined for IMAGE_FSTYPES entry 'ext4.gz.u-boot' - possibly
> invalid type name or missing support class
> ERROR: Failed to parse recipe:
> /srv/yocto/yocto-morty/meta-swupdate/recipes-extended/images/swupdate-image.bb
>
> It looks like there are new image types defined somewhere in this layer
> but they explicitly referring to `u-boot` and something is not working
> still. Would you have any ideas?

Sure. You cannot mix Yocto version of the layers. -master in
meta-swupdate is supposed to work witk -master in poky, and so on.

Betwwen -pyro and -rocke, the u-boot class was merged in the image class
(in poky) and it is not inherited again. But in morty, the u-boot image
type is still in a separate class, and this generates this error.

Best regards,
Stefano Babic

>
> Regards,
> -Dmitri
>
>
> On Friday, January 26, 2018 at 11:28:32 AM UTC-5, Dmitri Toubelis wrote:
>
> Hi,
>
> I'm trying get hang of the swupdate and ae if I can use it for our
> projects. We build images for our IoT devices for variety of
> different platforms and we need something that can work on all of them.
>
> 1. I attempted to incorporate SWupdate in our x86-64/GRUB based
> image (this is our reference image that we can easily test in VM)
> and hit a roadblock almost right away - it seems that meta-swupdate
> demands `u-boot-fw-utils` which are not applicable to the target
> platform. This is the error:
>
> ERROR: Nothing PROVIDES 'u-boot-fw-utils' (but
> /srv/yocto/yocto-morty/meta-swupdate/recipes-support/swupdate/swupdate_2017.01.bb

> <http://swupdate_2017.01.bb> DEPENDS on or otherwise requires it)

> ERROR: u-boot-fw-utils was skipped: Either UBOOT_MACHINE or
> UBOOT_CONFIG must be set in the intel-corei7-64 machine configuration.
> ERROR: Required build target 'swupdate' has no buildable providers.
> Missing or unbuildable dependency chain was: ['swupdate',
> 'u-boot-fw-utils']
>
> 2. My second attempt was to create .bbappend file and overwrite
> `defconfig` file with one generated by `make menuconfig` but it this
> didn't help at all. It looks like the defconfig file is taken not
> from ${WORKDIR} but directly from recipe, so I could not find any
> way of overriding it short of patching project files.
>
> So, right now I'm scratching my head and I would like to ask the
> following:
>
> 1. What is the recommended way to go about swupdate recipe
> customizations (I found examples for raspberry-pi but bit for
> x86-64/grub)
>
> 2. Could anyone share an example of a project that uses swupdate for
> x86/GRUB platform.
>
> Regards,
> -Dmitri
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To post to this group, send email to swup...@googlegroups.com
> <mailto:swup...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.