meta-ti

has anyone worked with meta-ti in yocto?
I am experincing some issues durring boot time (kernel panic for missing rfs)

and was wondering if I am doing somthingg wrong

here are my layers

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /mnt/yoctomnt/myyocto/poky/meta \
  /mnt/yoctomnt/myyocto/poky/meta-poky \
  /mnt/yoctomnt/myyocto/poky/meta-yocto-bsp \
  /mnt/yoctomnt/myyocto/meta-openembedded/meta-oe \
  /mnt/yoctomnt/myyocto/meta-arm/meta-arm-toolchain \
  /mnt/yoctomnt/myyocto/meta-arm/meta-arm \
  /mnt/yoctomnt/myyocto/meta-ti/meta-ti-bsp \
  /mnt/yoctomnt/myyocto/meta-ti/meta-ti-extras \
  "

in my local.cong only added beaglebone machine and I am using beaglebone black

Post your local.conf and what MACHINE= are you using?

I just built this a few minutes ago, it boots and has networking. Have not tested it other than boot up and eth connectivity.

Branch: Kirkstone
Poky: Just pulled it prior to the build so we should be close to the same page.

Layers:

fred@eng-dev2:~/build1/bbb/build_bbb_1$ bitbake-layers show-layers
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /home/fred/code/poky/meta                 5
meta-poky             /home/fred/code/poky/meta-poky            5
meta-yocto-bsp        /home/fred/code/poky/meta-yocto-bsp       5

Here is my local.conf for this build. After you source your build just overwrite with this local.conf.

Note that some of the file paths will need to be tuned to your machine.

MACHINE ?= "beaglebone-yocto"
# change this path for your local build machine
# if you have NVMe drive on the machine, place this stuff on NVMe.
DL_DIR ?= "/home/fred/code/downloads"

#Keep the arm64 and armhf sstate-cache in different directories.
SSTATE_DIR ?= "/home/fred/code/sstate-cache-armhf"
#SSTATE_DIR ?= "/home/fred/code/sstate-cache"
DISTRO ?= "poky"

#Use deb so if you need a package just rsync the .deb onto the target
#and use $dpkg -i  <name of package>.deb
PACKAGE_CLASSES ?= "package_deb"
EXTRA_IMAGE_FEATURES ?= " debug-tweaks tools-sdk"
#if you need more tools
#EXTRA_IMAGE_FEATURES ?= "debug-tweaks tools-debug tools-testapps tools-sdk dbg-pkgs dev-pkgs"

PACKAGE_EXCLUDE = "packagegroup-core-ssh-dropbear"

USER_CLASSES ?= "buildstats"


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 than 100MB or 1K inodes, perform a hard halt
# 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 necessary 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 \
    HALT,${TMPDIR},100M,1K \
    HALT,${DL_DIR},100M,1K \
    HALT,${SSTATE_DIR},100M,1K \
    HALT,/tmp,10M,1K"


PACKAGECONFIG:append:pn-qemu-system-native = " sdl"


CONF_VERSION = "2"
IMAGE_INSTALL:append = " apt sudo python3 rsync pstree openssh cmake gdb openssl acl make xz gzip"

As far as using the meta-ti, you will have to work on those if you need to use them.

What I provided is very stable and whomever maintains the MACHINE= “beaglebone-yocto” deserves all the credit for the layer and the time spent keeping it working.

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

MACHINE ?= "beaglebone"

#
# This sets the default machine to be qemux86-64 if no other machine is selected:
MACHINE ??= "qemux86-64"

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

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

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
#  "dbg-pkgs"       - add -dbg packages for all installed packages
#                     (adds symbol information for debugging/profiling)
#  "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
USER_CLASSES ?= "buildstats"

#
# 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 than 100MB or 1K inodes, perform a hard halt
# 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 necessary 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 \
    HALT,${TMPDIR},100M,1K \
    HALT,${DL_DIR},100M,1K \
    HALT,${SSTATE_DIR},100M,1K \
    HALT,/tmp,10M,1K"

#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can be
# 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 https 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://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
#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 lines. 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.
# Note: For this to work you also need hash-equivalence passthrough to the matching server
#
#BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/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"

#
# Memory Resident Bitbake
#
# Bitbake's server component can stay in memory after the UI for the current command
# has completed. This means subsequent commands can run faster since there is no need
# for bitbake to reload cache files and so on. Number is in seconds, after which the
# server will shut down.
#
#BB_SERVER_TIMEOUT = "60"

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



