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.
