Arria10 Mender Integration

Gary Newman

unread,

Aug 30, 2018, 5:59:40 AM8/30/18

to Mender List mender.io

Hi All,

I am a first time Mender User & I'm attempting to integrate Mender onto an Intel Arria10 SOC.

I have a working Yocto build base on u-boot 14.10 & Yocto 2.4 Rocko.

I have been trying to follow the 1.6 documentation on integrating mender with u-boot (sections 3 & 4).

I started out attempting the auto patch, but I found myself getting quite confused on which u-boot-mender.inc I should be getting my u-boot recipe to point at.

As there is no existing Mender layer specific to my board I ended up pointing my recipe at the core u-boot-mender.inc.

# Mender Changes

require /home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-mender.inc

PROVIDES += "u-boot"

RPROVIDES_${PN} += "u-boot"

I'm sure this is probably the wrong thing to do & is probably the route of my problems.

On following the build instructions in section 4 I hit the following errors when I got to the auto patching :-

Build Configuration:

BB_VERSION = "1.36.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING = "universal-4.8"

TARGET_SYS = "arm-poky-linux-gnueabi"

MACHINE = "arria10"

DISTRO = "poky"

DISTRO_VERSION = "2.4.3"

TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa9"

TARGET_FPU = "hard"

Mirza Krak

unread,

Aug 30, 2018, 6:56:07 AM8/30/18

to Mender List mender.io

On Thu, Aug 30, 2018 at 11:59 AM, 'Gary Newman' via Mender List
mender.io <men...@lists.mender.io> wrote:
> Hi All,

Hi Gary,

>
> I am a first time Mender User & I'm attempting to integrate Mender onto an
> Intel Arria10 SOC.

Welcome :).

> I have a working Yocto build base on u-boot 14.10 & Yocto 2.4 Rocko.
>
> I have been trying to follow the 1.6 documentation on integrating mender
> with u-boot (sections 3 & 4).

I would suggest to use the 1.5 documentation if you are working with
Rocko, 1.6 is probably still valid as well but it has some new
features that are not supported on Rock which might lead to confusion.

> I started out attempting the auto patch, but I found myself getting quite
> confused on which u-boot-mender.inc I should be getting my u-boot recipe to
> point at.
>
> As there is no existing Mender layer specific to my board I ended up
> pointing my recipe at the core u-boot-mender.inc.
>
> # Mender Changes
> require
> /home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-mender.inc

Aabove path does point to the correct file.

Though It should be enough to just add

require recipes-bsp/u-boot/u-boot-mender.inc.

Bitbake will figure out which file it is.

> PROVIDES += "u-boot"
> RPROVIDES_${PN} += "u-boot"
>
> I'm sure this is probably the wrong thing to do & is probably the route of
> my problems.
>
> On following the build instructions in section 4 I hit the following errors
> when I got to the auto patching :-

< snip >

> I guess if this is so then I can continue to make the manual u-boot changes
> to my board u-boot recipe.

I would probably go for above. The auto-patching normally works on
newer versions of U-boot which it is also tested against, but would
not expect it to work on 2014.10 U-boot version.

> Any help/pointers would be gratefully received.

I would start from this section [1] and onward. Will be here if there
are any questions along the way :).

This could work as inspiration/reference [2]

[1]. https://docs.mender.io/1.5/devices/integrating-with-u-boot/manual-u-boot-integration#u-boot-features
[2]. https://github.com/mirzak/meta-mender-community/tree/rocko/meta-mender-rockchip/recipes-bsp/u-boot
--
Mirza Krak | Embedded Solutions Architect | https://mender.io

Northern.tech AS | @northerntechHQ

Gary Newman

unread,

Aug 30, 2018, 8:42:56 AM8/30/18

to Mender List mender.io, mirza...@northern.tech

Hi Mirza,

Thanks for the quick reply, most appreciated.

I will switch to the 1.5 instructions as you advise.

The reason I went with u-boot 14.10 is because the Mender document states that "Mender currently recommends U-Boot v2014.07 or newer.".

My only other options appear to be 16.05 & 16.11, are these suitable?

---------------------------------------------------------------------------------------------------------------------

Sorry for the confusion, I was just looking at the rockchip example you sent.

https://github.com/mirzak/meta-mender-community/tree/rocko/meta-mender-rockchip/recipes-bsp/u-boot

I'm assuming that such a specific hardware layer would live in .../poky/meta-mender and get added as a separate build layer in bblayers.conf.

Would this then mean that mender requires zero direct changes to be made to my board uboot layer i.e. .../poky/meta-altera/recipes-bsp/u-boot

(I have been trying to make changes to this layer rather than creating a board specific layer in meta-mender)

---------------------------------------------------------------------------------------------------------------------------

I have tried changing my recipe .../poky/meta-altera/recipes-bsp/u-boot/u-boot-socfpga_v2014.10.bb back to require recipes-bsp/u-boot/u-boot-mender.inc

This now allows my bitbake virtual/bootloader to complete.

But on running bitbake core-image-minimal I am now getting the following error:

ERROR: Task do_patch in /home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb depends upon non-existent task do_mender_tar_src in /home/gnewman/yocto/mender_yocto/poky/meta-altera/recipes-bsp/u-boot/u-boot-socfpga_v2014.10.bb

ERROR: Command execution failed: 1

I'm guessing bitbake can't resolve recipes-bsp/u-boot/u-boot-mender.inc.

Is this because it assumes it's already in meta-mender?

Regards

Gary

Mirza Krak

unread,

Aug 30, 2018, 10:41:37 AM8/30/18

to Gary Newman, Mender List mender.io

