cat fw_env.config
/dev/mmcblk0 0x800000 0x20000
/dev/mmcblk0 0x1000000 0x20000
So the file is wrong, still trying to find the cause…
Hm, odd. It should come straight from the MENDER_STORAGE_DEVICE variable.
What does the following give you:
bitbake core-image-base -e | grep -E "^PREFERRED_PROVIDER_u-boot-fw-utils|^PREFERRED_RPROVIDER_u-boot-fw-utils"I get:
PREFERRED_PROVIDER_u-boot-fw-utils="u-boot-fw-utils-mender-auto-provided"
PREFERRED_RPROVIDER_u-boot-fw-utils="u-boot-fw-utils-mender-auto-provided"
I saw the file change after I did a clean on the u-boot, e.g.:
cat ./cortexa7hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/fw_env.config
/dev/mmcblk0 0x800000 0x20000
/dev/mmcblk0 0x1000000 0x20000
bitbake u-boot-fw-utils-mender-auto-provided u-boot-imx -c cleanall
bitbake myimage
cat ./cortexa7hf-neon-poky-linux-gnueabi/u-boot-fw-utils-mender-auto-provided/1.0-r0/fw_env.config
/dev/mmcblk1 0x800000 0x20000
/dev/mmcblk1 0x1000000 0x20000
So I’m not convinced the image is pulling in the correct files.
edit: pasted the wrong thing
Cleaning the image and rebuilding seems to have changed some files.
I’m away from the board until Thursday and then I’ll pick it up again.
I have it working now against the demo server. I was just a Yocto funny - cleaning the image and building again flushed it all out.
Thanks for the help, going to play around with it a bit now.
Great to hear, thanks for reporting back!
Here are the important bits:
PREFERRED_PROVIDER_u-boot = "u-boot-imx"
PREFERRED_RPROVIDER_u-boot = "u-boot-imx"
MENDER_STORAGE_DEVICE = "/dev/mmcblk1"
MENDER_STORAGE_TOTAL_SIZE_MB = "7580"
IMAGE_BOOT_FILES ?= "u-boot.imx"
IMAGE_BOOT_FILES = "zImage your-dtb-file-here.dtb"
IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET = "2"
IMAGE_BOOTLOADER_FILE = "u-boot.imx"
MENDER_UBOOT_PRE_SETUP_COMMANDS = " \
setenv kernel_addr_r \${loadaddr}; \
"
IMAGE_FSTYPES_remove += "sdcard.bz2"
I also had to patch u-boot:
sources/meta-freescale-your-layer/recipes-bsp/u-boot/u-boot-imx_%.bbappend file:
require recipes-bsp/u-boot/u-boot-mender.inc
FILESEXTRAPATHS_prepend := "${THISDIR}/patches:"
# GCC Patch - see https://groups.google.com/a/lists.mender.io/forum/#!topic/mender/p54Sv7nbfjk
SRC_URI += "file://default-gcc.patch"
sources/meta-freescale-your-layer/recipes-bsp/u-boot/patches/default-gcc.patch:
OE needs to be able to change the default compiler. If we pass in HOSTCC
through the make command, it overwrites not only this setting but also the
setting in tools/Makefile wrapped in ifneq ($(CROSS_BUILD_TOOLS),) which
breaks the build.
We therefore use override to ensure the value of HOSTCC is overwritten when
needed.
RP: Updated the patch to the version being submitted to upstream u-boot
Upstream-Status: Submitted [emailed to Masahiro Yamada for discussion]
RP 2017/3/11
Index: git/tools/Makefile
===================================================================
--- git.orig/tools/Makefile
+++ git/tools/Makefile
@@ -262,7 +262,7 @@ $(LICENSE_H): $(obj)/bin2header $(srctre
subdir- += env
ifneq ($(CROSS_BUILD_TOOLS),)
-HOSTCC = $(CC)
+override HOSTCC = $(CC)
quiet_cmd_crosstools_strip = STRIP $^
cmd_crosstools_strip = $(STRIP) $^; touch $@
Index: git/tools/env/Makefile
===================================================================
--- git.orig/tools/env/Makefile
+++ git/tools/env/Makefile
@@ -8,7 +8,7 @@
# fw_printenv is supposed to run on the target system, which means it should be
# built with cross tools. Although it may look weird, we only replace "HOSTCC"
# with "CC" here for the maximum code reuse of scripts/Makefile.host.
-HOSTCC = $(CC)
+override HOSTCC = $(CC)
# Compile for a hosted environment on the target
HOST_EXTRACFLAGS = $(patsubst -I%,-idirafter%, $(filter -I%, $(UBOOTINCLUDE))) \
Would be great if you could convert your notes to an PR here, https://github.com/mendersoftware/meta-mender-community
Is there a best-practice example to copy? Sometimes there are many ways to do things in Yocto and I would want to do it the best way.
Take a look here,
https://hub.mender.io/t/about-the-yocto-project-category/54/8
And I guess the git log is pretty good to look at for examples, e.g
https://github.com/mendersoftware/meta-mender-community/commits/sumo/meta-mender-nxp
The best way is very individual 
I am trying to get the PR and instructions done for this board now(link). Previously I was using my custom board which worked, but now that I am trying to adhere to the meta-mender-community structure I am getting this error:
ERROR: Task do_patch in /home/ecocel/mender-imx6ull/sources/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/ecocel/mender-imx6ull/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb
ERROR: Command execution failed: 1
My structure is here: https://github.com/brianleePTL/meta-mender-community/tree/rocko/meta-mender-nxp-imx6ull
Any clues?
Can you post the resulting local.conf, you typically get this if you do not have
INHERIT += "mender-full"
or lacking require recipes-bsp/u-boot/u-boot-mender.inc in U-boot fork recipe, but this you seem to have so I suspect the first mentioned.
Thanks for the reply.
I think I solved it
I ran:
bitbake-layers show-appends | grep -i u-boot
and got:
u-boot-fw-utils_2017.09.bb:
/home/brian/mender-imx6ull/sources/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils_%.bbappend
u-boot-fslc_2017.11.bb (skipped):
/home/brian/mender-imx6ull/sources/meta-freescale-3rdparty/recipes-bsp/u-boot/u-boot-fslc_%.bbappend
u-boot_2017.09.bb (skipped):
/home/brian/mender-imx6ull/sources/meta-mender/meta-mender-core/recipes-bsp/u-boot/u-boot_%.bbappend
So I discovered I had missed adding my new layer to the bblayers.conf.sample file - doh!
Also for reference, we recently did a board integration for i.MX8 on sumo branch (similar BSP to what you are using), you can take a look at the commit here,
I would suggest this as a good template for how I would have done it for i.MX6ULL
And the post,
But with these instructions,
mkdir mender-imx && cd mender-imx
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml
wget --directory-prefix .repo/manifests https://raw.githubusercontent.com/mendersoftware/meta-mender-community/sumo/meta-mender-imx/scripts/imx-4.14.98-2.0.0_demo_mender.xml
repo init -m imx-4.14.98-2.0.0_demo_mender.xml
repo sync
DISTRO=fsl-imx-xwayland MACHINE=imx8mqevk . fsl-setup-mender.sh -b build
Which is not how it is currently done in that post as the imx-4.14.98-2.0.0_demo_mender.xml file was up-streamed.
Looking for some advice here.
I get the following warning:
WARNING: u-boot-imx-2017.03-r0 do_provide_mender_defines: Found more than one dtb specified in KERNEL_DEVICETREE. Only one should be specified. Choosing the last one.
The file meta-fsl-bsp-release/imx/meta-bsp/conf/machine/imx6ull14x14evk.conf which is my machine.conf file contains the following:
KERNEL_DEVICETREE = "imx6ull-14x14-evk.dtb imx6ull-14x14-evk-btwifi.dtb imx6ull-14x14-evk-gpmi-weim.dtb
imx6ull-14x14-evk-usb-certi.dtb imx6ull-14x14-evk-emmc.dtb
"
I think since this uses an ‘=’ that means I can’t override this in the local.conf
What is the best practice here to only have a single .dtb? Create a new machine, e.g. imx6ull14x14evk-mender ?
Thanks
What is the best practice here to only have a single .dtb? Create a new machine, e.g. imx6ull14x14evk-mender ?
I would try really hard to avoid creating custom machines.
I guess the appropriate fix is to make sure that imx6ull14x14evk.conf is changed to ? = to allow overrides.
But one workaround you can use in local.conf is
KERNEL_DEVICETREE_remove "<name of the entries to you want to remove>"I’ve got a working build now so I’m just trying to absorb this post now (and find the things you are subtly saying I should change 
). I’m still trying to understand repo too, so bear with me.
If I understand whats happening properly, you are still using the NXP manifest to download the NXP repositories, but you then download an additional manifest with the mender info.
repo sync will then download both manifests. (I didn’t know it could do this)
You have a custom initialise script that calls the NXP script in the fashion it expects, while also setting up the mender side of things.
Reading between the lines, are the benefits:
?
I’ve got a working build now so I’m just trying to absorb this post now (and find the things you are subtly saying I should change
Understandable and do not worry much about it 
If I understand whats happening properly, you are still using the NXP manifest to download the NXP repositories, but you then download an additional manifest with the mender info.
repo syncwill then download both manifests. (I didn’t know it could do this)
You have a custom initialise script that calls the NXP script in the fashion it expects, while also setting up the mender side of things.
You have understood correctly.
Reading between the lines, are the benefits:
- Can still get updates from NXP since we use their manifest directly
Exactly, it is usually a pain to keep a copy of the upstream manifest, which would get out of date fast and one needs keep updating it “manually”
- Can still use their initialisation script to support multiple MACHINE and DISTRO variables
Yes, exactly. This is to make the Mender integration less “intrusive” to the upstream workflow even if the Mender integration is only valid for one MACHINE this could be extended to support more.
I think I have most of the documentation done here: [INCOMPLETE] i.MX 6ULL EVK and a pull request here: https://github.com/mendersoftware/meta-mender-community/pull/73
Let me know what else I can do. Once PR is done I will update the docs with the correct links and run through the build process using the instructions, then do the runtime testing etc.
Thanks.
I will take a look at the PR tomorrow, today is a public holiday so trying to enjoy that 