On 2016-09-09 2:33 PM, Clark, Mark A wrote:
All, I am still running into issues on building the RT image. I was
able to configure poky/jethro to create the core-image-rt. That being
said the kernel boot would hang at switching clock source “Switching to
clocksource tsc”. I was attempting to run down the issue there when
the 2.1 krogoth came along and looked promising given the kernel version
advance.
It is very unclear which items need to be tweaked to get a rt build as
the other recipes just work. Granted changing the kernel-source makes
sense due to it being a modified kernel.
Prior to Yocto I used Gentoo and patched the compatible kernel for
real-time before building the target. Yocto seems promising in that it
is more cohesive.
The two requirements I need are 1) real-time kernel and 2) genericx86
arch. Beyond changing local.conf to facilitate this I am at a loss as
to what needs changing to accomplish this.
The thing that is missing is a valid board definition for genericx86
and preempt-rt.
What I mean by "valid", is described in the Yocto project kernel manual
and BSP guide.
It is essential the entry point to the kernel configuration and patching
process and is what I had provided in that example .scc file.
For whatever reason, your build isn't picking up the board definition
while mine is (hence why you were getting a warning about an auto
generated BSP).
If you navigate your way to the kernel source directory (aka ${S},
which should be work-shared/genericx86/kernel-source), and look
in the .kernel-meta subdirectory, there's a file called "top_tgt".
If that isn't pointing at the the .scc file I sent, then the autogen
one is being used.
I can do another build on Monday, but it did work for me, and without
access to exactly your layers, it is hard to debug more.
Cheers,
Bruce
Enclosed are the files Bruce created as a scratch example of the recipes
and my local.conf file.
genericx86-preempt-rt.scc:
============================
define KMACHINE genericx86
define KTYPE preempt-rt
define KARCH i386
# no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch
include ktypes/preempt-rt/preempt-rt.scc
include bsp/common-pc/common-pc.scc
# default policy for preempt-rt kernels
include cfg/boot-live.scc
include cfg/usb-mass-storage.scc
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc
include cfg/virtio.scc
linux-yocto_4.4.bbappend:
===============================================
KBRANCH_genericx86 = "standard/base"
KBRANCH_genericx86-64 = "standard/base"
KMACHINE_genericx86 ?= "common-pc"
KMACHINE_genericx86-64 ?= "common-pc-64"
KBRANCH_edgerouter = "standard/edgerouter"
KBRANCH_beaglebone = "standard/beaglebone"
KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
SRCREV_machine_genericx86 ?= "3d2455f9da30f923c6bd69014fad4cc4ea738be6"
SRCREV_machine_genericx86-64 ?= "3d2455f9da30f923c6bd69014fad4cc4ea738be6"
SRCREV_machine_edgerouter ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
SRCREV_machine_beaglebone ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
SRCREV_machine_mpc8315e-rdb ?= "df00877ef9387b38b9601c82db57de2a1b23ce53"
COMPATIBLE_MACHINE_genericx86 = "genericx86"
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
COMPATIBLE_MACHINE_beaglebone = "beaglebone"
COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
LINUX_VERSION_genericx86 = "4.4.3"
LINUX_VERSION_genericx86-64 = "4.4.3"
FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto-4.4:"
SRC_URI += " file://genericx86-preempt-rt.scc"
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 ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for
# demonstration purposes:
#
#MACHINE ?= "beaglebone"
MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is
selected:
MACHINE ??= "qemux86"
#
# 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}/realtime"
#
# 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/ADT target architecture
#
# This variable specifies the architecture to build SDK/ADT items for
and means
# you can build the SDK packages for architectures other than the
machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686 and x86_64
SDKMACHINE ?= "i686"
#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to
the generated
# images. Some of these options are added to certain image types
automatically. The
# variable can contain the following options:
# "dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "dev-pkgs" - add -dev packages for all installed packages
# (useful if you want to develop against libs in the
image)
# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
# (useful if you want to run the package test suites)
# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
# "tools-debug" - add debugging tools (gdb, strace)
# "eclipse-debug" - add Eclipse remote debugging support
# "tools-profile" - add profiling tools (oprofile, exmap, 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
# - 'image-swab' to perform host system intrusion detection
# NOTE: if listing mklibs & prelink both, then make sure mklibs is
before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image,
see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu
(an emulator)
# after any root filesystems are created and run tests against those
images. To
# enable this uncomment this line. See classes/testimage(-auto).bbclass for
# further details.
#TEST_IMAGE = "1"
#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to
do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than
one parallel
# process may require the user's attention. The default is iterate over
the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches
which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x
only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail
instead):
PATCHRESOLVE = "noop"
#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of
space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR,
SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes, perform
a hard abort
# of the build. The reason for this is that running completely out of
space can corrupt
# files and damages the build in ways which may not be easily recoverable.
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects
which can
# used to accelerate build time. This variable can be used to configure
the system
# to search other mirror locations for these objects before it builds
the data itself.
#
# This can be a filesystem directory, or a remote url such as http or
ftp. These
# would contain the sstate-cache results from previous builds (possibly
from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and
points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to
add PATH
# at the end as shown in the examples below. This will be substituted
with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH
\n \
#file://.* file:///some/local/dir/sstate/PATH"
#
# Qemu configuration
#
# By default qemu will build with a builtin VNC server where graphical
output can be
# seen. The two lines below enable the SDL backend too. This assumes
there is a
# libsdl library available on your build system.
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
ASSUME_PROVIDED += "libsdl-native"
# CONF_VERSION is increased each time build/conf/ changes incompatibly
and is used to
# track the version of this file when it was generated. This can safely
be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"
COMPATIBLE_MACHINE_genericx86 = "genericx86"
PREFERED_PROVIDER_virtual/kernel = "linux-yocto-rt"
*Mark Clark*
Embedded Software Engineer
Embedded Software, Cedar Park, TX
Description: Description: Description: Description: National Oilwell
Varco Logo Color CMYK.jpg
Wellbore Technologies – Dynamic Drilling Solutions
Global Software Engineering
Office: (512) 340-5435
Mobile: (512) 736-9396
/“One Team – Infinite Solutions”/
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
