Re: [yocto] Warning about auto generated BSP description
Your kernel recipe needs to have an entry for the machine, e.g. a kernel recipe called linux-mainline.bb contains COMPATIBLE_MACHINE_mymachine = "mymachine" Also, your machine config file mymachine.conf needs to have a preferred kernel version, e.g: PREFERRED_PROVIDER_virtual/kernel ?= "linux-mainline" PREFERRED_VERSION_linux-yocto ?= "3.19%" PREFERRED_VERSION_linux-mainline ?= "4.2%" (I am not certain these will fix your error but you should have them defined.) -Rob On 9/13/15, 4:15 PM, "yocto-boun...@yoctoproject.org on behalf of Paul D. DeRocco" wrote: >I'm getting the following warning: > >[kernel]: An auto generated BSP description was used, this normally >indicates a misconfiguration. >Check that your machine (chroma-bsp) has an associated kernel description. > >Googling turns up the information that this is sometimes a spurious error >and nothing to worry about, because a full BSP description isn't strictly >required. However, as far as I can see I do indeed have a BSP description. >I built the BSP using the yocto-bsp tool. It created a >linux-yocto-rt_3.14.bbappend (since I'm using the RT kernel), and the >following files: > >chroma-bsp.cfg >chroma-bsp.scc >chroma-bsp-preempt-rt.scc >chroma-bsp-standard.scc >chroma-bsp-tiny.scc >chroma-bsp-user-config.cfg >chroma-bsp-user-features.scc >chroma-bsp-user-patches.scc > >The bbappend refers to chroma-bsp-preempt-rt.scc and the last three >(empty) files. chroma-bsp-preempt-rt.scc contains the requisite KMACHINE, >KTYPE and KARCH, and includes chroma-bsp.scc, which refers to >chroma-bsp.cfg. This seems to fit the definition of a "BSP description" in >3.4.5 of the Kernel Development Manual. The whole BSP tree is called >"meta-chroma-bsp" and that is indeed listed in my bblayers.conf. So why is >it complaining? > >Also, I don't know that "Check that your machine has an associated kernel >description" means. The term "kernel description" doesn't appear anywhere >in the docs. > >-- > >Ciao, Paul D. DeRocco >Paulmailto:pdero...@ix.netcom.com > >-- -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issues with yocto and kernel option CONFIG_MULTIUSER
A new kernel feature, CONFIG_MULTIUSER, was added to the linux kernel in 4.1: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2813893f8b197a14f1e1ddb04d99bce46817c84a This advanced kernel option defaults to “y", see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/Kconfig?id=refs/tags/v4.2 This kernel option is potentially helpful to embedded system developers because it enables a smaller kernel. However in the short term it causes several problems that are only apparently at runtime, most seriously that dropbear logins fail at runtime with "Exit (root): Failed to set euid”. Numerous busybox commands also fail, see http://lists.busybox.net/pipermail/busybox/2015-May/082910.html I encountered this issue because yocto’s kernel_configme() step uses the “allnoconfig” upgrade option rather than the “oldnoconfig” option, and do_kernel_configme() runs before do_configure(). Silent upgrades should be done with “oldnoconfig”. I have filed a bug on this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8289 I know the latest yocto-supported kernel is 3.19, but wanted to give users who are building newer kernels a heads-up about the CONFIG_MULTIUSER change to avoid unexpected ssh lockout. Rob Calhoun -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 4/30/15 10:06 AM, "Bruce Ashfield" wrote:
>On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote:
>>> What kernel recipe is used when your machine is set to 'astro' ?
>>> Something custom ? Or have you added machine compatibility to another
>>> known kernel recipe ?
>>
>> How would I see which kernel recipe is used?
>
>This is where my brute force techniques probably break down. I just
>do a 'bitbake virtual/kernel' and you'll see it display which
>recipe is being built.
>
>If you haven't added compatibility for your new machine to any
>recipe, I'm betting that linux-dummy is used.
>
>>
>> I did not customize anything except for aforementioned steps, simply
>>copied beaglebone.conf to astro.conf in the same directory. Also I did
>>not touch any kernel recipes (kernel is built externally), maybe that's
>>what's missing?
>
>It is plausible. But in theory, linux-dummy should still provide
>what you need (but since it doesn't build anything, there is
>no abi .. and no modules can be built against it) .. so the
>error isn't graceful.
>
>Bruce
>
>>
>> Jan
>>
I encountered the same error ("ERROR: No kernel-abiversion file found
(build/tmp/sysroots/{machinename}/pkgdata/kernel-depmod/kernel-abiversion),
cannot run depmod, aborting") after porting my system from poky-daisy to
poky-fido. My machine config sets PREFERRED_PROVIDER_virtual/kernel =
"linux-dummy", as we currently use a monolithic out-of-tree 2.6 kernel.
It's a clean fido checkout, and I tried trashing tmp and rebuilding
everything to no effect.
Based on
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image.bbcl
ass I have worked around this by setting:
USE_DEPMOD = "0"
in my image configuration. This works, and allows the root file system to
be built.
Is it a bug that depmod is not skipped automatically when linux-dummy is
specified? Am I risking death and destruction by overriding it? (We don't
have any kernel modules.)
Thanks,
Rob Calhoun
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?
On 4/22/14 3:57 AM, "Neuer User" wrote:
>Sorry for this simple question. I've just started building my first
>image with yocto and would now like to add a (very simple) own recipe.
(I am not familiar with gstreamer, but it looks like a big project and
maybe not so simple!)
The yocto build system figures out dependencies and build order, sets the
environment, and generates shell scripts to do the actual tasks. The
actual "work" is done by these shell scripts, not by the python code.
Your recipe explicitly defines some steps like do_compile(). When you do
this, you are saying "Let me control the compilation, I know what I am
doing!". Your do_compile() step is going to generate a run.do_compile
script, and that has to work just as if you were running the script
yourself.
If something doesn't work, try "bitbake {pkg} -c devshell". That will
drop you into the environment the compiler is going to see. The shell
scripts are in ../temp. Each script is a single step (do_compile etc). All
of the substitutions that Richard described will already have been made;
and you will see all the environment variables being set and the calls
made to the compiler, linker etc. This directory also contains the log
files from recent executions.
You can run these manually, e.g. ../temp/run.do_compile. (The files
without PIDs are symlinks to the latest script.) You can edit this script
and re-run the compile and link step until it works. Once you've figured
out what needs to be set or run, modify the recipe to generate that
environment or command.
An important thing to understand is that each step lives in its own little
world; an environment variable set in the do_compile is not present in
do_install unless you put it there. Avoidance of global state allows the
build system to run multiple tasks in parallel.
-Rob Calhoun
(still figuring this stuff out myself)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRCREV how is it supposed to work?
-Original Message-
From: Paul Eggleton
>
>AFAIK, there are two recommended values for SRCREV assuming you are
>fetching
>from an SCM at all:
>
>A) A specific revision (SHA1 hash when fetching from git)
>
>or
>
>B) "${AUTOREV}" if you want to always build the latest version available
>at
>time of building. If you want to build the latest version from a branch,
>specify it in branch= in the SRC_URI entry.
>
>Anything else isn't really a good idea. Sometimes I wonder if we ought to
>just
>tighten this up so that only settings that make sense can be set.
The current behavior is a little non-intuitive, since using SRCREV =
"${AUTOREV}"
alone will not force the package to be rebuilt when SRCREV changes. Unless
I am
mistaken, $PV needs to be modified also. But modifying $PV causes its own
headaches with patching, so I've ended up using recipes based on the model
below.
Another challenge is that bitbake's fetch2 is not very well documented. I
don't
think the "user" and "pswd" fields for the svn fetcher are documented
anywhere
outside of the source code.
I'd love to help address this, but I'm not sure where I should submit
updated documentation. Is this the right place?
git://git.yoctoproject.org/yocto-docs
Hans, below is a model recipe for building current head-of-line from a
subversion repository:
-Rob Calhoun
SST Inc
##
DESCRIPTION = "example_1.0.bb, autorevving checkout example"
# This says look for LICENSE in the root of the directory being checked
out. Fix
# license filename and md5sum as required.
LIC_FILES_CHKSUM = "file://LICENSE;md5=abc123"
# this is the rev of your recipe. Bumping it will toss the cache and redo
everything
PR = "r1"
# pick up latest svn rev for this module. Note this a deferred evaluation!
SRCREV = "${AUTOREV}"
# ${PV} is pulled from the recipe filename, e.g. helloworld_2.7.bb ->
${PV} expands to "2.7".
# We use immediate evaluation to define a new var PVBASE holding the
original value of ${PV}.
PVBASE := "${PV}"
# We need to tell bitbake about our current directory structure or we
won't be able to find patches after we mess with ${PV}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PVBASE}:"
# Then redefine PV to tack the svn rev onto the base version. This is
evaluated at fetch time.
# Then the package will get rebuilt any time the relevant part of the
source tree changes.
PV = "${PVBASE}.${SRCPV}"
# Now we format the source code URI.
# There is nothing special about "module"; it is just the final directory
of the svn checkout.
# SRC_URI below is equivalent to the svn command:
# "svn checkout --username=poky --password=xyzzy
https://svn.example.com/repo/trunk/example";
#
SRC_URI=
"svn://svn.example.com/repo/trunk;module=example;protocol=https;user=poky;p
swd=xyzzy"
# build will fail without this; it specifies where in the workdir to find
the source. The
# name must be the same as the "module" name in SRC_URI.
S = "${WORKDIR}/example"
# BELOW NOT PART OF RECIPE; IT SHOWS WHAT THE WORK DIR LOOKS LIKE WITH
THIS RECIPE.
# By setting PV, the cache is invalidated and new code checked out each
time the
# relevant part oF the svn repo gets updated because I've made the svn
revision look
# like a package version number to bitbake.
#
# Here is a directory listing of the work dir:
#
#
poky@build:/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/example$
ls -l
#drwxrwxr-x 12 poky poky 4096 Oct 30 10:17 1.0.57400-r1
#drwxrwxr-x 12 poky poky 4096 Oct 30 11:52 1.0.57401-r1
#drwxrwxr-x 12 poky poky 4096 Oct 31 12:37 1.0.57408-r1
#drwxrwxr-x 12 poky poky 4096 Nov 1 07:56 1.0.57412-r1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
