[yocto] Run-time discovery of machine for image compatibility check

[Smith, Virgil]

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-bounces at yoctoproject.org [mailto:yocto-
> bounces at yoctoproject.org] On Behalf Of Eystein Måløy Stenberg
> Sent: Tuesday, November 10, 2015 8:29 PM
> To: Khem Raj
> Cc: yocto at 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 <eystein at 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 at yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
>
> --
>
> Eystein
> --
> _______________________________________________
> yocto mailing list
> yocto at 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.