On Thu, Aug 30, 2018 at 2:42 PM, Gary Newman <gnewma...@googlemail.com> wrote:
> Hi Mirza,
>
> Thanks for the quick reply, most appreciated.
>
> I will switch to the 1.5 instructions as you advise.
>
> The reason I went with u-boot 14.10 is because the Mender document states
> that "Mender currently recommends U-Boot v2014.07 or newer.".

Yeah that is a bit confusing, it should say that minimum requirement is 2014.07.

> My only other options appear to be 16.05 & 16.11, are these suitable?

Newer is better, so if you are able to use 16.11, I would use that.

> ---------------------------------------------------------------------------------------------------------------------
>
> Sorry for the confusion, I was just looking at the rockchip example you
> sent.
> https://github.com/mirzak/meta-mender-community/tree/rocko/meta-mender-rockchip/recipes-bsp/u-boot
>
> I'm assuming that such a specific hardware layer would live in
> .../poky/meta-mender and get added as a separate build layer in
> bblayers.conf.
>
> Would this then mean that mender requires zero direct changes to be made to
> my board uboot layer i.e. .../poky/meta-altera/recipes-bsp/u-boot
> (I have been trying to make changes to this layer rather than creating a
> board specific layer in meta-mender)

You can make the changes directly in your BSP layer. That is not a problem.

It is simply a matter how you structure your project if you want to separate the changes required for Mender in a separate layer e.g meta-mender-altera

> ---------------------------------------------------------------------------------------------------------------------------
>
> I have tried changing my recipe
> .../poky/meta-altera/recipes-bsp/u-boot/u-boot-socfpga_v2014.10.bb back to
> require recipes-bsp/u-boot/u-boot-mender.inc
>
> This now allows my bitbake virtual/bootloader to complete.
>
> But on running bitbake core-image-minimal I am now getting the following
> error:
>
> ERROR: Task do_patch in
> /home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb
> depends upon non-existent task do_mender_tar_src in
> /home/gnewman/yocto/mender_yocto/poky/meta-altera/recipes-bsp/u-boot/u-boot-socfpga_v2014.10.bb
> ERROR: Command execution failed: 1
>
> I'm guessing bitbake can't resolve recipes-bsp/u-boot/u-boot-mender.inc.
> Is this because it assumes it's already in meta-mender?

Can you paste your local.conf and bblayers.conf

Gary Newman

unread,

Aug 31, 2018, 4:37:09 AM8/31/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Mirza,

------------------------------------------------------------------------------------------------------------------

local.conf :

#

# This file is your local configuration file and is where all local user settings

# are placed. The comments in this file give some guide to the options a new user

# to the system might want to change but pretty much any configuration option can

# be set in this file. More adventurous users can look at local.conf.extended

# which contains other examples of configuration which can be placed in this file

# but new users likely won't need any of them initially.

#

# Lines starting with the '#' character are commented out and in some cases the

# default values are provided as comments to show people example syntax. Enabling

# the option is a question of removing the # character and making any change to the

# variable as required.

#

# Machine Selection

#

# You need to select a specific machine to target the build with. There are a selection

# of emulated machines available which can boot and run in the QEMU emulator:

#

#MACHINE ?= "qemuarm"

#MACHINE ?= "qemuarm64"

#MACHINE ?= "qemumips"

#MACHINE ?= "qemumips64"

#MACHINE ?= "qemuppc"

#MACHINE ?= "qemux86"

#MACHINE ?= "qemux86-64"

#

# There are also the following hardware board target machines included for

# demonstration purposes:

#

#MACHINE ?= "beaglebone"

#MACHINE ?= "genericx86"

#MACHINE ?= "genericx86-64"

#MACHINE ?= "mpc8315e-rdb"

#MACHINE ?= "edgerouter"

#

# This sets the default machine to be qemux86 if no other machine is selected:

#MACHINE ??= "qemux86"

# The name of the disk image and Artifact that will be built.

# This is what the device will report that it is running, and different updates must have different names

# because Mender will skip installation of an Artifact if it is already installed.

MENDER_ARTIFACT_NAME = "release-1"

INHERIT += "mender-full"

# A MACHINE integrated with Mender.

MACHINE = "arria10"

#

# Where to place downloads

#

# During a first build the system will download many different source code tarballs

# from various upstream projects. This can take a while, particularly if your network

# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you

# can preserve this directory to speed up this part of subsequent builds. This directory

# is safe to share between multiple builds on the same machine too.

#

# The default is a downloads directory under TOPDIR which is the build directory.

#

#DL_DIR ?= "${TOPDIR}/downloads"

#

# Where to place shared-state files

#

# BitBake has the capability to accelerate builds based on previously built output.

# This is done using "shared state" files which can be thought of as cache objects

# and this option determines where those files are placed.

#

# You can wipe out TMPDIR leaving this directory intact and the build would regenerate

# from these files if no changes were made to the configuration. If changes were made

# to the configuration, only shared state files where the state was still valid would

# be used (done using checksums).

#

# The default is a sstate-cache directory under TOPDIR.

#

#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

#

# Where to place the build output

#

# This option specifies where the bulk of the building work should be done and

# where BitBake should place its temporary files and output. Keep in mind that

# this includes the extraction and compilation of many applications and the toolchain

# which can use Gigabytes of hard disk space.

#

# The default is a tmp directory under TOPDIR.

#

#TMPDIR = "${TOPDIR}/tmp"

#

# Default policy config

#

# The distribution setting controls which policy settings are used as defaults.

# The default value is fine for general Yocto project use, at least initially.

# Ultimately when creating custom policy, people will likely end up subclassing

# these defaults.

#

DISTRO ?= "poky"

# As an example of a subclass there is a "bleeding" edge policy configuration

# where many versions are set to the absolute latest code from the upstream

# source control systems. This is just mentioned here as an example, its not

# useful to most new users.

# DISTRO ?= "poky-bleeding"