beaglebone-yocto is amazing and the runqemu support is great

but I am trying to test the bsp because it has all the features like cap support,rtu, etc…

What recipe are you using?

nothing extra than core-image-minimal

I think the BSP just changes the kernel and adds some device tree binaries

That is part of the problem, this is exactly as it is stated “minimal”. That is what I used for the image that was just built.

Might try core-image-base and see if that has the packages you need.

Not sure what is cap support?

A summary:

u-boot was loading a config file /extlinux/extlinux.conf from the boot partition. This file contained the line:

APPEND root=PARTUUID=${uuid} rootwait rw earlycon console=${console},${baudrate}

But it seems the ${uuid} variable was not set.

The result was that the kernel panicked when it attempted to load the root device.

Manually changing the line in the config file to

APPEND root=/dev/mmcblk0p2 rootwait rw earlycon console=${console},${baudrate}

worked around the issue (although there may be some kind of intermittent error)

it worked, but I hope meta-ti maintainers look into this

2 Likes

Hello,
I am myself also fighting with the meta-ti layer on Kirkstone… I did not have this exact issue as yours, mine is somewhat similar: kworker fails during boot? - #3 by bremenpl

I have noticed that as soon as I remove the meta-ti-bsp and meta-ti-extras and go back to meta-yocto-bsp, this problem is mitigated.

Similar to your case, I went the meta-ti way to get more bsp support (PRU specifically). But maybe its easier to stick with meta-yocto-bsp and somehow try to add that support by hand…

The problem with the meta-yocto-bsp however is that my device tree overlay is not loaded during boot, while it was working for the meta-ti image…

my experience with meta-ti was extremely unpleasant and had many more issues later with adding some packages, I can live without RTU and cape support.

but is that only it?

does using meta-yocto-bsp give many compromises or is fine?

btw I also get your exact kworker error and I have to restart until it goes away.

this bsp is not good at all, at least for beaglebone black.

Hi @kemo_2001 and thank you for the answer.

my experience with meta-ti was extremely unpleasant and had many more issues later with adding some packages, I can live without RTU and cape support.

I also do not need these. My aim when going with meta-ti was simply because I assumed (maybe incorrectly as I am learning all the time) that this BSP would be better prepared for the BBB. In my project I need PRU support, and I have seen that it is within the meta-ti.

but is that only it?

No idea really.

does using meta-yocto-bsp give many compromises or is fine?

So far I haven’t decided on whether to use meta-yocto-bsp or meta-ti yet. I started off on Dunfell, and It feels that things were working a lot better there with meta-ti, but I was not able to get my custom DTS working (as I have discussed here in this lengthy topic):

Only after switching to Kirkstone, the DTS started to work on meta-ti.

btw I also get your exact kworker error and I have to restart until it goes away.

This is good to hear that I am not mad and this BSP is broken. Like said, this did not happen on Dunfell. But because of this problem + slow boot related to some I2C devices probing on bus 2 (which is always timing out) I decided to test meta-yocto-bsp.

in here there is no kworker issue or boot i2c probing (although i2c 2 is timing out when used with i2cdetect), but my custom overlay cannot be loaded anymore!

The other problem with meta-ti is that the boot partition cannot be mounted:

So all and all- I cannot use any of the 2 BSPs (meta-ti or meta-yocto-bsp), as both seem to not be “working good enough” for my (as I thought initially) basic purpose (at least on Kirkstone).

@kemo_2001 can you tell which bsp did you finally end up using?

You can try to use different reference distro other than poky, like Angstrom Which seems to be the default for beagleboards.

I will try to contact the maintainers to confirm the support issues and also look into using Angstrom instead of poky.

I will let you know if I find anything useful and let me know if you find anything as well.

Did that come back to life? A while back I was looking into it and what was found indicated it is extinct.

Will it seems to be the default distro installed on the eMMC but I don’t know how well is it on open embedded nowadays, but meta-ti readme states that it is supported

I am desperate and trying anything at this point.

Sounds good, thanks!

Did that come back to life? A while back I was looking into it and what was found indicated it is extinct.

I also thought this one is dead.

Will it seems to be the default distro installed on the eMMC

I dont know what is on the emmc by default, but I would guess that the production binary in the fab was not updated in years. The officially supported images from beaglebone.org are Debians I think.

Today I will also try to change the uboot version to a newer one (in poky) to see whether that resolves this device tree overlay problem.