[meta-swupdate] build fails under thud

[meta-swupdate] build fails under thud

[Moritz Porst]

[-- Attachment #1: Type: text/html, Size: 1942 bytes --]

Re: [meta-swupdate] build fails under thud

[Matthias Schoepfer]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Hi Moritz!

You need to configure swupdate kind of like the linux kernel with 
menuconfig:

bitbake -c menuconfig swupdate

do not forget to copy your config then into an bbappend to swupdate 
(defconfig).

Hope that helps,

Regards,

    Matthias

On 5/27/19 3:26 PM, Moritz Porst wrote:
> Hello
> I want to create an update mechanism for our embedded system. I chose 
> swupdate because it is very well documented and seems flexible.
> When trying to build swupdate-image it fails with several undefined 
> references, just a few as example:
> """
> /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: 
> bootloader/lib.a(uboot.o): in function `bootloader_env_set':
> | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to 
> `fw_env_open'
> | 
> /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld: 
> uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to 
> `fw_env_write'
> """
> I see lots of "uboot" in the trace, but to my understanding swupdate 
> should also work with grub which I enabled using:
> EFI_PROVIDER = "grub-efi"    (First tried to use 
> PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with EFI 
> booting)
> When I want to enable "uboot" this way, bitbake tells me there is no 
> uboot.
> I know there is also the option of writing my own init scripts but 
> this would be just reinventing the wheel (given there is an swupdate 
> available) and probably more error-prone than a grown update tool. 
> Thus I would like to get swupdate to work.
> Any ideas ?
> Best regards
> Moritz
>

[-- Attachment #2: Type: text/html, Size: 3045 bytes --]

Re: [meta-swupdate] build fails under thud

[Moritz Porst]

[-- Attachment #1: Type: text/html, Size: 5044 bytes --]

Re: [meta-swupdate] build fails under thud

[Matthias Schoepfer]

[-- Attachment #1: Type: text/plain, Size: 4614 bytes --]

Hi Moritz,

I will try to answer what I can inline:

On 5/27/19 5:05 PM, Moritz Porst wrote:
> Hi Matthias
> Thank you very much for your help, this is not mentioned in the 
> official repository.
> I tried what you said. It enables me (even without .bbappend) to build 
> the swupdate-image.
> Now for the defconfig. I did it with a .bbappend the way the yocto 
> documentation suggests (FILESEXTRAPATHS and SRC_URI) but which recipe 
> do I need to append to? I thought just choose swupdate_git.bb, then 
> swupdate_2018.11.bb. I always receive the following rootfs file:
you can either bbappend the _2018.11 or make a swupdate_%.bbappend, that 
is then valid for both _git and _2018.11 if you happen to use the _git 
version.
> swupdate-image-ccns5.ext4.gz.u-boot   (Clearly still uboot, I don't 
> know why it managed to build though)
> Also I get the following warning on invoking bitbake for swupdate-image:
> WARNING: 
> /opt/thudPoky/meta-swupdate/recipes-support/swupdate/swupdate_2018.11.bb.do_compile 
> is tainted from a forced run
This is because you bitbake -c menuconfig swupdate. If you clean the 
build (bitbake -c cleansstate swupdate), this should disappear. Then you 
can check, if your bbappend gets picked up correctly.
> Finally I always end up with microcode.cpio in my /boot directory 
> which comes from meta-intel. I guess swupdate would replace the 
> initrd/initramfs ?
> I put the following lines in my image description:
> INITRAMFS_IMAGE = "swupdate-image-ccns5"
> INITRAMFS_IMAGE_BUNDLE = "1"
> Shouldn't they cause the swupdate-image to be bundled into the kernel, 
> thus that if I build my image that I end up with the swupdate 
> initramfs in my /boot directory ?

Errr.... you want to *add* swupdate to an image recipe. It is not an 
image by itself. Well, I guess, there is a rescue image within swupdate, 
but that is a different story and I have no experience with it. There 
are ways to add packages to an image, for example through 
IMAGE_INSTALL_append = " swupdate " in local.conf

https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#usingpoky-extend-customimage-localconf

> Sorry for all the questions and thanks in advance !
> Best regards
> Moritz
> *Gesendet:* Montag, 27. Mai 2019 um 15:31 Uhr
> *Von:* "Matthias Schoepfer" <matthias.schoepfer@googlemail.com>
> *An:* yocto@yoctoproject.org
> *Betreff:* Re: [yocto] [meta-swupdate] build fails under thud
>
> Hi Moritz!
>
> You need to configure swupdate kind of like the linux kernel with 
> menuconfig:
>
> bitbake -c menuconfig swupdate
>
> do not forget to copy your config then into an bbappend to swupdate 
> (defconfig).
>
> Hope that helps,
>
> Regards,
>
>    Matthias
>
> On 5/27/19 3:26 PM, Moritz Porst wrote:
>
>     Hello
>     I want to create an update mechanism for our embedded system. I
>     chose swupdate because it is very well documented and seems flexible.
>     When trying to build swupdate-image it fails with several
>     undefined references, just a few as example:
>     """
>     /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld:
>     bootloader/lib.a(uboot.o): in function `bootloader_env_set':
>     | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to
>     `fw_env_open'
>     |
>     /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld:
>     uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to
>     `fw_env_write'
>     """
>     I see lots of "uboot" in the trace, but to my understanding
>     swupdate should also work with grub which I enabled using:
>     EFI_PROVIDER = "grub-efi"    (First tried to use
>     PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with
>     EFI booting)
>     When I want to enable "uboot" this way, bitbake tells me there is
>     no uboot.
>     I know there is also the option of writing my own init scripts but
>     this would be just reinventing the wheel (given there is an
>     swupdate available) and probably more error-prone than a grown
>     update tool. Thus I would like to get swupdate to work.
>     Any ideas ?
>     Best regards
>     Moritz
>
> -- _______________________________________________ yocto mailing list 
> yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 9390 bytes --]

Re: [meta-swupdate] build fails under thud

[Moritz Porst]

[-- Attachment #1: Type: text/plain, Size: 5154 bytes --]

Hello Matthias,

Thank you, your help is much appreciated. Seems I have misunderstood how
to add swupdate to my image. However the swupdate package somehow has to
put an initramfs in place since to my understanding it is also possible
to do updates without 2 rootfs available which would require an update
through the initramfs.

Anyway, thank you again ! This should make it work

On 27/05/2019 18:59, Matthias Schoepfer wrote:
>
> Hi Moritz,
>
> I will try to answer what I can inline:
>
> On 5/27/19 5:05 PM, Moritz Porst wrote:
>> Hi Matthias
>> Thank you very much for your help, this is not mentioned in the
>> official repository.
>> I tried what you said. It enables me (even without .bbappend) to
>> build the swupdate-image.
>> Now for the defconfig. I did it with a .bbappend the way the yocto
>> documentation suggests (FILESEXTRAPATHS and SRC_URI) but which recipe
>> do I need to append to? I thought just choose swupdate_git.bb, then
>> swupdate_2018.11.bb. I always receive the following rootfs file:
> you can either bbappend the _2018.11 or make a swupdate_%.bbappend,
> that is then valid for both _git and _2018.11 if you happen to use the
> _git version.
>> swupdate-image-ccns5.ext4.gz.u-boot   (Clearly still uboot, I don't
>> know why it managed to build though)
>> Also I get the following warning on invoking bitbake for swupdate-image:
>> WARNING:
>> /opt/thudPoky/meta-swupdate/recipes-support/swupdate/swupdate_2018.11.bb.do_compile
>> is tainted from a forced run
> This is because you bitbake -c menuconfig swupdate. If you clean the
> build (bitbake -c cleansstate swupdate), this should disappear. Then
> you can check, if your bbappend gets picked up correctly.
>> Finally I always end up with microcode.cpio in my /boot directory
>> which comes from meta-intel. I guess swupdate would replace the
>> initrd/initramfs ?
>> I put the following lines in my image description:
>> INITRAMFS_IMAGE = "swupdate-image-ccns5"
>> INITRAMFS_IMAGE_BUNDLE = "1"
>> Shouldn't they cause the swupdate-image to be bundled into the
>> kernel, thus that if I build my image that I end up with the swupdate
>> initramfs in my /boot directory ?
>
> Errr.... you want to *add* swupdate to an image recipe. It is not an
> image by itself. Well, I guess, there is a rescue image within
> swupdate, but that is a different story and I have no experience with
> it. There are ways to add packages to an image, for example through
> IMAGE_INSTALL_append = " swupdate " in local.conf
>
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#usingpoky-extend-customimage-localconf
>
>> Sorry for all the questions and thanks in advance !
>> Best regards
>> Moritz
>> *Gesendet:* Montag, 27. Mai 2019 um 15:31 Uhr
>> *Von:* "Matthias Schoepfer" <matthias.schoepfer@googlemail.com>
>> *An:* yocto@yoctoproject.org
>> *Betreff:* Re: [yocto] [meta-swupdate] build fails under thud
>>
>> Hi Moritz!
>>
>> You need to configure swupdate kind of like the linux kernel with
>> menuconfig:
>>
>> bitbake -c menuconfig swupdate
>>
>> do not forget to copy your config then into an bbappend to swupdate
>> (defconfig).
>>
>> Hope that helps,
>>
>> Regards,
>>
>>    Matthias
>>
>> On 5/27/19 3:26 PM, Moritz Porst wrote:
>>
>>     Hello
>>     I want to create an update mechanism for our embedded system. I
>>     chose swupdate because it is very well documented and seems flexible.
>>     When trying to build swupdate-image it fails with several
>>     undefined references, just a few as example:
>>     """
>>     /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld:
>>     bootloader/lib.a(uboot.o): in function `bootloader_env_set':
>>     | uboot.c:(.text.bootloader_env_set+0x40): undefined reference to
>>     `fw_env_open'
>>     |
>>     /opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld:
>>     uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to
>>     `fw_env_write'
>>     """
>>     I see lots of "uboot" in the trace, but to my understanding
>>     swupdate should also work with grub which I enabled using:
>>     EFI_PROVIDER = "grub-efi"    (First tried to use
>>     PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with
>>     EFI booting)
>>     When I want to enable "uboot" this way, bitbake tells me there is
>>     no uboot.
>>     I know there is also the option of writing my own init scripts
>>     but this would be just reinventing the wheel (given there is an
>>     swupdate available) and probably more error-prone than a grown
>>     update tool. Thus I would like to get swupdate to work.
>>     Any ideas ?
>>     Best regards
>>     Moritz
>>
>> -- _______________________________________________ yocto mailing list
>> yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
>>
>

[-- Attachment #2: Type: text/html, Size: 10913 bytes --]