#

# Package Management configuration

#

# This variable lists which packaging formats to enable. Multiple package backends

# can be enabled at once and the first item listed in the variable will be used

# to generate the root filesystems.

# Options are:

# - 'package_deb' for debian style deb files

# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)

# - 'package_rpm' for rpm style packages

# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"

# We default to rpm:

PACKAGE_CLASSES ?= "package_ipk"

#

# SDK target architecture

#

# This variable specifies the architecture to build SDK items for and means

# you can build the SDK packages for architectures other than the machine you are

# running the build on (i.e. building i686 packages on an x86_64 host).

# Supported values are i686 and x86_64

#SDKMACHINE ?= "i686"

#

# Extra image configuration defaults

#

# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated

# images. Some of these options are added to certain image types automatically. The

# variable can contain the following options:

# "dbg-pkgs" - add -dbg packages for all installed packages

# (adds symbol information for debugging/profiling)

# "dev-pkgs" - add -dev packages for all installed packages

# (useful if you want to develop against libs in the image)

# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages

# (useful if you want to run the package test suites)

# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)

# "tools-debug" - add debugging tools (gdb, strace)

# "eclipse-debug" - add Eclipse remote debugging support

# "tools-profile" - add profiling tools (oprofile, lttng, valgrind)

# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)

# "debug-tweaks" - make an image suitable for development

# e.g. ssh root access has a blank password

# There are other application targets that can be used here too, see

# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.

# We default to enabling the debugging tweaks.

EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#

# Additional image features

#

# The following is a list of additional classes to use when building images which

# enable extra features. Some available options which can be included in this variable

# are:

# - 'buildstats' collect build statistics

# - 'image-mklibs' to reduce shared library files size for an image

# - 'image-prelink' in order to prelink the filesystem image

# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink

# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended

USER_CLASSES ?= "buildstats image-mklibs image-prelink"

#

# Runtime testing of images

#

# The build system can test booting virtual machine images under qemu (an emulator)

# after any root filesystems are created and run tests against those images. To

# enable this uncomment this line. See classes/testimage(-auto).bbclass for

# further details.

#TEST_IMAGE = "1"

#

# Interactive shell configuration

#

# Under certain circumstances the system may need input from you and to do this it

# can launch an interactive shell. It needs to do this since the build is

# multithreaded and needs to be able to handle the case where more than one parallel

# process may require the user's attention. The default is iterate over the available

# terminal types to find one that works.

#

# Examples of the occasions this may happen are when resolving patches which cannot

# be applied, to use the devshell or the kernel menuconfig

#

# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none

# Note: currently, Konsole support only works for KDE 3.x due to the way

# newer Konsole versions behave

#OE_TERMINAL = "auto"

# By default disable interactive patch resolution (tasks will just fail instead):

PATCHRESOLVE = "noop"

#

# Disk Space Monitoring during the build

#

# Monitor the disk space during the build. If there is less that 1GB of space or less

# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully

# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort

# of the build. The reason for this is that running completely out of space can corrupt

# files and damages the build in ways which may not be easily recoverable.

# It's necesary to monitor /tmp, if there is no space left the build will fail

# with very exotic errors.

BB_DISKMON_DIRS ??= "\

STOPTASKS,${TMPDIR},1G,100K \

STOPTASKS,${DL_DIR},1G,100K \

STOPTASKS,${SSTATE_DIR},1G,100K \

STOPTASKS,/tmp,100M,100K \

ABORT,${TMPDIR},100M,1K \

ABORT,${DL_DIR},100M,1K \

ABORT,${SSTATE_DIR},100M,1K \

ABORT,/tmp,10M,1K"

#

# Shared-state files from other locations

#

# As mentioned above, shared state files are prebuilt cache data objects which can

# used to accelerate build time. This variable can be used to configure the system

# to search other mirror locations for these objects before it builds the data itself.

#

# This can be a filesystem directory, or a remote url such as http or ftp. These

# would contain the sstate-cache results from previous builds (possibly from other

# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the

# cache locations to check for the shared objects.

# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH

# at the end as shown in the examples below. This will be substituted with the

# correct path within the directory structure.

#SSTATE_MIRRORS ?= "\

#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \

#file://.* file:///some/local/dir/sstate/PATH"

#

# Qemu configuration

#

# By default qemu will build with a builtin VNC server where graphical output can be

# seen. The two lines below enable the SDL backend too. By default libsdl-native will

# be built, if you want to use your host's libSDL instead of the minimal libsdl built

# by libsdl-native then uncomment the ASSUME_PROVIDED line below.

PACKAGECONFIG_append_pn-qemu-native = " sdl"

PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"

#ASSUME_PROVIDED += "libsdl-native"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to

# track the version of this file when it was generated. This can safely be ignored if

# this doesn't mean anything to you.

CONF_VERSION = "1"

### arria10 changes ###

PREFERRED_PROVIDER_virtual/kernel = "linux-altera-ltsi"

PREFERRED_PROVIDER_virtual/bootloader = "u-boot-socfpga"

PREFERRED_VERSION_linux-altera-ltsi = "4.9.78%"

#GCCVERSION = "linaro-7.2"

#SDKGCCVERSION = "linaro-7.2"

GCCVERSION = "linaro-5.2"

SDKGCCVERSION = "linaro-5.2"

DEFAULTTUNE = "cortexa9hf-neon"

# Mender Changes

MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image-sd"

MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"

DISTRO_FEATURES_append = " systemd"

VIRTUAL-RUNTIME_init_manager = "systemd"

DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

VIRTUAL-RUNTIME_initscripts = ""

ARTIFACTIMG_FSTYPE = "ext4"

------------------------------------------------------------------------------------------------------------------

bblayers.conf :

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf

# changes incompatibly

POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"

BBFILES ?= ""

BBLAYERS ?= " \

/home/gnewman/yocto/mender_yocto/poky/meta \

/home/gnewman/yocto/mender_yocto/poky/meta-poky \

/home/gnewman/yocto/mender_yocto/poky/meta-yocto-bsp \

/home/gnewman/yocto/mender_yocto/poky/meta-altera \

/home/gnewman/yocto/mender_yocto/poky/meta-linaro/meta-linaro-toolchain \

/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core \

"

------------------------------------------------------------------------------------------------------------------

Thanks,

Gary

Mirza Krak

unread,

Aug 31, 2018, 7:02:40 AM8/31/18

to Gary Newman, Mender List mender.io

On Fri, Aug 31, 2018 at 10:37 AM, Gary Newman <gnewma...@googlemail.com> wrote:

Hi Mirza,

Hi Gary,

Your configuration looks good to me and can not see any obvious problems with it.

Have you put,

MENDER_UBOOT_AUTO_CONFIGURE = "0"

In your U-boot recipe as well?

You can also try running:

bitbake virtual/bootloader -c mender_tar_src

> I'm guessing bitbake can't resolve recipes-bsp/u-boot/u-boot-mender.inc.

> Is this because it assumes it's already in meta-mender?

Bitbake would have complained that it could not find the file, that is a consequence of using "require". So probably something else, we just have to find it :).

--

Mirza Krak | Embedded Solutions Architect | https://mender.io

Northern.tech AS | @northerntechHQ

Gary Newman

unread,

Sep 3, 2018, 6:18:42 AM9/3/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Mirza,

Good news, I've managed to get a bit further.

I added MENDER_UBOOT_AUTO_CONFIGURE = "0" to my u-boot recipe.

I then cleaned out my tmp directory & did a clean build (bitbake virtual/bootloader).

After some additional changes to .../include/configs/socfpga_arria10.h (as per documentation), the u-boot build is completing.

I have now moved onto bitbake core-image-minimal & have hit an issue with building fw-utils:

--------------------------------------------------------------------------------------------------------

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_package: objcopy failed with exit code 1 (cmd was 'arm-poky-linux-gnueabi-objcopy' --only-keep-debug '/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_printenv' '/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/.debug/fw_printenv'):

arm-poky-linux-gnueabi-objcopy:/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_printenv: File format not recognized

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_package: Function failed: split_and_strip_files

ERROR: Logfile of failure stored in: /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/temp/log.do_package.29121

ERROR: Task (/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb:do_package) failed with exit code '1'

NOTE: Tasks Summary: Attempted 1683 tasks of which 548 didn't need to be rerun and 1 failed.

Summary: 1 task failed:

/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb:do_package

--------------------------------------------------------------------------------------------------------

I didn't make any changes in my u-boot for u-boot-fw-utils as u-boot appeared to build OK.

Any ideas?

Best Regards,

Gary

Mirza Krak

unread,

Sep 3, 2018, 7:42:25 AM9/3/18

to Gary Newman, Mender List mender.io

On Mon, Sep 3, 2018 at 12:18 PM, Gary Newman <gnewma...@googlemail.com> wrote:

Hi Mirza,

Hi Gary,

Good news, I've managed to get a bit further.

Nice!

I added MENDER_UBOOT_AUTO_CONFIGURE = "0" to my u-boot recipe.
I then cleaned out my tmp directory & did a clean build (bitbake virtual/bootloader).
After some additional changes to .../include/configs/socfpga_arria10.h (as per documentation), the u-boot build is completing.

I have now moved onto bitbake core-image-minimal & have hit an issue with building fw-utils:

--------------------------------------------------------------------------------------------------------

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_package: objcopy failed with exit code 1 (cmd was 'arm-poky-linux-gnueabi-objcopy' --only-keep-debug '/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_printenv' '/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/.debug/fw_printenv'):
arm-poky-linux-gnueabi-objcopy:/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_printenv: File format not recognized
ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_package: Function failed: split_and_strip_files
ERROR: Logfile of failure stored in: /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/temp/log.do_package.29121
ERROR: Task (/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb:do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1683 tasks of which 548 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb:do_package

--------------------------------------------------------------------------------------------------------

I didn't make any changes in my u-boot for u-boot-fw-utils as u-boot appeared to build OK.

Any ideas?

Could you run "file /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_printenv" to check what format the file actually is. It might have been that it has been compiled for the wrong architecture.

Also are you still using the 2014.xx U-boot version?

Gary Newman

unread,

Sep 3, 2018, 8:07:36 AM9/3/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Mirza,

I ran fw_printenv on my x86 build system:

gnewman@server-1:~/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin$ ./fw_printenv

Cannot parse config file: No such file or directory

So It looks like its been compiled for x86.

Yes I am currently still building u-boot-socfpga_v2014.10.bb.

Cheers,

Gary

Mirza Krak

unread,

Sep 3, 2018, 8:20:27 AM9/3/18

to Mender List mender.io, Gary Newman

On Mon, Sep 3, 2018 at 2:07 PM, 'Gary Newman' via Mender List
mender.io <men...@lists.mender.io> wrote:
>
> Hi Mirza,
>
> I ran fw_printenv on my x86 build system:
>
> gnewman@server-1:~/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin$ ./fw_printenv
> Cannot parse config file: No such file or directory
>
> So It looks like its been compiled for x86.

I would try running "bitbake -c cleansstate
u-boot-fw-utils-mender-auto-provided" and re-build to to make sure to
get an clean build.

>
>
> Yes I am currently still building u-boot-socfpga_v2014.10.bb.

You will probably have a more pleasant experience if you use a newer
version, as I understood it that was an option? Especially with the
"auto provided" recipes which are tested against newer versions.

--
Mirza Krak | Embedded Solutions Architect | https://mender.io

Northern.tech AS | @northerntechHQ

Gary Newman

unread,

Sep 5, 2018, 6:15:04 AM9/5/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Mirza,

I have spent the last couple of days trying to upgrade my uboot to a newer version.

It turned out that the 2016.05 & 2016.11 recipes didn't support the arria10.

I did get 2017.07 to build but the bin image that was built was too large for the altera mkpimage tool & therefore I couldn't deploy it to my board.

So I'm back to having to use the 2014.10 uboot.

I have rebuilt uboot & the kernel successfully.

I attempted to rebuild bitbake core-image-minimal.

This has resulted in the same issue:

----------------------------------------------------------------------------

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_package: objcopy failed with exit code 1 (cmd was 'arm-poky-linux-gnueabi-objcopy' --only-keep-debug '/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_setenv' '/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/.debug/fw_setenv'):

arm-poky-linux-gnueabi-objcopy:/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/package/sbin/fw_setenv: File format not recognized

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_package: Function failed: split_and_strip_files

ERROR: Logfile of failure stored in: /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/temp/log.do_package.9957

ERROR: Task (/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb:do_package) failed with exit code '1'

----------------------------------------------------------------------------

I ran bitbake -c cleansstate u-boot-fw-utils-mender-auto-provided and then re-ran bitbake core-image-minimal.

This resulted in the same build error.

I haven't made the 'u-boot-fw-utils' changes describe the 'Manual U-boot integration' section of the document as it stated 'It is almost never necessary to change anything with regards to this recipe'.

Are these changes required, or do you think I am missing something else in my u-boot configuration?

Regards,

Gary

TEXIER Pierre-Jean

unread,

Sep 5, 2018, 6:22:46 AM9/5/18

to men...@lists.mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Gary,

It seems you have to include the following patch [1] in your layer.

[1] http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/files/default-gcc.patch?h=pyro

Regards, Pierre-Jean

--
You received this message because you are subscribed to the Google Groups "Mender List mender.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+un...@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.

Gary Newman

unread,

Sep 7, 2018, 4:55:39 AM9/7/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Pierre-Jean,

Thanks very much for information about the patch.

I've had a few issues trying to work out where to apply the patch.

I finally managed to patch what I believe to be the correct Makefiles:

/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/tools/Makefile

/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/tools/env/Makefile

This appears to successfully now be cross compiling the env files, although I've now hit a new issue with the definition of uint8_t, uint32_t etc:

-------------------------------------------------------------------------------------------------------------------------------------------

| make -f scripts/Makefile.build obj=tools/env

| arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0=/usr/src/debug/u-boot-fw-utils-mender-auto-provided/1.0-r0 -fdebug-prefix-map=/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/recipe-sysroot-native= -fdebug-prefix-map=/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/recipe-sysroot= -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wp,-MD,tools/env/.fw_env.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafterinclude -idirafter/home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/arch/arm/include -idirafter /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/tools/env -DUSE_HOSTCC -DTEXT_BASE= -c -o tools/env/fw_env.o tools/env/fw_env.c

| tools/env/fw_env.c:52:2: error: unknown type name 'uint8_t'

| uint8_t mtd_type; /* type of the MTD device */

| ^

| tools/env/fw_env.c:77:2: error: unknown type name 'uint32_t'

| uint32_t crc; /* CRC32 over data bytes */

| ^

| tools/env/fw_env.c:82:2: error: unknown type name 'uint32_t'

| uint32_t crc; /* CRC32 over data bytes */

| ^

| tools/env/fw_env.c:95:2: error: unknown type name 'uint32_t'

| uint32_t *crc;

| ^

| tools/env/fw_env.c:107:8: error: unknown type name 'uint8_t'

| static uint8_t aes_key[AES_KEY_LENGTH] = { 0 };

| ^

| tools/env/fw_env.c: In function 'fw_env_close':

| tools/env/fw_env.c:338:31: error: 'uint8_t' undeclared (first use in this function)

| *environment.crc = crc32(0, (uint8_t *) environment.data, ENV_SIZE);

| ^

| tools/env/fw_env.c:338:31: note: each undeclared identifier is reported only once for each function it appears in

| tools/env/fw_env.c:338:40: error: expected expression before ')' token

| *environment.crc = crc32(0, (uint8_t *) environment.data, ENV_SIZE);

| ^

| tools/env/fw_env.c:338:21: error: too few arguments to function 'crc32'

| *environment.crc = crc32(0, (uint8_t *) environment.data, ENV_SIZE);

| ^

| In file included from tools/env/fw_env.c:32:0:

| tools/env/fw_env.h:63:23: note: declared here

| extern unsigned long crc32 (unsigned long, const unsigned char *, unsigned);

| ^

| tools/env/fw_env.c: At top level:

| tools/env/fw_env.c:676:37: error: unknown type name 'uint8_t'

| static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart)

| ^

| tools/env/fw_env.c:704:21: error: unknown type name 'uint8_t'

| off_t offset, uint8_t mtd_type)

| ^

| tools/env/fw_env.c:793:22: error: unknown type name 'uint8_t'

| off_t offset, uint8_t mtd_type)

| ^

| tools/env/fw_env.c: In function 'env_aes_cbc_crypt':

| tools/env/fw_env.c:990:2: error: unknown type name 'uint8_t'

| uint8_t *data = (uint8_t *)payload;

| ^

| tools/env/fw_env.c:990:19: error: 'uint8_t' undeclared (first use in this function)

| uint8_t *data = (uint8_t *)payload;

| ^

| tools/env/fw_env.c:990:28: error: expected expression before ')' token

| uint8_t *data = (uint8_t *)payload;

| ^

| tools/env/fw_env.c:992:10: error: expected ';' before 'key_exp'

