Re: [yocto] update mechanisms
On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote: On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote: > Hi Patrick, > > On 30/11/2016 15:59, Patrick Ohly wrote: > > I've started a Wiki page > > https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the > > moment, but might as well be mentioned already now. > > I have seen Mariano added an entry for SWUpdate, too, thanks - I would > like to edit for better explanation on some parts. Should I try to edit > directly the page or is it better to discuss it here ? Use your own judgment. If its uncontroversial, the feel free to edit the page directly, otherwise let's discuss it here. If feel that putting information directly into the table is too limiting (it should be brief), then feel free to start a complete section about SWUpdate. I'll do the same for swupd. Editing the sections should be possible without conflicts, we just have to be more careful about editing the table concurrently. I updated the Mender part of the wiki now that the stable version Mender 1.0 is released. These changes should not be controversial, but let me know if you disagree. We are planning to keep the Mender section up-to-date as we release new versions, as I think this is what you expect. Are there any plans for next steps or is the wiki the "final state" in terms of integrating OTA updates in Yocto/OE? -- Eystein -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project SDK Quickstart Guide
Hi, The Yocto Project Software Development Kit (SDK) can save us a lot of time when developing embedded applications. To make it easier to approach we have published a guide for using the SDK with simple example applications. It should take about 30 minutes to follow and give a basic understanding of the SDK's use-cases. You can find the SDK quickstart here: https://mender.io/resources/yocto-sdk-quickstart Please let me know if have comments or questions. -- Eystein Stenberg Mender.io -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky master issue with kernel and gcc version
On 01/06/16 19:53, Bruce Ashfield wrote: On 2016-06-01 10:48 PM, Eystein Måløy Stenberg wrote: Hi, I am trying to build a vexpress-qemu machine targe from poky's master branch, but I get this error compiling the kernel: | /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/compiler-gcc.h:121:30: fatal error: linux/compiler-gcc6.h: No such file or directory Apparently it is picking gcc 6.1 and kernel 4.1.24, which do not play well together. The best approach is probably to use kernel 4.2 or newer. Is there a bug filed for this? I would think this is affecting quite a lot of people as I am not doing any special configuration for my build. We've already fixed all the gcc6.x builds for the supported machines in linux-yocto 4.1/4.4. What kernel tree is that building ? upstream ? linux-yocto ? And if linux-yocto, what branch ? It is building linux-yocto 4.1. I have attached the compilation log, in case that helps. What I am doing is simply building a vexpress-qemu machine with poky's master, so it should be quite straightforward to reproduce. In particular, I am following our projects guide for creating a Mender build at https://github.com/mendersoftware/meta-mender/blob/master/README.md, but I don't think it reaches the Mender-specific layers. Thanks for the help and let me know if there's anything else you need. Bruce Thank you. -- Eystein DEBUG: Executing shell function do_compile NOTE: make -j 4 zImage CC=arm-poky-linux-gnueabi-gcc -fuse-ld=bfd LD=arm-poky-linux-gnueabi-ld.bfd LOADADDR=0x6080 CHK include/config/kernel.release GEN ./Makefile CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h Using /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source as source for kernel HOSTCC scripts/conmakehash HOSTCC scripts/sortextable MKELF scripts/mod/elfconfig.h CC scripts/mod/devicetable-offsets.s HOSTCC scripts/mod/sumversion.o In file included from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/compiler.h:54:0, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/uapi/linux/stddef.h:1, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/stddef.h:4, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/uapi/linux/posix_types.h:4, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/uapi/linux/types.h:13, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/types.h:5, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/mod_devicetable.h:11, from /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/scripts/mod/devicetable-offsets.c:2: /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/compiler-gcc.h:121:30: fatal error: linux/compiler-gcc6.h: No such file or directory #include gcc_header(__GNUC__) ^ compilation terminated. make[4]: *** [scripts/mod/devicetable-offsets.s] Error 1 make[4]: *** Waiting for unfinished jobs make[3]: *** [scripts/mod] Error 2 make[2]: *** [scripts] Error 2 make[1]: *** [sub-make] Error 2 make: *** [__sub-make] Error 2 ERROR: oe_runmake failed ERROR: Function failed: do_compile (log file is located at /home/yocto/poky/build/tmp/work/vexpress_qemu-poky-linux-gnueabi/linux-yocto/4.1.24+gitAUTOINC+46bb64d605_86093f78f6-r0/temp/log.do_compile.14419) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] poky master issue with kernel and gcc version
Hi, I am trying to build a vexpress-qemu machine targe from poky's master branch, but I get this error compiling the kernel: | /home/yocto/poky/build/tmp/work-shared/vexpress-qemu/kernel-source/include/linux/compiler-gcc.h:121:30: fatal error: linux/compiler-gcc6.h: No such file or directory Apparently it is picking gcc 6.1 and kernel 4.1.24, which do not play well together. The best approach is probably to use kernel 4.2 or newer. Is there a bug filed for this? I would think this is affecting quite a lot of people as I am not doing any special configuration for my build. Thank you. -- Eystein Stenberg Mender.io -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Run-time discovery of machine for image compatibility check
Virgil, Thank you for pointing this out, I've updated the post to override the variable instead! On 11/11/15 08:50, Smith, Virgil wrote: > The recommendations on your blog suggest modifying image-buildinfo.bbclass to > change IMAGE_BUILDINFO_VARS. > You /should/ be able to avoid this by simply adding something like > > IMAGE_BUILDINFO_VARS_append = " MACHINE DEVICE_MODEL DEVICE_TYPE" > or > IMAGE_BUILDINFO_VARS = "DISTRO DISTRO_VERSION MACHINE DEVICE_MODEL > DEVICE_TYPE" > to local.conf. > > The first version should extend the value whereas the second should > completely replace it. > This should work because image-buildinfo.bbclass used the ?= operator to set > the variable. > For the same reason you should NOT use += to extend the variable, but should > use _append instead. > > This should be easier to maintain when updating your 'version of yocto'. > > > NOTE: In /extreme/ summary this would mean > > Add the following to local.conf >INHERIT += "image-buildinfo" >DEVICE_MODEL = "some-extra-identifying-details" >IMAGE_BUILDINFO_VARS_append = " MACHINE DEVICE_MODEL" > > to get a /etc/build file in your resulting image with information similar to > the build configuration summary bitbake outputs during a build. > > > >> -Original Message- >> From: yocto-boun...@yoctoproject.org [mailto:yocto- >> boun...@yoctoproject.org] On Behalf Of Eystein Måløy Stenberg >> Sent: Tuesday, November 10, 2015 8:29 PM >> To: Khem Raj >> Cc: yocto@yoctoproject.org >> Subject: Re: [yocto] Run-time discovery of machine for image compatibility >> check >> >> Thanks to everyone on the input on this issue. I eventually solved it by >> using an >> image feature called "buildinfo". >> >> In case someone come across a similar need in the future I've created these >> two >> blog post to advertise buildinfo it a bit more and show how to use it: >> >> * https://www.mender.io/blog/build-info-yocto-1 >> * https://www.mender.io/blog/build-info-yocto-2 >> >> On 30/09/15 17:45, Khem Raj wrote: >>> >>>> On Sep 30, 2015, at 2:31 PM, Eystein Måløy Stenberg <eyst...@mender.io> >> wrote: >>>> >>>> Hi, >>>> >>>> Before starting a bitbake build, we input the MACHINE variable in >>>> local.conf (e.g. MACHINE ?= beaglebone). >>>> >>>> Is there a way to detect this variable at run-time? I.e. if I have >>>> built the image, written it to a device, and I'm now logged in to it. >>> >>> There is no standard bill of materials that you will find on images. >>> Everyone produces it per own needs. The reason is that we do not have >>> a one OTA mechanism recommended or preferred in OpenEmbedded or >>> maintained by yocto project. May be this could be a thing to consider >>> come future right now, there were other big fish to fry around workflow. OTA >> firmware upgrade, could be big thing for next release or there after. >>> >>> I don’t have a better answer for you at the moment. You have to work >>> with device firmware manufacturer and see if they have put some image info >> into the image in some form. >>> >>>> >>>> The reason I want this is that I'm working on a project to deploy >>>> image updates (remotely), and I only want to write the image if the >>>> device is compatible with the image file. So I need to know both the >>>> hardware/board type and what the image target is (assuming this is >>>> the MACHINE variable alone). Then I will only write the image if they >>>> are the same. >>>> >>>> Also, do you think using the MACHINE variable is the right approach >>>> for this problem? Maybe someone has had a similar problem? >>>> >>>> I'm new to Yocto, sorry if I'm asking something obvious (but I could >>>> not find an answer in the docs). >>>> >>>> Thanks! >>>> >>>> -- >>>> >>>> Eystein >>>> -- >>>> ___ >>>> yocto mailing list >>>> yocto@yoctoproject.org >>>> https://lists.yoctoproject.org/listinfo/yocto >>> >> >> -- >> >> Eystein >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > Notice to recipient: This email is meant for only the intended recipient of > the transmission, and may be a communication privileged by law, subject to > export control restrictions or that otherwise contains proprietary > information. If you receive this email by mistake, please notify us > immediately by replying to this message and then destroy it and do not > review, disclose, copy or distribute it. Thank you in advance for your > cooperation. > -- Eystein -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Run-time discovery of machine for image compatibility check
Thanks to everyone on the input on this issue. I eventually solved it by using an image feature called "buildinfo". In case someone come across a similar need in the future I've created these two blog post to advertise buildinfo it a bit more and show how to use it: * https://www.mender.io/blog/build-info-yocto-1 * https://www.mender.io/blog/build-info-yocto-2 On 30/09/15 17:45, Khem Raj wrote: > >> On Sep 30, 2015, at 2:31 PM, Eystein Måløy Stenberg <eyst...@mender.io> >> wrote: >> >> Hi, >> >> Before starting a bitbake build, we input the MACHINE variable in >> local.conf (e.g. MACHINE ?= beaglebone). >> >> Is there a way to detect this variable at run-time? I.e. if I have built >> the image, written it to a device, and I'm now logged in to it. > > There is no standard bill of materials that you will find on images. Everyone > produces it > per own needs. The reason is that we do not have a one OTA mechanism > recommended or preferred > in OpenEmbedded or maintained by yocto project. May be this could be a thing > to consider come future > right now, there were other big fish to fry around workflow. OTA firmware > upgrade, could be big thing for next release > or there after. > > I don’t have a better answer for you at the moment. You have to work with > device firmware manufacturer > and see if they have put some image info into the image in some form. > >> >> The reason I want this is that I'm working on a project to deploy image >> updates (remotely), and I only want to write the image if the device is >> compatible with the image file. So I need to know both the >> hardware/board type and what the image target is (assuming this is the >> MACHINE variable alone). Then I will only write the image if they are >> the same. >> >> Also, do you think using the MACHINE variable is the right approach for >> this problem? Maybe someone has had a similar problem? >> >> I'm new to Yocto, sorry if I'm asking something obvious (but I could not >> find an answer in the docs). >> >> Thanks! >> >> -- >> >> Eystein >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > -- Eystein -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Run-time discovery of machine for image compatibility check
Hi, Before starting a bitbake build, we input the MACHINE variable in local.conf (e.g. MACHINE ?= beaglebone). Is there a way to detect this variable at run-time? I.e. if I have built the image, written it to a device, and I'm now logged in to it. The reason I want this is that I'm working on a project to deploy image updates (remotely), and I only want to write the image if the device is compatible with the image file. So I need to know both the hardware/board type and what the image target is (assuming this is the MACHINE variable alone). Then I will only write the image if they are the same. Also, do you think using the MACHINE variable is the right approach for this problem? Maybe someone has had a similar problem? I'm new to Yocto, sorry if I'm asking something obvious (but I could not find an answer in the docs). Thanks! -- Eystein -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Test software update deployment prototype
Hi, I'm working on a project for deploying software updates, e.g. Yocto images, to field devices. Please let me know if you'd be interested in testing a prototype. I'll provide more context if you email me directly (don't want to spam this list). Thank you. -- Eystein Stenberg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
