Pine A64-LTS

I am trying to get mender (u-boot + client) integrated in my yocto+poky setup for a Pine A64-LTS unit.
I have added the meta-mender-core layer to my bblayers.conf and hoped the autodetect would do its magic. My bitbake fails at:

| /home/patrick/yocto-new/poky/build/tmp/work/pine_a64_lts-poky-linux/u-boot/1_2020.01-r0/tmp-src/scripts/dtc/libfdt/fdt_overlay.c: In function ‘overlay_update_local_node_references’:
| /home/patrick/yocto-new/poky/build/tmp/work/pine_a64_lts-poky-linux/u-boot/1_2020.01-r0/tmp-src/scripts/dtc/libfdt/fdt_overlay.c:253:17: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
| for (i = 0; i < (fixup_len / sizeof(uint32_t)); i++) {
| ^
| scripts/dtc/pylibfdt/libfdt_wrap.c:149:11: fatal error: Python.h: No such file or directory
| # include <Python.h>
| ^~~~~~~~~~
| compilation terminated.
| error: command ‘gcc’ failed with exit status 1
| make[3]: *** [scripts/dtc/pylibfdt/Makefile:27: scripts/dtc/pylibfdt/_libfdt.so] Error 1
| make[2]: *** [scripts/Makefile.build:432: scripts/dtc/pylibfdt] Error 2
| make[1]: *** [scripts/Makefile.build:432: scripts/dtc] Error 2
| make: *** [Makefile:551: scripts] Error 2
| WARNING: exit code 2 from a shell command.
|
ERROR: Task (/home/patrick/yocto-new/poky/meta/recipes-bsp/u-boot/u-boot_2020.01.bb:do_mender_uboot_auto_configure) failed with exit code ‘1’
NOTE: Tasks Summary: Attempted 2596 tasks of which 2581 didn’t need to be rerun and 1 failed.

Summary: 1 task failed:
/home/patrick/yocto-new/poky/meta/recipes-bsp/u-boot/u-boot_2020.01.bb:do_mender_uboot_auto_configure
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Maybe i am expecting too much of the current meta layer? Am i correct that this meta-mender-core
layer can be added to my existing layers or do i have to adapt mender to work together with my
specific board? Like i already see a Raspberrypi folder?

My intention is too just add meta-mender-core to let it do adaptations to my own u-boot and kernel changes that i have done in meta-pine64 layer. I was expecting some machine.conf in the meta-mender part to select/add my board specific items, but did not find any.

Current bblayers.conf is:

POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
changes incompatibly
POKY_BBLAYERS_CONF_VERSION = “2”

BBPATH = “${TOPDIR}”
BBFILES ?= “”

BBLAYERS ?= "
/home/patrick/yocto-new/poky/meta
/home/patrick/yocto-new/poky/meta-poky
/home/patrick/yocto-new/poky/meta-yocto-bsp
/home/patrick/yocto-new/poky/meta-pine64
/home/patrick/yocto-new/poky/meta-mender/meta-mender-core
"

Any help will be appreciated :slight_smile:

Hi @ppeters,

The goal of the automatic patching is that you can just add the layer, configure the Mender bits, and have it all “just work”. The reality is that certain boards require extra help. Some, like the Raspberry Pi, require quite a bit since that platform uses a non-standard custom binary firmware that makes things a bit difficult.

It doesn’t look like we have an out-of-the-box integration for this platform so there may be some steps needed.

Can you also share your local.conf settings for integrating with Mender?

I did find this link which looks similar to your build error here so it’s possible that adding a patch or two into a custom bitbake layer may be all that is needed.

Drew

@ppeters how about to add u-boot_%.bbappend following: ```DEPENDS_append = " python3-native" and see if it helps. Thanks.

Hi Drewmoseley and MarekBelisko,

Thank you both for your help. I tried the DEPENDS_append item but it had no effect. I also tried it at other places and also variations like DEPENDS += “python3-native”

I am beginning to question if the ‘meta-mender/meta-mender-core/recipes-bsp/u-boot/files/uboot_auto_configure.sh’ script is really capable of compiling the u-boot for aarch64 architecture (Pine A64-LTS unit). It looks like the script has some parameters like CROSS_COMPILE, but when i analyze the actual statements it executes, especially the ‘make’ commands i found out that CROSS_COMPILE is just empty. It looks to me that the script isn’t respecting the Yocto build environment and currently tries to do a make with the host gcc compile and without any include paths and/or library paths.

Does anyone have succesfully used meta-mender-core and u-boot recipe for an aarch64 architecture target system?

I also tried adding meta-openembedded and meta-python but all did not work.

I will add my local.conf and bblayers.conf below this item. Sorry for the long item, but i could not upload text files…

---- 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-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86-64 if no other machine is selected:
#MACHINE ??= "qemux86-64"
MACHINE ?= "pine-a64-lts"

#
# 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_rpm"
PACKAGE_CLASSES ?= "package_deb"

#
# 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"
SDKMACHINE ?= "aarch64"

#
# 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)
#  "src-pkgs"       - add -src packages for all installed packages
#                     (adds source code for debugging)
#  "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. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See classes/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO_qemuall = "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"

#
# Yocto Project SState Mirror
#
# The Yocto Project has prebuilt artefacts available for its releases, you can enable
# use of these by uncommenting the following line. This will mean the build uses
# the network to check for artefacts at the start of builds, which does slow it down
# equally, it will also speed up the builds by not having to build things if they are
# present in the cache. It assumes you can download something faster than you can build it
# which will depend on your network.
#
#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"

#
# Qemu configuration
#
# By default native qemu will build with a builtin VNC server where graphical output can be
# seen. The line below enables the SDL UI frontend too.
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
# By default libsdl2-native will be built, if you want to use your host's libSDL instead of 
# the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
#ASSUME_PROVIDED += "libsdl2-native"

# You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds
# a handy set of menus for controlling the emulator.
#PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"

#
# Hash Equivalence
#
# Enable support for automatically running a local hash equivalence server and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact.
#
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#
#BB_HASHSERVE = "auto"
#BB_SIGNATURE_HANDLER = "OEEquivHash"

# 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"

INIT_MANAGER = "systemd"

DISTRO_FEATURES += "ipv4 ipv6 wayland opengl pam"
#IMAGE_INSTALL_append = " python3"

PACKAGECONFIG_append_pn-mesa = " gallium lima kmsro"

IMAGE_FSTYPES = "ext4 wic.bz2"

# 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 = "Test-release-1"

#INHERIT += "mender-full"

# The version of Mender to build. This needs to match an existing recipe in the meta-mender repository.
#
# Given your Yocto Project version, see which versions of Mender you can currently build here:
# https://docs.mender.io/overview/compatibility#mender-client-and-yocto-project-version
#
# Given a Mender client version, see the corresponding version of the mender-artifact utility:
# https://docs.mender.io/overview/compatibility#mender-clientserver-and-artifact-format
#
# Note that by default this will select the latest released version of the tools.
# If you need an earlier version, please uncomment the following and set to the
# required version.
#
# PREFERRED_VERSION_pn-mender = "2.6.0"
# PREFERRED_VERSION_pn-mender-artifact = "3.5.1"
# PREFERRED_VERSION_pn-mender-artifact-native = "3.5.1"

ARTIFACTIMG_FSTYPE = "ext4"

# Build for hosted Mender
#
# To get your tenant token:
#    - log in to https://hosted.mender.io
#    - click your email at the top right and then "My organization"
#    - press the "COPY TO CLIPBOARD"
#    - assign content of clipboard to MENDER_TENANT_TOKEN
#
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "test123"

# Build for Mender demo server
#
# https://docs.mender.io/administration/demo-installation
#
# Uncomment below and update IP address to match the machine running the
# Mender demo server
#MENDER_DEMO_HOST_IP_ADDRESS = "192.168.0.100"

# Build for Mender production setup (on-prem)
#
# https://docs.mender.io/administration/production-installation
#
# Uncomment below and update the URL to match your configured domain
# name and provide the path to the generated server.crt file.
#
# Note that a custom server.crt file is only necessary if you are using
# self-signed certificates.
#
# NOTE! It is recommend that you provide below information in your custom
# Yocto layer and this is only for demo purposes. See linked documentation
# for additional information.
#MENDER_SERVER_URL = "https://docker.mender.io"
#FILESEXTRAPATHS_prepend_pn-mender := "<DIRECTORY-CONTAINING-server.crt>:"
#SRC_URI_append_pn-mender = " file://server.crt"

# Custom mender image creation settings.

MENDER_STORAGE_DEVICE = "/dev/mmcblk0"

# Currently SD card is 15 900 000 000 bytes is (/1024/1024) 15163MB we will make a safety round down to 15000MB
MENDER_STORAGE_TOTAL_SIZE_MB="15000"

# Just to prevent wrong calculation results. The current image data will just fit fine in 7000MB of filesystem storage space
IMAGE_ROOTFS_SIZE="7000000"

IMAGE_OVERHEAD_FACTOR="1.15"

MENDER_BOOT_PART_SIZE_MB="256"

MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image mender-client-install mender-systemd mender-growfs-data mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"

------ 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/patrick/yocto-new/poky/meta \
  /home/patrick/yocto-new/poky/meta-poky \
  /home/patrick/yocto-new/poky/meta-yocto-bsp \
  /home/patrick/yocto-new/poky/meta-openembedded/meta-oe \
  /home/patrick/yocto-new/poky/meta-openembedded/meta-python \
  /home/patrick/yocto-new/poky/meta-pine64 \
  /home/patrick/yocto-new/poky/meta-mender/meta-mender-core \
  "

@ppeters Yes I’ve compiled arm64 bananpi-m64 machine with mender.
Please try to pull meta-mender-community repo and include meta-mender-sunxi layer in you bblayers.conf and see if it helps. There is config for aarch64 and also u-boot fixes.

Also above error shows that python3 dependency is missing but python3-native is present in poky layer already. I suggest to add above and make clean build (drop build/tmp directory) and see if it helps.

Thanks

Hi MarekBelisko,

I did not had the time yet to completely test your suggestion. I did a quick look at the meta-mender-community layer but it is also depending on meta-sunxi which does not (yet) support the Pine A64-LTS;
only the Pine A64+ (Plus).

It also looked to me as if this solution is somewhat a workaround for the meta-mender-core layer because if i take a quick look at the meta-mender-community solution i noticed that the MENDER_AUTO_CONFIGURE setting gets turned off.

Nonetheless i will try your solution tomorrow and see if i can get it working for
the Pine A64-LTS. Thanks and i will keep you informed of the progress.

@ppeters any update? Thanks.

Hi MarekBelisko,

Sorry for the late update but i also needed to finish some other work. I have tried your advise of meta-mender-community but still did not get it working. I first noticed the meta-sunxi layer that it also depends on does not have support for the Pine A64-LTS; only the Pine A64+ version. So i adapted some files in the meta-sunxi but also in the meta-mender-community to get a better match with my Pine A64-LTS board.

See the files below i changed or added:

I copied the file /meta-sunxi/conf/machine/pine64-plus.conf to a new file called: meta-sunxi/conf/machine/pine-a64-lts.conf
I changed the contents to match my pine A64-LTS board. The new file contains:

#@TYPE: Machine
#@NAME: pine-a64-lts
#@DESCRIPTION: Machine configuration for the pine-a64-lts, based on Allwinner A64 CPU


require conf/machine/include/sun50i.inc

KERNEL_DEVICETREE = "allwinner/sun50i-a64-pine64-lts.dtb"
UBOOT_MACHINE = "pine64-lts_defconfig"

I also added a new file to the meta-meder-community layer at:

meta-mender-community/meta-mender-sunxi/conf/machine/pine-a64-lts.conf
The contents of this file is shown below:

#@TYPE: Machine
#@NAME: Pine A64 LTS
#@DESCRIPTION: Machine configuration for the FriendlyARM Pine-A64-lts, based on the Allwinner A64 CPU

require conf/machine/include/sun50i.inc

KERNEL_DEVICETREE = "allwinner/sun50i-a64-pine64-lts.dtb"
UBOOT_MACHINE = "pine64-lts_defconfig"

PREFERRED_PROVIDER_virtual/kernel=  "linux-friendlyarm"

When i tried the above setup i got an error during the u-boot compiling complaining about that the binary size of the u-bboot image got to big. Larger than 0x7e000.
To fix this i changed the patch file at: meta-mender-community/meta-mender-sunxi/recipes-bsp/u-boot/files/0001-configs-sunxi-add-Mender-required-options.patch

to have a larger board size limit. the patch file now looks like:

From c338d50eb7e8e9d4ea4883a8f50894ca0a48c9ec Mon Sep 17 00:00:00 2001
From: Marek Belisko <marek.belisko@open-nandra.com>
Date: Wed, 5 Aug 2020 20:59:01 +0200
Subject: [PATCH] configs: sunxi: add Mender required options

Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
---
 include/configs/sunxi-common.h | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0ef289f..d8ca72f 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -125,6 +125,10 @@

 #if defined(CONFIG_ENV_IS_IN_MMC)

+#define CONFIG_BOOTCOUNT_LIMIT
+#define CONFIG_BOOTCOUNT_ENV
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+
 #ifdef CONFIG_ARM64
 /*
  * This is actually (CONFIG_ENV_OFFSET -
@@ -134,13 +138,6 @@
-#define CONFIG_BOARD_SIZE_LIMIT                0x7e000
+#define CONFIG_BOARD_SIZE_LIMIT                0x9ffff
 #endif

-#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
-/* If we have two devices (most likely eMMC + MMC), favour the eMMC */
-#define CONFIG_SYS_MMC_ENV_DEV         1
-#else
-/* Otherwise, use the only device we have */
-#define CONFIG_SYS_MMC_ENV_DEV         0
-#endif
 #define CONFIG_SYS_MMC_MAX_DEVICE      4
 #endif

--
2.7.4

After this change u-boot went fine but i got another error about vfat boot label too large (larger than 11 characters). I found an earlier message on the forum i think it was from you stating i should add the following to my local.conf: BOOTDD_VOLUME_ID = “boot”

My current local.conf now looks like the contents below:

#
# 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-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86-64 if no other machine is selected:
#MACHINE ??= "qemux86-64"
MACHINE ?= "pine-a64-lts"

#
# 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_rpm"
PACKAGE_CLASSES ?= "package_deb"

#
# 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"
SDKMACHINE ?= "aarch64"

#
# 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)
#  "src-pkgs"       - add -src packages for all installed packages
#                     (adds source code for debugging)
#  "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. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See classes/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO_qemuall = "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"

#
# Yocto Project SState Mirror
#
# The Yocto Project has prebuilt artefacts available for its releases, you can enable
# use of these by uncommenting the following line. This will mean the build uses
# the network to check for artefacts at the start of builds, which does slow it down
# equally, it will also speed up the builds by not having to build things if they are
# present in the cache. It assumes you can download something faster than you can build it
# which will depend on your network.
#
#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"

#
# Qemu configuration
#
# By default native qemu will build with a builtin VNC server where graphical output can be
# seen. The line below enables the SDL UI frontend too.
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
# By default libsdl2-native will be built, if you want to use your host's libSDL instead of
# the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
#ASSUME_PROVIDED += "libsdl2-native"

# You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds
# a handy set of menus for controlling the emulator.
#PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"

#
# Hash Equivalence
#
# Enable support for automatically running a local hash equivalence server and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact.
#
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#
#BB_HASHSERVE = "auto"
#BB_SIGNATURE_HANDLER = "OEEquivHash"

# 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"

INIT_MANAGER = "systemd"

DISTRO_FEATURES += "ipv4 ipv6 wayland opengl pam"
#IMAGE_INSTALL_append = " python3"

PACKAGECONFIG_append_pn-mesa = " gallium lima kmsro"

#IMAGE_FSTYPES = "ext4 wic.bz2"
IMAGE_FSTYPES = "sdimg"

# 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 = "Test1"

#INHERIT += "mender-full"

# The version of Mender to build. This needs to match an existing recipe in the meta-mender repository.
#
# Given your Yocto Project version, see which versions of Mender you can currently build here:
# https://docs.mender.io/overview/compatibility#mender-client-and-yocto-project-version
#
# Given a Mender client version, see the corresponding version of the mender-artifact utility:
# https://docs.mender.io/overview/compatibility#mender-clientserver-and-artifact-format
#
# Note that by default this will select the latest released version of the tools.
# If you need an earlier version, please uncomment the following and set to the
# required version.
#
# PREFERRED_VERSION_pn-mender = "2.6.0"
# PREFERRED_VERSION_pn-mender-artifact = "3.5.1"
# PREFERRED_VERSION_pn-mender-artifact-native = "3.5.1"

ARTIFACTIMG_FSTYPE = "ext4"

# Build for hosted Mender
#
# To get your tenant token:
#    - log in to https://hosted.mender.io
#    - click your email at the top right and then "My organization"
#    - press the "COPY TO CLIPBOARD"
#    - assign content of clipboard to MENDER_TENANT_TOKEN
#
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "test123"

# Build for Mender demo server
#
# https://docs.mender.io/administration/demo-installation
#
# Uncomment below and update IP address to match the machine running the
# Mender demo server
#MENDER_DEMO_HOST_IP_ADDRESS = "192.168.0.100"

# Build for Mender production setup (on-prem)
#
# https://docs.mender.io/administration/production-installation
#
# Uncomment below and update the URL to match your configured domain
# name and provide the path to the generated server.crt file.
#
# Note that a custom server.crt file is only necessary if you are using
# self-signed certificates.
#
# NOTE! It is recommend that you provide below information in your custom
# Yocto layer and this is only for demo purposes. See linked documentation
# for additional information.
#MENDER_SERVER_URL = "https://docker.mender.io"
#FILESEXTRAPATHS_prepend_pn-mender := "<DIRECTORY-CONTAINING-server.crt>:"
#SRC_URI_append_pn-mender = " file://server.crt"

# Custom mender image creation settings.

MENDER_STORAGE_DEVICE = "/dev/mmcblk0"

# Currently SD card is 15 900 000 000 bytes is (/1024/1024) 15163MB we will make a safety round down to 15000MB
MENDER_STORAGE_TOTAL_SIZE_MB="15000"

# Just to prevent wrong calculation results. The current image data will just fit fine in 7000MB of filesystem storage space
IMAGE_ROOTFS_SIZE="7000000"

IMAGE_OVERHEAD_FACTOR="1.15"

MENDER_BOOT_PART_SIZE_MB="256"

MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image mender-client-install mender-systemd mender-growfs-data mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"



IMAGE_INSTALL_append = " kernel-image kernel-devicetree"

# The Pine64LTS does not boot when using uImage which is the default,
# hence we change the default to zImage for all boards
#KERNEL_IMAGETYPE ?= "zImage"

IMAGE_BOOT_FILES = "boot.scr"

#MENDER_IMAGE_BOOTLOADER_FILE="u-boot-sunxi-with-spl.bin"
MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET="16"

# Pine64LTS, mmc index differs in U-boot and Linux. This configuration is for uSD.
MENDER_STORAGE_DEVICE_pine-a64-lts = "/dev/mmcblk0"
MENDER_UBOOT_STORAGE_DEVICE_pine-a64-lts = "0"

# Pine64LTS, uncomment this for eMMC. Remember to remove above!
#MENDER_STORAGE_DEVICE_pine-a64-lts = "/dev/mmcblk3"
#MENDER_UBOOT_STORAGE_DEVICE_pine-a64-lts = "1"

# Use BOOT VOLUME ID with short name or else image build fals on vfat name length max. 11 characters!
BOOTDD_VOLUME_ID = "boot"

After this change i did got an image. Actually i got multiple images. The strange thing is that one image called:

build/tmp/deploy/images/pine-a64-lts/core-image-base-pine-a64-lts-20210518072514.rootfs.sunxi-sdimg which is about 6880MB

and another image called:
build/tmp/deploy/images/pine-a64-lts/core-image-base-pine-a64-lts-20210518073723.sdimg which is about 14984MB.

The problem is that the first file (6880MB) contains a SPL header at the correct 0x2000 hex location but the second file only zero’s (0x00 hex). So i now only tried flashing the smaller file (6880MB) on my SDcard and tris booting from it. I got black screen and no info. I looked at it with my logic analyzer and got the following data out of the serial pins:

1/1/Bus1(UART)/1254/ /
T1/2/Bus1(UART)/2121/ /
T1/3/Bus1(UART)/2988/U/
T1/4/Bus1(UART)/3854/-/
T1/5/Bus1(UART)/4721/B/
T1/6/Bus1(UART)/5588/o/
T1/7/Bus1(UART)/6454/o/
T1/8/Bus1(UART)/7321/t/
T1/9/Bus1(UART)/8188/ /
T1/10/Bus1(UART)/9054/S/
T1/11/Bus1(UART)/9921/P/
T1/12/Bus1(UART)/10788/L/
T1/13/Bus1(UART)/11655/ /
T1/14/Bus1(UART)/12521/2/
T1/15/Bus1(UART)/13388/0/
T1/16/Bus1(UART)/14255/2/
T1/17/Bus1(UART)/15121/0/
T1/18/Bus1(UART)/15988/./
T1/19/Bus1(UART)/16855/0/
T1/20/Bus1(UART)/17721/1/
T1/21/Bus1(UART)/18588/-/
T1/22/Bus1(UART)/19455/g/
T1/23/Bus1(UART)/20321/3/
T1/24/Bus1(UART)/21188/0/
T1/25/Bus1(UART)/22055/3/
T1/26/Bus1(UART)/22921/f/
T1/27/Bus1(UART)/23788/8/
T1/28/Bus1(UART)/24655/f/
T1/29/Bus1(UART)/25521/e/
T1/30/Bus1(UART)/26388/ /
T1/31/Bus1(UART)/27255/(/
T1/32/Bus1(UART)/28121/J/
T1/33/Bus1(UART)/28988/a/
T1/34/Bus1(UART)/29855/n/
T1/35/Bus1(UART)/30721/ /
T1/36/Bus1(UART)/31588/0/
T1/37/Bus1(UART)/32455/6/
T1/38/Bus1(UART)/33321/ /
T1/39/Bus1(UART)/34188/2/
T1/40/Bus1(UART)/35055/0/
T1/41/Bus1(UART)/35921/2/
T1/42/Bus1(UART)/36788/0/
T1/43/Bus1(UART)/37655/ /
T1/44/Bus1(UART)/38521/-/
T1/45/Bus1(UART)/39388/ /
T1/46/Bus1(UART)/40255/2/
T1/47/Bus1(UART)/41121/0/
T1/48/Bus1(UART)/41988/:/
T1/49/Bus1(UART)/42855/5/
T1/50/Bus1(UART)/43721/6/
T1/51/Bus1(UART)/44588/:/
T1/52/Bus1(UART)/45455/3/
T1/53/Bus1(UART)/46321/1/
T1/54/Bus1(UART)/47188/ /
T1/55/Bus1(UART)/48055/+/
T1/56/Bus1(UART)/48922/0/
T1/57/Bus1(UART)/49788/0/
T1/58/Bus1(UART)/50655/0/
T1/59/Bus1(UART)/51522/0/
T1/60/Bus1(UART)/52388/)/
T1/61/Bus1(UART)/53255/ /
T1/62/Bus1(UART)/54122/ /
T1/63/Bus1(UART)/54988/D/
T1/64/Bus1(UART)/55855/R/
T1/65/Bus1(UART)/56722/A/
T1/66/Bus1(UART)/57588/M/
T1/67/Bus1(UART)/58455/:/
T1/68/Bus1(UART)/86898/ /
T1/69/Bus1(UART)/87765/2/
T1/70/Bus1(UART)/88631/0/
T1/71/Bus1(UART)/89498/4/
T1/72/Bus1(UART)/90365/8/
T1/73/Bus1(UART)/91232/ /
T1/74/Bus1(UART)/92098/M/
T1/75/Bus1(UART)/92965/i/
T1/76/Bus1(UART)/93832/B/
T1/77/Bus1(UART)/94698/ /
T1/78/Bus1(UART)/95565/ /
T1/79/Bus1(UART)/100240/T/
T1/80/Bus1(UART)/101106/r/
T1/81/Bus1(UART)/101973/y/
T1/82/Bus1(UART)/102840/i/
T1/83/Bus1(UART)/103706/n/
T1/84/Bus1(UART)/104573/g/
T1/85/Bus1(UART)/105440/ /
T1/86/Bus1(UART)/106306/t/
T1/87/Bus1(UART)/107173/o/
T1/88/Bus1(UART)/108040/ /
T1/89/Bus1(UART)/108906/b/
T1/90/Bus1(UART)/109773/o/
T1/91/Bus1(UART)/110640/o/
T1/92/Bus1(UART)/111506/t/
T1/93/Bus1(UART)/112373/ /
T1/94/Bus1(UART)/113240/f/
T1/95/Bus1(UART)/114106/r/
T1/96/Bus1(UART)/114973/o/
T1/97/Bus1(UART)/115840/m/
T1/98/Bus1(UART)/116706/ /
T1/99/Bus1(UART)/117573/M/
T1/100/Bus1(UART)/118440/M/
T1/101/Bus1(UART)/119306/C/
T1/102/Bus1(UART)/120173/1/
T1/103/Bus1(UART)/121040/ /
T1/104/Bus1(UART)/121906/ /

So the last line only says trying to boot from mmc1. I am stuck at this point. No mather what i try to adapt in my local.conf it alwayss says trying to boot from mmc1. It looks like the spl part is working but it cant start the u-boot or maybe a wrong entry point is used?

If you have any advise to solve this i highly appreciate it.
Thanks again for your help.

Hi,

ok thanks for info. I’ve hit similar issue today when build image for Banapi-m64 board which have same CPU basically. It hang on trying to boot from mmc1 and that’s it. I’ll inspect mender patches and check what can be wrong and keep you posted.

Thanks and BR

I’ve moved a forward a bit. By adding:

MENDER_IMAGE_BOOTLOADER_FILE="u-boot-sunxi-with-spl.bin"
MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET="16"

I was able to run u-boot but then it hangs because it cannot load devicetree like:

Found U-Boot script /boot.scr
402 bytes read in 2 ms (196.3 KiB/s)
## Executing script at 4fc00000
Saving Environment to MMC... Writing to redundant MMC(0)... OK
switch to partitions #0, OK
mmc0 is current device
25201152 bytes read in 2023 ms (11.9 MiB/s)
ERROR: Did not find a cmdline Flattened Device Tree
EHCI failed to shut down host controller.

Starting kernel ...

According google it looks like kernel override beginning of devicetree and thus cannot be loaded. I’ll continue with investigations and update it here.

@ppeters maybe can you add above variables to your config and give a try please?

Thanks.

Seems I fixed it. Problem was between keyboard and chair ;). By default u-boot look for devicetree in allwinner/board.dtb and mender image have it directly in /boot directory. When manually edited fdtfile variable board boots.

@ppeters can you please took this patch: sunxi: arm64 fixes by nandra · Pull Request #230 · mendersoftware/meta-mender-community · GitHub and try with your board. Please note that I also need to set: MENDER_STORAGE_DEVICE = "/dev/mmcblk2" because SDcard appear as mmcblkp2

@MarekBelisko
Thank you for keeping me informed. Good to hear you got it working. I am still stuck at the u-boot trying to boot from mmc. I think my problem is more of a SPL/u-boot issue because i normally use the meta-pine64 layer to get the SPL+u-boot working for my Pine-A64LTS board. I think the meta-sunxi layer misses some items which makes the u-boot incompatible with my board.

Can you provide me with some additional info on your solution, so for instance the contents of your bblayer and/or local.conf maybe i am still missing something else.

Hi, I think problem could be also ATF (Arm Trusted Firmware). I had now strange issue that board stays in Trying to boot from MMC1 and issue was that u-boot-sunxi-with-spl.bin don’t have AFT included. In this case nothing more was printed on console. Can you double check that (in compile logs etc.) Thanks.

Hi MarekBelisko,

I finally got it working, but i still had to use the meta-pine64 layer to get a good atf + u-boot starting point. After a lot of patching and trial on error i finally got a mix of meta-mender-community meta-mender-core and meta-pine64 working. I still got the same problem as you did with the dtb file in the /boot directory where mender tries to get it from /boot/allwinner/. I do not have a nice fix for this and just copied the file myself in the correct folder. I also still have another problem and that is with the fw_env.config.default environment is trying to store in mmcblk1 which i think should be mmcblk0. I have to look into that, but it probably is an easy fix.

Just for anyone trying to get the PineA64-LTS working, here are all the files i changed:

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-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86-64 if no other machine is selected:
#MACHINE ??= "qemux86-64"
MACHINE ?= "pine-a64-lts"

#
# 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_rpm"
PACKAGE_CLASSES ?= "package_deb"

#
# 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"
SDKMACHINE ?= "aarch64"

#
# 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)
#  "src-pkgs"       - add -src packages for all installed packages
#                     (adds source code for debugging)
#  "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. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See classes/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO_qemuall = "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"

#
# Yocto Project SState Mirror
#
# The Yocto Project has prebuilt artefacts available for its releases, you can enable
# use of these by uncommenting the following line. This will mean the build uses
# the network to check for artefacts at the start of builds, which does slow it down
# equally, it will also speed up the builds by not having to build things if they are
# present in the cache. It assumes you can download something faster than you can build it
# which will depend on your network.
#
#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"

#
# Qemu configuration
#
# By default native qemu will build with a builtin VNC server where graphical output can be
# seen. The line below enables the SDL UI frontend too.
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
# By default libsdl2-native will be built, if you want to use your host's libSDL instead of
# the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
#ASSUME_PROVIDED += "libsdl2-native"

# You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds
# a handy set of menus for controlling the emulator.
#PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"

#
# Hash Equivalence
#
# Enable support for automatically running a local hash equivalence server and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact.
#
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#
#BB_HASHSERVE = "auto"
#BB_SIGNATURE_HANDLER = "OEEquivHash"

# 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"

INIT_MANAGER = "systemd"

DISTRO_FEATURES += "ipv4 ipv6 wayland opengl pam"
#IMAGE_INSTALL_append = " python3"

PACKAGECONFIG_append_pn-mesa = " gallium lima kmsro"

#IMAGE_FSTYPES = "ext4 wic.bz2"
#IMAGE_FSTYPES = "sdimg"

# 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 = "Test1"

#INHERIT += "mender-full"

# The version of Mender to build. This needs to match an existing recipe in the meta-mender repository.
#
# Given your Yocto Project version, see which versions of Mender you can currently build here:
# https://docs.mender.io/overview/compatibility#mender-client-and-yocto-project-version
#
# Given a Mender client version, see the corresponding version of the mender-artifact utility:
# https://docs.mender.io/overview/compatibility#mender-clientserver-and-artifact-format
#
# Note that by default this will select the latest released version of the tools.
# If you need an earlier version, please uncomment the following and set to the
# required version.
#
# PREFERRED_VERSION_pn-mender = "2.6.0"
# PREFERRED_VERSION_pn-mender-artifact = "3.5.1"
# PREFERRED_VERSION_pn-mender-artifact-native = "3.5.1"

ARTIFACTIMG_FSTYPE = "ext4"

# Build for hosted Mender
#
# To get your tenant token:
#    - log in to https://hosted.mender.io
#    - click your email at the top right and then "My organization"
#    - press the "COPY TO CLIPBOARD"
#    - assign content of clipboard to MENDER_TENANT_TOKEN
#
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "test123"

# Build for Mender demo server
#
# https://docs.mender.io/administration/demo-installation
#
# Uncomment below and update IP address to match the machine running the
# Mender demo server
#MENDER_DEMO_HOST_IP_ADDRESS = "192.168.0.100"

# Build for Mender production setup (on-prem)
#
# https://docs.mender.io/administration/production-installation
#
# Uncomment below and update the URL to match your configured domain
# name and provide the path to the generated server.crt file.
#
# Note that a custom server.crt file is only necessary if you are using
# self-signed certificates.
#
# NOTE! It is recommend that you provide below information in your custom
# Yocto layer and this is only for demo purposes. See linked documentation
# for additional information.
#MENDER_SERVER_URL = "https://docker.mender.io"
#FILESEXTRAPATHS_prepend_pn-mender := "<DIRECTORY-CONTAINING-server.crt>:"
#SRC_URI_append_pn-mender = " file://server.crt"

# Custom mender image creation settings.

# Currently SD card is 15 900 000 000 bytes is (/1024/1024) 15163MB we will make a safety round down to 15000MB
MENDER_STORAGE_TOTAL_SIZE_MB="15000"

# Just to prevent wrong calculation results. The current image data will just fit fine in 7000MB of filesystem storage space
IMAGE_ROOTFS_SIZE="7000000"

IMAGE_OVERHEAD_FACTOR="1.15"

MENDER_BOOT_PART_SIZE_MB="256"

MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image mender-client-install mender-systemd mender-growfs-data mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"

IMAGE_INSTALL_append = " kernel-image kernel-devicetree"

# The Pine64LTS does not boot when using uImage which is the default,
# hence we change the default to Image for all boards
KERNEL_IMAGETYPE ?= "Image"
#KERNEL_IMAGETYPE ?= "vmlinux"


IMAGE_BOOT_FILES = "boot.scr sun50i-a64-pine64-lts.dtb;allwinner/sun50i-a64-pine64-lts.dtb"

MENDER_IMAGE_BOOTLOADER_FILE="u-boot-sunxi-with-spl.bin"
MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET="16"

# Pine64LTS, mmc index differs in U-boot and Linux. So MMC1 in u-boot is mmcblk0 in Linux kernel. This configuration is for uSD.
MENDER_STORAGE_DEVICE_pine-a64-lts = "/dev/mmcblk0"
MENDER_UBOOT_STORAGE_DEVICE_pine-a64-lts = "0"

MENDER_STORAGE_DEVICE = "/dev/mmcblk0"
MENDER_UBOOT_STORAGE_DEVICE = "0"

# Use BOOT VOLUME ID with short name or else image build fals on vfat name length max. 11 characters!
BOOTDD_VOLUME_ID = "BOOT"

CORE_IMAGE_EXTRA_INSTALL += " kernel-modules"

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/patrick/yocto-new2/poky/meta \
  /home/patrick/yocto-new2/poky/meta-poky \
  /home/patrick/yocto-new2/poky/meta-yocto-bsp \
  /home/patrick/yocto-new2/poky/meta-openembedded/meta-oe \
  /home/patrick/yocto-new2/poky/meta-pine64 \
  /home/patrick/yocto-new2/poky/meta-mender-community/meta-mender-sunxi \
  /home/patrick/yocto-new2/poky/meta-mender/meta-mender-core \
  "

meta-pine64/conf/machine/pine-a64-lts.conf

#@TYPE: Machine
#@NAME: Pine A64 LTS Board
#@DESCRIPTION: An Allwinner based development board https://www.pine64.org/

require conf/machine/include/arm/arch-arm64.inc
require conf/machine/include/a64.inc

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_MACHINE ?= "pine64-lts_defconfig"

PREFERRED_PROVIDER_virtual/kernel ?= "linux-pine64"
#KERNEL_CLASSES = "kernel-fitimage"
#KERNEL_IMAGETYPE = "fitImage"
KERNEL_IMAGETYPE ?= "Image"

# Don't change kernel_devicetree path or you end up with compile error about makefile no rule to make target
KERNEL_DEVICETREE = "allwinner/sun50i-a64-pine64-lts.dtb"

MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"

IMAGE_FSTYPES += "wic"
WKS_FILE ?= "pine64-bsp-image.wks"

IMAGE_BOOT_FILES ?= " \
    Image \
    allwinner/sun50i-a64-pine64-lts.dtb \
    boot.scr \
    "

WKS_FILE_DEPENDS ?= " \
    mtools-native \
    dosfstools-native \
    virtual/bootloader \
    virtual/kernel \
    "

SERIAL_CONSOLES = "115200;ttyS0"
MACHINE_FEATURES = "alsa apm keyboard rtc serial screen touchscreen usbgadget usbhost vfat ext2 ext3"

meta-pine64/conf/machine/include/a64.inc

SOC_FAMILY = "a64"

require conf/machine/include/soc-family.inc

PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
UBOOT_BINARY ?= "u-boot-sunxi-with-spl.bin"
SPL_BINARY ?= "spl/sunxi-spl.bin"
UBOOT_ENTRYPOINT = "0x40080000"
UBOOT_DTB_LOADADDRESS = "0x4FA00000"
UBOOT_ENV ?= "boot"
UBOOT_ENV_SUFFIX ?= "scr"

TFA_PLATFORM = "sun50i_a64"
TFA_BUILD_TARGET = "bl31"

meta-pine64/recipes-bsp/u-boot/u-boot_%.bbappend

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI_append_a64 = " \
    file://boot.cmd \
    file://0001-sun6i-Increase-the-maximum-UART-baud-rate.patch \
    "

DEPENDS_append_a64 = " u-boot-tools-native"

ATF_DEPENDS ??= ""

EXTRA_OEMAKE_append_a64 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-pine-a64-lts.bin"
ATF_DEPENDS_a64 = " virtual/arm-trusted-firmware:do_deploy"

EXTRA_OEMAKE_append_h6 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-pine-a64-lts.bin"
ATF_DEPENDS_h6 = " virtual/arm-trusted-firmware:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

do_configure_prepend_a64() {
    mkimage -A arm -O linux -T script -C none -n "U-Boot boot script" \
        -d ${WORKDIR}/boot.cmd ${WORKDIR}/${UBOOT_ENV_BINARY}
}

#FILES_${PN}_append_a64 = " /boot/boot.scr"

meta-pine64/recipes-bsp/u-boot/files/boot.cmd

# Default to (primary) SD
rootdev=mmcblk0p2
if itest.b *0x28 == 0x02 ; then
        # U-Boot loaded from eMMC or secondary SD so use it for rootfs too
        echo "U-boot loaded from eMMC or secondary SD"
        rootdev=mmcblk1p2
fi
setenv bootargs console=${console} console=tty1 root=/dev/${rootdev} rootwait panic=10 ${extra}
load mmc 0:1 ${fdt_addr_r} ${fdtfile}
load mmc 0:1 ${kernel_addr_r} Image
booti ${kernel_addr_r} - ${fdt_addr_r}

meta-pine64/recipes-kernel/linux/linux-pine64_5.11.bb

DESCRIPTION = "Mainline Linux kernel with touchscreen support for Pine64"
SECTION = "kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

LINUX_VERSION ?= "5.11"
LINUX_VERSION_EXTENSION = "-mainline"
KERNEL_VERSION_SANITY_SKIP="1"

BRANCH = "linux-5.11.y"
SRCREV = "${AUTOREV}"

PV = "${LINUX_VERSION}+git${SRCPV}"

SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git;branch=${BRANCH} \
           file://0002-arm64-allwinner-sopine-baseboard-Enable-Bluetooth-an.patch \
           file://0003-arm64-allwinner-pine64-Enable-Bluetooth-and-WiFi.patch \
           file://0004-arm64-allwinner-sopine-baseboard-Enable-FeiyangFY070.patch \
           file://0006-drivers-sunxi-mmc-Don-t-specify-PROBE_PREFER_ASYNCHR.patch \
           file://extra.cfg \
           file://screen.cfg \
           file://battery.cfg \
           file://pine_a64lts_kernel_config_armbian.cfg \
          "

KBUILD_DEFCONFIG_sopine-a64 = "defconfig"
KBUILD_DEFCONFIG_pine-a64-lts = "defconfig"
KCONFIG_MODE="--alldefconfig"

COMPATIBLE_MACHINE = "pine-a64-lts"

meta-mender-community/meta-mender-sunxi/conf/layer.conf

# Copyright 2018 Northern.tech AS

# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
        ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "mender-sunxi"
BBFILE_PATTERN_mender-sunxi = "^${LAYERDIR}/"
BBFILE_PRIORITY_mender-sunxi = "11"

LAYERSERIES_COMPAT_mender-sunxi = "thud warrior zeus dunfell"

LAYERDEPENDS_mender-sunxi = "pine64-layer"

meta-mender-community/meta-mender-sunxi/conf/machine/pine-a64-lts.conf

#@TYPE: Machine
#@NAME: Pine A64 LTS
#@DESCRIPTION: Machine configuration for the FriendlyARM Pine-A64-lts, based on the Allwinner A64 CPU

require conf/machine/include/arm/arch-arm64.inc
require conf/machine/include/a64.inc
#require conf/machine/include/sun50i.inc

KERNEL_DEVICETREE = "allwinner/sun50i-a64-pine64-lts.dtb"

UBOOT_MACHINE = "pine64-lts_defconfig"

#PREFERRED_PROVIDER_virtual/kernel=  "linux-friendlyarm"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-pine64"

meta-mender-community/meta-mender-sunxi/recipes-bsp/u-boot/files/0001-configs-sunxi-add-Mender-required-options.patch

From c338d50eb7e8e9d4ea4883a8f50894ca0a48c9ec Mon Sep 17 00:00:00 2001
From: Marek Belisko <marek.belisko@open-nandra.com>
Date: Wed, 5 Aug 2020 20:59:01 +0200
Subject: [PATCH] configs: sunxi: add Mender required options

Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
---
 include/configs/sunxi-common.h | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0ef289f..d8ca72f 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -125,6 +125,10 @@

 #if defined(CONFIG_ENV_IS_IN_MMC)

+#define CONFIG_BOOTCOUNT_LIMIT
+#define CONFIG_BOOTCOUNT_ENV
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+
 #ifdef CONFIG_ARM64
 /*
  * This is actually (CONFIG_ENV_OFFSET -
@@ -134,13 +138,6 @@
-#define CONFIG_BOARD_SIZE_LIMIT                0x7e000
+#define CONFIG_BOARD_SIZE_LIMIT                0xaffff
 #endif

-#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
-/* If we have two devices (most likely eMMC + MMC), favour the eMMC */
-#define CONFIG_SYS_MMC_ENV_DEV         1
-#else
-/* Otherwise, use the only device we have */
-#define CONFIG_SYS_MMC_ENV_DEV         0
-#endif
 #define CONFIG_SYS_MMC_MAX_DEVICE      4
 #endif

--
2.7.4

meta-mender-community/meta-mender-sunxi/recipes-kernel/linux/linux-pine64_%.bbappend

do_kernel_configme[depends] += "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
do_kernel_configme[depends] += "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
do_kernel_configme[depends] += "bc-native:do_populate_sysroot bison-native:do_populate_sysroot"

It would be nice if the maintainer of meta-sunxi integrates the meta-pine64 items so in the future we can directly let mender-meta-core also depend on meta-sunxi again for this board…

1 Like

Thanks for sharing. I’ll look at dtb and will try to resolve it in meta-mender-community for sunxi.