| uint8_t key_exp[AES_EXPAND_KEY_LENGTH];

| ^

| tools/env/fw_env.c:993:2: error: unknown type name 'uint32_t'

| uint32_t aes_blocks;

| ^

| tools/env/fw_env.c:996:26: error: 'key_exp' undeclared (first use in this function)

| aes_expand_key(aes_key, key_exp);

| ^

| tools/env/fw_env.c:996:17: warning: passing argument 1 of 'aes_expand_key' from incompatible pointer type [-Wincompatible-pointer-types]

| aes_expand_key(aes_key, key_exp);

| ^

| In file included from tools/env/fw_env.c:34:0:

| include/aes.h:43:6: note: expected 'u8 * {aka unsigned char *}' but argument is of type 'int *'

| void aes_expand_key(u8 *key, u8 *expkey);

| ^

| tools/env/fw_env.c:1002:35: warning: passing argument 2 of 'aes_cbc_encrypt_blocks' from incompatible pointer type [-Wincompatible-pointer-types]

| aes_cbc_encrypt_blocks(key_exp, data, data, aes_blocks);

| ^

| In file included from tools/env/fw_env.c:34:0:

| include/aes.h:82:6: note: expected 'u8 * {aka unsigned char *}' but argument is of type 'int *'

| void aes_cbc_encrypt_blocks(u8 *key_exp, u8 *src, u8 *dst, u32 num_aes_blocks);

| ^

| tools/env/fw_env.c:1002:41: warning: passing argument 3 of 'aes_cbc_encrypt_blocks' from incompatible pointer type [-Wincompatible-pointer-types]

| aes_cbc_encrypt_blocks(key_exp, data, data, aes_blocks);

| ^

| In file included from tools/env/fw_env.c:34:0:

| include/aes.h:82:6: note: expected 'u8 * {aka unsigned char *}' but argument is of type 'int *'

| void aes_cbc_encrypt_blocks(u8 *key_exp, u8 *src, u8 *dst, u32 num_aes_blocks);

| ^

| tools/env/fw_env.c:1004:35: warning: passing argument 2 of 'aes_cbc_decrypt_blocks' from incompatible pointer type [-Wincompatible-pointer-types]

| aes_cbc_decrypt_blocks(key_exp, data, data, aes_blocks);

| ^

| In file included from tools/env/fw_env.c:34:0:

| include/aes.h:92:6: note: expected 'u8 * {aka unsigned char *}' but argument is of type 'int *'

| void aes_cbc_decrypt_blocks(u8 *key_exp, u8 *src, u8 *dst, u32 num_aes_blocks);

| ^

| tools/env/fw_env.c:1004:41: warning: passing argument 3 of 'aes_cbc_decrypt_blocks' from incompatible pointer type [-Wincompatible-pointer-types]

| aes_cbc_decrypt_blocks(key_exp, data, data, aes_blocks);

| ^

| In file included from tools/env/fw_env.c:34:0:

| include/aes.h:92:6: note: expected 'u8 * {aka unsigned char *}' but argument is of type 'int *'

| void aes_cbc_decrypt_blocks(u8 *key_exp, u8 *src, u8 *dst, u32 num_aes_blocks);

| ^

| tools/env/fw_env.c: In function 'flash_write':

| tools/env/fw_env.c:1033:7: warning: implicit declaration of function 'flash_write_buf' [-Wimplicit-function-declaration]

| rc = flash_write_buf(dev_target, fd_target, environment.image,

| ^

| tools/env/fw_env.c: In function 'flash_read':

| tools/env/fw_env.c:1089:7: warning: implicit declaration of function 'flash_read_buf' [-Wimplicit-function-declaration]

| rc = flash_read_buf(dev_current, fd, environment.image, CUR_ENVSIZE,

| ^

| tools/env/fw_env.c: In function 'fw_env_open':

| tools/env/fw_env.c:1222:20: error: 'uint8_t' undeclared (first use in this function)

| crc0 = crc32 (0, (uint8_t *) environment.data, ENV_SIZE);

| ^

| tools/env/fw_env.c:1222:29: error: expected expression before ')' token

| crc0 = crc32 (0, (uint8_t *) environment.data, ENV_SIZE);

| ^

| tools/env/fw_env.c:1222:9: error: too few arguments to function 'crc32'

| crc0 = crc32 (0, (uint8_t *) environment.data, ENV_SIZE);

| ^

| In file included from tools/env/fw_env.c:32:0:

| tools/env/fw_env.h:63:23: note: declared here

| extern unsigned long crc32 (unsigned long, const unsigned char *, unsigned);

| ^

| tools/env/fw_env.c:1279:30: error: expected expression before ')' token

| crc1 = crc32 (0, (uint8_t *) redundant->data, ENV_SIZE);

| ^

| tools/env/fw_env.c:1279:10: error: too few arguments to function 'crc32'

| crc1 = crc32 (0, (uint8_t *) redundant->data, ENV_SIZE);

| ^

| In file included from tools/env/fw_env.c:32:0:

| tools/env/fw_env.h:63:23: note: declared here

| extern unsigned long crc32 (unsigned long, const unsigned char *, unsigned);

| ^

| make[1]: *** [tools/env/fw_env.o] Error 1

| make: *** [env] Error 2

| ERROR: oe_runmake failed

| WARNING: /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/temp/run.do_compile.4652:1 exit 1 from 'exit 1'

| ERROR: Function failed: do_compile (log file is located at /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/temp/log.do_compile.4652)

ERROR: Task (/home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb:do_compile) failed with exit code '1'

NOTE: Tasks Summary: Attempted 1891 tasks of which 1882 didn't need to be rerun and 2 failed.

-------------------------------------------------------------------------------------------------------------------------------------------

I'm guessing these definitions were somehow defined by gcc and are not by arm-poky-linux-gnueabi-gcc .

Will try and check it down.

Regards,

Gary

Mirza Krak

unread,

Sep 7, 2018, 5:02:20 AM9/7/18

to Gary Newman, Mender List mender.io

On Fri, Sep 7, 2018 at 10:55 AM, Gary Newman <gnewma...@googlemail.com> wrote:

Hi Pierre-Jean,

< clip >

This should be fixed by following patch, [1], but it should have been applied together with the rest of Mender patches.

[1]. https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/recipes-bsp/u-boot/patches/0001-Add-missing-header-which-fails-on-recent-GCC.patch

--

Mirza Krak | Embedded Solutions Architect | https://mender.io

Northern.tech AS | @northerntechHQ

Gary Newman

unread,

Sep 7, 2018, 5:51:06 AM9/7/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Mirza,

Thanks for that.

I think this probably highlights my lack of understanding of how to apply patches inside yocto/the mender layer.

I couldn't work out how to add a new patch into /home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb.

There didn't appear to be any previous application of patches from within this recipe.

I added the line SRC_URI += "file://default-gcc.patch" to u-boot-fw-utils-mender-auto-provided_1.0.bb & this resulted in the patch file getting copied to /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/. However the patch never got applied to the /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/ build directory.

I ended up hacking a copy of pre patched Makefiles into the do_patch() routine in boot-fw-utils-mender-auto-provided_1.0.bb.

I appreciate this is certainly not the correct way to do this.

So I'm therefore a little confused as to how the other patches (0001-Add-missing-header-which-fails-on-recent-GCC.patch included) get applied to the u-boot-fw-utils-mender-auto-provided build directory.

Thanks in advance for any pointers on patching u-boot-fw-utils-mender-auto-provided.

Regards,

Gary

Mirza Krak

unread,

Sep 7, 2018, 5:59:08 AM9/7/18

to Gary Newman, Mender List mender.io

On Fri, Sep 7, 2018 at 11:51 AM, Gary Newman <gnewma...@googlemail.com> wrote:

Hi Mirza,

Thanks for that.

I think this probably highlights my lack of understanding of how to apply patches inside yocto/the mender layer.

I couldn't work out how to add a new patch into /home/gnewman/yocto/mender_yocto/poky/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb.

The chain of includes that result in the patches being applied is:

- u-boot-fw-utils-mender-auto-provided

- require u-boot-fw-utils-mender.inc

- require u-boot-mender-common.inc

- This contains the SRC_URIs for all the patches

So by default these should have been applied without you doing anything.

There didn't appear to be any previous application of patches from within this recipe.

I added the line SRC_URI += "file://default-gcc.patch" to u-boot-fw-utils-mender-auto-provided_1.0.bb & this resulted in the patch file getting copied to /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/. However the patch never got applied to the /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/ build directory.

I ended up hacking a copy of pre patched Makefiles into the do_patch() routine in boot-fw-utils-mender-auto-provided_1.0.bb.
I appreciate this is certainly not the correct way to do this.

So I'm therefore a little confused as to how the other patches (0001-Add-missing-header-which-fails-on-recent-GCC.patch included) get applied to the u-boot-fw-utils-mender-auto-provided build directory.

Thanks in advance for any pointers on patching u-boot-fw-utils-mender-auto-provided.

If you want to append patches to u-boot-fw-utils-mender-auto-provided you need to create a u-boot-fw-utils-mender-auto-provided.bbappend file in a seperate layer that adds to SRC_URI.

I can recommend reading trough the Yocto manual, there is section about applying patches [1]

[1]. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#modifying-an-existing-recipe

Gary Newman

unread,

Sep 7, 2018, 6:04:06 AM9/7/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Ok I will check the patch documentation.

Thanks

Gary Newman

unread,

Sep 7, 2018, 10:42:29 AM9/7/18

to Mender List mender.io, gnewma...@googlemail.com, mirza...@northern.tech

Hi Mirza,

Ok I've now worked out why the patching didn't appear to be working u-boot-fw-utils-mender-auto-provided.

For some reason the 2014.10 arria10 u-boot build wants to build from:

/home/gnewman/yocto/mender_yocto/build/tmp/work/arria10-poky-linux-gnueabi/u-boot-socfpga/v2014.10-r1/u-boot-socfpga-v2014.10

NOT

/home/gnewman/yocto/mender_yocto/build/tmp/work/arria10-poky-linux-gnueabi/u-boot-socfpga/v2014.10-r1/git

Following some advice from an Altera Forum I was advised to copy the code from the git directory, to the u-boot-socfpga-v2014.10 directory.

This allowed the u-boot build to complete.

This is the root cause of my issues!
Its an Altera issue, not a Mender one!

The mender patches get applied to the u-boot-socfpga-v2014.10 directory, but u-boot-mender.inc tar's up the git directory into mender-u-boot-src.tar.gz (This does not contain the patches).

When u-boot-fw-utils-mender-auto-provided is built it doesnt reapply the patches (which is what I assumed), it just un-tars mender-u-boot-src.tar.gz (which doesn't contain the patched code).

So I tried a work around of copying the u-boot-socfpga-v2014.10 directory back into the git directory before mender-u-boot-src.tar.gz is created.

This has gotten me around cross compilation issues.

Thanks for you help.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Unfortunately I've now hit the next build issue:

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_populate_lic: QA Issue: u-boot-fw-utils-mender-auto-provided: The LIC_FILES_CHKSUM does not match for file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6

u-boot-fw-utils-mender-auto-provided: The new md5 checksum is c7383a594871c03da76b3707929d2919

u-boot-fw-utils-mender-auto-provided: Here is the selected license text:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

U-Boot is Free Software. It is copyrighted by Wolfgang Denk and

many others who contributed code (see the actual source code and the

git commit messages for details). You can redistribute U-Boot and/or

modify it under the terms of version 2 of the GNU General Public

License as published by the Free Software Foundation. Most of it can

also be distributed, at your option, under any later version of the

GNU General Public License -- see individual files for exceptions.

NOTE! This license does *not* cover the so-called "standalone"

applications that use U-Boot services by means of the jump table

...

GNU General Public License v2.0 only GPL-2.0 Y gpl-2.0.txt http://www.gnu.org/licenses/gpl-2.0.txt

GNU General Public License v2.0 or later GPL-2.0+ Y gpl-2.0.txt http://www.gnu.org/licenses/gpl-2.0.txt

GNU Library General Public License v2 or later LGPL-2.0+ Y lgpl-2.0.txt http://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt

GNU Lesser General Public License v2.1 or later LGPL-2.1+ Y lgpl-2.1.txt http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt

eCos license version 2.0 eCos-2.0 eCos-2.0.txt http://www.gnu.org/licenses/ecos-license.html

BSD 2-Clause License BSD-2-Clause Y bsd-2-clause.txt http://spdx.org/licenses/BSD-2-Clause

BSD 3-clause "New" or "Revised" License BSD-3-Clause Y bsd-3-clause.txt http://spdx.org/licenses/BSD-3-Clause#licenseText

IBM PIBS (PowerPC Initialization and IBM-pibs ibm-pibs.txt

Boot Software) license

ISC License ISC Y isc.txt https://spdx.org/licenses/ISC

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

u-boot-fw-utils-mender-auto-provided: Check if the license information has changed in /home/gnewman/yocto/mender_yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/git/Licenses/README to verify that the LICENSE value "GPL-2.0" remains valid [license-checksum]

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_populate_lic: Fatal QA errors found, failing task.

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_populate_lic: Function failed: populate_lic_qa_checksum

Any ideas about this one?

Regards,

Gary

Mirza Krak

unread,

Sep 7, 2018, 10:48:42 AM9/7/18

to Gary Newman, Mender List mender.io

On Fri, Sep 7, 2018 at 4:42 PM, Gary Newman <gnewma...@googlemail.com> wrote:

Hi Mirza,

Ok I've now worked out why the patching didn't appear to be working u-boot-fw-utils-mender-auto-provided.

For some reason the 2014.10 arria10 u-boot build wants to build from:
/home/gnewman/yocto/mender_yocto/build/tmp/work/arria10-poky-linux-gnueabi/u-boot-socfpga/v2014.10-r1/u-boot-socfpga-v2014.10

NOT

/home/gnewman/yocto/mender_yocto/build/tmp/work/arria10-poky-linux-gnueabi/u-boot-socfpga/v2014.10-r1/git

Following some advice from an Altera Forum I was advised to copy the code from the git directory, to the u-boot-socfpga-v2014.10 directory.

This allowed the u-boot build to complete.

This is the root cause of my issues!
Its an Altera issue, not a Mender one!

The mender patches get applied to the u-boot-socfpga-v2014.10 directory, but u-boot-mender.inc tar's up the git directory into mender-u-boot-src.tar.gz (This does not contain the patches).

When u-boot-fw-utils-mender-auto-provided is built it doesnt reapply the patches (which is what I assumed), it just un-tars mender-u-boot-src.tar.gz (which doesn't contain the patched code).

So I tried a work around of copying the u-boot-socfpga-v2014.10 directory back into the git directory before mender-u-boot-src.tar.gz is created.

This has gotten me around cross compilation issues.

Thanks for you help.

No problem and glad that you are able to progress.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Unfortunately I've now hit the next build issue:

ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_populate_lic: QA Issue: u-boot-fw-utils-mender-auto-provided: The LIC_FILES_CHKSUM does not match for file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6
u-boot-fw-utils-mender-auto-provided: The new md5 checksum is c7383a594871c03da76b3707929d2919
u-boot-fw-utils-mender-auto-provided: Here is the selected license text:

We actually have a fix for above which is currently only on "master" and "sumo" of meta-mender [1]. You could try and cherry-pick that or apply the same changes to your rocko instance.

[1]. https://github.com/mendersoftware/meta-mender/commit/76927a8a59488be45427dde1a5fb19b169f7b032#diff-117ad34f1b1783e49d49a7ba2d7690db

--

Mirza Krak

unread,

Sep 14, 2018, 3:48:12 AM9/14/18

to Gary Newman, Mender List mender.io

On Fri, Sep 7, 2018 at 4:48 PM, Mirza Krak <mirza...@northern.tech> wrote:
>
> On Fri, Sep 7, 2018 at 4:42 PM, Gary Newman <gnewma...@googlemail.com> wrote:
>>
>> Hi Mirza,

Hi Gary!

< clip >

>> Unfortunately I've now hit the next build issue:
>>
>>
>> ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_populate_lic: QA Issue: u-boot-fw-utils-mender-auto-provided: The LIC_FILES_CHKSUM does not match for file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6
>> u-boot-fw-utils-mender-auto-provided: The new md5 checksum is c7383a594871c03da76b3707929d2919
>> u-boot-fw-utils-mender-auto-provided: Here is the selected license text:
>
>
> We actually have a fix for above which is currently only on "master" and "sumo" of meta-mender [1]. You could try and cherry-pick that or apply the same changes to your rocko instance.
>
> [1]. https://github.com/mendersoftware/meta-mender/commit/76927a8a59488be45427dde1a5fb19b169f7b032#diff-117ad34f1b1783e49d49a7ba2d7690db

I am curios if things worked out for you with above fix? There is also
an PR [1] which back-ports above fix to "rocko" branch.

[1]. https://github.com/mendersoftware/meta-mender/pull/600