from:"Bruce Ashfield"

[yocto] [PATCH 2/2] linux-yocto/meta: cleanup and streamline kernel meta data

2011-04-01 Thread Bruce Ashfield

Fixes [YOCTO #945]

As part of the update to 2.6.37 existing configuration and
patches from the -stable kernel were left in place as a reminder
of features and configuration carry forward. A lot of these
reminders are no longer necessary and the kernel meta data
needs to be cleaned up to prepare for activities related to
newer kernels.

Also in this meta update are configuration changes to allow
common_pc derived BSPs to have a clean baseline configuration.

Signed-off-by: Bruce Ashfield 
---
 .../conf/distro/include/poky-default-revisions.inc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/include/poky-default-revisions.inc 
b/meta/conf/distro/include/poky-default-revisions.inc
index a2b6a98..9a3ae7e 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -109,7 +109,7 @@ SRCREV_machine_pn-linux-yocto_routerstationpro ?= 
"8db69980d76e1f863af409e701759
 SRCREV_machine_pn-linux-yocto_mpc8315e-rdb ?= 
"6861d8a4d58f8aa75997f7678cc454791544507a"
 SRCREV_machine_pn-linux-yocto_beagleboard ?= 
"69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
 SRCREV_machine_pn-linux-yocto ?= "69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
-SRCREV_meta_pn-linux-yocto ?= "51c761795b078bf3c80104ed6e73b3d995067384"
+SRCREV_meta_pn-linux-yocto ?= "727fc4769aa920fc5bb3eb9a81bf92d0e6340903"
 SRCREV_pn-linux-libc-headers-yocto ??= 
"69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3"
 SRCREV_pn-matchbox-config-gtk ??= "3ed74dfb7c57be088a5ab36e446c0ccde9fa1028"
 SRCREV_pn-matchbox-desktop-sato ??= "76"
-- 
1.7.0.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Change Endianess for MIPS build

2011-04-05 Thread Bruce Ashfield


On 11-04-05 06:43 AM, Robert Berger wrote:

Hi,

I was wondering what needs to be done to build (at least) a little
endian qemu root file system for MIPS.

Yocto builds this:

ELF 32-bit MSB executable, MIPS, MIPS64 version 1 (SYSV), dynamically
linked (uses shared libs), not stripped

I would need this:

ELF 32-bit LSB executable, MIPS, MIPS64 version 1 (SYSV), dynamically
linked (uses shared libs), not stripped

I guess SITEINFO_ENDIANESS (endian-big, endian-little) needs to be
changed to endian-little somewhere.

Can you please point me to where this needs to be done?


For the kernel, you'll need to modify the configuration to
be little endian. There is latent support in the kernel tree,
and I'll see about making the switch here so I can send some
better steps/changes for the kernel.

As for the rest of the system, you'd likely also need
to modify TARGET_ARCH to be mipsle, and adjust the
compile flags as required. I'm sure that there is an
example of this, but my quick check didn't reveal it.

Hopefully others will jump in with the right pointers!

Cheers,

Bruce



... or maybe I'm completely wrong and it needs to be done elsewhere ...

Regards,

Robert

..."I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the symptoms
rather than the underlying problems." --Linus

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-virtualization -> docker not packaged when using PACKAGE_CLASSES ?= "package_deb"

2018-04-19 Thread Bruce Ashfield


On 2018-04-10 5:31 AM, Mark Junghanns wrote:

Hello Bruce,

unfortunately, there is not a single warning or error message whatsoever thrown. The 
first occasion, some error message is thrown, occurs during do_rootfs where it complains 
about the missing package "docker" - which is obviously missing as it has not 
been build.

As I mentioned in my original post, the docker package is being built when 
using the rpm backend though.



It may not be all that helpful, but I can confirm that with oe-core
master and the latest meta-virtualization, I do get a docker .deb
produced:

23015988 Apr 19 16:55 
docker_18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0_amd64.deb


Cheers,

Bruce


Mark

-Ursprüngliche Nachricht-
Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] Im 
Auftrag von Bruce Ashfield
Gesendet: Montag, 9. April 2018 16:30
An: Mark Junghanns; yocto@yoctoproject.org
Betreff: Re: [yocto] meta-virtualization -> docker not packaged when using 
PACKAGE_CLASSES ?= "package_deb"

On 04/06/2018 09:13 AM, Mark Junghanns wrote:

Hello,
I encountered a funny behavior the other day. While trying to integrate Docker 
into my image using the openembedded meta-virtualization layer, I happened to 
not being able to get my image finalized.

Usually I build with
  PACKAGE_CLASSES ?= "package_deb".

I also added
  DISTRO_FEATURES_append = " virtualization"

The build process aborts at some point within do_rootfs, stating something like that the 
package 'docker' could not be found. I tracked down the problem to docker's  
build/tmp/work//docker//deploy-debs/ directory. I found the 
following packages:

docker-contrib_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_
amd64.deb docker-distribution-dev_v2.6.2-r0_amd64.deb
docker-registry_v2.6.2-r0_amd64.deb
docker-dbg_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_amd6
4.deb docker-distribution-ptest_v2.6.2-r0_amd64.deb
docker-distribution-dbg_v2.6.2-r0_amd64.deb
docker-ptest_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_am
d64.deb


The package that is actually missing, is the docker package itself. I suppose 
it would be named 
docker_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_amd64.deb.

There is not any single warning or error thrown whatsoever during the build of 
docker, it seems to just silently refusing to build the package.

Yet, when change PACKAGE_CLASSES ?= "package_deb" to PACKAGE_CLASSES ?= 
"package_rpm" it would build all required docker RPM-Packages just fine. At the end of 
the day I way able to get a complete image with Docker integrated, which is fine for the moment. 
Unfortunately I need to stick with the DEB format for update reasons, so eventually I need to deal 
with this issue again.

Has anyone seen this happening as well? Any idea, where and how to fix this?


I've never seen this, but then again, I've also never used the .deb package 
backend.

When you were building with .debs, and your image had "docker' in the image 
install .. was there any errors thrown due to the package not being created ?

Bruce



Thanks in advance for your help!

Mark



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] LINUX_VERSION issue in recipe

2018-04-27 Thread Bruce Ashfield




On 4/27/2018 5:34 PM, Andre McCurdy wrote:

On Fri, Apr 27, 2018 at 3:44 AM, Damien LEFEVRE  wrote:

Hi,

This must be a stupid basic question. I have the following recipe append:

keymaps_1.0.bbappend
-
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " file://keymaps.service \
file://keymap.sh \
"

do_install_append() {
 install -d ${D}${sysconfdir}
 ln -sf /usr/share/keymaps/i386/qwerty/fi.map.gz
${D}${sysconfdir}/keymap-${LINUX_VERSION}.map.gz

 install -d ${D}${systemd_system_unitdir}
 install -m 0644 ${WORKDIR}/keymaps.service ${D}${systemd_system_unitdir}
}

FILES_${PN} += " ${sysconfdir}/* \
  ${systemd_system_unitdir}/* \
"

inherit systemd
SYSTEMD_SERVICE_${PN} = "${PN}.service"
-

The LINUX_VERSION is not expanded and the final symlink name becomes
/etc/keymap-.map.gz.

What's correct way to get the linux version in the recipe files?


In general, there isn't a correct way to do that. The LINUX_VERSION
variable is defined within the kernel recipe and other recipes won't
have access to it.

A core concept in OE is that recipes build independently of each
other. In this case, since the keymaps recipe has no direct dependency
on the kernel, you should not expect the keymaps recipe to be rebuilt
(or affected in any way) when the kernel or kernel version changes.


Yep. Unless you inherit the kernel build classes there's no
easy way to do this. But if the kernel classes are inherited,
then some of the variables like KERNEL_VERSION become available
to use .. but of course, you've just tightly coupled things to
the kernel.

Cheers,

Bruce



The keymaps init script ( meta/recipes-bsp/keymaps/files/keymap.sh )
detects the kernel version dynamically at runtime. If you need a
kernel version specific symlink in your target rootfs, maybe you could
create it at runtime from your keymaps service file?


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't compile out of tree kernel module when CONFIG_SYSTEM_TRUSTED_KEYRING is set in the kernel configuration

2018-05-02 Thread Bruce Ashfield

On Wed, May 2, 2018 at 5:05 PM, Martin Townsend 
wrote:

> Hi,
>
> I get the following error when compiling a kernel module using the
> latest version of Rocko (The kernel is not linux-yocto but NXP's
> freescale linux-imx, maybe this could be a factor) :
>
> ERROR: kernel-module-driver-0.1-r0 do_make_scripts: Function failed:
> do_make_scripts (log file is located at
> /ws/yocto-rocko/build/tmp/work/mach_1717-linux-gnueabi/
> kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703)
> ERROR: Logfile of failure stored in:
> /ws/yocto-rocko/build/tmp/work/mach_1717-cwr-linux-
> gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703
> Log data follows:
> | DEBUG: Executing shell function do_make_scripts
> | make: Entering directory
> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source'
> | make[1]: Entering directory
> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-
> 1717/kernel-build-artifacts'
> |   HOSTCC  scripts/extract-cert
> | /ws/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-
> source/scripts/extract-cert.c:21:25:
> fatal error: openssl/bio.h: No such file or directory
> | compilation terminated.
> | scripts/Makefile.host:107: recipe for target 'scripts/extract-cert'
> failed
> | make[2]: *** [scripts/extract-cert] Error 1
> | /ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/
> kernel-source/Makefile:560:
> recipe for target 'scripts' failed
> |
>
> I checked the makefile and extract-cert is only compiled if
> CONFIG_SYSTEM_TRUSTED_KEYRING is set which we have.
>
>  I could install libssl-dev but it doesn't feel right installing this
> and it's not in the system requirements plus the file openssl/bio.h is
> in the recipe-sysroot-native directory of the kernel module WORK_DIR.
>

I've run into this plenty of times with newer kernels (4.14+), which is why
all the linux-yocto recipes have:


DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
DEPENDS += "openssl-native util-linux-native"

As does my re-worked kernel-devsrc.

So yah, you can just add the dependency to fix the problem.

Bruce


>
>
> Any help would be greatly appreciated,
> Marin.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-openstack][PATCH] python-requests: remove PREFERRED_VERSION limit

2018-05-21 Thread Bruce Ashfield


merged.

Bruce

On 2018-05-18 2:06 AM, mingli...@windriver.com wrote:

From: Mingli Yu 

* Previously, add PREFERRED_VERSION for python-requests
   as we want to use version >=2.10.0 and the full commit
   message as below:

   commit 185eccef8964632f5b255265a0a8e59fe5858397
   Author: Mark Asselstine 
   Date:   Fri Jan 20 16:59:31 2017 -0500

 python-requests: use version from meta-openembedded

 We want to use a version >=2.10.0 as required by python-keystoneauth1
 so set a PREF so we don't get the older version found in
 meta-virtualization and used by docker.

 Signed-off-by: Mark Asselstine 
 Signed-off-by: Bruce Ashfield 

* Now meta-oe upreved python-requests to 2.18.4, remove
   PREFERRED_VERSION limit to avoid bitbake messages like:

   "NOTE: preferred version 2.13.0 of python-requests not available"

Signed-off-by: Mingli Yu 
---
  meta-openstack/conf/layer.conf | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta-openstack/conf/layer.conf b/meta-openstack/conf/layer.conf
index 55df509..c376d58 100644
--- a/meta-openstack/conf/layer.conf
+++ b/meta-openstack/conf/layer.conf
@@ -31,7 +31,6 @@ PREFERRED_VERSION_python-futures = "3.0.3%"
  PREFERRED_VERSION_python-django = "1.8.6"
  PREFERRED_VERSION_python-netaddr = "0.7.19"
  PREFERRED_VERSION_python-sqlalchemy = "1.0.16"
-PREFERRED_VERSION_python-requests = "2.13.0"
  PREFERRED_VERSION_python-eventlet = "0.20.0"
  PREFERRED_VERSION_python-warlock = "1.2.0"
  PREFERRED_VERSION_python-jsonschema = "2.6.0"



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cgroups and iptables problems running docker - maybe my config wrong?

2018-05-31 Thread Bruce Ashfield


On 2018-05-31 7:00 AM, Jakob Hasse wrote:

Hello,


Make sure to cc meta-virtualization on questions like this, since
that is where you'll get more eyes that are running docker
all the time.


I ran into trouble running docker on our target.
1. When I want to start docker, I first have to re-mount cgroups:
root@target:~# cgroups-umount
root@target:~# cgroups-mount
Otherwise docker would produce an error:
ERRO[0002] Failed to built-in GetDriver graph btrfs /var/lib/docker

2. When I then start dockerd, it complains about a missing nat table:
root@target:~# dockerd
INFO[] libcontainerd: new containerd process, pid: 929
WARN[] containerd: low RLIMIT_NOFILE changing to max current=1024 
max=4096

INFO[0001] [graphdriver] using prior storage driver: overlay2
INFO[0001] Graph migration to content-addressability took 0.00 seconds
WARN[0001] Your kernel does not support cgroup memory limit
WARN[0001] Unable to find cpu cgroup in mounts
WARN[0001] Unable to find blkio cgroup in mounts
WARN[0001] Unable to find cpuset cgroup in mounts
WARN[0001] mountpoint for pids not found
INFO[0001] Loading containers: start.
WARN[0001] Running modprobe nf_nat failed with message: `modprobe: 
WARNING: Module nf_nat not found in directory 
/lib/modules/4.9.81-dey+g2c6ae4c`, error: exit status 1
WARN[0001] Running modprobe xt_conntrack failed with message: `modprobe: 
WARNING: Module xt_conntrack not found in directory 
/lib/modules/4.9.81-dey+g2c6ae4c`, error: exit status 1
Error starting daemon: Error initializing network controller: error 
obtaining controller instance: failed to create NAT chain: iptables 
failed: iptables --wait -t nat -N DOCKER: iptables v1.6.1: can't 
initialize iptables table `nat': Table does not exist (do you need to 
insmod?)

Perhaps iptables or your kernel needs to be upgraded.
  (exit status 3)

Our configuration is as suggested here: 
https://wiki.yoctoproject.org/wiki/TipsAndTricks/DockerOnImage, except 


I've never seen that wiki page before (or at least I don't remember
seeing it), so I can't confirm or deny the validity of the content :)

that I don't include the system systemd stuff  (it lets my build fail) 


If systemd is breaking your build, make sure to log a bugzilla against
oe-core


and connman (using NetworkManager).
Furthermore, I added the following lines to the kernel bbappend file:

# remove old defconfig
SRC_URI_remove = " defconfig"
# replace with new defconfig
SRC_URI_append = " file://defconfig"

KERNEL_FEATURES_append = " features/cgroups/cgroups.scc "

I also added a lot of configurations manually to the defconfig (mostly 
via menuconfig) to enable NAT:


CONFIG_CGROUP_DEVICE=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_TABLES=y
CONFIG_NF_NAT=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_HL=y
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_RECENT=y
CONFIG_IP_VS=y
CONFIG_NF_TABLES_IPV4=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_BTRFS_FS=y
CONFIG_OVERLAY_FS=y

Apart from that, I added virtualization and aufs as DISTRO_FEATURE in 
local.conf and also enabled it in menuconfig.


But I still keep getting the above mentioned iptables error when trying 
to start docker. All this hassle makes me suspicious, especially as I'm 
quite sure that I once had docker running already with an image on our 
target and it wasn't that hard. So maybe it's just a misconfiguration 
and I need to add something in local.conf or the kernel recipe? Is 
systemd necessary? Or am I missing some life-or-death kernel 
configuration? It would also be nice if I could avoid the cgroup 
re-mounting before starting docker.


What release branch are you using ?

I'm running docker from meta-virt every day, as are many others,
but you have several differences in your configuration.

 - most use systemd as the init manager, I know that I do. That
   is going to impact how cgroups is set up on your 'host' image.
   You shouldn't need to touch cgroups at all if systemd is used,
   since it is correct out of the box.

 - You are using a different kernel and kernel configuration.
   linux-yocto + the configuration fragments in the layer are what
   is routinely tested. Are you using linux-yocto, or something
   different ? If it is different, all you can do is run the various
   checks to make sure that the docker prereqs are in place.

   The errors you see in dockerd tells me that the options you are
   turning on, are not making it into the final kernel that is
   running on target.

Cheers,

Bruce



Thanks for every answer!
All the Best,
Jakob



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cgroups and iptables problems running docker - maybe my config wrong?

2018-06-04 Thread Bruce Ashfield

 that the introduction of systemd "confuses" dnf. I found a quite 
similar description in this bugreport here:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12025
only that I'm not using different machines. This bug doesn't seem to be 
resolved yet.


Our Yocto-distribution is DIGI Embedded Yocto. So non-standard.
Shall I still log a bug against oe-core?


You could, but without a reproducer on oe-core, chances are that it
won't be easily resolved.

At a glance, it isn't clear to me how systemd is causing your 
busybox-hwclock

issue. But if you check the list, that particular package has recently
been moved around/broken out. So I'd suggest making sure that all of
your layers are on the correct branches and that releases aren't being
mixed.

Bruce


If someone here has some more helpful ideas, I would be very thankful.

All the Best,
Jakob

On 31.05.2018 13:44, Bruce Ashfield wrote:

On 2018-05-31 7:00 AM, Jakob Hasse wrote:

Hello,


Make sure to cc meta-virtualization on questions like this, since
that is where you'll get more eyes that are running docker
all the time.


I ran into trouble running docker on our target.
1. When I want to start docker, I first have to re-mount cgroups:
root@target:~# cgroups-umount
root@target:~# cgroups-mount
Otherwise docker would produce an error:
ERRO[0002] Failed to built-in GetDriver graph btrfs /var/lib/docker

2. When I then start dockerd, it complains about a missing nat table:
root@target:~# dockerd
INFO[] libcontainerd: new containerd process, pid: 929
WARN[] containerd: low RLIMIT_NOFILE changing to max current=1024 
max=4096

INFO[0001] [graphdriver] using prior storage driver: overlay2
INFO[0001] Graph migration to content-addressability took 0.00 seconds
WARN[0001] Your kernel does not support cgroup memory limit
WARN[0001] Unable to find cpu cgroup in mounts
WARN[0001] Unable to find blkio cgroup in mounts
WARN[0001] Unable to find cpuset cgroup in mounts
WARN[0001] mountpoint for pids not found
INFO[0001] Loading containers: start.
WARN[0001] Running modprobe nf_nat failed with message: `modprobe: 
WARNING: Module nf_nat not found in directory 
/lib/modules/4.9.81-dey+g2c6ae4c`, error: exit status 1
WARN[0001] Running modprobe xt_conntrack failed with message: 
`modprobe: WARNING: Module xt_conntrack not found in directory 
/lib/modules/4.9.81-dey+g2c6ae4c`, error: exit status 1
Error starting daemon: Error initializing network controller: error 
obtaining controller instance: failed to create NAT chain: iptables 
failed: iptables --wait -t nat -N DOCKER: iptables v1.6.1: can't 
initialize iptables table `nat': Table does not exist (do you need to 
insmod?)

Perhaps iptables or your kernel needs to be upgraded.
  (exit status 3)

Our configuration is as suggested here: 
https://wiki.yoctoproject.org/wiki/TipsAndTricks/DockerOnImage, except 


I've never seen that wiki page before (or at least I don't remember
seeing it), so I can't confirm or deny the validity of the content :)

that I don't include the system systemd stuff  (it lets my build fail) 


If systemd is breaking your build, make sure to log a bugzilla against
oe-core


and connman (using NetworkManager).
Furthermore, I added the following lines to the kernel bbappend file:

# remove old defconfig
SRC_URI_remove = " defconfig"
# replace with new defconfig
SRC_URI_append = " file://defconfig"

KERNEL_FEATURES_append = " features/cgroups/cgroups.scc "

I also added a lot of configurations manually to the defconfig 
(mostly via menuconfig) to enable NAT:


CONFIG_CGROUP_DEVICE=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_TABLES=y
CONFIG_NF_NAT=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_HL=y
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_RECENT=y
CONFIG_IP_VS=y
CONFIG_NF_TABLES_IPV4=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_BTRFS_FS=y
CONFIG_OVERLAY_FS=y

Apart from that, I added virtualization and aufs as DISTRO_FEATURE in 
local.conf and also enabled it in menuconfig.


But I still keep getting the above mentioned iptables error when 
trying to start docker. All this hassle makes me suspicious, 
especially as I'm quite sure that I once had docker running already 
with an image on our target and it wasn't that hard. So maybe it's 
just a misconfiguration and I need to add something in local.conf or 
the kernel recipe? Is systemd necessary? Or am I missing some 
life-or-death kernel configuration? It would also be nice if I could 
avoid the cgroup re-mounting before starting docker.


What release branch are you using ?

I'm running docker fro

Re: [yocto] [Resolved] Re: cgroups and iptables problems running docker - maybe my config wrong?

2018-06-06 Thread Bruce Ashfield


On 2018-06-06 10:33 AM, Jakob Hasse wrote:

Hello Bruce, hello Yoctoers,

my problem is solved. It was the kernel options. I added all additional 
kernel options which this check-script here suggests: 
https://github.com/moby/moby/blob/master/contrib/check-config.sh. This 
script was a big help


Finally, docker runs, with one ERROR message and one WARNING though, but 
it does :) If I have more problems, I'll come back to the list.




Great news.

I was about to do another run of this, and still will, but this is
good to know.

Definitely let us know what breaks next :D

Bruce


Thank you for the help so far.

All the Best,
Jakob

On 05.06.2018 18:23, Jakob Hasse wrote:

Hello,

right now, there is no insmod warning anymore, only iptables does 
still not work with the nat table:


root@ccimx6uluvalue:~# dockerd
INFO[] libcontainerd: new containerd process, pid: 1003
WARN[] containerd: low RLIMIT_NOFILE changing to max current=1024 
max=4096

INFO[0001] [graphdriver] using prior storage driver: overlay2
INFO[0001] Graph migration to content-addressability took 0.00 seconds
WARN[0001] Your kernel does not support cgroup memory limit
WARN[0001] Unable to find cpu cgroup in mounts
WARN[0001] Unable to find blkio cgroup in mounts
WARN[0001] Unable to find cpuset cgroup in mounts
WARN[0001] mountpoint for pids not found
INFO[0001] Loading containers: start.
Error starting daemon: Error initializing network controller: error 
obtaining controller instance: failed to create NAT chain: iptables 
failed: iptables --wait -t nat -N DOCKER: iptables v1.6.1: can't 
initialize iptables table `nat': Table does not exist (do you need to 
insmod?)

Perhaps iptables or your kernel needs to be upgraded.
 (exit status 3)

Best Regards,
Jakob

On 05.06.2018 18:11, Jakob Hasse wrote:

On 04.06.2018 17:53, Bruce Ashfield wrote:

On 2018-06-01 12:15 PM, Jakob Hasse wrote:

Hello Bruce,

Thank you very much for the quick response. I tried to built in the 
kernel changes. But the iptables error persists.


I double checked over the weekend, and I have no problems with
linux-yocto + the meta-virtualization fragment and docker.

Thanks a lot for the work!


Did you say that you confirmed on target via /proc/config.gz that
all the options you tried to enable are still present in the running
kernel ?
I double checked with /proc/config.gz and all the modules are 
builting except for CONFIG_NF_TABLES, CONFIG_NF_TABLES_IPV4. The last 
two might not even exists, I was so desperate that I put everything 
into the configuration which I could find related to NAT.
Some modules are builtin as modules instead (...=m instead of ...=y), 
however.


Eventually, I tried to enable systemd again and it still breaks my 
build -.-:


test$ bitbake core-image-base
NOTE: Started PRServer with DBfile: 
/home/build/test/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40169, 
PID: 2335
Loading cache: 100% 
|| 
Time: 0:00:00

Loaded 3023 entries from dependency cache.
Parsing recipes: 100% 
|##| 
Time: 0:00:01
Parsing of 2194 .bb files complete (2193 cached, 1 parsed). 3024 
targets, 146 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.36.0"
BUILD_SYS    = "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-dey-linux-gnueabi"
MACHINE  = "ccimx6ulstarter"
DISTRO   = "dey"
DISTRO_VERSION   = "2.4-r1"
TUNE_FEATURES    = "arm armv7ve vfp thumb neon 
callconvention-hard cortexa7"

TARGET_FPU   = "hard"
meta
meta-poky
meta-yocto-bsp   = "HEAD:3befe6d7b7fa8c8481519aa8dd0cae52207ad339"
meta-oe
meta-python
meta-networking
meta-webserver   = "HEAD:dacfa2b1920e285531bec55cd2f08743390aaf57"
meta-qt5 = "HEAD:cfe02f26de53e5c20e6f9555059cbaaf5ab9b22f"
meta-swupdate    = "HEAD:6e4eab4f475b0129d6510815a3bbc4748c97dbbe"
meta-freescale   = "HEAD:d6141ea291a1ac9ab8fb1dd1110d408f840fda57"
meta-fsl-demos   = "HEAD:0ec6d7e206705702b5b534611754de0787f92b72"
meta-digi-arm
meta-digi-dey    = "HEAD:1246ecff2cecea9247d94f36385608ac844d7abb"

Initialising tasks: 100% 
|###| 
Time: 0:00:04

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: core-image-base-1.0-r0 do_rootfs: Could not invoke dnf. 
Command 
'/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf 
-y -c 
/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base

Re: [linux-yocto] [PATCH 4.14&4.15] MIPS: Use '+=" instead of '=' to avoid the CFLAGS override

2018-06-11 Thread Bruce Ashfield


On 2018-06-11 6:17 AM, Kevin Hao wrote:

We used the CFLAGS_xxx to workaround the gcc 8 build warnings
for some specific file. But CFLAGS_xxx is also used with '=' in
other places of this Makefile. This override the gcc 8 workaround,
so replace all the '=' with '+=" to fix this issue.


merged. SRCREV updates will be out shortly.

Bruce



Signed-off-by: Kevin Hao 
---
  arch/mips/kernel/Makefile | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index f10e1e15e1c6..7a00a8e840ad 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -124,11 +124,11 @@ obj-$(CONFIG_MIPS_CPS_PM) += pm-cps.o
  ifeq ($(CONFIG_CPU_MIPSR2), y)
  CFLAGS_DSP= -DHAVE_AS_DSP
  
-CFLAGS_signal.o			= $(CFLAGS_DSP)

-CFLAGS_signal32.o  = $(CFLAGS_DSP)
-CFLAGS_process.o   = $(CFLAGS_DSP)
-CFLAGS_branch.o= $(CFLAGS_DSP)
-CFLAGS_ptrace.o= $(CFLAGS_DSP)
+CFLAGS_signal.o+= $(CFLAGS_DSP)
+CFLAGS_signal32.o  += $(CFLAGS_DSP)
+CFLAGS_process.o   += $(CFLAGS_DSP)
+CFLAGS_branch.o+= $(CFLAGS_DSP)
+CFLAGS_ptrace.o+= $(CFLAGS_DSP)
  endif
  
  CPPFLAGS_vmlinux.lds		:= $(KBUILD_CFLAGS)




--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [PATCH][meta-cloud-services] spice: remove spice receipe from meta-cloud-services

2018-06-21 Thread Bruce Ashfield


On 06/21/2018 02:11 AM, Changqing Li wrote:

spice have been export to meta-openembedded/meta-networking,
and have newer version. spice under this layer now have
compile error, but spice under networking layer don't.
Maybe we should not maintain 2 same spices, so delete it.


I'm going to hold onto this one a bit longer. We have specific
version requirements and will revisit when the next openstack
uprev is done.

Cheers,

Bruce



Signed-off-by: Changqing Li 
---
  ...ros-in-printf-to-keep-compatibility-betwe.patch |  72 ---
  ...xl-Fix-BITMAP_FMT_IS_RGB-defined-but-not-.patch |  29 --
  recipes-support/spice/files/CVE-2017-7506-1.patch  |  81 -
  recipes-support/spice/files/CVE-2017-7506-2.patch  |  37 
  recipes-support/spice/files/CVE-2017-7506-3.patch  |  54 ---
  .../spice/files/Fix-build-issues-with-gcc-7.patch  |  59 
  .../build-allow-separated-src-and-build-dirs.patch |  62 -
  ...ac-add-subdir-objects-to-AM_INIT_AUTOMAKE.patch |  29 --
  .../spice/files/spice-fix-CVE-2013-4282.patch  | 100 -
  recipes-support/spice/spice_git.bb |  79 
  10 files changed, 602 deletions(-)
  delete mode 100644 
recipes-support/spice/files/0001-Use-PRI-macros-in-printf-to-keep-compatibility-betwe.patch
  delete mode 100644 
recipes-support/spice/files/0001-red_parse_qxl-Fix-BITMAP_FMT_IS_RGB-defined-but-not-.patch
  delete mode 100644 recipes-support/spice/files/CVE-2017-7506-1.patch
  delete mode 100644 recipes-support/spice/files/CVE-2017-7506-2.patch
  delete mode 100644 recipes-support/spice/files/CVE-2017-7506-3.patch
  delete mode 100644 
recipes-support/spice/files/Fix-build-issues-with-gcc-7.patch
  delete mode 100644 
recipes-support/spice/files/build-allow-separated-src-and-build-dirs.patch
  delete mode 100644 
recipes-support/spice/files/configure.ac-add-subdir-objects-to-AM_INIT_AUTOMAKE.patch
  delete mode 100644 recipes-support/spice/files/spice-fix-CVE-2013-4282.patch
  delete mode 100644 recipes-support/spice/spice_git.bb

diff --git 
a/recipes-support/spice/files/0001-Use-PRI-macros-in-printf-to-keep-compatibility-betwe.patch
 
b/recipes-support/spice/files/0001-Use-PRI-macros-in-printf-to-keep-compatibility-betwe.patch
deleted file mode 100644
index 18fa8fa..000
--- 
a/recipes-support/spice/files/0001-Use-PRI-macros-in-printf-to-keep-compatibility-betwe.patch
+++ /dev/null
@@ -1,72 +0,0 @@
-From 3cb746329ea4846bd9c65e0198e69423379b6f62 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?=EC=86=8C=EB=B3=91=EC=B2=A0?= 
-Date: Thu, 24 Apr 2014 12:26:32 +
-Subject: [PATCH] Use PRI macros in printf to keep compatibility between
- 32/64bit system
-
-gcc's some integer type definitions are different between 32/64bit system.
-This causes platform dependency problem with printf function. However,
-we can avoid this problem by using PRI macros that supports platform
-independent printf.

- server/mjpeg_encoder.c | 7 ---
- server/red_worker.c| 4 ++--
- 2 files changed, 6 insertions(+), 5 deletions(-)
-
-diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
-index aea4964..f465d88 100644
 a/server/mjpeg_encoder.c
-+++ b/server/mjpeg_encoder.c
-@@ -23,6 +23,7 @@
- #include "mjpeg_encoder.h"
- #include 
- #include 
-+#include 
-
- #define MJPEG_MAX_FPS 25
- #define MJPEG_MIN_FPS 1
-@@ -66,7 +67,7 @@ static const int 
mjpeg_quality_samples[MJPEG_QUALITY_SAMPLE_NUM] = {20, 30, 40,
-  * are not necessarily related to mis-estimation of the bit rate, and we would
-  * like to wait till the stream stabilizes.
-  */
--#define MJPEG_WARMUP_TIME 3000L // 3 sec
-+#define MJPEG_WARMUP_TIME 3000LL // 3 sec
-
- enum {
- MJPEG_QUALITY_EVAL_TYPE_SET,
-@@ -638,7 +639,7 @@ static void 
mjpeg_encoder_adjust_params_to_bit_rate(MJpegEncoder *encoder)
-
- spice_debug("cur-fps=%u new-fps=%u (new/old=%.2f) |"
- "bit-rate=%.2f (Mbps) latency=%u (ms) quality=%d |"
--" new-size-avg %lu , base-size %lu, (new/old=%.2f) ",
-+" new-size-avg %"PRIu64" , base-size %"PRIu64", (new/old=%.2f) 
",
- rate_control->fps, new_fps, 
((double)new_fps)/rate_control->fps,
- ((double)rate_control->byte_rate*8)/1024/1024,
- latency,
-@@ -703,7 +704,7 @@ static void mjpeg_encoder_adjust_fps(MJpegEncoder 
*encoder, uint64_t now)
-
- avg_fps = ((double)rate_control->adjusted_fps_num_frames*1000) /
-   adjusted_fps_time_passed;
--spice_debug("#frames-adjust=%lu #adjust-time=%lu avg-fps=%.2f",
-+spice_debug("#frames-adjust=%"PRIu64" #adjust-time=%"PRIu64" 
avg-fps=%.2f",
- rate_control->adjusted_fps_num_frames, 
adjusted_fps_time_passed, avg_fps);
- spice_debug("defined=%u old-adjusted=%.2f", rate_control->fps, 
rate_control->adjusted_fps);
- fps_ratio = avg_fps / rate_control->fps;
-diff --git a/server/red_worker.c b/server/red_wor

Re: [linux-yocto] [PATCH] Revert mm/vmstat.c: fix vmstat_update() preemption BUG

2018-07-25 Thread Bruce Ashfield


On 2018-07-24 9:47 PM, He Zhe wrote:



On 2018年07月25日 04:07, Bruce Ashfield wrote:

On 2018-07-23 10:07 PM, He Zhe wrote:



On 2018年07月24日 03:21, Bruce Ashfield wrote:

Which version/branches is this for ?



This is for linux-yocto rt branches. linux-yocto-4.12 does not need this
fix, since the commit, see below, causing the issue have not been included.


Rather than me guessing. Which versions are you looking at ? I've got
active -stable updates for many of the linux-yocto trees, so any number
could be impacted.


I'm looking at
git://git.yoctoproject.org/linux-yocto
v4.14/standard/preempt-rt/base
v4.14/standard/preempt-rt/intel

I want to fix
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v4.14/standard/preempt-rt/base&id=08e9dbd5184e4e059adf1cc77b5dc08eca314a77
by porting
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v4.14-rt&id=ac7768148a10fe7e934a7a510cc067883163f115




thanks for the details. This is now merged.

Bruce


Thanks,
Zhe




Bruce



git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

commit 08e9dbd5184e4e059adf1cc77b5dc08eca314a77
Author: Steven J. Hill 
AuthorDate: Wed Mar 28 16:01:09 2018 -0700
Commit: Greg Kroah-Hartman 
CommitDate: Wed May 30 07:52:21 2018 +0200

  mm/vmstat.c: fix vmstat_update() preemption BUG


Thanks,
Zhe


Given the author, I'm assuming it is for the -rt branches and also
for 4.12 .. but I'd like a confirmation of that.

Bruce

On 2018-07-20 4:13 AM, zhe...@windriver.com wrote:

From: Sebastian Andrzej Siewior 

commit 97731753d44d5efcb95b994dc952c0e8195b3e96 upstream

This patch reverts commit c7f26ccfb2c3 ("mm/vmstat.c: fix
vmstat_update() preemption BUG").
Steven saw a "using smp_processor_id() in preemptible" message and
added a preempt_disable() section around it to keep it quiet. This is
not the right thing to do it does not fix the real problem.

vmstat_update() is invoked by a kworker on a specific CPU. This worker
it bound to this CPU. The name of the worker was "kworker/1:1" so it
should have been a worker which was bound to CPU1. A worker which can
run on any CPU would have a `u' before the first digit.

smp_processor_id() can be used in a preempt-enabled region as long as
the task is bound to a single CPU which is the case here. If it could
run on an arbitrary CPU then this is the problem we have an should seek
to resolve.
Not only this smp_processor_id() must not be migrated to another CPU but
also refresh_cpu_vm_stats() which might access wrong per-CPU variables.
Not to mention that other code relies on the fact that such a worker
runs on one specific CPU only.

Therefore I revert that commit and we should look instead what broke the
affinity mask of the kworker.

Cc: Steven J. Hill 
Cc: Tejun Heo 
Cc: Andrew Morton 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt (VMware) 

Backport this to fix following serious crash for preempt-rt kernel

BUG: scheduling while atomic: kworker/3:1/91/0x0002
Preemption disabled at:
[] vmstat_update+0x2d/0xb0
CPU: 3 PID: 91 Comm: kworker/3:1 Not tainted 4.14.48-rt29-yocto-preempt-rt #1
Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge, BIOS 
BDW-E2R1.86C.0118.R01.1503110618 03/11/2015
Workqueue: mm_percpu_wq vmstat_update
Call Trace:
    dump_stack+0x4f/0x6b
    ? vmstat_update+0x2d/0xb0
    __schedule_bug.cold.24+0x7d/0x9a
    __schedule+0x45a/0x6c0
    ? task_blocks_on_rt_mutex+0x173/0x300
    schedule+0x3d/0xd0
    rt_spin_lock_slowlock_locked+0x118/0x2a0
    rt_spin_lock_slowlock+0x48/0x60
    rt_spin_lock+0x3f/0x50
    queue_delayed_work_on+0x63/0x100
    vmstat_update+0x6e/0xb0
    process_one_work+0x1c3/0x430
    worker_thread+0x32/0x440
    kthread+0x127/0x140
    ? process_one_work+0x430/0x430
    ? kthread_create_on_node+0x40/0x40
    ret_from_fork+0x35/0x40

Signed-off-by: He Zhe 
---
    mm/vmstat.c | 2 --
    1 file changed, 2 deletions(-)

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 84fd6eb..0d17b8f 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1782,11 +1782,9 @@ static void vmstat_update(struct work_struct *w)
     * to occur in the future. Keep on running the
     * update worker thread.
     */
-    preempt_disable();
    queue_delayed_work_on(smp_processor_id(), mm_percpu_wq,
    this_cpu_ptr(&vmstat_work),
    round_jiffies_relative(sysctl_stat_interval));
-    preempt_enable();
    }
    }
   












--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Kernel configuration problems

2018-07-28 Thread Bruce Ashfield


On 7/27/2018 6:20 PM, Greg Wilson-Lindberg wrote:
I'm trying to add a couple of drivers to the kernel in a Raspberry pi3 
build.


I've got the passing of the config options working, but I'm getting 
warnings from the kernel build that the options are not being applied:


WARNING: linux-raspberrypi-1_4.4.50+gitAUTOINC+04c8e47067-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it 
into the kernel's final configuration:


-- CONFIG_SND_SOC_MAX9768 -
Config: CONFIG_SND_SOC_MAX9768
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_SND_SOC_MAX9768=y
Actual value:

Config 'SND_SOC_MAX9768' has the following conditionals:
Dependency values are:

-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_MAX1363=m
Actual value:     # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
   I2C (value: "y")
Dependency values are:
   I2C [y]


My problem is that I don't understand why the options are not being applied.

For the MAX_9768, it depends on I2C=y which is true. I've run the linux 
kernel menu config and when I get to the Sound SOC support none of the 
drivers that require I2C support (i.e. 'select SND_SOC_MAX9768 if I2C') 
are displayed. I don't see anything else that would disable them, the 
other drivers in the SOC Kconfig that don't depend on I2C or that depend 
on SPI_MASTER are displayed.


The MAX1363 can be set in the menuconfig to 'm', but still won't set 
from the scc, cfg files.


Any insight into what's going on here would be greatly appreciated.


I can help with this ... but first, is this a configuration that I can
build myself ? i.e. what branch, what layers and what extra configs
would I need ?

Bruce



Regards,

cid:image001.png@01D35D7D.179A7510

*Greg Wilson-Lindberg *

*Principal Firmware Engineer | Sakura Finetek USA, Inc. *

**

1750 W 214^th Street | Torrance, CA 90501 | U.S.A.

T: +1 310 783 5075

F: +1 310 618 6902 | E: gwil...@sakuraus.com

www.sakuraus.com

cid:image002.png@01D35D7D.179A7510



cid:image003.png@01D35D7D.179A7510



Confidentiality Notice: This e-mail transmission may contain 
confidential or legally privileged information that is intended only for 
the individual or entity named in the e-mail address. If you are not the 
intended recipient, you are hereby notified that any disclosure, 
copying, distribution, or reliance upon the contents of this e-mail is 
strictly prohibited. If you have received this e-mail transmission in 
error, please reply to the sender, so that Sakura Finetek USA, Inc. can 
arrange for proper delivery, and then please delete the message from 
your inbox. Thank you.





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] LXD on yocto

2018-08-22 Thread Bruce Ashfield


On 08/22/2018 10:40 AM, Sarayu Sivanandam wrote:
Hi all, Is anyone currently working on creating a recipe for LXD? I want 
to create a recipe for LXD for my project and any inputs for the same is 
welcome. Thanks and Regards


check on the meta-virtualization list. We already have lxc and the
support tools, and lxd has been discussed there in the past.

So asking there, will find you someone that may already have a recipe
or is working on one.

If you do write a recipe, meta-virt is the best place to send it, so
you'll be on the right list for that as well.

Bruce



Sarayu






--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] poky: set linux-yocto default to 4.18

2018-08-24 Thread Bruce Ashfield

4.18 will be the newest kernel in the upcoming release, so we bump
our default to it in preparation of 4.15 being dropped.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 392c2383ee47..c5d9e5d6d5fd 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "4.14%"
+PREFERRED_VERSION_linux-yocto ?= "4.18%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/2] poky: set linux-yocto default to 4.18

2018-08-30 Thread Bruce Ashfield

4.18 will be the newest kernel in the upcoming release, so we bump
our default to it in preparation of 4.15 being dropped.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 392c2383ee47..c5d9e5d6d5fd 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "4.14%"
+PREFERRED_VERSION_linux-yocto ?= "4.18%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/2] yocto-bsp: drop 4.15 bbappend

2018-08-30 Thread Bruce Ashfield

4.18 is replacing 4.15 as the latest kernel in the upcoming
release, so we drop this dangling bbappend.

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto_4.15.bbappend | 27 --
 1 file changed, 27 deletions(-)
 delete mode 100644 
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.15.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.15.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.15.bbappend
deleted file mode 100644
index 45ac05d432de..
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.15.bbappend
+++ /dev/null
@@ -1,27 +0,0 @@
-KBRANCH_genericx86  = "v4.15/standard/base"
-KBRANCH_genericx86-64  = "v4.15/standard/base"
-KBRANCH_edgerouter = "v4.15/standard/edgerouter"
-KBRANCH_beaglebone-yocto = "v4.15/standard/beaglebone"
-KBRANCH_mpc8315e-rdb = "v4.15/standard/fsl-mpc8315e-rdb"
-
-KMACHINE_genericx86 ?= "common-pc"
-KMACHINE_genericx86-64 ?= "common-pc-64"
-KMACHINE_beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine_genericx86?= "51273ff79f4ad930f4a788257f58e1266cb236e3"
-SRCREV_machine_genericx86-64 ?= "51273ff79f4ad930f4a788257f58e1266cb236e3"
-SRCREV_machine_edgerouter ?= "3373c0cf71f2812eeb9694839456df6f67fd32ac"
-SRCREV_machine_beaglebone-yocto ?= "e25dbfe95302eeaa1a03a828d05c09479574488a"
-SRCREV_machine_mpc8315e-rdb ?= "0b32edc46dfe7c40bf5451e9b7533c823bb2c6c4"
-
-COMPATIBLE_MACHINE_genericx86 = "genericx86"
-COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE_edgerouter = "edgerouter"
-COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
-COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
-
-LINUX_VERSION_genericx86 = "4.15.18"
-LINUX_VERSION_genericx86-64 = "4.15.18"
-LINUX_VERSION_edgerouter = "4.15.18"
-LINUX_VERSION_beaglebone-yocto = "4.15.18"
-LINUX_VERSION_mpc8315e-rdb = "4.15.18"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is KCONFIG_MODE test backwards in kernel-yocto.bbclass?

2018-09-26 Thread Bruce Ashfield


On 2018-09-25 10:03 PM, Aaron Cohen wrote:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-yocto.bbclass#n297

With no KCONFIG_MODE specified, we check if the user has copied a 
defconfig to workdir, and then use allnoconfig if so. Shouldn't we be 
using alldefconfig in this case?


The result currently is that if you use a defconfig file that you add to 
SRC_URI, much of it won't work, because it's been set to no by 
allnoconfig, and it's not super-obvious, to me at least, why.


Nope. This is fully intentional. The defconfig is traditionally
a complete .config that specifies all values. As such, we clear
the settings with allnoconfig and then apply it to the tree.

If you want a minimal .config (like fragments, etc), that adds
only non-default settings, we use alldefconfig and then apply
the fragments.

Cheers,

Bruce






--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] about beaglebone-yocto bitbake core-image-rt

2018-09-27 Thread Bruce Ashfield


On 09/27/2018 02:15 AM, ?? wrote:

$ git clone git://git.yoctoproject.org/poky
$ cd poky
$ . ./oe-init-build-env build-bbb

edit conf/local.conf to set MACHINE ??= "beaglebone-yocto"

$ echo "PREFERRED_PROVIDER_virtual/kernel = \"linux-yocto-rt\"" >> 
conf/local.conf

$ bitbake -v core-image-rt

got errors:

Loading cache...done.
Loaded 1260 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
PREFERRED_PROVIDERS
ERROR: Nothing PROVIDES 'linux-yocto-rt' (but 
/home/jaloo/backup/yocto/src/poky/meta/recipes-rt/images/core-image-rt.bb DEPENDS 
on or otherwise requires it)
linux-yocto-rt was skipped: incompatible with machine beaglebone-yocto 
(not in COMPATIBLE_MACHINE)
linux-yocto-rt was skipped: incompatible with machine beaglebone-yocto 
(not in COMPATIBLE_MACHINE)

NOTE: Target 'linux-yocto-rt' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['linux-yocto-rt']
NOTE: Target 'core-image-rt' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-rt', 
'linux-yocto-rt']

ERROR: Required build target 'core-image-rt' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-rt', 
'linux-yocto-rt']


The problem is just what they error message is trying to say.
There's no declared machine compatibility between that board
and the linux-yocto-rt recipe.

You could create a bbappend that contained both a BSP
definition and that sets the compatibility. But I can't
say if it would, or wouldn't have runtime issues.

i.e. you need to append beaglbone-yocto to the COMPATIBLE_MACHINE
variable.

You also need a BSP definition for the -rt kernel, but at
a glance, it looks like there's already one in the kernel-cache,
so you should get a valid configuration.

Bruce



Summary: There were 2 ERROR messages shown, returning a non-zero exit code.







--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-dev][PATCH] i2c: i801: fix DNV's SMBCTRL register offset

2018-09-27 Thread Bruce Ashfield


This will show up in the -stable updates. I typically prefer to
wait for these to cycle through that process, rather than applying
them directly .. since it means I will have rebase / conflicts when
I merge the -stable updates.

That being said, it is fairly trivial, so I've applied it to the
-dev kernel.

Bruce

On 09/27/2018 02:58 AM, Yongxin Liu wrote:

From: Felipe Balbi 

commit 851a15114895c5bce163a6f2d57e0aa4658a1be4 upstream.

DNV's iTCO is slightly different with SMBCTRL sitting at a different
offset when compared to all other devices. Let's fix so that we can
properly use iTCO watchdog.

Fixes: 84d7f2ebd70d ("i2c: i801: Add support for Intel DNV")
Cc:  # v4.4+
Signed-off-by: Felipe Balbi 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Yongxin Liu 
---
  drivers/i2c/busses/i2c-i801.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index aa726607645e..45fcf0c37a9e 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -139,6 +139,7 @@
  
  #define SBREG_BAR		0x10

  #define SBREG_SMBCTRL 0xc6000c
+#define SBREG_SMBCTRL_DNV  0xcf000c
  
  /* Host status bits for SMBPCISTS */

  #define SMBPCISTS_INTSBIT(3)
@@ -1396,7 +1397,11 @@ static void i801_add_tco(struct i801_priv *priv)
spin_unlock(&p2sb_spinlock);
  
  	res = &tco_res[ICH_RES_MEM_OFF];

-   res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL;
+   if (pci_dev->device == PCI_DEVICE_ID_INTEL_DNV_SMBUS)
+   res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL_DNV;
+   else
+   res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL;
+
res->end = res->start + 3;
res->flags = IORESOURCE_MEM;
  



--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-dev][PATCH] i2c: i801: fix DNV's SMBCTRL register offset

2018-09-27 Thread Bruce Ashfield


On 09/27/2018 11:32 AM, Bruce Ashfield wrote:

This will show up in the -stable updates. I typically prefer to
wait for these to cycle through that process, rather than applying
them directly .. since it means I will have rebase / conflicts when
I merge the -stable updates.

That being said, it is fairly trivial, so I've applied it to the
-dev kernel.



I spoke to soon. this is already in the 4.18 -stable series,
so I just bumped linux-yocto-dev to include the .9 -stable.

Bruce


Bruce

On 09/27/2018 02:58 AM, Yongxin Liu wrote:

From: Felipe Balbi 

commit 851a15114895c5bce163a6f2d57e0aa4658a1be4 upstream.

DNV's iTCO is slightly different with SMBCTRL sitting at a different
offset when compared to all other devices. Let's fix so that we can
properly use iTCO watchdog.

Fixes: 84d7f2ebd70d ("i2c: i801: Add support for Intel DNV")
Cc:  # v4.4+
Signed-off-by: Felipe Balbi 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Yongxin Liu 
---
  drivers/i2c/busses/i2c-i801.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-i801.c 
b/drivers/i2c/busses/i2c-i801.c

index aa726607645e..45fcf0c37a9e 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -139,6 +139,7 @@
  #define SBREG_BAR    0x10
  #define SBREG_SMBCTRL    0xc6000c
+#define SBREG_SMBCTRL_DNV    0xcf000c
  /* Host status bits for SMBPCISTS */
  #define SMBPCISTS_INTS    BIT(3)
@@ -1396,7 +1397,11 @@ static void i801_add_tco(struct i801_priv *priv)
  spin_unlock(&p2sb_spinlock);
  res = &tco_res[ICH_RES_MEM_OFF];
-    res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL;
+    if (pci_dev->device == PCI_DEVICE_ID_INTEL_DNV_SMBUS)
+    res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL_DNV;
+    else
+    res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL;
+
  res->end = res->start + 3;
  res->flags = IORESOURCE_MEM;





--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: driver: spi-nor: add new spi-norflash support

2018-09-27 Thread Bruce Ashfield


On 09/26/2018 12:03 AM, meng...@windriver.com wrote:

From: Limeng 


Hi Bruce,

Add 2 spi-norflash support  Stratix10 SoC platform.
Macronix 512Mb MX25U51245GXDI00
Macronix 2Gb MX66U2G45G



merged

Bruce


patches as below:
0001-spi-nor-add-support-for-mx66u2g45g.patch
0002-spi-nor-add-support-for-mx25u51245g.patch

Please help to meger the 2 patches into linux-yocto, kernel 4.12, branch is 
standard/base

spi-nor.c |2 ++
1 file changed, 2 insertions(+)


thanks,
Limeng



--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: intel-socfpga: drivers: edac: get patches for double bits ecc error detection

2018-09-27 Thread Bruce Ashfield


On 09/27/2018 02:45 AM, meng...@windriver.com wrote:

From: Limeng 


Hi Bruce,

Get below patches for double bits ecc error detection feature

0001-Documentation-dt-edac-Move-Altera-SOCFPGA-EDAC-file.patch
0002-EDAC-altera-Handle-SDRAM-Uncorrectable-Errors-on-Str.patch
0003-EDAC-altera-Fix-ARM64-build-warning.patch


merged

Bruce



Please help to meger this patch into linux-yocto, kernel 4.12, branch is 
standard/base


  Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt |  275 
--
  b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt |  275 
++
  b/drivers/edac/altera_edac.c|   69 ++
  b/drivers/edac/altera_edac.h|8
  4 files changed, 340 insertions(+), 287 deletions(-)


thanks,
Limeng



--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: arm64: dts: stratix10: move dts node gpio_fpga into board specific dts file.

2018-09-27 Thread Bruce Ashfield


On 09/26/2018 09:43 PM, meng...@windriver.com wrote:

From: Limeng 


Hi Bruce,

The FPGA IO peripheral is only in specific FPGA design on Intel-PSG Stratix10
development board, and not all FPGA designs include FPGA IO. In addtional, this
part of resource <0xf9001080 0x4> is able to be used for any peripheral.

Therefore, move the dts node gpio_fpga from header file socfpga_stratix10.dtsi
into board specific dts file

patches as below:
0001-arm64-dts-stratix10-move-dts-node-gpio_fpga-into-boa.patch


merged

Bruce



Please help to meger this patch into linux-yocto, kernel 4.12, branch is 
standard/base

  socfpga_stratix10.dtsi  |   16 
  socfpga_stratix10_socdk.dts |   16 
  2 files changed, 16 insertions(+), 16 deletions(-)


thanks,
Limeng



--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [PATCH][meta-virtualization] docker-distribution: fix do package qa warning

2018-09-29 Thread Bruce Ashfield


These are all to the wrong mailing list, please resend them
to the meta-virtualization list.

On 2018-09-29 5:26 AM, changqing...@windriver.com wrote:

From: Changqing Li 

fix below warning:

1.do_package_qa: QA Issue: No GNU_HASH in the elf binary: 
xxx/usr/sbin/registry' [ldflags]
2.do_package_qa: QA Issue: ELF binary 'xxx/usr/sbin/registry'
has relocations in .text [textrel]


These need to be 2 separate patches on the resend.

Bruce



Add GOBUILDFLAGS which have -buildmode=pie to fix the second problem

Signed-off-by: Changqing Li 
---
  .../docker-distribution/docker-distribution_git.bb |  3 +-
  .../files/0001-fix-do_package_qa-error.patch   | 32 ++
  2 files changed, 34 insertions(+), 1 deletion(-)
  create mode 100644 
recipes-containers/docker-distribution/files/0001-fix-do_package_qa-error.patch

diff --git a/recipes-containers/docker-distribution/docker-distribution_git.bb 
b/recipes-containers/docker-distribution/docker-distribution_git.bb
index add5ce1..23d94c9 100644
--- a/recipes-containers/docker-distribution/docker-distribution_git.bb
+++ b/recipes-containers/docker-distribution/docker-distribution_git.bb
@@ -6,6 +6,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=d2794c0df5b907fdace235a619d80314"
  SRCREV_distribution="48294d928ced5dd9b378f7fd7c6f5da3ff3f2c89"
  SRC_URI = 
"git://github.com/docker/distribution.git;branch=release/2.6;name=distribution;destsuffix=git/src/github.com/docker/distribution
 \
 file://docker-registry.service \
+   file://0001-fix-do_package_qa-error.patch \
"
  
  PACKAGES =+ "docker-registry"

@@ -57,7 +58,7 @@ do_install() {
  }
  
  INSANE_SKIP_${PN} += "ldflags already-stripped"

-INSANE_SKIP_docker-registry += "ldflags already-stripped"
+INSANE_SKIP_${MLPREFIX}docker-registry += "ldflags already-stripped"
  
  FILES_docker-registry = "${sbindir}/*"

  FILES_docker-registry += "${systemd_unitdir}/system/docker-registry.service"
diff --git 
a/recipes-containers/docker-distribution/files/0001-fix-do_package_qa-error.patch
 
b/recipes-containers/docker-distribution/files/0001-fix-do_package_qa-error.patch
new file mode 100644
index 000..269b0cd
--- /dev/null
+++ 
b/recipes-containers/docker-distribution/files/0001-fix-do_package_qa-error.patch
@@ -0,0 +1,32 @@
+From 4b9d701fabff8e7969db081406d00fa9fe46b3fd Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Thu, 27 Sep 2018 11:05:51 +0800
+Subject: [PATCH] fix do_package_qa error
+
+fix below error:
+do_package_qa: QA Issue: ELF binary 'xxx/usr/sbin/registry'
+has relocations in .text [textrel]
+
+Upstream-Status: Inappropriate [oe-specific]
+
+Signed-off-by: Changqing Li 
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index 47b8f1d..13b0f92 100644
+--- a/Makefile
 b/Makefile
+@@ -39,7 +39,7 @@ GODEP=$(shell which godep || echo '')
+
+ ${PREFIX}/bin/registry: $(GOFILES)
+   @echo "+ $@"
+-  @go build -tags "${DOCKER_BUILDTAGS}" -o $@ ${GO_LDFLAGS}  
${GO_GCFLAGS} ./cmd/registry
++  @go build -tags "${DOCKER_BUILDTAGS}" -o $@ ${GO_LDFLAGS} 
${GOBUILDFLAGS} ${GO_GCFLAGS} ./cmd/registry
+
+ ${PREFIX}/bin/digest:  $(GOFILES)
+   @echo "+ $@"
+--
+2.7.4
+



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-virtualization] docker: fix package qa warning

2018-09-29 Thread Bruce Ashfield


On 2018-09-29 5:26 AM, changqing...@windriver.com wrote:

From: Changqing Li 

fix below warning:
do_package_qa: QA Issue: ELF binary 'xxx/usr/bin/docker'
has relocations in .text [textrel]

Signed-off-by: Changqing Li 
---
  recipes-containers/docker/docker_git.bb|  1 +
  .../files/0001-fix-do_package_qa-error.patch   | 31 ++
  2 files changed, 32 insertions(+)
  create mode 100644 
recipes-containers/docker/files/0001-fix-do_package_qa-error.patch

diff --git a/recipes-containers/docker/docker_git.bb 
b/recipes-containers/docker/docker_git.bb
index 73e0120..1a8d1a6 100644
--- a/recipes-containers/docker/docker_git.bb
+++ b/recipes-containers/docker/docker_git.bb
@@ -28,6 +28,7 @@ SRC_URI = "\
file://docker.init \
file://hi.Dockerfile \
  file://0001-libnetwork-use-GO-instead-of-go.patch \
+file://0001-fix-do_package_qa-error.patch \
"
  
  # Apache-2.0 for docker

diff --git a/recipes-containers/docker/files/0001-fix-do_package_qa-error.patch 
b/recipes-containers/docker/files/0001-fix-do_package_qa-error.patch
new file mode 100644
index 000..79e71a5
--- /dev/null
+++ b/recipes-containers/docker/files/0001-fix-do_package_qa-error.patch
@@ -0,0 +1,31 @@
+From 56c865e2a7269d63f0780b4cd1ed6fdb18e3ff1b Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Wed, 26 Sep 2018 17:41:59 +0800
+Subject: [PATCH] fix do_package_qa error
+
+fix below error:
+do_package_qa: QA Issue: ELF binary 'xxx/usr/bin/docker'
+has relocations in .text [textrel]
+
+Upstream-Status: Inappropriate [oe-specific]
+
+Signed-off-by: Changqing Li 
+---
+ cli/scripts/build/dynbinary | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cli/scripts/build/dynbinary b/cli/scripts/build/dynbinary
+index 3c32ed3..938e086 100755
+--- a/cli/scripts/build/dynbinary
 b/cli/scripts/build/dynbinary
+@@ -9,6 +9,6 @@ source ./scripts/build/.variables
+
+ echo "Building dynamically linked $TARGET"
+ export CGO_ENABLED=1
+-go build -o "${TARGET}" -tags pkcs11 --ldflags "${LDFLAGS}" "${SOURCE}"
++go build -o "${TARGET}" -tags pkcs11 --ldflags "${LDFLAGS}" -buildmode=pie 
"${SOURCE}"


This should be conditional. I'm not seeing these warnings/errors
on any of my builds, so clearly you have a different configuration.

Bruce


+
+ ln -sf "$(basename "${TARGET}")" build/docker
+--
+2.7.4
+



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] kernel-dev: document the change detection of kernel feature files

2018-10-02 Thread Bruce Ashfield


On 2018-10-01 8:42 AM, Urs Fässler wrote:

Recommend to add recipe-space features to SRC_URI so that changes to them
are detected automatically.

Signed-off-by: Urs Fässler 
Signed-off-by: Pascal Bach 
---
  documentation/kernel-dev/kernel-dev-common.xml | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 83b02b1c1..6289ce8d4 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -2623,6 +2623,9 @@
  .scc file in the
  SRC_URI statement to reference multiple 
kernel
  features.
+Since BitBake only detects changes on files listed in
+SRC_URI, it is best to add all


This is not necessarily true. It would be better stated that if you
are modifying the .cfg files in the layer directly, you should list
them on the SRC_URI to have the changes picked up by bitbake.

It is not a matter of "best", so it should be stated that way.


+.cfg to SRC_URI.
  
  
  

@@ -2674,10 +2677,10 @@
  
  
  Add the Feature File to 
SRC_URI:
-Add the .scc file to the
+Add the .cfg and 
.scc file to the
  recipe's SRC_URI statement:
  
- SRC_URI_append = " file://test.scc"
+ SRC_URI_append = " file://test.cfg file://test.scc"


This is wrong. You should not have both on the SRC_URI

Bruce


  
  The leading space before the path is important as the
  path is appended to the existing path.



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] changing kernel config in Morty build

2018-10-05 Thread Bruce Ashfield


On 2018-10-04 4:38 PM, Greg Wilson-Lindberg wrote:

Does anybody else have any idea about what is going on here?



I can't tell from the information provided.

But if you can send me a set of layers to clone, and
configure locally, I can figure it out.

Cheers,

Bruce

Yocto is seeing my request to change the kernel config, suggests that 
the change is acceptable, but then doesn't make it.


Thanks in advance for any insight,

Greg

**

*From:*Greg Wilson-Lindberg
*Sent:* Tuesday, October 02, 2018 02:22 PM
*To:* yocto@yoctoproject.org
*Subject:* changing kernel config in Morty build

I'm trying to change some kernel configuration flags in a 
raspberrypi3 Morty build and I get warnings that it isn't working.


Here is the build info and warnings:

Build Configuration:

BB_VERSION        = "1.32.0"

BUILD_SYS         = "x86_64-linux"

NATIVELSBSTRING   = "universal"

TARGET_SYS        = "arm-poky-linux-gnueabi"

MACHINE           = "raspberrypi3"

DISTRO            = "b2qt"

DISTRO_VERSION    = "2.2.4"

TUNE_FEATURES     = "arm armv7ve vfp thumb neon vfpv4 
callconvention-hard cortexa7"


TARGET_FPU        = "hard"

SDKMACHINE        = "x86_64"

meta

meta-poky         = "HEAD:df76669bdd70aa0d903c4211dde731221c7e756d"

meta-raspberrypi  = "HEAD:2a192261a914892019f4f428d7462bb3c585ebac"

meta-oe

meta-python

meta-networking

meta-initramfs

meta-multimedia   = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"

meta-boot2qt

meta-raspberrypi-extras = ":"

meta-mingw        = "HEAD:1c2e155111dce94423cc227ea69f7f50f316c78e"

meta-qt5          = "HEAD:49e9d9a73b5c6e3d6eab88dc0005305e85b1a62d"

meta-sakura       = ":"

Initialising tasks: 100% 
|#| 
Time: 0:00:00


NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

WARNING: linux-raspberrypi-1_4.4.50+gitAUTOINC+04c8e47067-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it 
into the kernel's final configuration:


-- CONFIG_SND_SOC_MAX9768 -

Config: CONFIG_SND_SOC_MAX9768

From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg


Requested value:  CONFIG_SND_SOC_MAX9768=y

Actual value:

Config 'SND_SOC_MAX9768' has the following conditionals:

Dependency values are:

-- CONFIG_MAX1363 -

Config: CONFIG_MAX1363

From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg


Requested value:  CONFIG_MAX1363=m

Actual value:     # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:

   I2C (value: "y")

Dependency values are:

   I2C [y]

-- CONFIG_CAN_EMS_USB -

Config: CONFIG_CAN_EMS_USB

From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg


Requested value:  CONFIG_CAN_EMS_USB=m

Actual value:     # CONFIG_CAN_EMS_USB is not set

Config 'CAN_EMS_USB' has the following conditionals:

   (none)

Dependency values are:

Here is my

linux-raspberrypi_4.4.bbappend for the kernel:

# Scribe additions to Kernel configuration

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

FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URI += "file://Scribe.scc "

SRC_URI += "file://mcp251x.c.patch "

The Scribe.scc file:

# Scribe additions to kernel configuration

kconf hardware Scribe.cfg

And the Scribe.cfg file:

# Scribe additions to kernel configuration

# Enable MAX9768

#CONFIG_SOC_ALL_CODECS=m

#CONFIG_COMPILE_TEST=y

CONFIG_SND_SOC_MAX9768=y

# Enable MAX11606

#IIO=y

CONFIG_MAX1363=m

# Enable EMS CPC-USB

CONFIG_CAN_EMS_USB=m

Here is my directory tree:

Qt-5.9.6

      Yocto-mirror                                                     # 
Yocto build mirror


      Yocto-build-RPi3                                              # 
Yocto build root


                 build-raspberrypi                                   # 
build directory


                 sources
  # yocto sources


                        meta-sakura                                   # 
our recipes


                                recipes-kernel                        # 
directory for kernel changes


                                        linux
    # directory that contains linux-raspberrypi_4.4.bbappend


                                               files
      # directory that contains .scc & .cfg files


As seen above none of the changes are accepted although there is nothing 
that blocks any of them.


Any help understanding this would be greatly appreciated.

Regards,

Greg Wilson-Lindberg





--
___
yocto mailing list

Re: [yocto] changing kernel config in Morty build

2018-10-08 Thread Bruce Ashfield

On 2018-10-05 7:26 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
I've been able to reproduce the problem in a more minimal environment.

To build a basic Yocto Raspberry Pi environment I based my build on the 
instructions found here:
https://themeaningfulengineer.github.io/exploring-yocto-with-raspberrypi/

The steps that I actually executed are:

git clone -b morty --single-branch git://git.yoctoproject.org/poky
cd poky/
git clone -b morty http://git.yoctoproject.org/git/meta-raspberrypi
source oe-init-build-env rpi-build

In rpi-build/conf/local.conf I changed the MACHINE assignment to "raspberrypi2" from 
"qemu86"

In rpi-build/conf/bblayers.conf I added "  /home/gwilson/Qt/poky/meta-raspberrypi 
\" to pick up the raspberry layer.

At this point I ran:
bitbake rpi-hwup-image

to verify that the environment was correct. The build finished with only a 
couple of warnings about checksum problems and using alternate mirrors.
I then copied in my kernel scripts and added in the directory to the bblayers 
file.
When I rebuilt with these changes I get the same warnings/errors about changing 
the kernel config that I get with my full build environment.
I've attached my meta-test directory with the kernel configuration .bbappend and .scc 
& .cfg files, and the final bblayers.conf & local.conf files.
Thank you for taking a look at this.

Thanks Greg,

I was able to reproduce the problem a few minutes ago, but will have to 
look at the root cause in the morning!

Bruce

Regards,
Greg Wilson-Lindberg

*From:* yocto-boun...@yoctoproject.org 
 on behalf of Greg Wilson-Lindberg 

*Sent:* Friday, October 5, 2018 9:23:52 AM
*To:* Bruce Ashfield; yocto@yoctoproject.org
*Subject:* Re: [yocto] changing kernel config in Morty build
Hi Bruce,
I'll do my best to get something for you.
Thanks,

Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.

1750 W 214th Street | Torrance, CA 90501 | U.S.A.
T: +1 310 783 5075
F: +1 310 618 6902 | E: gwil...@sakuraus.com
www.sakuraus.com <http://www.sakuraus.com>

Confidentiality Notice: This e-mail transmission may contain 
confidential or legally privileged information that is intended only 
for the individual or entity named in the e-mail address. If you are 
not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, or reliance upon the contents of 
this e-mail is strictly prohibited. If you have received this e-mail 
transmission in error, please reply to the sender, so that Sakura 
Finetek USA, Inc. can arrange for proper delivery, and then please 
delete the message from your inbox. Thank you.

> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Friday, October 05, 2018 08:46 AM
> To: Greg Wilson-Lindberg ; yocto@yoctoproject.org
> Subject: Re: [yocto] changing kernel config in Morty build
>
> On 2018-10-04 4:38 PM, Greg Wilson-Lindberg wrote:
> > Does anybody else have any idea about what is going on here?
> >
>
> I can't tell from the information provided.
>
> But if you can send me a set of layers to clone, and configure 
locally, I can figure it

> out.
>
> Cheers,
>
> Bruce
>
> > Yocto is seeing my request to change the kernel config, suggests that
> > the change is acceptable, but then doesn't make it.
> >
> > Thanks in advance for any insight,
> >
> > Greg
> >
> > **
> >
> > *From:*Greg Wilson-Lindberg
> > *Sent:* Tuesday, October 02, 2018 02:22 PM
> > *To:* yocto@yoctoproject.org
> > *Subject:* changing kernel config in Morty build
> >
> > I'm trying to change some kernel configuration flags in a
> > raspberrypi3 Morty build and I get warnings that it isn't working.
> >
> > Here is the build info and warnings:
> >
> > Build Configuration:
> >
> > BB_VERSION        = "1.32.0"
> >
> > BUILD_SYS         = "x86_64-linux"
> >
> > NATIVELSBSTRING   = "universal"
> >
> > TARGET_SYS        = "arm-poky-linux-gnueabi"
> >
> > MACHINE           = "raspberrypi3"
> >
> > DISTRO            = "b2qt"
> >
> > DISTRO_VERSION    = "2.2.4"
> >
> > TUNE_FEATURES     = "arm armv7ve vfp thumb neon vfpv4
> > callconvention-hard cortexa7"
> >
> > TARGET_FPU        = "hard"
> >
> > SDKMACHINE        = "x86_64"
> >
> > meta
> >
> > meta-poky         = "HEAD:df76669bdd70aa0d903c4211dde731221c

Re: [yocto] changing kernel config in Morty build

2018-10-09 Thread Bruce Ashfield

On 2018-10-05 7:26 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
I've been able to reproduce the problem in a more minimal environment.

To build a basic Yocto Raspberry Pi environment I based my build on the 
instructions found here:
https://themeaningfulengineer.github.io/exploring-yocto-with-raspberrypi/

The steps that I actually executed are:

git clone -b morty --single-branch git://git.yoctoproject.org/poky
cd poky/
git clone -b morty http://git.yoctoproject.org/git/meta-raspberrypi
source oe-init-build-env rpi-build

In rpi-build/conf/local.conf I changed the MACHINE assignment to "raspberrypi2" from 
"qemu86"

In rpi-build/conf/bblayers.conf I added "  /home/gwilson/Qt/poky/meta-raspberrypi 
\" to pick up the raspberry layer.

At this point I ran:
bitbake rpi-hwup-image

to verify that the environment was correct. The build finished with only a 
couple of warnings about checksum problems and using alternate mirrors.

I then copied in my kernel scripts and added in the directory to the bblayers 
file.

When I rebuilt with these changes I get the same warnings/errors about changing 
the kernel config that I get with my full build environment.

I've attached my meta-test directory with the kernel configuration .bbappend and .scc 
& .cfg files, and the final bblayers.conf & local.conf files.

Thanks for the layers and cut & paste instructions. They helped
a lot.

.. even with that start, it took me a bit to figure things out.

In the end, I can't actually figure out how to get the fragment
working with the rpi kernel configuration routines as they stand
in the morty timeframe.

in recipes-kernel/linux/linux-rpi.inc, there's a do_configure_prepend
routine who's first action is to clear ${B}/.config .. which is where
the kernel-yocto bbclass would have put the merged config + fragment.
(The defconfig is also a placeholder defconfig, I could work around
that, but in the end, it doesn't matter since that routine zeros out
anything that has merged).

So as I see it, you'll either need to carry your own defconfig, patch
the in-tree defconfig that is used, or write routines in your bbappend
to modify the configuration directly. I admit to not looking to see
if the techniques to do this are described anywhere, since I was just
trying to sort out why the fragment wasn't being properly applied.

Sorry I couldn't be of more help.

Cheers,

Bruce

Thank you for taking a look at this.

Regards,

Greg Wilson-Lindberg

*From:* yocto-boun...@yoctoproject.org  
on behalf of Greg Wilson-Lindberg 

*Sent:* Friday, October 5, 2018 9:23:52 AM
*To:* Bruce Ashfield; yocto@yoctoproject.org
*Subject:* Re: [yocto] changing kernel config in Morty build
Hi Bruce,
I'll do my best to get something for you.
Thanks,

Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.

1750 W 214th Street | Torrance, CA 90501 | U.S.A.
T: +1 310 783 5075
F: +1 310 618 6902 | E: gwil...@sakuraus.com
www.sakuraus.com <http://www.sakuraus.com>

Confidentiality Notice: This e-mail transmission may contain 
confidential or legally privileged information that is intended only for 
the individual or entity named in the e-mail address. If you are not the 
intended recipient, you are hereby notified that any disclosure, 
copying, distribution, or reliance upon the contents of this e-mail is 
strictly prohibited. If you have received this e-mail transmission in 
error, please reply to the sender, so that Sakura Finetek USA, Inc. can 
arrange for proper delivery, and then please delete the message from 
your inbox. Thank you.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, October 05, 2018 08:46 AM
To: Greg Wilson-Lindberg ; yocto@yoctoproject.org
Subject: Re: [yocto] changing kernel config in Morty build

On 2018-10-04 4:38 PM, Greg Wilson-Lindberg wrote:
> Does anybody else have any idea about what is going on here?
>

I can't tell from the information provided.

But if you can send me a set of layers to clone, and configure locally, I can 
figure it
out.

Cheers,

Bruce

> Yocto is seeing my request to change the kernel config, suggests that
> the change is acceptable, but then doesn't make it.
>
> Thanks in advance for any insight,
>
> Greg
>
> **
>
> *From:*Greg Wilson-Lindberg
> *Sent:* Tuesday, October 02, 2018 02:22 PM
> *To:* yocto@yoctoproject.org
> *Subject:* changing kernel config in Morty build
>
> I'm trying to change some kernel configuration flags in a
> raspberrypi3 Morty build and I get warnings that it isn't working.
>
> Here is the build info and warnings:
>
> Build Configuration:
>
> BB_VERSION        = "1.32.0"
>
> BUILD_SYS         = "x86_64-linux"
>
> NATIVEL

Re: [yocto] changing kernel config in Morty build

2018-10-10 Thread Bruce Ashfield


On 2018-10-10 3:07 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
I've got another question. I know that in a .bbappend I can specify functions 
to run during the build procedure, would it be possible to add in a function 
that would run after the do_configure_prepend() in the linux-rpi.inf file? If I 
could do that, then I could modify the config file that is produced by that 
...prepend() function.


Yep. You can specify routines like that. You just need to get the
content and ordering right to do what you want.

Bruce



Or the other option is to modify the linux-rpi.inc file itself.
Regards,

Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.
  


-Original Message-
From: Greg Wilson-Lindberg
Sent: Wednesday, October 10, 2018 09:31 AM
To: 'Bruce Ashfield' ; yocto@yoctoproject.org
Subject: RE: [yocto] changing kernel config in Morty build

Hi Bruce,
Thanks for all of your help in looking into this. I did get another response 
that
detailed using an out of tree defconfig. They didn't know if it would work with 
Morty,
they are using it with Sumo. I'll have to try it with Morty.
Thanks again,
Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, October 09, 2018 08:16 PM
To: Greg Wilson-Lindberg ;
yocto@yoctoproject.org
Subject: Re: [yocto] changing kernel config in Morty build

On 2018-10-05 7:26 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
I've been able to reproduce the problem in a more minimal environment.

To build a basic Yocto Raspberry Pi environment I based my build on
the

instructions found here:

https://themeaningfulengineer.github.io/exploring-yocto-with-raspber
ry
pi/

The steps that I actually executed are:

git clone -b morty --single-branch git://git.yoctoproject.org/poky
cd poky/ git clone -b morty
http://git.yoctoproject.org/git/meta-raspberrypi
source oe-init-build-env rpi-build

In rpi-build/conf/local.conf I changed the MACHINE assignment to

"raspberrypi2"

from "qemu86"


In rpi-build/conf/bblayers.conf I added "
/home/gwilson/Qt/poky/meta-raspberrypi

\" to pick up the raspberry layer.


At this point I ran:
bitbake rpi-hwup-image

to verify that the environment was correct. The build finished with
only a couple of

warnings about checksum problems and using alternate mirrors.


I then copied in my kernel scripts and added in the directory to the bblayers 
file.

When I rebuilt with these changes I get the same warnings/errors
about changing

the kernel config that I get with my full build environment.


I've attached my meta-test directory with the kernel configuration
.bbappend and

.scc & .cfg files, and the final bblayers.conf & local.conf files.

Thanks for the layers and cut & paste instructions. They helped a lot.

.. even with that start, it took me a bit to figure things out.

In the end, I can't actually figure out how to get the fragment
working with the rpi kernel configuration routines as they stand in the morty

timeframe.


in recipes-kernel/linux/linux-rpi.inc, there's a do_configure_prepend
routine who's first action is to clear ${B}/.config .. which is where
the kernel-yocto bbclass would have put the merged config + fragment.
(The defconfig is also a placeholder defconfig, I could work around
that, but in the end, it doesn't matter since that routine zeros out anything 
that has

merged).


So as I see it, you'll either need to carry your own defconfig, patch
the in-tree defconfig that is used, or write routines in your bbappend
to modify the configuration directly. I admit to not looking to see if
the techniques to do this are described anywhere, since I was just
trying to sort out why the fragment wasn't being properly applied.

Sorry I couldn't be of more help.

Cheers,

Bruce



Thank you for taking a look at this.

Regards,

Greg Wilson-Lindberg




--
--
*From:* yocto-boun...@yoctoproject.org
 on behalf of Greg Wilson-Lindberg

*Sent:* Friday, October 5, 2018 9:23:52 AM
*To:* Bruce Ashfield; yocto@yoctoproject.org
*Subject:* Re: [yocto] changing kernel config in Morty build Hi
Bruce, I'll do my best to get something for you.
Thanks,

Greg Wilson-Lindberg
Principal Firmware Engineer | Sakura Finetek USA, Inc.

1750 W 214th Street | Torrance, CA 90501 | U.S.A.
T: +1 310 783 5075
F: +1 310 618 6902 | E: gwil...@sakuraus.com www.sakuraus.com
<http://www.sakuraus.com>





Confidentiality Notice: This e-mail transmission may contain
confidential or legally privileged information that is intended only
for the individual or entity named in the e-mail address. If you are
not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or reliance upon the contents of
this e-mail is strictly

Re: [yocto] Fwd: preempt-rt for 4.14.71 fails to build

2018-10-10 Thread Bruce Ashfield


On 2018-10-10 2:18 PM, Dimitris Tassopoulos wrote:

Hi all!

I've tried to build the latest preempt-rt kernel from the 
`v4.14/standard/preempt-rt/base`

and it fails to build. These are the hashes I've used:



This should go to the linux-yocto list, since that's where
people interested in the linux-yocto kernel variants will
notice it.

In this case, there was a bad merge. If you check the
preempt-rt branches of 4.14 there's a fix queued, but I
haven't sent SRCREV updates yet.

Bruce


```
LINUX_VERSION = "4.14.71"
SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3"
SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3"
```

And the errors I get are:
```
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: 
In function '__rt_mutex_lock':
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48: 
error: passing argument 3 of 'rt_mutex_fastlock' from incompatible 
pointer type [-Werror=incompatible-pointer-types]

   rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
                                                 ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: 
note: expected 'struct ww_acquire_ctx *' but argument is of type 'int 
(*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum 
rtmutex_chainwalk,  struct ww_acquire_ctx *)'

  rt_mutex_fastlock(struct rt_mutex *lock, int state,
  ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2: 
error: too few arguments to function 'rt_mutex_fastlock'

   rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
   ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: 
note: declared here

  rt_mutex_fastlock(struct rt_mutex *lock, int state,
  ^
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: 
In function 'rt_mutex_lock':
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2: 
error: too many arguments to function 'rt_mutex_lock_state'

   rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0);
   ^~~
/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20: 
note: declared here

  static int __sched rt_mutex_lock_state(struct rt_mutex *lock, int state)
```

Is there any change that the latest rt44 patches are nor applied?

Thanks!
Dimitris




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: preempt-rt for 4.14.71 fails to build

2018-10-10 Thread Bruce Ashfield


Check the list. It never came through. You need to be a subscriber
and would have received a bounce message.

I know that, since I got the bounce as the list admin :D

Bruce

On 2018-10-10 4:03 PM, Dimitris Tassopoulos wrote:
I've already send this to that list a few days ago, but since I didn't 
got any reply there I've also asked here in case that someone else 
shares the same experience.


Dimitris

On Wed, 10 Oct 2018, 21:48 Bruce Ashfield, <mailto:bruce.ashfi...@windriver.com>> wrote:


On 2018-10-10 2:18 PM, Dimitris Tassopoulos wrote:
 > Hi all!
 >
 > I've tried to build the latest preempt-rt kernel from the
 > `v4.14/standard/preempt-rt/base`
 > and it fails to build. These are the hashes I've used:
 >

This should go to the linux-yocto list, since that's where
people interested in the linux-yocto kernel variants will
notice it.

In this case, there was a bad merge. If you check the
preempt-rt branches of 4.14 there's a fix queued, but I
haven't sent SRCREV updates yet.

Bruce

 > ```
 > LINUX_VERSION = "4.14.71"
 > SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3"
 > SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3"
 > ```
 >
 > And the errors I get are:
 > ```
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:

 > In function '__rt_mutex_lock':
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48:

 > error: passing argument 3 of 'rt_mutex_fastlock' from incompatible
 > pointer type [-Werror=incompatible-pointer-types]
 >    rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
 >                                                  ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:

 > note: expected 'struct ww_acquire_ctx *' but argument is of type
'int
 > (*)(struct rt_mutex *, int,  struct hrtimer_sleeper *, enum
 > rtmutex_chainwalk,  struct ww_acquire_ctx *)'
 >   rt_mutex_fastlock(struct rt_mutex *lock, int state,
 >   ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2:

 > error: too few arguments to function 'rt_mutex_fastlock'
 >    rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
 >    ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1:

 > note: declared here
 >   rt_mutex_fastlock(struct rt_mutex *lock, int state,
 >   ^
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:

 > In function 'rt_mutex_lock':
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2:

 > error: too many arguments to function 'rt_mutex_lock_state'
 >    rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0);
 >    ^~~
 >

/rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20:

 > note: declared here
 >   static int __sched rt_mutex_lock_state(struct rt_mutex *lock,
int state)
 > ```
 >
 > Is there any change that the latest rt44 patches are nor applied?
 >
 > Thanks!
 > Dimitris
 >
 >



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-virtualization][PATCH] libvirt: remove qemu from PACKAGECONFIG for mips n32 and n64

2018-10-18 Thread Bruce Ashfield


Wrong mailing list. Use meta-virtualization for these patches.

I'm cross posting this there, for the archives.

I've grabbed and merged this change (but could easily have missed
it, since it was the wrong list and I wasn't directly copied).

Bruce

On 10/15/18 9:45 PM, kai.k...@windriver.com wrote:

From: Kai Kang 

PACKAGECONFIG 'qemu' causes libvirt depends on package qemu. But qemu
is not compatible with mips n32 and n64. So remove 'qemu' from
PACKAGECONFIG for mips n32 and n64.

Signed-off-by: Kai Kang 
Signed-off-by: Mark Hatle 
---
  recipes-extended/libvirt/libvirt_4.7.0.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/recipes-extended/libvirt/libvirt_4.7.0.bb 
b/recipes-extended/libvirt/libvirt_4.7.0.bb
index 47275ae..a1175f5 100644
--- a/recipes-extended/libvirt/libvirt_4.7.0.bb
+++ b/recipes-extended/libvirt/libvirt_4.7.0.bb
@@ -186,6 +186,10 @@ PACKAGECONFIG ??= "qemu yajl uml openvz vmware vbox esx 
iproute2 lxc test \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'polkit', 
'', d)} \
"
  
+# qemu is NOT compatible with mips64

+PACKAGECONFIG_remove_mipsarchn32 = "qemu"
+PACKAGECONFIG_remove_mipsarchn64 = "qemu"
+
  # enable,disable,depends,rdepends
  #
  PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu,"



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH v2] kernel-dev: note about the change detection of kernel feature files

2018-10-25 Thread Bruce Ashfield


On 10/22/18 5:07 AM, Urs Fässler wrote:

It is not the expected behavior that changes on the .cfg files only
referenced from .scc files are not detected.


This looks good to me.

Also note that I have an outstanding bugzilla to see if I can invalidate
stamps, etc, when these elements change .. so at that point, I'd be able
to fixup this documentation section.

Bruce



Signed-off-by: Urs Fässler 
Signed-off-by: Pascal Bach 
---
  documentation/kernel-dev/kernel-dev-common.xml | 4 
  1 file changed, 4 insertions(+)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 83b02b1c1..2e421e7ba 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -2623,6 +2623,10 @@
  .scc file in the
  SRC_URI statement to reference multiple 
kernel
  features.
+
+Bitbake only detects changes on files listed in
+SRC_URI.
+
  
  
  




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-26 Thread Bruce Ashfield

On 10/26/2018 4:28 AM, Måns Zigher wrote:
So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" even
though I am not so sure it is a workaround or not. The problem is fixed
adding to kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of kernel-devsrc
depending on /bin/awk

cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67

The best solution might be to add kernel patches but since the number of
/bin/awk have increased I think that this is fine in the kernel universe
but a problem in poky universe. So by adding it to kernel-devsrc it will
make sure that when the kernel get's tainted in the future it will not
break the rpm build. This is a "bug" only when using rpm ipk will not
detect it as a problem.

I'm ok with this type of solution as well, since this is similar
to what we've had to do with perf in the past (sed and modify versus
patching). I can always patch and fix things in linux-yocto, but then
another other kernel still suffers the issue.

It would be better if folks with this problem also send patches upstream
to allow us to vary the location of awk via a variable, since that would
eventually fix all kernels without needing any modifications .. but that
is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher >:

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc works. The
error is from do_populate_sdk and I am suspecting that the problem
is related to me using rpm. I believe rpm might be to smart in this
case detecting the dependency and resulting dnf from failing when
running the task do_populate_sdk. Any suggestion on how to get
forward on this error. I would like to run dnf manually to check any
dependency of the kernel-devsrc rpm package but cannot figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bruce Ashfield

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

On 10/26/2018 4:28 AM, Måns Zigher wrote:

So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" even
though I am not so sure it is a workaround or not. The problem is fixed
adding to kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of kernel-devsrc
depending on /bin/awk
cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.

Bruce

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher mailto:mans.zig...@gmail.com>>:

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bruce Ashfield

On 2018-10-29 11:12 AM, Khem Raj wrote:

On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
wrote:

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

On 10/26/2018 4:28 AM, Måns Zigher wrote:

So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" evenYup. That
works too (as would a variable from the env), but we'll still

need a sed based patch in the short term.

though I am not so sure it is a workaround or not. The problem is fixed
adding to kernel-devsrc.bbappend

The original solution can be found at

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.

short term is fine, but I think this should be fixed in upstream kernel.

Also agreed. That was my primary suggestion as well, since even with
that slow pace, we'd have it in all the kernel trees by the next
Yocto release window.

Bruce

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher mailto:mans.zig...@gmail.com>>:

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bruce Ashfield

On 2018-10-29 11:18 AM, Bas Mevissen wrote:

On 2018-10-29 16:14, Bruce Ashfield wrote:

On 2018-10-29 11:12 AM, Khem Raj wrote:

On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
wrote:

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

On 10/26/2018 4:28 AM, Måns Zigher wrote:
So it looks like the number of /bin/awk have increased so the
patch will
fix one problem but there is more to fix. I have a "workaround"
evenYup. That works too (as would a variable from the env), but
we'll still

need a sed based patch in the short term.
though I am not so sure it is a workaround or not. The problem is
fixed

adding to kernel-devsrc.bbappend

The original solution can be found at

The best solution might be to add kernel patches but since the
number of
/bin/awk have increased I think that this is fine in the kernel
universe
but a problem in poky universe. So by adding it to kernel-devsrc
it will
make sure that when the kernel get's tainted in the future it
will not
break the rpm build. This is a "bug" only when using rpm ipk will
not

detect it as a problem.

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.

short term is fine, but I think this should be fixed in upstream kernel.

Also agreed. That was my primary suggestion as well, since even with
that slow pace, we'd have it in all the kernel trees by the next
Yocto release window.

I would recommend to keep some kind of automated hot patching in as not
all vendor kernels will catch up that quickly, if ever.

That is what we normally do. See the old perf patches. They test for
the issue, and then sed the change if required.

Bruce

-- Bas.

Bruce

It would be better if folks with this problem also send patches
upstream
to allow us to vary the location of awk via a variable, since that
would
eventually fix all kernels without needing any modifications ..
but that

is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher

<mailto:mans.zig...@gmail.com>>:

Hi,

I am trying to add the kernel devsrc to the SDK but I am
getting the

following error

Problem: conflicting requests
- nothing provides /bin/awk needed by
kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this
problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

running the task do_populate_sdk. Any suggestion on how to get
forward on this error. I would like to run dnf manually to
check any
dependency of the kernel-devsrc rpm package but cannot
figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [avahi] add service into rocko

2018-10-31 Thread Bruce Ashfield


On 10/31/18 7:03 AM, Jairo wrote:

Hi all,

I need to install an avahi service on rocko for (a node of) node-red.

OK, I have an avahi_0.6.32.bb recipe at 'sources/poky/meta/recipes-
connectivity/avahi/' which path is added at bblayers.conf file.

but if I add the package at local.conf file like this:

IMAGE_INSTALL_append = " avahi"

when I try to make an image, bitbake can't find avahi

Collected errors:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy
'avahi'.

What I'm doing wrong?


The recipe name and the packages that you install are not (always)
the same thing.

i.e. in the recipe:

PACKAGES =+ "libavahi-gobject avahi-daemon libavahi-common libavahi-core 
libavahi-client avahi-dnsconfd libavahi-glib avahi-autoipd avahi-utils"



So depending on the functionality that you want, you'd be installing
one or more of those packages to your image. (I'm betting you just
want avahi-daemon).

Bruce



Thanks,
Jairo




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

2018-10-31 Thread Bruce Ashfield


On 10/31/18 9:23 AM, Heiko Schocher wrote:

Hello all,

just builded core-image-minimal with current head of thud branch for
the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 
4.14.78",

installed the resulting sd card image and boot it, and get:

INIT: Id "O0" respawning too fast: disabled for
5 minutes

Reason seems to be:

meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

SERIAL_CONSOLES = "115200;ttyO0"

shouldn't this be

SERIAL_CONSOLES = "115200;ttyS0"

With this fix, sd card image boot fine ... may I oversee seomthing
obvious ?


Doesn't look like it.

I'd suggest sending a patch to the yocto mailing list, that
way folks can comment directly and it can be pulled into
point releases, etc.

Bruce



bye,
Heiko


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

2018-11-02 Thread Bruce Ashfield


On 2018-11-02 4:59 AM, Kevin Hao wrote:

On Fri, Nov 02, 2018 at 09:01:34AM +0100, Heiko Schocher wrote:

Hello Kevin,

Am 01.11.2018 um 03:18 schrieb Kevin Hao:

On Wed, Oct 31, 2018 at 02:23:00PM +0100, Heiko Schocher wrote:

Hello all,

just builded core-image-minimal with current head of thud branch for
the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 4.14.78",
installed the resulting sd card image and boot it, and get:

INIT: Id "O0" respawning too fast: disabled for
5 minutes

Reason seems to be:

meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

SERIAL_CONSOLES = "115200;ttyO0"

shouldn't this be

SERIAL_CONSOLES = "115200;ttyS0"

With this fix, sd card image boot fine ... may I oversee seomthing
obvious ?


No, it should be 'ttyO0'. It is set by the omap serial driver. You can
refer the following in platform_data/serial-omap.h:
#define OMAP_SERIAL_NAME"ttyO"


Yes, you are right, but I see with linux kernel 4.14.78 from

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=e7405910ca5553eae8744af4e5c03e64ee048cb1

and I see:

[0.00] Linux version 4.14.78 (oe-user@oe-host) (gcc version 8.2.0
(GCC)) #1 Thu Nov 1 10:51:09 UTC 2018
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
[...]
[0.362878] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
[0.365758] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud = 
300) is a 8250
[1.030465] console [ttyS0] enabled

So definitely a ttyS0 ...


OK, so you don't use the linux-yocto kernel, you must not use the Yocto kernel
meta either. The reason that you got a ttyS0 here is that you use the
8250_omap.c driver. But in Yocto we use the omap-serial.c driver. You can
workaround this issue by enabling SERIAL_8250_OMAP_TTYO_FIXUP.


Thanks Kevin!

I had missed that detail in my reply.

Bruce



Thanks,
Kevin



bye,
Heiko


Thanks,
Kevin



bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-kernel-cache][v4.4][PATCH] kver: bump to v4.4.147

2018-11-06 Thread Bruce Ashfield


On 2018-11-06 5:10 PM, akuster808 wrote:


On 11/6/18 2:05 PM, Khem Raj wrote:

On Tue, Nov 6, 2018 at 1:57 PM Armin Kuster  wrote:

Signed-off-by: Armin Kuster
---
  kver | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kver b/kver
index 7b008cd..5ccc572 100644
--- a/kver
+++ b/kver
@@ -1 +1 @@
-v4.4.141
+v4.4.147

why not 4.4.162


because linux-yocto-4.4 
 is not at 
4.4.162. I am just trying to use the latest in that kernel repo.


Did you want .162 ? I have a whole set of -stable updates staged
here, but haven't pushed anything since releases are imminent.

But in the case of 4.4, I could lift my freeze, given that the kernel
recipe isn't active in master, hence the release schedule is
different.

Bruce




- armin


--
2.7.4

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-kernel-cache][v4.4][PATCH] kver: bump to v4.4.147

2018-11-06 Thread Bruce Ashfield


On 2018-11-06 8:07 p.m., akuster808 wrote:


On 11/6/18 2:42 PM, Bruce Ashfield wrote:

On 2018-11-06 5:10 PM, akuster808 wrote:


On 11/6/18 2:05 PM, Khem Raj wrote:

On Tue, Nov 6, 2018 at 1:57 PM Armin Kuster
wrote:

Signed-off-by: Armin Kuster
---
   kver | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kver b/kver
index 7b008cd..5ccc572 100644
--- a/kver
+++ b/kver
@@ -1 +1 @@
-v4.4.141
+v4.4.147

why not 4.4.162


because linux-yocto-4.4
<http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/> is not
at 4.4.162. I am just trying to use the latest in that kernel repo.


Did you want .162 ? I have a whole set of -stable updates staged
here, but haven't pushed anything since releases are imminent.


We are a day or two away from freezing for a Rocko QA run so if I can
get it sometime tomorrow, I should be able to  get some runtime on that
update otherwise no need to rush things.


If you check the 4.4 tree, and the kernel-cache, I've pushed the
latest set of -stable updates.

Up to you if you want to bump the SRCREVs to pick them up, but I've
validated them with my builds/boots.

Bruce



- armin



But in the case of 4.4, I could lift my freeze, given that the kernel
recipe isn't active in master, hence the release schedule is
different.




Bruce




- armin


--
2.7.4

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto






--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QEMU kernel defconfigs

2018-11-15 Thread Bruce Ashfield


On 2018-11-15 12:29 p.m., Jon Mason wrote:

I'm having difficulty determining where the kernel defconfigs are
defined and located.  I'm specifically looking for the qemuarm and
qemuarm64 kernel defconfigs.  I've looked at the relevant
documentation, 
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
and
no SRC_URI with defconfig or KBUILD_DEFCONFIG_KMACHINE defined in
meta/recipes-kernel/linux/linux-yocto_4.18.bb

What am I missing?


The reference machines with linux-yocto don't use defconfigs at all.
They are fully assembled from the configuration fragments in the
kernel-cache repo.

You'll see the location of the kernel-cache, and the routines that
gather up the fragments in the linux-yocto* recipes.

The kernel development manual has that detail as well:

https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#kernel-dev-advanced

Bruce



Also, "A defconfig file is simply a .config renamed to "defconfig"."
is not correct.  A properly created defconfig is created by `make
savedefconfig` and is a minimal file which only has the delta between
the desired config and defaults from the Kconfig files.
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file

Thanks,
Jon



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kconfig variables not being included in yocto build.

2018-11-19 Thread Bruce Ashfield

On 2018-11-19 2:13 p.m., Sakib Sajal wrote:

Hello,

I have been trying to patch the linux kernel and add some kernel
configuration but I am failing to add kconfig fragments to be included
in the final build.

Initially I tried patching the kernel with hardcoded values in the patch.

I am building for qemu to minimize the variables I have to worry about.

Build Configuration:
BB_VERSION = "1.38.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-16.04"
TARGET_SYS = "i586-poky-linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "2.5.1" // branch "sumo"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""

My initial project structure:

-poky
--meta
--meta-poky
--meta-yocto-bsp
--meta-my-layer
---recipes-kernel
linux
-linux-yocto
--my-patch.patch
-linux-yocto_4%.bbappend
---conf
layer.conf

Content of the bbappend file:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://my-patch.patch"

I enabled my-layer by adding the layer in the build/conf/bblayers.conf
file. I was able to build an image and test my changes with the
hardcoded valued in my patch.

However I want the values to be configurable through kernel
configuration. Since I knew what variables I have introduced, I put them
in a .cfg file with their desired values in the linux-yocto folder.

New project structure:

-poky
--meta-my-layer
---recipes-kernel
linux
-linux-yocto
--my-conf-frag.cfg

(other files and directories are same as before)

Added the following line to the .bbappend file:
SRC_URI += "file://my-conf-frag.cfg"

Content of my-conf-frag.cfg:
CONFIG_MY_FIRST_VAR="MY-NAME"
CONFIG_MY_SECOND_VAR=y

Then I run:
bitbake core-image-base

and get the following error:

ERROR: Task
(/poky/meta/recipes-kernel/linux/linux-yocto_4.14.bb:do_compile)
failed with exit code '1'

The kernel isn't being compiled since it does not know what
"CONFIG_MY_FIRST_VAR" is.

I checked for .config files in the build directory and found one in
"poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/cfg/.config"
which contained the two variables I defined in my cfg file. But that
file is a kernel configuration fragment file itself. The final config
file which is used to build the image is located, I believe, in
"poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.14.67+gitAUTOINC+c43c9e19a2_084af9624d-r0/linux-qemux86-standard-build/.config"
but i do not see the variables there in the final .config file. I was
also able to locate the cfg and the patch file in
"/poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.14.67+gitAUTOINC+c43c9e19a2_084af9624d-r0/"directory.
Therefore the files are being picked up by the build system but the
fragments are not being applied to make the final .config file used to
build the kernel.

Without being able to see the code that defines those CONFIG_
symbols, I can't say for sure. But if the fragment was located
and added to the config queue, then the only real way that they
wouldn't be in the final .config is a missing dependency for the
option.

If there's any way that you could make the specific layers available
to me for a test build, I could offer more specific suggestions.

Bruce

I went through yocto mailing list for similar problems and followed the
steps provided with no success. I also went through yocto's mega-manual
and kernel development manual as well as the yocto-lab pdfs and followed
all the different steps but i always get the compilation error.

Can someone please help me. Thanks in advance!

Sakib Sajal

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-kernel-tools][PATCH] tools/kconf_check: modify grep pattern

2018-12-12 Thread Bruce Ashfield


On 12/11/18 5:12 AM, Hongzhi.Song wrote:

The cmd line, , can't
match all expect config options.

This is because that it is not always space after 'config'


This should say "not always one space". There really should
always just be a single space, but typos do sneak in. I'll
queue the patch shortly.

Bruce


in kernel-source/*/.../Kconfig.
e.g. "config  IP_VS_IPV6" in net/netfilter/ipvs/Kconfig

So we should change the cmd to grep '^[  ]*\(menu\)*config\s'.

Signed-off-by: Hongzhi.Song 
---
  tools/kconf_check | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kconf_check b/tools/kconf_check
index aa86180..20b49cd 100755
--- a/tools/kconf_check
+++ b/tools/kconf_check
@@ -241,7 +241,7 @@ find ${kernel_source} \
  # known list of all Kconfig* files.  Again, must filter dups.
  rm -f ${LOGDIR}/all.cfg
  for i in `cat ${LOGDIR}/all.kcf` ; do
-cat ${kernel_source}/$i | grep '^[ ]*\(menu\)*config ' | \
+cat ${kernel_source}/$i | grep '^[ ]*\(menu\)*config\s' | \
awk '{print "CONFIG_"$2}' >> ${LOGDIR}/all.cfg
  done
  mv -f ${LOGDIR}/all.cfg ${LOGDIR}/all.cfg~



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-kernel-tools][PATCH] tools/kconf_check: modify grep pattern

2018-12-16 Thread Bruce Ashfield


On 2018-12-12 8:36 p.m., Hongzhi, Song wrote:

Thanks.

So would you help to remedy the commit log while merging the patch?


I've tweaked the message and added this to my queue. It will
come out early this week.

Bruce




--Hongzhi


On 12/13/2018 02:45 AM, Bruce Ashfield wrote:

On 12/11/18 5:12 AM, Hongzhi.Song wrote:

The cmd line, , can't
match all expect config options.

This is because that it is not always space after 'config'


This should say "not always one space". There really should
always just be a single space, but typos do sneak in. I'll
queue the patch shortly.

Bruce


in kernel-source/*/.../Kconfig.
e.g. "config  IP_VS_IPV6" in net/netfilter/ipvs/Kconfig

So we should change the cmd to grep '^[  ]*\(menu\)*config\s'.

Signed-off-by: Hongzhi.Song 
---
  tools/kconf_check | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kconf_check b/tools/kconf_check
index aa86180..20b49cd 100755
--- a/tools/kconf_check
+++ b/tools/kconf_check
@@ -241,7 +241,7 @@ find ${kernel_source} \
  # known list of all Kconfig* files.  Again, must filter dups.
  rm -f ${LOGDIR}/all.cfg
  for i in `cat ${LOGDIR}/all.kcf` ; do
-    cat ${kernel_source}/$i | grep '^[ ]*\(menu\)*config ' | \
+    cat ${kernel_source}/$i | grep '^[ ]*\(menu\)*config\s' | \
  awk '{print "CONFIG_"$2}' >> ${LOGDIR}/all.cfg
  done
  mv -f ${LOGDIR}/all.cfg ${LOGDIR}/all.cfg~








--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] poky-lsb: bump preferred kernel to 4.19

2018-12-16 Thread Bruce Ashfield

Signed-off-by: Bruce Ashfield 
---

This goes along with the series just sent to oe-core to remove 4.14 and
introduce 4.19 as the LTS (and LSB) kernel. 

Bruce

 meta-poky/conf/distro/poky-lsb.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky-lsb.conf 
b/meta-poky/conf/distro/poky-lsb.conf
index 1c426bae0e87..5c7e2720abaf 100644
--- a/meta-poky/conf/distro/poky-lsb.conf
+++ b/meta-poky/conf/distro/poky-lsb.conf
@@ -11,4 +11,4 @@ PREFERRED_PROVIDER_virtual/libx11 = "libx11"
 KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
 
 # Use the LTSI Kernel for LSB Testing
-PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.14%"
+PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.19%"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] x86_64 kernel with i586 userland plus SDK?

2018-12-17 Thread Bruce Ashfield


On 12/17/18 7:25 AM, Richard Weinberger wrote:

[Resending with correct mail]

Richard,

On Mon, Dec 17, 2018 at 11:34 AM  wrote:


On Mon, 2018-12-17 at 11:26 +0100, Richard Weinberger wrote:

On Wed, Nov 28, 2018 at 9:42 AM Richard Purdie
 wrote:

The system can definitely do it, its just not something we tend to
do
very often so its not entirely clear the best way to do it.

What may work is selecting the i586 tune from an x64-64 target
machine?

Copying qemux86-64.conf to qemux86-64-2.conf and changing it to
have
DEFAULTTUNE ?= "i586" did appear to start to build at least in a
quick
test here...


I went this approach for now.
That way I get i586 userland and an SDK with both 32bit and 64bit
toolchains.
The SDK offers me multiple environment files to include.

What I don't understand right now is, how can i tell the kernel
recipe
that it has
to use the 64bit toolchain to build the kernel?

Any hints?


I think (but am going from memory) that the x86 toolchains can generate
64 and 32 bit code with the right compiler option. The kernel just
passes in the right options if configured to build as 64 bit even if it
has the 32 bit toolchain?


This was my hope, and this is also what I get when doing such builds manually.
Having a x86_64 gcc and building userspace with "-m32" appended.

Yocto seems to try a different approach.
When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
toolchain by default.

Build Configuration:
BB_VERSION   = "1.38.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "i686-poky-linux"
MACHINE  = "myqemux86-64"
DISTRO   = "poky"
DISTRO_VERSION   = "2.5.1"
TUNE_FEATURES= "m32 i586"

What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
kernel (and modules).


For the most part the kernel builds do not take any flags from the
outside, i.e. they are all generated based on the kernel build
structure, not what is calling the build. (unless you bury flags
into the definition of $(CC), etc, but I wouldn't recommend that.

So if you have a 64 bit capable toolchain, have a 64 bit configured
kernel (i.e. CONFIG_64BIT=y), are passing -m32 to usespace .. the
kernel really should build 64bit.

Have you tried that and are seeing the kernel still be built with the
32bit toolchain ?

Bruce






--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] x86_64 kernel with i586 userland plus SDK?

2018-12-17 Thread Bruce Ashfield


On 12/17/18 8:50 AM, Richard Weinberger wrote:

Bruce,

On Mon, Dec 17, 2018 at 2:47 PM Bruce Ashfield
 wrote:

Yocto seems to try a different approach.
When I use qemux86-64.conf with DEFAULTTUNE being "i586" it generates a 32bit
toolchain by default.

Build Configuration:
BB_VERSION   = "1.38.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "i686-poky-linux"
MACHINE  = "myqemux86-64"
DISTRO   = "poky"
DISTRO_VERSION   = "2.5.1"
TUNE_FEATURES= "m32 i586"

What I need is a x86_64-poky-linux toolchain with -m32 set for everything except
kernel (and modules).


For the most part the kernel builds do not take any flags from the
outside, i.e. they are all generated based on the kernel build
structure, not what is calling the build. (unless you bury flags
into the definition of $(CC), etc, but I wouldn't recommend that.

So if you have a 64 bit capable toolchain, have a 64 bit configured
kernel (i.e. CONFIG_64BIT=y), are passing -m32 to usespace .. the
kernel really should build 64bit.


This was my plan, but yocto always create a 32bit toolchain when
it set DEFAULTTUNE to i586 for a 64bit machine.


Have you tried that and are seeing the kernel still be built with the
32bit toolchain ?


Yes, it builds with i686-poky-linux. :-(


It's Monday, and I've only had half a coffee .. so bear with me. When
I see i686, I'd expect that without -m32 it is generating 64bit by
default .. so there's definitely a -m32 sneaking into the definition of
CC for the kernel build ?

Do you have a dump of the kernel build line that I could see ?

Bruce





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incorrect config generated for yocto-style kernel (sumo)

2019-01-09 Thread Bruce Ashfield


On 2019-01-07 9:00 a.m., Kristupas Savickas wrote:

Hello,

I'm porting a kernel to use yocto-style build process. The kernel 
fetches fine, but there's a problem with '.config' file generation. I'd 
like to supply a 'defconfig' and a configuration fragment file 
'test.cfg' (which should be overlayed on top of 'defconfig') from the 
bitbake recipe. What I end up getting is a '.config' file that looks 
like it used the default values - neither 'defconfig' nor 'test.cfg' was 
used. Here's what I have going in my recipe:


The defconfig + fragment wouldn't have been ignored, but it is
also possible that other settings / fragments were applied that
are making it look like they were not applied.

Can you look at your kernel-source/.kernel-meta/bsp_definition
file, and see what was used as the entry point to the configuration ?
If something was generated by the system, it would be pulling in
the standard definitions/fragments.

Cheers,

Bruce




LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

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

SRCREV    = "8f450c58d196723a78527b643910b90d7cd6549f"

SRC_URI = " \
     git://g...@redacted.git;protocol=ssh \
     file://defconfig \
"

SRC_URI_append_test = "file://test.cfg"

PV = "3.18.20"
KBRANCH = "master"

KMACHINE = "test"
KARCH = "arm"

And here's what the directory structure looks like:

meta-test/recipes-kernel/linux-test
├── meta-test/recipes-kernel/linux-test/files
│   ├── meta-test/recipes-kernel/linux-test/files/defconfig
│   └── meta-test/recipes-kernel/linux-test/files/test.cfg
└── meta-test/recipes-kernel/linux-test/linux-test_git.bb

Configuration files are fetched as intended:

$ ls build/tmp-glibc/work/test-oe-linux-gnueabi/linux-test/3.18.20-r0/
defconfig    linux-test-standard-build  recipe-sysroot-native test.cfg
license-destdir  recipe-sysroot   temp


I've followed instructions from 
https://www.yoctoproject.org/docs/2.5/kernel-dev/kernel-dev.html#creating-a-defconfig-file 
and 
https://www.yoctoproject.org/docs/2.5/kernel-dev/kernel-dev.html#creating-config-fragments. 



Am I doing something wrong here?



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Deactivating KERNEL_FEATURES

2019-01-29 Thread Bruce Ashfield

On Tue, Jan 29, 2019 at 9:50 PM Chuck Wolber  wrote:
>
> This question is with respect to the Yocto thud (2.6.x) branch. I have also 
> reviewed section 2.3.3 and 2.3.4 of the Kernel Development document.
>
>
> My kernel configuration (cfg) seems to be overridden by KERNEL_FEATURES and 
> it is not clear how to stop this behavior. To take one specific example, 
> nothing I have tried seems to successfully deactivate the sound configuration 
> kernel options.
>
> My linux-yocto_4.18.%.bbappend file has the following contents:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI_append += "file://0001-kernel-config.cfg"
>
> The following line appears in 0001-kernel-config.cfg:
>
> # CONFIG_SOUND is not set
>
> And yet when I configure the kernel (bitbake -c configure linux-yocto) the 
> resultant .config in the linux-yocto ${WORKDIR} contains "CONFIG_SOUND=m" and 
> a plethora of other sound related options that should be turned off. I did 
> the full kernel build and verified that the .config reflects the final result 
> in the kernel.
>
> "bitbake -e linux-yocto" contains the following, which seems to explain a bit:
>
> KERNEL_FEATURES=" features/nfsd/nfsd-enable.scc features/debug/printk.scc  
> features/kernel-sample/kernel-sample.scc features/netfilter/netfilter.scc 
> cfg/virtio.scc cfg/sound.scc cfg/paravirt_kvm.scc "
>
> I should also add that our configuration includes:
>
> DISTRO_FEATURES_remove = " alsa pulseaudio" 
> DISTRO_FEATURES_BACKFILL_CONSIDERED = " alsa pulseaudio".
>
>
> How do I ensure that my kernel config gets the last say and is not overridden?

KERNEL_FEATURES is a variable like any other. Have you tried using
KERNEL_FEATURES_remove to pull the sound configs out ? We've also only
enabled those features for the qemux86* machines, so it shouldn't be
leaking into other configs .. but as you mentioned, perhaps the sound
configs are just something you picked as an example.

Bruce

>
> Thank you,
>
> ..Ch:W..
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable

2019-02-02 Thread Bruce Ashfield


On 2019-02-02 9:59 p.m., Ken Sloat wrote:

Hello,

I have an out of tree kernel module which I want autoloaded at startup
on my system. Looking at the Yocto project manual, I see that one way
I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
variable within my custom module recipe.

What I have found is that the module-split class is indeed generating
the "/etc/modules-load.d/mymodule.conf" file, however this file is not
actually being installed. To be more precise it is appearing in the
"package" directory (i.e.
tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
within the "image" directory (nor in my final rootfs).

Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
Is the intention for this variable I add extra steps to manually
install this file in my recipe? FYI I'm using Morty.


Can you provide your recipe ? It would make suggestions easier. For
example, my first question is: Is the module being installed to your
image via IMAGE_INSTALL, or some other similar variable ?

Bruce



Thanks,
Ken Sloat



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable

2019-02-02 Thread Bruce Ashfield


On 2019-02-02 10:16 p.m., Ken Sloat wrote:

On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
 wrote:


On 2019-02-02 9:59 p.m., Ken Sloat wrote:

Hello,

I have an out of tree kernel module which I want autoloaded at startup
on my system. Looking at the Yocto project manual, I see that one way
I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
variable within my custom module recipe.

What I have found is that the module-split class is indeed generating
the "/etc/modules-load.d/mymodule.conf" file, however this file is not
actually being installed. To be more precise it is appearing in the
"package" directory (i.e.
tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
within the "image" directory (nor in my final rootfs).

Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
Is the intention for this variable I add extra steps to manually
install this file in my recipe? FYI I'm using Morty.


Can you provide your recipe ? It would make suggestions easier. For
example, my first question is: Is the module being installed to your
image via IMAGE_INSTALL, or some other similar variable ?

Bruce



Thanks,
Ken Sloat





Hi Bruce,

Thanks for your quick reply. Yes the module is being installed via
image_install. Module is installed but generated conf file is not. See
recipe below:


Hmm. If you are really installing kernel-module- to the
image, at a glance, what you have really should be enough.

Can you confirm that you are seeing your .ko on the image, and that
it just isn't being autoloaded ? Are you running an init system that
respects the autoload configuration ?



require mymodule.inc

inherit module kernel-module-split


Note that module already inherits kernel-module-split, so you really
shouldn't need to explicitly add that inherit.

Bruce



DEPENDS = "virtual/kernel"

EXTRA_OEMAKE_append = " \
 KERNELDIR=${STAGING_KERNEL_DIR} \
 "

MAKE_TARGETS = "module"

MODULE_NAME = "mymodule"

PKG_${PN} = "kernel-module-${MODULE_NAME}"

module_do_install() {
 install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
 install -m 0644 ${MODULE_NAME}.ko \
 ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
}

FILES_${PN} = " \
 /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
"

KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/4] meta-yocto-bsp/poky: update kernel to 5.0

2019-03-06 Thread bruce . ashfield

From: Bruce Ashfield 

This is a follow on to my oe-core series that introduces the 5.0
kernel. Once that is merged (and all outstanding issues resolved),
these can be applied to make the default 5.0 for poky and the
reference BSPs.

The removal of 4.18 from master will follow once everything is updated.

Cheers,

Bruce

The following changes since commit bbcc844c89493841d002cddb00a537a069b278e2:

  machine: bump preferred version to 5.0 (2019-03-06 11:37:45 -0500)

are available in the Git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (2):
  meta-yocto-bsp: introduce 5.0 bbappend
  poky/kernel: make default 5.0

Kevin Hao (2):
  meta-yocto-bsp: Add the v5.0 kernel support for all the BSPs
  meta-yocto-bsp: Update the default kernel to v5.0 for the non-x86 BSPs

 meta-poky/conf/distro/poky.conf   |  2 +-
 .../conf/machine/beaglebone-yocto.conf|  2 +-
 meta-yocto-bsp/conf/machine/edgerouter.conf   |  2 +-
 meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf |  2 +-
 .../linux/linux-yocto_5.0.bbappend| 27 +++
 5 files changed, 31 insertions(+), 4 deletions(-)
 create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend

-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/4] meta-yocto-bsp: introduce 5.0 bbappend

2019-03-06 Thread bruce . ashfield

From: Bruce Ashfield 

Although the hardware reference boards are not using the 5.x
kernel yet, we generate a baseline bbappend for future work.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.0.bbappend| 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
new file mode 100644
index 00..de5d84db11
--- /dev/null
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
@@ -0,0 +1,27 @@
+KBRANCH_genericx86  = "v4.19/standard/base"
+KBRANCH_genericx86-64  = "v4.19/standard/base"
+KBRANCH_edgerouter = "v4.19/standard/edgerouter"
+KBRANCH_beaglebone-yocto = "v4.19/standard/beaglebone"
+KBRANCH_mpc8315e-rdb = "v4.19/standard/fsl-mpc8315e-rdb"
+
+KMACHINE_genericx86 ?= "common-pc"
+KMACHINE_genericx86-64 ?= "common-pc-64"
+KMACHINE_beaglebone-yocto ?= "beaglebone"
+
+SRCREV_machine_genericx86?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_genericx86-64 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
+SRCREV_machine_edgerouter ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
+SRCREV_machine_beaglebone-yocto ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_mpc8315e-rdb ?= "21aae3b4437eb6eec18804f1bad692030352430c"
+
+COMPATIBLE_MACHINE_genericx86 = "genericx86"
+COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
+
+LINUX_VERSION_genericx86 = "4.19.14"
+LINUX_VERSION_genericx86-64 = "4.19.14"
+LINUX_VERSION_edgerouter = "4.19.14"
+LINUX_VERSION_beaglebone-yocto = "4.19.14"
+LINUX_VERSION_mpc8315e-rdb = "4.19.14"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/4] meta-yocto-bsp: Add the v5.0 kernel support for all the BSPs

2019-03-06 Thread bruce . ashfield

From: Kevin Hao 

Boot test for all the boards.

Signed-off-by: Kevin Hao 
Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.0.bbappend| 24 +--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
index de5d84db11..fe52a06550 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
@@ -1,17 +1,17 @@
-KBRANCH_genericx86  = "v4.19/standard/base"
-KBRANCH_genericx86-64  = "v4.19/standard/base"
-KBRANCH_edgerouter = "v4.19/standard/edgerouter"
-KBRANCH_beaglebone-yocto = "v4.19/standard/beaglebone"
-KBRANCH_mpc8315e-rdb = "v4.19/standard/fsl-mpc8315e-rdb"
+KBRANCH_genericx86  = "v5.0/standard/base"
+KBRANCH_genericx86-64  = "v5.0/standard/base"
+KBRANCH_edgerouter = "v5.0/standard/edgerouter"
+KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone"
+KBRANCH_mpc8315e-rdb = "v5.0/standard/fsl-mpc8315e-rdb"
 
 KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_genericx86?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
 SRCREV_machine_genericx86-64 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
 SRCREV_machine_edgerouter ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
-SRCREV_machine_beaglebone-yocto ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_beaglebone-yocto ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
 SRCREV_machine_mpc8315e-rdb ?= "21aae3b4437eb6eec18804f1bad692030352430c"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.19.14"
-LINUX_VERSION_genericx86-64 = "4.19.14"
-LINUX_VERSION_edgerouter = "4.19.14"
-LINUX_VERSION_beaglebone-yocto = "4.19.14"
-LINUX_VERSION_mpc8315e-rdb = "4.19.14"
+LINUX_VERSION_genericx86 = "5.0"
+LINUX_VERSION_genericx86-64 = "5.0"
+LINUX_VERSION_edgerouter = "5.0"
+LINUX_VERSION_beaglebone-yocto = "5.0"
+LINUX_VERSION_mpc8315e-rdb = "5.0"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 3/4] meta-yocto-bsp: Update the default kernel to v5.0 for the non-x86 BSPs

2019-03-06 Thread bruce . ashfield

From: Kevin Hao 

Signed-off-by: Kevin Hao 
Signed-off-by: Bruce Ashfield 
---
 meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
 meta-yocto-bsp/conf/machine/edgerouter.conf   | 2 +-
 meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf 
b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index 69e11eca59..70d3cfea3d 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -24,7 +24,7 @@ SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
 SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 
 KERNEL_IMAGETYPE = "zImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf 
b/meta-yocto-bsp/conf/machine/edgerouter.conf
index b7a94e9cbb..78c87f2f87 100644
--- a/meta-yocto-bsp/conf/machine/edgerouter.conf
+++ b/meta-yocto-bsp/conf/machine/edgerouter.conf
@@ -11,7 +11,7 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
 KERNEL_IMAGE_STRIP_EXTRA_SECTIONS  = ".comment"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 
 SERIAL_CONSOLES = "115200;ttyS0"
 USE_VT ?= "0"
diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf 
b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index 6f5b9859d7..54a34be3aa 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -14,7 +14,7 @@ SERIAL_CONSOLES = "115200;ttyS0"
 
 MACHINE_FEATURES = "keyboard pci ext2 ext3 serial"
 
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 4/4] poky/kernel: make default 5.0

2019-03-06 Thread bruce . ashfield

From: Bruce Ashfield 

The 5.0 kernel is available and 4.18 will soon be dropped,
so we updated the preferred version to 5.0.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index adb2af9c9d..6544c03396 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 
 SDK_NAME = 
"${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cloud-services][PATCH] dhcp: Add the default route option

2019-03-24 Thread Bruce Ashfield

merged

Bruce

On Thu, Mar 21, 2019 at 10:52 PM Zhixiong Chi
 wrote:
>
> Add the default route option for the operation of adding route,
> while we set the static route and the mask setting is 0.
>
> For example:
> add_routes 32 169 254 169 254 10 209 67 4 0 10 209 67 1
>
> The first route (169.254.169.254/32 via 10.209.67.4) is added successfully,
> but the second route (10.209.67.1, default) is not added at all.
>
> Signed-off-by: Zhixiong Chi 
> ---
>  recipes-connectivity/dhcp/files/dhclient-exit-hooks | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/recipes-connectivity/dhcp/files/dhclient-exit-hooks 
> b/recipes-connectivity/dhcp/files/dhclient-exit-hooks
> index 3be5e02..41bcb08 100644
> --- a/recipes-connectivity/dhcp/files/dhclient-exit-hooks
> +++ b/recipes-connectivity/dhcp/files/dhclient-exit-hooks
> @@ -66,6 +66,9 @@ while [ $# -ne 0 ]; do
>elif [ $mask -gt 8 ]; then
>  destination="-net $1.$2.0.0/$mask"
>  shift; shift
> +  #Add the default route
> +  elif [ $mask -eq 0 ]; then
> +destination="default"
>else
>  destination="-net $1.0.0.0/$mask"
>  shift
> --
> 2.17.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Worries kernels supported

2019-04-05 Thread Bruce Ashfield

On Thu, Apr 4, 2019 at 5:28 PM akuster808  wrote:
>
> Hello,
>
> I noticed there are 3 kernels in Warrior. 4.18, 4.19 an 5.0. Do we
> really need 4.18?
> I see its the default version for poky-tiny. 4.18 is EOL but maintained
> by Windriver.

4.18 needed to be around through M3 to backstop some layers and references
that were being updated.

I may delete it as part of M4, but really, since I kept it through M3, I may not
churn it in M4.  I handle all the support load on the linux-yocto
reference kernels,
so it shouldn't cause any one harm one way or the other.

I keep a very close eye on the versions, so nothing is around by chance or
by mistake .. and best to just copy me on the email, since I can
easily miss them
in the noise.

Bruce

>
> regards,
> Armin
>
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Worries kernels supported

2019-04-05 Thread Bruce Ashfield

On Fri, Apr 5, 2019 at 7:42 PM Bruce Ashfield  wrote:
>
> On Thu, Apr 4, 2019 at 5:28 PM akuster808  wrote:
> >
> > Hello,
> >
> > I noticed there are 3 kernels in Warrior. 4.18, 4.19 an 5.0. Do we
> > really need 4.18?
> > I see its the default version for poky-tiny. 4.18 is EOL but maintained
> > by Windriver.
>
> 4.18 needed to be around through M3 to backstop some layers and references
> that were being updated.
>
> I may delete it as part of M4, but really, since I kept it through M3, I may 
> not
> churn it in M4.  I handle all the support load on the linux-yocto
> reference kernels,
> so it shouldn't cause any one harm one way or the other.
>
> I keep a very close eye on the versions, so nothing is around by chance or
> by mistake .. and best to just copy me on the email, since I can
> easily miss them
> in the noise.

... and you did copy me.  gmail sucks at showing me the headers
and I just got off 27 hours of planes,
so sorry about the noise.

I also meant to say, if someone wants to update poky-tiny to use 4.19
(it wouldn't be a huge effort, but
there's probably some config wrangling needed), I would definitely be
willing to remove 4.18 from master.
It will definitely be gone after the upcoming release.

Bruce

>
> Bruce
>
> >
> > regards,
> > Armin
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] poky-tiny: set 5.0 as the preferred kernel

2019-04-09 Thread bruce . ashfield

From: Bruce Ashfield 

Updating poky-tiny to prefer 5.0 as the kernel version. Boot
tested against qemux86 and qemuarm. This removes the last user
of the 4.18 kernel, so we can queue it for removal from master.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf 
b/meta-poky/conf/distro/poky-tiny.conf
index 690cb0d5c9..243d492918 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -38,7 +38,7 @@ TCLIBC = "musl"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "4.18%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "5.0%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is linux-yocto-rt kernel compatible with x32 tune?

2017-06-14 Thread Bruce Ashfield

On Thu, Jun 15, 2017 at 4:11 AM, Paul D. DeRocco 
wrote:

> I've been fighting with this off and on for a week. If I build
> core-image-minimal for a generic86-64 machine, I can get it to use the x32
> ABI, or I can switch to the linux-yocto-rt 4.8 kernel, but I can't do
> both.
>
> If I do both, it builds with no complaint other than a lot of bit size
> errors in grub-efi do_package_qa (which don't seem to matter with the
> standard kernel). Most binaries, including loadable kernel modules, are
> properly built as ELF architecture i386:x64-32, but the kernel itself is
> built as i386:x86-64. The result is an immediate kernel panic trying to
> run init, because the kernel doesn't know how to load it.
>
> I understand that not all packages have been updated to work with x32, but
> the RT kernel? Is this a combination that is known not to work? If it is
> expected to work, am I the first person to try to boot it on actual
> hardware? I'd like to know either that this simply won't work, so I can
> stop wasting time on it, or get some help diagnosing the problem and
> fixing it. I'm stumped.
>

I can't think of a reason off the top of my head that would prevent this
from working at the kernel level.

But can you confirm that a non-rt build for the same board works with
x32 ? It could just be a kernel configuration issue if it does work with
non-rt, since the -rt variant may not have a BSP entry point defined.

Bruce


>
> --
>
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-realtime][PATCH] schedtool-dl: Fix SCHED_DEADLINE value out of range

2017-07-03 Thread Bruce Ashfield


merged.

Bruce

On 2017-06-29 10:29 PM, zhe...@windriver.com wrote:

From: He Zhe 

The upstream commit 3ffb479929c31cbae09de08f94f58b8f0f061d91
tries to fix this issue but it's not complete.

This patch adds flags at the last necessary place.

Signed-off-by: He Zhe 
---
  recipes-tools/schedtool-dl/schedtool-dl.bb |  6 ++-
  ...-add-flags-to-parameters-of-sched_setattr.patch | 56 ++
  2 files changed, 61 insertions(+), 1 deletion(-)
  create mode 100644 
recipes-tools/schedtool-dl/schedtool-dl/0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch

diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb 
b/recipes-tools/schedtool-dl/schedtool-dl.bb
index 578e5df..20c8919 100644
--- a/recipes-tools/schedtool-dl/schedtool-dl.bb
+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb
@@ -3,13 +3,17 @@ SECTION = "devel"
  LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = "file://LICENSE;md5=dc1f51f7ca94aebffb9b3663d82873ec"
  
-SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=git"

+SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=git \
+   
file://0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch \
+  "
  SRCREV = "3ffb479929c31cbae09de08f94f58b8f0f061d91"
  
  S = "${WORKDIR}/git"
  
  EXTRA_OEMAKE = "'CC=${CC}'"
  
+TARGET_CC_ARCH += "${LDFLAGS}"

+
  do_compile() {
oe_runmake
  }
diff --git 
a/recipes-tools/schedtool-dl/schedtool-dl/0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch
 
b/recipes-tools/schedtool-dl/schedtool-dl/0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch
new file mode 100644
index 000..65d5059
--- /dev/null
+++ 
b/recipes-tools/schedtool-dl/schedtool-dl/0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch
@@ -0,0 +1,56 @@
+From c75ae0f6ac2bb9eb893cce82e93144e1b3c36389 Mon Sep 17 00:00:00 2001
+From: Qi Hou 
+Date: Wed, 16 Mar 2016 05:44:40 +
+Subject: [PATCH] schedtool-dl: add flags to parameters of sched_setattr
+
+git://github.com/jlelli/schedtool-dl.git;protocol=git
+commit 3ffb479929c31cbae09de08f94f58b8f0f061d91
+
+The commit numbered as 3ffb479 has adapted to the very last changes to the 
ABI,except for the
+syscall of sched_setattr.
+
+While executing schedtool,there was an error,like below:
+
+root@128:/opt/wr-test/testcases/kts/edf# schedtool -E -t 8000:1 -e yes
+ERROR: could not set PID 1731 to E: SCHED_DEADLINE - value out of range / 
policy not implemented
+
+The cause of this case is that the syscall of sched_setattr is declared with 3 
parameters,but in
+the use of it in schedtool,there was only two parameters.So to adapt this 
declaration,we should
+add one more parameter,flags,when calling sched_setattr.
+
+In kernel source file kernel/sched/core.c,the declaration of the syscall of 
sched_setattr like below:
+/**
+ * sys_sched_setattr - same as above, but with extended sched_attr
+ * @pid: the pid in question.
+ * @uattr: structure containing the extended parameters.
+ * @flags: for future extension.
+ */
+ SYSCALL_DEFINE3(sched_setattr, pid_t, pid, struct sched_attr __user *, uattr,
+unsigned int, flags)
+ {
+   ...
+ }
+
+In schedtool-dl source file syscall_magic.h,the use of sched_setattr like 
below:
+syscall(__NR_sched_setattr, pid, attr)
+
+Upstream-Status: Backport
+
+Signed-off-by: Qi Hou 
+---
+ syscall_magic.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/syscall_magic.h b/syscall_magic.h
+index 7dcb967..2735dfb 100644
+--- a/syscall_magic.h
 b/syscall_magic.h
+@@ -76,4 +76,4 @@ struct sched_attr {
+   syscall(__NR_sched_getattr, pid, attr, size, flags)
+
+ #define sched_setattr(pid, attr, flags) \
+-  syscall(__NR_sched_setattr, pid, attr)
++  syscall(__NR_sched_setattr, pid, attr,flags)
+--
+1.9.1
+



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] linux-yocto-dev stagnated at 4.11-rc6

2017-07-10 Thread Bruce Ashfield


On 07/10/2017 01:11 PM, Einar Vading wrote:

Hello everyone,
I was just wondering if there is a reason for linux-yocto-dev staying at 
4.11-rc6? I was under the impression that it would basically follow 
kernel.org  which is now at 4.12 since a few days.


I was on vacation (and traveling) for the past few weeks, hence the
update cadence has slowed.

I just did an update of all the -stable kernels, and a new 4.12+ (most
likely 4.13-rc1) kernel will follow at some point this week.

Bruce



Thank you,
Einar




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-virtualization] [recipes-containers] criu version 2.12.1

2017-07-25 Thread Bruce Ashfield

Hi Frederico,

Thanks for the patch, but this needs to go to the meta-virtualization list.


Also, we carry a _git recipe in meta-virt to track the various releases
(and sometimes points in between).
So this patch should be done against that recipe versus creating a new
versioned variant.

Finally, make sure to check the patch submission guidelines, since this
patch doesn't have a proper
commit log or a Signed-off-by.

Cheers,

Bruce


On Tue, Jul 25, 2017 at 8:26 AM, Federico Pietro Briata  wrote:

> Hi All,
>
> in attach my recipes for Criu 2.12.1.
>
> Best regards,
>
> Federico Briata
>
>
> ---
>  
> recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0002-criu-Skip-documentation-install.patch
>  |   28 +++
>  
> recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch
>  |   94 +++
>  recipes-containers/criu/criu_2.12.1.bb   
> |   79 +++
>  
> recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch
>  |   24 ++
>  4 files changed, 225 insertions(+), 0 deletions(-)
>
> diff --git 
> a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch
>  
> b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch
> new file mode 100644
> index 000..88efba3
> --- /dev/null
> +++ 
> b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Change-libraries-install-directory.patch
> @@ -0,0 +1,24 @@
> +diff --git a/Makefile.install b/Makefile.install
> +index 7f867cf..15b6065 100644
> +--- a/Makefile.install
>  b/Makefile.install
> +@@ -8,19 +8,6 @@ LIBDIR  := $(PREFIX)/lib
> + INCLUDEDIR  := $(PREFIX)/include
> + LIBEXECDIR  := $(PREFIX)/libexec
> +
> +-#
> +-# For recent Debian/Ubuntu with multiarch support.
> +-DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH 
> 2>/dev/null)
> +-ifneq "$(DEB_HOST_MULTIARCH)" ""
> +-LIBDIR  := $(PREFIX)/lib/$(DEB_HOST_MULTIARCH)
> +-else
> +-#
> +-# For most other systems
> +-ifeq "$(shell uname -m)" "x86_64"
> +-LIBDIR  := $(PREFIX)/lib64
> +-endif
> +-endif
> +-
> + export PREFIX BINDIR SBINDIR MANDIR
> + export LIBDIR INCLUDEDIR LIBEXECDIR
> +
> diff --git 
> a/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch
>  
> b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch
> new file mode 100644
> index 000..1e1437d
> --- /dev/null
> +++ 
> b/recipes-containers/criu/criu-2.12.1+gitAUTOINC+14e0bf7baf/0001-criu-Fix-toolchain-hardcode.patch
> @@ -0,0 +1,94 @@
> +diff --git a/Makefile b/Makefile
> +index 79490d0..1e421b1 100644
> +--- a/Makefile
>  b/Makefile
> +@@ -54,7 +54,7 @@ LDARCH ?= $(SRCARCH)
> +
> + export SRCARCH LDARCH VDSO
> +
> +-UNAME-M := $(shell uname -m)
> ++UNAME-M ?= $(shell uname -m)
> + export UNAME-M
> +
> + ifeq ($(ARCH),arm)
> +diff --git a/criu/pie/Makefile b/criu/pie/Makefile
> +index 141c018..09dbdc6 100644
> +--- a/criu/pie/Makefile
>  b/criu/pie/Makefile
> +@@ -17,7 +17,7 @@ restorer-obj-e += 
> ./$(ARCH_DIR)/syscalls.built-in.o
> + #
> + CFLAGS  := $(filter-out -pg $(CFLAGS-GCOV),$(CFLAGS))
> + CFLAGS  += -iquote $(SRC_DIR)/criu/pie/piegen
> +-CFLAGS  += -iquote $(SRC_DIR)/criu/arch/$(ARCH)/include
> ++CFLAGS  += -iquote 
> $(SRC_DIR)/criu/arch/$(SRCARCH)/include
> + CFLAGS  += -iquote $(SRC_DIR)/criu/include
> + CFLAGS  += -iquote $(SRC_DIR)/include
> + CFLAGS  += -iquote $(SRC_DIR)
> +diff --git a/scripts/nmk/scripts/include.mk b/scripts/nmk/scripts/include.mk
> +index 711b9da..3d44624 100644
> +--- a/scripts/nmk/scripts/include.mk
>  b/scripts/nmk/scripts/include.mk
> +@@ -20,7 +20,7 @@ SUBARCH := $(shell uname -m | sed   \
> + -e s/aarch64.*/arm64/)
> +
> + ARCH?= $(SUBARCH)
> +-SRCARCH := $(ARCH)
> ++SRCARCH ?= $(ARCH)
> +
> + export SUBARCH ARCH SRCARCH
> +
> +diff --git a/scripts/nmk/scripts/tools.mk b/scripts/nmk/scripts/tools.mk
> +index 56dba84..1698821 100644
> +--- a/scripts/nmk/scripts/tools.mk
>  b/scripts/nmk/scripts/tools.mk
> +@@ -2,30 +2,30 @@ ifndef nmk_defined__tools
> +
> + #
> + # System tools shorthands
> +-RM  := rm -f
> ++RM  ?= rm -f
> + HOSTLD  ?= ld
> +-LD  := $(CROSS_COMPILE)$(HOSTLD)
> ++LD  ?= $(CROSS_COMPILE)$(HOSTLD)
> + HOSTCC  ?= gcc
> +-CC  := $(CROSS_COMPILE)$(HOSTCC)
> +-CPP := $(CC) -E
> +-AS  := $(CROSS_COMPILE)as
> +-AR  := $(CROSS_COMP

Re: [yocto] Idea for bbappend / layer organization and naming convention

2017-08-14 Thread Bruce Ashfield


On 2017-08-14 3:36 PM, Gunnar Andersson wrote:


Yocto community,

Triggered by the previous email request to yocto@ about best practices for
layer organization I'm finally firing off this email for (hopefully) some
feedback on an idea we first kicked around, discussed for rough consensus
and then decided to implement in the Yocto based GDP project [1].  You can
see it as a trial, anything can be changed, but so far so good...

We adopted a somewhat novel (but actually not really unique, see inside)
naming convention [2] for all modifications to components that belong to
other layers.



I've been using a similar naming/sorting mechanism in layers that
I maintain for several years now. When you have a single layer that
is carrying bbappends to many other layers, I find that it really
helps keep everything separated and aids finding the original
recipe.

(that being said, recent work with layer index, etc, make it
easier to locate the original recipe and any bbappends .. but that
doesn't preclude keeping things organized in a layer).

Cheers,

Bruce


This convention shows what layers are being modified by the .bbappends by
actually naming the layer it is (intending to**) modify.  The initiative
also aims to highlight and separate .bbappends (modifications) from uniquely
added components in our project (new .bb files) in GDP.

**Note that we are well aware this does NOT control bitbake behavior (as
neither does the recipe-xxx/ directory convention), and is therefore just a
guide.  If the project is misconfigured, bitbake could do something
different than the naming convention implies and it could even be
misleading, but at least the *programmer intent* is shown clearly.

I think it also makes .bbappends more explicitly visible and might trigger
the idea:   Do we really need this?  Are we really modifying *that* adopted
layer, and if so, why?

To Russel who wrote the previous request for guidance - feel free to
consider, but I won't recommend this directly since it's by no means an
agreed best practice in all of the community.  I'm rather asking for other
experienced OE developers to consider and comment on the idea.

For oldtimers it's probably easy to find this odd and just be negative
against it since well, "standard practice", inertia, NIH and all that, but
I'll stick my neck out anyway because it seems to solve some issues of
organization and understanding at least for us (and I'm a sucker for some
flamebait ;)

If the intro is too formal and long, just look at the final examples.  I
think you'll get it.  Feel free to ask.


- Gunnar

--
Gunnar Andersson 
Development Lead
GENIVI Alliance

[1] https://github.com/GENIVI/genivi-dev-platform
[2] Naming strategy for bitbake extension layers:   
https://at.projects.genivi.org/wiki/x/w4Xk





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Idea for bbappend / layer organization and naming convention

2017-08-18 Thread Bruce Ashfield


On 08/18/2017 10:46 AM, Gunnar Andersson wrote:


On Mon, 2017-08-14 at 23:02 -0400, Bruce Ashfield wrote:

On 2017-08-14 3:36 PM, Gunnar Andersson wrote:


Yocto community,

Triggered by the previous email request to yocto@ about best practices
for layer organization I'm finally firing off this email for (hopefully)
some feedback on an idea we first kicked around, discussed for rough
consensus and then decided to implement in the Yocto based GDP project
[1].  You can see it as a trial, anything can be changed, but so far so
good...

We adopted a somewhat novel (but actually not really unique, see inside)
naming convention [2] for all modifications to components that belong to
other layers.



I've been using a similar naming/sorting mechanism in layers that
I maintain for several years now.


Great.  Is it similar, or /exactly/ like this?  I'm only asking because I
think it would be useful to have some written down rules and if there are
additional tweaks that will improve this proposal, I'd like to hear them.



Exactly. The layer name and recipe-* structure is nested in a layer
that is carrying bbappends. That way there's zero confusion about where
the main recipe can be found.

Bruce


I suspected it might actually be somewhat of a common practice.


When you have a single layer that is carrying bbappends to many other
layers, I find that it really helps keep everything separated and aids
finding the original recipe.


Yes, that is the idea.



(that being said, recent work with layer index, etc, make it
easier to locate the original recipe and any bbappends .. but that
doesn't preclude keeping things organized in a layer).


... but I didn't get any more feedback than yours, so I'll just leave it
where it is for now.  Maybe this is not something the other Yocto community
cares about, or similar practices are actually done in practice, but not
written down.  Or maybe everyone is OK with the state of mixing .bb and
.bbappend files within the layers...

So far I think the initial experience on our side is positive.  It's
something that needs to be looked after a bit (we have a few mistakes to
fix).  But since some directories will only have .bb files, and others only
.bbappend files, it's therefore easy to script a warning system for anything
that is out of place.

Best Regards
- Gunnar


Cheers,

Bruce


[trimmed]


--
Gunnar Andersson 
Development Lead
GENIVI Alliance

[1] https://github.com/GENIVI/genivi-dev-platform
[2] Naming strategy for bitbake extension layers:   
https://at.projects.genivi.org/wiki/x/w4Xk





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/2] poky: update default kernel to 4.12 and lsb to 4.9

2017-08-20 Thread Bruce Ashfield

Hi all,

To match the pull request to oe-core that adds the 4.12 kernel and removes
the 4.1 kernel these two patches bump the default kernel to 4.12 and also
update LSB to use the 4.9 kernel.

Build and boot testing was performed on all qemu architectures.

Cheers,

Bruce

The following changes since commit 847d9000180cafedb23c60a6673adcec62ca67a1:

  linux-yocto/4.10: CVE & misc fixes (2017-08-20 22:38:46 -0400)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (2):
  poky: bump preferred version of linux-yocto to 4.12
  poky: bump poky lsb to linux 4.9

 meta-poky/conf/distro/poky-lsb.conf | 2 +-
 meta-poky/conf/distro/poky.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/2] poky: bump preferred version of linux-yocto to 4.12

2017-08-20 Thread Bruce Ashfield

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 940e15865ef0..1c6a01b542dd 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "4.10%"
+PREFERRED_VERSION_linux-yocto ?= "4.12%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/2] poky: bump poky lsb to linux 4.9

2017-08-20 Thread Bruce Ashfield

Due to the age of 4.1 and it being removed from oe-core master
as an active kernel, we can bump poky-lsb to the newer 4.9 LTSI
kernel version.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-lsb.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky-lsb.conf 
b/meta-poky/conf/distro/poky-lsb.conf
index e7d6995a7357..24cfb08b1201 100644
--- a/meta-poky/conf/distro/poky-lsb.conf
+++ b/meta-poky/conf/distro/poky-lsb.conf
@@ -12,4 +12,4 @@ PREFERRED_PROVIDER_virtual/libx11 = "libx11"
 KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
 
 # Use the LTSI Kernel for LSB Testing
-PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.1%"
+PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.9%"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is there a summary somewhere of container-based YP solutions?

2017-09-08 Thread Bruce Ashfield


On 2017-09-08 4:56 PM, Robert P. J. Day wrote:


   topic came up today about docker/container-based solutions for
embedded linux systems, and i already know some of that:

  * meta-virtualization layer has recipes-containers/ recipes


FYI: there are actually quite a few container tools that are
outside recipes-containers in meta-virt.


  * resinOS is tailored for containers

i'm curious if anyone has summarized the container-related aspects of
YP.


I've never seen a summary, but if you check the yocto bugzilla you'll
find more things on top of what currently exists in oe-core + meta-virt
for container features in planning.

Something I've been working on for 2+ years: https://github.com/OverC,
which is a container OS that Wind River builds into:
https://www.windriver.com/products/operating-systems/pulsar/

Togan labs is also working in the same area:
https://toganlabs.wordpress.com/2017/07/03/oryx-linux-v0-2-0-released/

There are lots of core features of oe-core/yocto that are ideally
suited to container work, tight dependency tracking, small footprint,
reproducible builds, application containers/microservices and that
all stems from everything like the recent work to allow kernel modules
to be installed without kernel images or the ability to build images
without kernels installed, SDKs, etc. So really, there's not a whole
lot in oe-core that I wouldn't say isn't peripherally of interest to
someone working with containers.

The various OTA update options also play in this area, as does the
work in meta-intel for clear containers, etc.

Mentioning OTA makes me chuckle, since having a consensus around
container features (and what is important, etc) is about as hard as
nailing down a consensus of defacto implementation for OTA :D

Everything that I do around containers ends up in meta-virtualization,
meta-cloud-services (and then meta-overc) so a shameless plug is to
check there for lots of guidance and information.

Bruce



rday



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cloud-services][PATCH] packagegroups: fix invalid license file

2017-09-15 Thread Bruce Ashfield


wrong mailing list, but merged anyway.

use the meta-virtualization mailing list for these.

Bruce

On 2017-09-15 5:27 AM, jackie.hu...@windriver.com wrote:

From: Jackie Huang 

Use '${COMMON_LICENSE_DIR}/MIT' for MIT License to fix the warning:

| WARNING: packagegroup-cloud-compute do_populate_lic:
   ${COREBASE}/LICENSE is not a valid license file, please use
   '${COMMON_LICENSE_DIR}/MIT' for a MIT License file in LIC_FILES_CHKSUM.
   This will become an error in the future

Signed-off-by: Jackie Huang 
---
  .../recipes-extended/packagegroups/packagegroup-cloud-benchmarking.bb   | 2 +-
  .../recipes-extended/packagegroups/packagegroup-cloud-compute.bb| 2 +-
  .../recipes-extended/packagegroups/packagegroup-cloud-controller.bb | 2 +-
  .../recipes-extended/packagegroups/packagegroup-cloud-debug.bb  | 2 +-
  .../recipes-extended/packagegroups/packagegroup-cloud-extras.bb | 2 +-
  .../recipes-extended/packagegroups/packagegroup-cloud-network.bb| 2 +-
  6 files changed, 6 insertions(+), 6 deletions(-)

diff --git 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-benchmarking.bb
 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-benchmarking.bb
index 6310b8f..e659c31 100644
--- 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-benchmarking.bb
+++ 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-benchmarking.bb
@@ -1,7 +1,7 @@
  SUMMARY = "Add benchmarking capabilities to cloud images"
  PR = "r0"
  LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
  
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
  
  inherit packagegroup

diff --git 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-compute.bb 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-compute.bb
index 21f8f10..2e9446d 100644
--- 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-compute.bb
+++ 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-compute.bb
@@ -1,7 +1,7 @@
  SUMMARY = "Configuration for OpenStack Compute node"
  PR = "r0"
  LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
  
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
  
  inherit packagegroup

diff --git 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-controller.bb
 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-controller.bb
index f172839..1f0a8de 100644
--- 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-controller.bb
+++ 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-controller.bb
@@ -1,7 +1,7 @@
  SUMMARY = "Configuration for OpenStack Controller node"
  PR = "r0"
  LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
  
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
  
  inherit packagegroup

diff --git 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-debug.bb 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-debug.bb
index e5517d2..fecbdc6 100644
--- a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-debug.bb
+++ b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-debug.bb
@@ -1,7 +1,7 @@
  SUMMARY = "Add debugging capabilities to cloud images"
  PR = "r0"
  LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
  
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
  
  inherit packagegroup

diff --git 
a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-extras.bb 
b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-extras.bb
index 6fb6045..9273916 100644
--- a/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-extras.bb
+++ b/meta-openstack/recipes-extended/packagegroups/packagegroup-cloud-extras.bb
@@ -1,7 +1,7 @@
  SUMMARY = "Extra packages that improve the usability of compute/control nodes"
  PR = "r0"
  LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
  
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
  
  inherit packagegroup

diff --git 
a/meta-openstack

Re: [yocto] Configuration fragments not making it into kernel configuration

2017-10-01 Thread Bruce Ashfield


On 2017-09-30 11:22 PM, Jonathan Haws wrote:

All,

I've created a bbappend that appends to the linux-yocto-rt recipe to
simply apply configuration fragments.  I've been using this recipe for
some time (through many releases) but since I moved to the morty branch
my fragments aren't getting applied to the actual kernel configuration.
  The kernel_configcheck task doesn't catch the error either.

What I'm trying to do in a nutshell is disable the in-kernel IGB driver
and use my own, patched version.  The configuration fragments are
installed by my recipe in:

/tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/

However the .config file at:

  /tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/linux-corei7-64-intel-
common-preempt-rt-build/.config

doesn't have the necessary configuration - it still has the default.

I know I can fix this by simply doing a menuconfig, but that isn't the
proper way to do it - I have multiple BSP layers that do the same thing
and they all behave in the same way.

What am I doing wrong?  I've attached my layer that contains the
recipe.  If the fragments are getting installed I think the recipe is
working right - but is there something in the lower-level class that
isn't working or do I have a configuration that is breaking it?



It could be either.

Let me do a build with your configuration on Monday and see if I
get a similar result.

Bruce


Any help or direction is appreciated.  This has been really frustrating
since I know I've done this before and all the threads I've found on
the lists from before haven't really given an answer - maybe I just
missed the golden thread?

Thanks!
Jon





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuration fragments not making it into kernel configuration

2017-10-02 Thread Bruce Ashfield


On 09/30/2017 11:22 PM, Jonathan Haws wrote:

All,

I've created a bbappend that appends to the linux-yocto-rt recipe to
simply apply configuration fragments.  I've been using this recipe for
some time (through many releases) but since I moved to the morty branch
my fragments aren't getting applied to the actual kernel configuration.
  The kernel_configcheck task doesn't catch the error either.

What I'm trying to do in a nutshell is disable the in-kernel IGB driver
and use my own, patched version.  The configuration fragments are
installed by my recipe in:

/tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/

However the .config file at:

  /tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/linux-corei7-64-intel-
common-preempt-rt-build/.config

doesn't have the necessary configuration - it still has the default.

I know I can fix this by simply doing a menuconfig, but that isn't the
proper way to do it - I have multiple BSP layers that do the same thing
and they all behave in the same way.

What am I doing wrong?  I've attached my layer that contains the
recipe.  If the fragments are getting installed I think the recipe is
working right - but is there something in the lower-level class that
isn't working or do I have a configuration that is breaking it?


I did a build with morty and your BSP, and I'm not seeing
the same results.

One notable difference is that if you are using the tip of
the morty branches, you should get 4.8.17, not 4.8.3.

I did zero extra configuration, just added your layer, meta-intel
and then bitbaked linux-yocto-rt.

Maybe I'm misunderstanding what I see in the BSP layer, but I
did get IGB disabled:

:~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-intel-common-preempt-rt-build$ 
grep CONFIG_IGB .config

# CONFIG_IGB is not set
CONFIG_IGBVF=m

And I did get a warning during the build:

-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From: 
/home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-source/.kernel-meta/configs/standard/preempt-rt/intel/features/dca/dca.cfg

Requested value:  CONFIG_IGB_DCA=y
Actual value:

Config 'IGB_DCA' has the following conditionals:
  IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are:
  y [y] m [m] IGB [n] DCA [y]



Which explains why CONFIG_IGB_DCA didn't make it into the final .config

Can you clarify what you were looking to get for final configuration
settings ?

Bruce




Any help or direction is appreciated.  This has been really frustrating
since I know I've done this before and all the threads I've found on
the lists from before haven't really given an answer - maybe I just
missed the golden thread?

Thanks!
Jon





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuration fragments not making it into kernel configuration

2017-10-02 Thread Bruce Ashfield


On 2017-10-02 11:23 AM, Jonathan Haws wrote:

I know I can fix this by simply doing a menuconfig, but that
isn't
the
proper way to do it - I have multiple BSP layers that do the same
thing
and they all behave in the same way.

What am I doing wrong?  I've attached my layer that contains the
recipe.  If the fragments are getting installed I think the
recipe
is
working right - but is there something in the lower-level class
that
isn't working or do I have a configuration that is breaking it?

I did a build with morty and your BSP, and I'm not seeing
the same results.

One notable difference is that if you are using the tip of
the morty branches, you should get 4.8.17, not 4.8.3.

I did zero extra configuration, just added your layer, meta-intel
and then bitbaked linux-yocto-rt.

I just noticed that my meta-intel layer was a few commits behind, a
likely culprit for what I'm seeing.  I'm rebuilding to see what I
get.
I'll report back when I have something.

If this doesn't solve my issue, would you recommend wiping my sstate?
I've already wiped out tmp without success.


Issue resolved.  Fragments now making it into the kernel configuration
correctly.  Thanks, Bruce!



Maybe I'm misunderstanding what I see in the BSP layer, but I
did get IGB disabled:

:~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-
yocto-
rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-
intel-
common-preempt-rt-build$
grep CONFIG_IGB .config
# CONFIG_IGB is not set
CONFIG_IGBVF=m

And I did get a warning during the build:

-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From:
/home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-
source/.kernel-meta/configs/standard/preempt-
rt/intel/features/dca/dca.cfg
Requested value:  CONFIG_IGB_DCA=y
Actual value:

Config 'IGB_DCA' has the following conditionals:
    IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are:
    y [y] m [m] IGB [n] DCA [y]



Which explains why CONFIG_IGB_DCA didn't make it into the final
.config

Can you clarify what you were looking to get for final
configuration
settings ?

The three fragments should disable the Intel IGB driver (CONFIG_IGB
not
set), enable some GPIO I2C drivers, and enable direct cache access.

I'm guessing CONFIG_IGB_DCA was set in the original config and
CONFIG_IGB is not being set, so IGB_DCA is getting unset causing the
warning.  I'll adjust my IGB fragment to explicity disable
CONFIG_IGB_DCA as well.


I get the same warning, and I believe it is because that setting is
only available if CONFIG_IGB is 'y' or 'm'.  Since I'm removing
CONFIG_IGB, CONFIG_IGB_DCA isn't even an option.  If I add "#
CONFIG_IGB_DCA is not set" to my fragment, I get the following warning:
-- CONFIG_IGB_DCA -
Config: CONFIG_IGB_DCA
From: /opt/yocto/poky/build-teisit/tmp/work-shared/xpedite7570/kernel-
source/.kernel-meta/configs/standard/preempt-
rt/intel/features/dca/dca.cfg /opt/yocto/poky/build-teisit/tmp/work-
shared/xpedite7570/kernel-source/.kernel-meta/configs/standard/preempt-
rt/intel/Remove_Intel_IGB_driver.cfg
Requested value:  # CONFIG_IGB_DCA is not set
Actual value:

Config 'IGB_DCA' has the following conditionals:
   IGB && DCA && !(IGB = y && DCA = m) (value: "n")
IGB && DCA && !(IGB = y && DCA = m) (value: "n")
Dependency values are:
   y [y] m [m] IGB [n] DCA [y]

What is the best way to clean up this type of warning - one where the
setting is a conditional option and is enabled in the default
configuration but a fragment removes the parent option?


This actually shoots through a gap in the audit code. Not a bug,
but due to a historical way that the options are flagged.

Only mismatches in 'hardware' options are reported, since that could
cause a boot failure or other similary severe issue with a board.

The option in question is tagged as 'hardware' by the upper layers
and there's currently no way to undo that tag.

The warning you are getting indicates that while the option was
set to a value, it wasn't in the final .config at all .. i.e. in this
case a dependency is gone so the option doesn't make it in at all
(off or non).

Since it is only a warning, and we understand it, it can be
ignored. I'm going to add a method in master that would allow that
hardware tag of the option to be cleared, and then it wouldn't be
in the final .config.

Cheers,

Bruce






--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] more efficient debug kernel

2017-10-19 Thread Bruce Ashfield


On 10/18/2017 06:29 PM, Robert Berger wrote:

Hi,

I usually build a debug kernel with debug info included, which makes it 
run "suboptimal". Distros build the kernel with CONFIG_DEBUG_INFO 
enables, but strip symbols out of the resulting kernel and kernel 
modules, and place them in the separate debuginfo packages. This makes 
the kernel much smaller and also makes it run more efficiently because 
of caching.


Is this possible with the Yocto kernel tooling as well?


That isn't something that I've ever done via oe-core or the
Yocto kernel tooling.

We can absolutely support different kernel types, and in fact,
do have a developer/debug kernel and a production kernel variant.
But they are typically built and packaged separately rather than
being generated from the same build.

There is also a strip() routine for the kernel, but it only
operates on vmlinux (and was used to keep very large images
under bootloader size restrictions). I'd see this as something
that could definitely be done in a 2nd phase part of a build,
since it is just processing already created binaries (maybe
someone does have such a thing in a custom layer).

The multiple image builds, kernel module splitting, upgrade
paths, multilibs, etc, all make the packaging pretty complex
already, but there might be something in this area that could
be done.

I had an old bugzilla entry about kernel-dev packaging: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7095,

but it didn't touch on this issue.

That being said, maybe there already is something that the core
packaging classes are doing (I just looked at my latest kernel
build and didn't see anything) .. and that I'm just missing ..
if so, hopefully someone else will enlighten us :D

Bruce



Regards,

Robert


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_kernel_checkout() not using the correct directory

2017-11-02 Thread Bruce Ashfield


On 2017-11-02 4:16 PM, Bishop, Mark (STRT) wrote:

I changed the code in  arm/layers/core/meta/classes/kernel-yocto.bbclass

From:
.
else
     # case: we have no git repository at all.
 # To support low bandwidth options for building the kernel, 
we'll just
 # convert the tree to a git repo and let the rest of the 
process work unchanged

     # if ${S} hasn't been set to the proper subdirectory a default of 
"linux" is
 # used, but we can't initialize that empty directory. So check 
it and throw a
     # clear error

     cd ${S}
     if [ ! -f "Makefile" ]; then
..

To:
else
 # case: we have no git repository at all.
 # To support low bandwidth options for building the kernel, 
we'll just
 # convert the tree to a git repo and let the rest of the 
process work unchanged

 # if ${S} hasn't been set to the proper subdirectory a default of 
"linux" is
 # used, but we can't initialize that empty directory. So check 
it and throw a
 # clear error

 if [ -d "${WORKDIR}/trunk/" ]; then
 source_workdir="${WORKDIR}/trunk"
 if [ "${source_dir}" != "${source_workdir}" ]; then
 rm -rf ${S}
 mv ${WORKDIR}/trunk ${S}
 fi
 fi

 cd ${S}
 if [ ! -f "Makefile" ]; then

And everything is working but it seems that this would be the wrong way to do 
this as this is me editing a base class file.



Yah, not a great idea to modify the base class.

It may be working, but if you actually add a patch to the SRC_URI,
it will fail, since the rest of the code also needs a git
repository (to apply patches, merge branches, etc, etc). You may
or may not have done that, but where you put that sample code *should*
let the tgz processing do the right thing and create a simple git
repo.

I wrote that code (a long time ago now!) to work with git trees or
tgz's. Anything that isn't dropping the source into a location that
is different than that, won't work (as you found out and worked
around).

You could add your own task that runs before do_kernel_checkout to
put the svn checkout into ${S}, and then do_checkout_checkout will
do its work as normal.

You can add that task in your kernel recipe, or in a bbappend to
a kernel recipe.

i.e.

addtask kernel_svn_precondition before do_kernel_checkout after do_unpack

do_kernel_svn_precondition() {
  if [ -d "${WORKDIR}/trunk/" ]; then
  source_workdir="${WORKDIR}/trunk"
  if [ "${source_dir}" != "${source_workdir}" 
]; then

  rm -rf ${S}
  mv ${WORKDIR}/trunk ${S}
  fi
  fi
}

Maybe someone else will have a better idea, but that is mine :D

Cheers,

Bruce




From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Bishop, Mark (STRT)
Sent: Thursday, November 02, 2017 1:48 PM
To: yocto@yoctoproject.org
Subject: [yocto] do_kernel_checkout() not using the correct directory

I am trying to compile a kernel located in SVN.

I get this error message:
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: S 
/tmp/stride/work-shared/plnx_arm/kernel-source is not set to the linux source 
directory. Check
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: the recipe 
and set S to the proper extracted subdirectory
ERROR: linux-xlnx-4.9-xilinx-v2017.2+git20-r0 do_kernel_checkout: Function 
failed: do_kernel_checkout (log file is located at 
/tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928)
ERROR: Logfile of failure stored in: 
/tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/temp/log.do_kernel_checkout.34928
ERROR: Task 
(/opt/pkg/petalinux/2017.2/components/yocto/source/arm/layers/meta-xilinx/recipes-kernel/linux/linux-xlnx_4.9.bb:do_kernel_checkout)
 failed with exit code '1'

And my kernel gets downloaded to:
/tmp/stride/work/plnx_arm-xilinx-linux-gnueabi/linux-xlnx/4.9-xilinx-v2017.2+git20-r0/trunk
But Yocto is looking for it in /tmp/stride/work-shared/plnx_arm/kernel-source
Which is why it is failing in kernel-yocto.bbclass when I try and compile a 
kernel located in SVN.

If it is a git repo it gets copied into 
/tmp/stride/work-shared/plnx_arm/kernel-source and things work nicely.


do_kernel_checkout() {
...
if [ -d "${WORKDIR}/git/" ]; then
# case: git repository
     # if S is WORKDIR/git, then we shouldn't be moving or deleting 
the tree.
     if [ "${source_dir}" != "${source_workdir}" ]; then
     if [ -d "${source_wor

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

2017-11-07 Thread Bruce Ashfield


On 11/07/2017 08:46 AM, Alan Martinovic wrote:

Hi,
I'm trying to get yocto to build the kernel with an in-tree defconfig.
For that I found references to the variable KBUILD_DEFCONFIG_KMACHINE.

However, I've been experiencing that the kernel is being built with
some default defconfig, and not the in-tree one that came with the
kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.

I've looked through all yocto sources for where the
KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
kernel recipe. So I decided to dissect my recipe.


What is your kernel recipe ? Something you wrote, or something
from a vendor ?



There is a:

inherit kernel

in my recipe for which, besides others, defines how the kernel config
will be selected.
Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
the kernel configuration happens:

kernel_do_configure() {
 # fixes extra + in /lib/modules/2.6.37+
 # $ scripts/setlocalversion . => +
 # $ make kernelversion => 2.6.37
 # $ make kernelrelease => 2.6.37+
 touch ${B}/.scmversion ${S}/.scmversion

 if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
"${B}/.config" ]; then
 mv "${S}/.config" "${B}/.config"
 fi

 # Copy defconfig to .config if .config does not exist. This allows
 # recipes to manage the .config themselves in do_configure_prepend().
 if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
 cp "${WORKDIR}/defconfig" "${B}/.config"
 fi

 ${KERNEL_CONFIG_COMMAND}
}


I'm planning a workaround by overriding the do_configure in my recipe
to select the correct defconfig from the kernel. It does seem however
like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to do
the workarounds.

Anyone has experiences with successfully using KBUILD_DEFCONFIG_KMACHINE?
Is it a specific poky feature (I'm not using poky but specific open
embedded layers and bitbake)?

That is a feature of kernel-yocto, so if your recipe is inheriting
kernel-yocto you can use what you are looking for.

But note, in the documentation you are referencing you have to replace
KMACHINE with your actual machine .. not use the string KMACHINE.

i.e. in your recipe (or bbappend)

# for cases where the KMACHINE (KERNEL MACHINE) and bitbake
# machine match, just do this:
KMACHINE=$MACHINE

KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"

i.e. it is just a standard bitbake variable with a machine OVERRIDE
to make it specific to the machine you are building.

Bruce



Be Well,
Alan

Ref.
https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

2017-11-09 Thread Bruce Ashfield


On 2017-11-09 8:11 AM, Alan Martinovic wrote:

What is your kernel recipe ? Something you wrote, or something
from a vendor ?


Something I inherited.
It does seem to have been based on linux-yocto-custom.bb 
<http://linux-yocto-custom.bb>.



SECTION = "kernel"
DESCRIPTION = "Mainline Linux kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"

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

KBRANCH = "senic/4.13"
SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"

PV = "4.13+git${SRCPV}"
S = "${WORKDIR}/git"

KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"

SRC_URI = 
"git://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH} 
<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}> 
\

           "


Running it with:

bitbake -v linux-senic


It fails with:

ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: 
Could not configure senic-hub-beta-standard
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: 
Function failed: do_kernel_configme (log file is located at 
/home/alan/senic-o
s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641) 

ERROR: Logfile of failure stored in: 
/home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2

18af-r0/temp/log.do_kernel_configme.5641


Not sure when "-standard" got appended...?


That's just part of the localversion processing in the bbclass, so
no worries there.


A more exact error seems to be:

linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: + 
configs=[ERROR]: no configuration queue found in outdir (.kernel-meta)


Could it be expecting a "linux-yocto style" with the meta branches?



Nope. Well, you do need some sort of configuration available, but it
doesn't have to be in that format.

That error is indicating that no configuration was found (no defconfig
or fragments).

A couple more questions, and I can probably sort this out.

- what branch/release of yocto are you using ?
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"

For that second one, I'm wondering if the variable expansion is not
working with the machine override.

.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch//configs/ .. so make
sure that is the case with senic_defconfig.

You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.

Bruce





On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield 
mailto:bruce.ashfi...@windriver.com>> wrote:


On 11/07/2017 08:46 AM, Alan Martinovic wrote:

Hi,
I'm trying to get yocto to build the kernel with an in-tree
defconfig.
For that I found references to the variable
KBUILD_DEFCONFIG_KMACHINE.

However, I've been experiencing that the kernel is being built with
some default defconfig, and not the in-tree one that came with the
kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.

I've looked through all yocto sources for where the
KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
kernel recipe. So I decided to dissect my recipe.


What is your kernel recipe ? Something you wrote, or something
from a vendor ?



There is a:

inherit kernel

in my recipe for which, besides others, defines how the kernel
config
will be selected.
Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
the kernel configuration happens:

kernel_do_configure() {
          # fixes extra + in /lib/modules/2.6.37+
          # $ scripts/setlocalversion . => +
          # $ make kernelversion => 2.6.37
          # $ make kernelrelease => 2.6.37+
          touch ${B}/.scmversion ${S}/.scmversion

          if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
"${B}/.config" ]; then
                  mv "${S}/.config" "${B}/.config"
          fi

          # Copy defconfig to .config if .config does not exist.
This allows
          # recipes to manage the .config themselves in
do_configure_prepend().
          if [ -f "${WORKDIR}/defconfig" ] && [ ! -f
"${B}/.conf

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

2017-11-09 Thread Bruce Ashfield


On 11/09/2017 10:53 AM, Alan Martinovic wrote:

  - what branch/release of yocto are you using ?


Morty

- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"


Yup, same error.

.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch//configs/ .. so make
sure that is the case with senic_defconfig.


Yup, it's in there.


You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.


Yup, am using that as a workaround .

What is the difference between do_kernel_configme and do_configure?


do configure is the existing/traditional/common/simple kernel.bbclass
way to copy a defconfig and make sure it gets into the build.

do_kernel_configme has more processing and logic to deal with
kernel config fragments and wasn't something that was desired to be
imposed on all build (but I do have a streamlined version that moves
the logic into the core class now .. that will be out for review
shortly).

Things like the KBUILD_DEFCONFIG that you are trying to use, are
that extra level of processing that weren't needed/wanted in the
core part.


Not quite clear on why both exist.
I ask because I originally wanted to override do_configure as a fix,
and it seems that wouldn't have helped because it fails at 
do_kernel_configme.


Are the recipes / kernel tree something I can find ? If I can just
launch a build, I'm sure I can point out what is wrong pretty
quickly.

Bruce




On Thu, Nov 9, 2017 at 3:13 PM, Bruce Ashfield 
mailto:bruce.ashfi...@windriver.com>> wrote:


On 2017-11-09 8:11 AM, Alan Martinovic wrote:

     What is your kernel recipe ? Something you wrote, or something
     from a vendor ?


Something I inherited.
It does seem to have been based on linux-yocto-custom.bb
<http://linux-yocto-custom.bb> <http://linux-yocto-custom.bb>.


SECTION = "kernel"
DESCRIPTION = "Mainline Linux kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"

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

KBRANCH = "senic/4.13"
SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"

PV = "4.13+git${SRCPV}"
S = "${WORKDIR}/git"

KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"

SRC_URI =

"git://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}

<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>

<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}

<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>>
\
            "


Running it with:

bitbake -v linux-senic


It fails with:

ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0
do_kernel_configme: Could not configure senic-hub-beta-standard
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0
do_kernel_configme: Function failed: do_kernel_configme (log
file is located at /home/alan/senic-o

s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641)

ERROR: Logfile of failure stored in:

/home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2
18af-r0/temp/log.do_kernel_configme.5641


Not sure when "-standard" got appended...?


That's just part of the localversion processing in the bbclass, so
no worries there.

A more exact error seems to be:

linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: +
configs=[ERROR]: no configuration queue found in outdir
(.kernel-meta)

Could it be expecting a "linux-yocto style" with the meta branches?


Nope. Well, you do need some sort of configuration available, but it
doesn't have to be in that format.

That error is indicating that no configuration was found (no defconfig
or fragments).

A couple more questions, and I can probably sort this out.

- what branch/release of yocto are you using ?
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"

For that second one, I'm wondering if the variable expansion is not
working with the

Re: [yocto] Q: Kernel SCC files: shouldn't a changed patch trigger a rebuild?

2017-12-07 Thread Bruce Ashfield

On Wed, Dec 6, 2017 at 6:46 PM, Erwin Rieger 
wrote:

>
> Hello list,
>
> i have written a kernel recipe derived from linux-yocto-custom. The
> SRC_URI includes a SCC file that in turn includes a kernel patch.
>
> First of all, this works as expected, the patch is applied to the kernel
> source and my custom kernel is built.
>
> But the kernel is NOT rebuilt if i modify the kernel patch (without
> touching the SCC file). In other words: changed files that are directly
> named in the SRC_URI variable trigger a rebuild, but indirectly included
> changed input files (through a SCC file) do not.
>
> Is this the intended behaviour?
>

Currently that is the intended behaviour.

The fetcher is what is responsible for detecting if something changes, and
re-fetching, etc.
The fetcher only knows about the files on the SRC_URI (or the SRCREV for a
remote repository).

The patch referenced by the .scc file is not directly on the SRC_URI so it
doesn't trigger
the re-fetch.

I've had an old bugzilla for this for some time, and have tried on a couple
of occasions to
address it, but ended up not getting the semantics right. i.e. not
re-inventing the fetcher
or duplicating code, etc.

I manage all my patches via either .scc files on the SRC_URI or via a repo
containing
.scc files + patches. Since that allows me to re-use them as functional
blocks between
kernels and couples changes to their configuration fragments. (I only point
that out to
say that your use case and workflow is valid)

If you do store the .scc files + patches in a repo, and fetch it via
AUTOREV (or a set SRCREV),
then you will get the behaviour you are looking for.

I'll bubble this back up to the top of my queue and follow up when I know a
bit more. I need
to revisit my old notes and see if anything is viable.

Cheers,

Bruce

>
>
> PS:
> I can provide more info and my test files if needed.
>
>
>
>
>
>
> --
> Mit freundlichen Gruessen Erwin Rieger
>
> 
> | Ingenieurbuero Rieger, Software Entwicklung
> | EMail: erwin.rie...@ibrieger.de
> 
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] user space package recommends kernel fragment with builting CONFIG

2017-12-11 Thread Bruce Ashfield


On 2017-12-11 10:19 AM, Paulo Neves wrote:

Hello all,

I have the idea I am doing someting in a strange way but correct me if
I am wrong.
I want to make hostapd RRECOMEND .config fragments which have wireless
drivers. How do I achieve this?


You can't really do it via the hostapd recipe, since if you could, you'd
break the separation between recipes (and if the build system allowed
it, you'd be able to influence any other recipe from another .. and a
lot would break).

You'll need to have a kernel bbappend in your layer, and from there,
you can use the KERNEL_FEATURES variable (if the fragment is in the
common kernel-cache) or put a .cfg fragment on the SRC_URI.

If you want to conditionally trigger the SRC_URI addition or the
KERNEL_FEATURE, you could use a distro feature that both hostapd
and the kernel recipe use to enable a set of common features.

Cheers,

Bruce





Paulo Neves



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to config kernel in my own meta layer?

2017-12-22 Thread Bruce Ashfield

On Thu, Dec 21, 2017 at 11:32 AM, Fan Zhang  wrote:
> Greetings,
>
> I have a recipes that requires 128MB of CMA allocation for DMA. I followed
> the instruction in
> http://www.yoctoproject.org/docs/1.6/kernel-dev/kernel-dev.html#changing-the-configuration
> and did the following:
>
> My recipes structure:
>
> meta-mylayer\recipes-my\uio-test\
>
> 1. Then in uio-test folder, I have uio-test.bb that created by recipetool
> (in general) with some modification. uio-test.bb looks like this:
>
> #--
>
> # Recipe created by recipetool
> # This is the basis of a recipe and may need further editing in order to be
> fully functional.
> # (Feel free to remove these comments when editing.)
>
> # Unable to find any files that looked like license statements. Check the
> accompanying
> # documentation and source headers and set LICENSE and LIC_FILES_CHKSUM
> accordingly.
> #
> # NOTE: LICENSE is being set to "CLOSED" to allow you to at least start
> building - if
> # this is not accurate with respect to the licensing of the software being
> built (it
> # will not be in most cases) you must specify the correct value before using
> this
> # recipe for anything other than initial testing/development!
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
>
> # No information for SRC_URI yet (only an external source tree was
> specified)
> PV = "2.0.2"
> SRC_URI = "file://src"
>
> # NOTE: this is a Makefile-only piece of software, so we cannot generate
> much of the
> # recipe automatically - you will need to examine the Makefile yourself and
> ensure
> # that the appropriate arguments are passed in.
>
> do_configure () {
> # Specify any needed configure commands here
> :
> }
>
> do_compile () {
> # You will almost certainly need to add additional arguments here
> cd ${WORKDIR}/src
> oe_runmake
> }
>
> FILES_${PN} = "/www/pages /etc/lighttpd.d"
> do_install () {
> # This is a guess; additional arguments may be required
> cd ${WORKDIR}/src
> oe_runmake install 'DESTDIR=${D}'
> }
>
> DEPENDS = "libgcc boost"
> RDEPENDS_${PN} = "libgcc boost-thread boost-system lighttpd
> lighttpd-module-cgi"
> #--
>
> 2. Also in uio-test folder, I have uio-test.bbappend file with these
> contents:
>
> #--
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://uio-test.cfg"
>
> #--^^^-
>
> 3. In uio-test/files folder, I have uio-test.cfg with the following
> contents:
>
>
> #--
>
> CONFIG_CMA_ALIGNMENT=8
> CONFIG_CMA=y
> CONFIG_CMA_AREAS=7
> CONFIG_DMA_CMA=y
> CONFIG_CMA_SIZE_MBYTES=128
> CONFIG_CMA_SIZE_SEL_MBYTES=y
> CONFIG_DMADEVICES=y
> CONFIG_DMA_ENGINE=y
> CONFIG_DMA_OF=y
> CONFIG_XILINX_DMA_ENGINES=y
> CONFIG_XILINX_DMA=y
> CONFIG_DMA_API_DEBUG=y
> CONFIG_HAS_DMA=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_HAVE_DMA_CONTIGUOUS=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_HAVE_GENERIC_DMA_COHERENT=y
> CONFIG_ARM_DMA_MEM_BUFFERABLE=y
> CONFIG_ZONE_DMA_FLAG=0
> #--^^^-
>
> My question: I think the cfg file is being parsed because if I change the
> folder name files to something else, bitbake will complaint about not being
> able to find uio-test.cfg. However, the final .config in built do not have
> the CMA allocated. My meta layer does have a priority higher than the
> upstream layers. What else can cause the problem here? Any suggestions?
> Thanks.

The question is ... which kernel is it ? If the kernel recipe you are
using doesn't
inherit linux-yocto, the fragments won't be applied.

And a second question, what release/branch are you using ?

On that note, I actually have a patch completed to move the core of the fragment
support to kernel.bbclass, so any kernel could use it. So if you
aren't linux-yocto
and would like to test a patch, I could send it along.

Bruce

>
> Fan Zhang
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel configuration problem/confusion

2017-12-22 Thread Bruce Ashfield




On 12/22/2017 3:51 PM, Greg Wilson-Lindberg wrote:
I'm trying to add some kernel configuration to a Raspberry pi3 yocto 
build.  I've got the .cfg fragment being read in, but I'm getting 
warnings that indicate that they are not making the desired changes.



The first one is CONFIG_SND_SOC_MAX9768. This is a sound codec and the 
Kconfig file has it in a long list of select's. the one for the MAX9768 is:


     select CONFIG_SND_SOC_MAX9768 if I2C

I2C is set, but CONFIG_SND_SOC_MAX9768 ends up undefined. the warning 
I'm getting is:


-- CONFIG_SND_SOC_MAX9768 -
Config: CONFIG_SND_SOC_MAX9768
From: 
/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_SND_SOC_MAX9768=y
Actual value:

Config 'SND_SOC_MAX9768' has the following conditionals:
Dependency values are:

SND_SOC_MAX9768 ends up not being selected even though I try to set it 
ti 'y'



The second one is CONFIG_MAX1363, this is an ADC that I'm trying to set, 
the warning is:


-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_MAX1363=y
Actual value:     # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
   I2C (value: "y")
Dependency values are:
   I2C [y]

It ends up being not set. In both cases the value that I'm trying to set 
is ignored. Any insight would be greatly appreciated.


The python library that tries to detangle the Kconfig dependencies
isn't perfect (but I do have an update for it pending), so you might
not be getting the entire story in that information dumb.

Two things to check:

 - there are no other fragments that are disabling the same option
 - use menuconfig in the kernel to search the option and see what it
   reports for the dependencies.

There's some constraint or overriding command that is not allowing the
option into the final config, we just need to track it down.

Bruce




Regards,

Greg




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel configuration problem/confusion

2017-12-23 Thread Bruce Ashfield




On 12/22/2017 6:17 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
First, thanks for the unbelievably quick response.

I searched the Yocto sources and didn't find anything that was trying to 
manipulate either of the variables except my .cfg.


The memuconfig search for MAX9768 results in:
Symbol: SND_SOC_MAX9768 [=n]
     Type  : tristate
       Defined at sound/soc/codecs/Kconfig:917
       Depends on: SOUND [=y] && !M68K && !UML && SND [=m] && SND_SOC [=m]
       Selected by: SND_SOC_ALL_CODECS [=n] && SOUND [=y] && !M68K && 
!UML && SND [=m] && SND_SOC [=m] && COMPILE_TEST [=n] && I2C [=y]
To my (untrained) eye it seems that I need SND_SOC_ALL_CODECS 
& COMPILE_TEST. I tried setting them but I get a similar error 
for COMPILE_TEST. A search for it yields:

  Symbol: COMPILE_TEST [=n]
     Type  : boolean
     Prompt: Compile also drivers which will not load
       Location:
     (1) -> General setup
       Defined at init/Kconfig:56
Which doesn't seem to suggest that there should be any problems setting it.



True, but since SND_SOC_MAX9768 doesn't have any help text (aka
a prompt in Kconfig speak) then it isn't something that you can
actually reach by menuconfig and by extension .. it must be selected
by other code. So you are on the right track. Either those symbols
are also missing dependencies, or MAX9768 itself is missing a
dependency.



The search for MAX1363 yields:
  Symbol: MAX1363 [=n]
     Type  : tristate
      Prompt: Maxim max1363 ADC driver
       Location:
         -> Device Drivers
           -> Industrial I/O support (IIO [=m])
     (1)     -> Analog to digital converters
       Defined at drivers/iio/adc/Kconfig:218
       Depends on: IIO [=m] && I2C [=y]
       Selects: IIO_BUFFER [=y] && IIO_TRIGGERED_BUFFER [=n]
Which doesn't seem to mereveal any reason that I shouldn't be able to 
set it.


At a glance, I'm also not seeing the reason. Did you try forcing
IIO=y and seeing if there's a difference ? =m should satisfy that
Kconfig dependency, but it is worth checking.

Is this a mainline kernel ? or something else that I could build ?
Maybe with a quick test here, it would be more obvious.

Bruce



Regards,
Greg

*From:* Bruce Ashfield 
*Sent:* Friday, December 22, 2017 12:27:22 PM
*To:* Greg Wilson-Lindberg; yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel configuration problem/confusion


On 12/22/2017 3:51 PM, Greg Wilson-Lindberg wrote:
I'm trying to add some kernel configuration to a Raspberry pi3 yocto 
build.  I've got the .cfg fragment being read in, but I'm getting 
warnings that indicate that they are not making the desired changes.



The first one is CONFIG_SND_SOC_MAX9768. This is a sound codec and the 
Kconfig file has it in a long list of select's. the one for the MAX9768 is:


      select CONFIG_SND_SOC_MAX9768 if I2C

I2C is set, but CONFIG_SND_SOC_MAX9768 ends up undefined. the warning 
I'm getting is:


-- CONFIG_SND_SOC_MAX9768 -
Config: CONFIG_SND_SOC_MAX9768
From: 
/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_SND_SOC_MAX9768=y
Actual value:

Config 'SND_SOC_MAX9768' has the following conditionals:
Dependency values are:

SND_SOC_MAX9768 ends up not being selected even though I try to set it 
ti 'y'



The second one is CONFIG_MAX1363, this is an ADC that I'm trying to set, 
the warning is:


-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_MAX1363=y
Actual value:     # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
    I2C (value: "y")
Dependency values are:
    I2C [y]

It ends up being not set. In both cases the value that I'm trying to set 
is ignored. Any insight would be greatly appreciated.


The python library that tries to detangle the Kconfig dependencies
isn't perfect (but I do have an update for it pending), so you might
not be getting the entire story in that information dumb.

Two things to check:

   - there are no other fragments that are disabling the same option
   - use menuconfig in the kernel to search the option and see what it
     reports for the dependencies.

There's some constraint or overriding command that is not allowing the
option into the final config, we just need to track it down.

Bruce




Regards,

Greg




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel configuration problem/confusion

2018-01-03 Thread Bruce Ashfield


On 2017-12-27 12:11 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,

First, the kernel is 4.4.50, the recipe is linux-raspberrypi_4.4.bb in 
meta-raspberrypi. My image recipe is based on one from Qt, but it is 
using the kernel recipe in meta-raspberry.



I changed my .bbappend to:

# Scribe additions to kernel configuration

# Enable MAX9768
#CONFIG_SOC_ALL_CODECS=m
#CONFIG_COMPILE_TEST=y
#CONFIG_SND_SOC_MAX9768=m

# Enable MAX11606
IIO=y
CONFIG_MAX1363=m

and I get:

WARNING: linux-raspberrypi-1_4.4.50+gitAUTOINC+04c8e47067-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it 
into the kernel's final configuration:


-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_MAX1363=m
Actual value:     # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
   I2C (value: "y")
Dependency values are:
   I2C [y]

It's acting like there is some hidden dependency that it is not telling 
us about. I tried running menuconfig and that allows me so set it 
without any problems.


Sorry for the slow reply. I've been out of the office (and will be
until the 8th).

Are you still looking into this ? Rather than me make mistakes in
the exact configuration, can you send me (offlist, or here, doesn't
really matter) your bblayers to make sure I'm building exactly the
same thing ?

Bruce



Regards,
Greg


----
*From:* Bruce Ashfield 
*Sent:* Saturday, December 23, 2017 7:29 PM
*To:* Greg Wilson-Lindberg; yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel configuration problem/confusion


On 12/22/2017 6:17 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
First, thanks for the unbelievably quick response.

I searched the Yocto sources and didn't find anything that was trying to 
manipulate either of the variables except my .cfg.


The memuconfig search for MAX9768 results in:
Symbol: SND_SOC_MAX9768 [=n]
      Type  : tristate
        Defined at sound/soc/codecs/Kconfig:917
        Depends on: SOUND [=y] && !M68K && !UML && SND [=m] && SND_SOC [=m]
        Selected by: SND_SOC_ALL_CODECS [=n] && SOUND [=y] && !M68K && 
!UML && SND [=m] && SND_SOC [=m] && COMPILE_TEST [=n] && I2C [=y]
To my (untrained) eye it seems that I need SND_SOC_ALL_CODECS 
& COMPILE_TEST. I tried setting them but I get a similar error 
for COMPILE_TEST. A search for it yields:

   Symbol: COMPILE_TEST [=n]
      Type  : boolean
      Prompt: Compile also drivers which will not load
        Location:
      (1) -> General setup
        Defined at init/Kconfig:56
Which doesn't seem to suggest that there should be any problems setting it.



True, but since SND_SOC_MAX9768 doesn't have any help text (aka
a prompt in Kconfig speak) then it isn't something that you can
actually reach by menuconfig and by extension .. it must be selected
by other code. So you are on the right track. Either those symbols
are also missing dependencies, or MAX9768 itself is missing a
dependency.



The search for MAX1363 yields:
   Symbol: MAX1363 [=n]
      Type  : tristate
       Prompt: Maxim max1363 ADC driver
        Location:
          -> Device Drivers
            -> Industrial I/O support (IIO [=m])
      (1)     -> Analog to digital converters
        Defined at drivers/iio/adc/Kconfig:218
        Depends on: IIO [=m] && I2C [=y]
        Selects: IIO_BUFFER [=y] && IIO_TRIGGERED_BUFFER [=n]
Which doesn't seem to mereveal any reason that I shouldn't be able to 
set it.


At a glance, I'm also not seeing the reason. Did you try forcing
IIO=y and seeing if there's a difference ? =m should satisfy that
Kconfig dependency, but it is worth checking.

Is this a mainline kernel ? or something else that I could build ?
Maybe with a quick test here, it would be more obvious.

Bruce



Regards,
Greg

*From:* Bruce Ashfield 
*Sent:* Friday, December 22, 2017 12:27:22 PM
*To:* Greg Wilson-Lindberg; yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel configuration problem/confusion


On 12/22/2017 3:51 PM, Greg Wilson-Lindberg wrote:
I'm trying to add some kernel configuration to a Raspberry pi3 yocto 
build.  I've got the .cfg fragment being read in, but I'm getting 
warnings that indicate that they are not making the desired changes.



The first one is CONFIG_SND_SOC_MAX9768. This is a sound codec and the 
Kconfig file has it in a long list of select's. the one for the MAX9768 is:


      select CONFIG_SND_SOC_MAX9768 if I2C

I2C is set, but CONFIG_SND_SOC_MAX9768 ends up undefined. the warning 
I&#

Re: [yocto] Kernel configuration problem/confusion

2018-01-08 Thread Bruce Ashfield


Hi Greg,

I'm back at things now, and will fire up a build!

Bruce

On 2018-01-04 11:39 AM, Greg Wilson-Lindberg wrote:

Hi Bruce,

Yes I'm still having problems with this. I've attached both my bblayers 
and local configuration files. Thanks for your help.


Regards,

Greg

----
*From:* Bruce Ashfield 
*Sent:* Wednesday, January 3, 2018 6:30:52 PM
*To:* Greg Wilson-Lindberg; yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel configuration problem/confusion
On 2017-12-27 12:11 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,

First, the kernel is 4.4.50, the recipe is linux-raspberrypi_4.4.bb in 
meta-raspberrypi. My image recipe is based on one from Qt, but it is 
using the kernel recipe in meta-raspberry.



I changed my .bbappend to:

# Scribe additions to kernel configuration

# Enable MAX9768
#CONFIG_SOC_ALL_CODECS=m
#CONFIG_COMPILE_TEST=y
#CONFIG_SND_SOC_MAX9768=m

# Enable MAX11606
IIO=y
CONFIG_MAX1363=m

and I get:

WARNING: linux-raspberrypi-1_4.4.50+gitAUTOINC+04c8e47067-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it 
into the kernel's final configuration:


-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg

Requested value:  CONFIG_MAX1363=m
Actual value:     # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
    I2C (value: "y")
Dependency values are:
    I2C [y]

It's acting like there is some hidden dependency that it is not telling 
us about. I tried running menuconfig and that allows me so set it 
without any problems.


Sorry for the slow reply. I've been out of the office (and will be
until the 8th).

Are you still looking into this ? Rather than me make mistakes in
the exact configuration, can you send me (offlist, or here, doesn't
really matter) your bblayers to make sure I'm building exactly the
same thing ?

Bruce



Regards,
Greg


----
*From:* Bruce Ashfield 
*Sent:* Saturday, December 23, 2017 7:29 PM
*To:* Greg Wilson-Lindberg; yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel configuration problem/confusion


On 12/22/2017 6:17 PM, Greg Wilson-Lindberg wrote:

Hi Bruce,
First, thanks for the unbelievably quick response.

I searched the Yocto sources and didn't find anything that was trying to 
manipulate either of the variables except my .cfg.


The memuconfig search for MAX9768 results in:
Symbol: SND_SOC_MAX9768 [=n]
      Type  : tristate
        Defined at sound/soc/codecs/Kconfig:917
        Depends on: SOUND [=y] && !M68K && !UML && SND [=m] && SND_SOC [=m]
        Selected by: SND_SOC_ALL_CODECS [=n] && SOUND [=y] && !M68K && 
!UML && SND [=m] && SND_SOC [=m] && COMPILE_TEST [=n] && I2C [=y]
To my (untrained) eye it seems that I need SND_SOC_ALL_CODECS 
& COMPILE_TEST. I tried setting them but I get a similar error 
for COMPILE_TEST. A search for it yields:

   Symbol: COMPILE_TEST [=n]
      Type  : boolean
      Prompt: Compile also drivers which will not load
        Location:
      (1) -> General setup
        Defined at init/Kconfig:56
Which doesn't seem to suggest that there should be any problems setting it.



True, but since SND_SOC_MAX9768 doesn't have any help text (aka
a prompt in Kconfig speak) then it isn't something that you can
actually reach by menuconfig and by extension .. it must be selected
by other code. So you are on the right track. Either those symbols
are also missing dependencies, or MAX9768 itself is missing a
dependency.



The search for MAX1363 yields:
   Symbol: MAX1363 [=n]
      Type  : tristate
       Prompt: Maxim max1363 ADC driver
        Location:
          -> Device Drivers
            -> Industrial I/O support (IIO [=m])
      (1)     -> Analog to digital converters
        Defined at drivers/iio/adc/Kconfig:218
        Depends on: IIO [=m] && I2C [=y]
        Selects: IIO_BUFFER [=y] && IIO_TRIGGERED_BUFFER [=n]
Which doesn't seem to mereveal any reason that I shouldn't be able to 
set it.


At a glance, I'm also not seeing the reason. Did you try forcing
IIO=y and seeing if there's a difference ? =m should satisfy that
Kconfig dependency, but it is worth checking.

Is this a mainline kernel ? or something else that I could build ?
Maybe with a quick test here, it would be more obvious.

Bruce



Regards,
Greg

*From:* Bruce Ashfield 
*Sent:* Friday, December 22, 2017 12:27:22 PM
*To:* Greg Wilson-Lindberg; yocto@yoctoproject.org
*Subject:* Re: [yocto] Kernel configuration problem/confusion


On 12/22

Re: [yocto] adding meta-virtualization gives bitbake error

2018-01-26 Thread Bruce Ashfield


On 2018-01-26 6:52 AM, Jakob Hasse wrote:

Hello,

we're trying to include meta-virtualization in to our project, in 
particular, we want to use docker. However, as soon as I include the 
layer in to our project, bitbake complains:


bitbake -C compile core-image-base
NOTE: Started PRServer with DBfile: 
/home/jakob/workspace/beerstation/cache/prserv.sqlite3, IP: 127.0.0.1, 
PORT: 46136, PID: 5713

ERROR: Execution of event handler 'virt_bbappend_distrocheck' failed
Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck(e=0x7f945e05d3c8>):

  python virt_bbappend_distrocheck() {
     >    skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
  if 'virtualization' not in 
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:

TypeError: getVar() missing 1 required positional argument: 'expand'

ERROR: Command execution failed: Traceback (most recent call last):
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/command.py", 
line 101, in runAsyncCommand

     self.cooker.updateCache()
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/cooker.py", line 
1627, in updateCache
     bb.event.fire(bb.event.SanityCheck(False), 
self.databuilder.mcdata[mc])
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
201, in fire

     fire_class_handlers(event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
124, in fire_class_handlers

     execute_handler(name, handler, event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
96, in execute_handler

     ret = handler(event)
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck

     skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
TypeError: getVar() missing 1 required positional argument: 'expand'


Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


Do we need to checkout a specific branch or so (though I can't find one 
right now)?
Do we need to change some kernel configuration? I added all 
virtualization drivers in the "drivers" section of the kernel config 
already.


We're using DIGI embedded Yocto 2.2 (poky).



You need to check out the matching branch to the release you've
been given as an enablement, since some of the APIs, etc, have
changed and the meta-virt sanity check that was added later than
the 2.2 release isn't working.

2.2 was the 'morty' release, and meta-virt does have a branch for
that:

--
% git whatchanged origin/morty

commit eb6b5129561eda9ea1f47e85ab9ed9e5a6b8f64c
Author: Fabio Berton 
Date:   Tue Nov 28 09:15:59 2017 -0200

python-*: use https for pypi URLs

Several of the recipes here were using http URLs for source hosted on
pypi - pypi apparently no longer supports http so switch to https
    instead.

Apply this commit [1] to morty branch.
[1] 
https://www.mail-archive.com/meta-virtualization@yoctoproject.org/msg02821.html


Signed-off-by: Fabio Berton 
Signed-off-by: Bruce Ashfield 
-

So check out the morty branch and you'll have better luck.

Bruce



Thanks and all the best,
Jakob



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] how the linux-raspberry skip the do_kernel_metadata?

2018-01-26 Thread Bruce Ashfield

On Fri, Jan 26, 2018 at 4:06 AM, kk  wrote:
> I see the linux-raspberrypi_4.9.bb recipe didn't use the yocto-kernel-cache,
> and add configure in linux-raspberrypi.inc, I am interested in how the
> linux-raspberry skip the do_kernel_metadata?

That task does more than just enable the kernel-cache data, but in theory you
could just delete the task yourself and see what breaks.

(i.e. make a bbappend to the kernel recipe and use something like
"deltask kernel_metadata" to remove the task).

What problem is that step causing in your build ? Maybe there's a better way
to fix things if it's a performance issue or some sort of other bug.

Bruce

>
> Thanks!
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running Docker

2018-02-02 Thread Bruce Ashfield


On 2018-02-02 10:57 AM, Jakob Hasse wrote:

Hello Bruce,

Thank you for the advice with the morty branch, this worked perfectly.

Now, however, docker is installed on my Yocto-system but I can't run it:

~# docker
-sh: /usr/bin/docker: No such file or directory


I've seen this before. It normally means that the executable isn't
in a format that your target recognizes. It could very well be the
go support in the older branch isn't building the right thing.

What does 'file' say about the executable ?

Bruce



Is "docker" the client to control and run containers (e.g. "docker run 
hello-world")?
On my Ubuntu machine, this works, I installed docker and docker.io via 
apt, then I could run "docker run hello-world".


All the Best and many thanks in advance!
Jakob

On 26.01.2018 14:05, Bruce Ashfield wrote:

On 2018-01-26 6:52 AM, Jakob Hasse wrote:

Hello,

we're trying to include meta-virtualization in to our project, in 
particular, we want to use docker. However, as soon as I include the 
layer in to our project, bitbake complains:


bitbake -C compile core-image-base
NOTE: Started PRServer with DBfile: 
/home/jakob/workspace/beerstation/cache/prserv.sqlite3, IP: 
127.0.0.1, PORT: 46136, PID: 5713

ERROR: Execution of event handler 'virt_bbappend_distrocheck' failed
Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck(e=at 0x7f945e05d3c8>):

  python virt_bbappend_distrocheck() {
 >    skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') 
== "1"
  if 'virtualization' not in 
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:

TypeError: getVar() missing 1 required positional argument: 'expand'

ERROR: Command execution failed: Traceback (most recent call last):
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/command.py", 
line 101, in runAsyncCommand

 self.cooker.updateCache()
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/cooker.py", 
line 1627, in updateCache
 bb.event.fire(bb.event.SanityCheck(False), 
self.databuilder.mcdata[mc])
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", 
line 201, in fire

 fire_class_handlers(event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", 
line 124, in fire_class_handlers

 execute_handler(name, handler, event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", 
line 96, in execute_handler

 ret = handler(event)
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck

 skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
TypeError: getVar() missing 1 required positional argument: 'expand'


Summary: There were 2 ERROR messages shown, returning a non-zero exit 
code.



Do we need to checkout a specific branch or so (though I can't find 
one right now)?
Do we need to change some kernel configuration? I added all 
virtualization drivers in the "drivers" section of the kernel config 
already.


We're using DIGI embedded Yocto 2.2 (poky).



You need to check out the matching branch to the release you've
been given as an enablement, since some of the APIs, etc, have
changed and the meta-virt sanity check that was added later than
the 2.2 release isn't working.

2.2 was the 'morty' release, and meta-virt does have a branch for
that:

--
% git whatchanged origin/morty

commit eb6b5129561eda9ea1f47e85ab9ed9e5a6b8f64c
Author: Fabio Berton 
Date:   Tue Nov 28 09:15:59 2017 -0200

    python-*: use https for pypi URLs

    Several of the recipes here were using http URLs for source hosted on
    pypi - pypi apparently no longer supports http so switch to https
    instead.

    Apply this commit [1] to morty branch.
    [1] 
https://www.mail-archive.com/meta-virtualization@yoctoproject.org/msg02821.html 



    Signed-off-by: Fabio Berton 
    Signed-off-by: Bruce Ashfield 
-

So check out the morty branch and you'll have better luck.

Bruce



Thanks and all the best,
Jakob







--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running Docker

2018-02-05 Thread Bruce Ashfield


On 02/02/2018 11:21 AM, Jakob Hasse wrote:

Hello,

file says:
# file /usr/bin/docker
/usr/bin/docker: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, 
BuildID[sha1]=87db889a25d481762a8d2c7aaa1bd52af2458915, not stripped




Sorry for the slow reply, I was away for a bit.

And does that description match your target (and the other executables)
that do work ? If the kernel doesn't recognize the binary interpreter
of an executable, the message you are seeing is what you get.

Cheers,

Bruce


Regards,
Jakob

On 02.02.2018 17:14, Bruce Ashfield wrote:

On 2018-02-02 10:57 AM, Jakob Hasse wrote:

Hello Bruce,

Thank you for the advice with the morty branch, this worked perfectly.

Now, however, docker is installed on my Yocto-system but I can't run it:

~# docker
-sh: /usr/bin/docker: No such file or directory


I've seen this before. It normally means that the executable isn't
in a format that your target recognizes. It could very well be the
go support in the older branch isn't building the right thing.

What does 'file' say about the executable ?

Bruce



Is "docker" the client to control and run containers (e.g. "docker 
run hello-world")?
On my Ubuntu machine, this works, I installed docker and docker.io 
via apt, then I could run "docker run hello-world".


All the Best and many thanks in advance!
Jakob

On 26.01.2018 14:05, Bruce Ashfield wrote:

On 2018-01-26 6:52 AM, Jakob Hasse wrote:

Hello,

we're trying to include meta-virtualization in to our project, in 
particular, we want to use docker. However, as soon as I include 
the layer in to our project, bitbake complains:


bitbake -C compile core-image-base
NOTE: Started PRServer with DBfile: 
/home/jakob/workspace/beerstation/cache/prserv.sqlite3, IP: 
127.0.0.1, PORT: 46136, PID: 5713

ERROR: Execution of event handler 'virt_bbappend_distrocheck' failed
Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck(e=at 0x7f945e05d3c8>):

  python virt_bbappend_distrocheck() {
 >    skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') 
== "1"
  if 'virtualization' not in 
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:

TypeError: getVar() missing 1 required positional argument: 'expand'

ERROR: Command execution failed: Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/command.py", line 
101, in runAsyncCommand

 self.cooker.updateCache()
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/cooker.py", 
line 1627, in updateCache
 bb.event.fire(bb.event.SanityCheck(False), 
self.databuilder.mcdata[mc])
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", 
line 201, in fire

 fire_class_handlers(event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", 
line 124, in fire_class_handlers

 execute_handler(name, handler, event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", 
line 96, in execute_handler

 ret = handler(event)
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck

 skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
TypeError: getVar() missing 1 required positional argument: 'expand'


Summary: There were 2 ERROR messages shown, returning a non-zero 
exit code.



Do we need to checkout a specific branch or so (though I can't find 
one right now)?
Do we need to change some kernel configuration? I added all 
virtualization drivers in the "drivers" section of the kernel 
config already.


We're using DIGI embedded Yocto 2.2 (poky).



You need to check out the matching branch to the release you've
been given as an enablement, since some of the APIs, etc, have
changed and the meta-virt sanity check that was added later than
the 2.2 release isn't working.

2.2 was the 'morty' release, and meta-virt does have a branch for
that:

--
% git whatchanged origin/morty

commit eb6b5129561eda9ea1f47e85ab9ed9e5a6b8f64c
Author: Fabio Berton 
Date:   Tue Nov 28 09:15:59 2017 -0200

    python-*: use https for pypi URLs

    Several of the recipes here were using http URLs for source 
hosted on

    pypi - pypi apparently no longer supports http so switch to https
    instead.

    Apply this commit [1] to morty branch.
    [1] 
https://www.mail-archive.com/meta-virtualization@yoctoproject.org/msg02821.html 



    Signed-off-by: Fabio Berton 
    Signed-off-by: Bruce Ashfield 
-

So check out the morty branch and you'll have better luck.

Bruce



Thanks and all the best,
Jakob











--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running Docker

2018-02-05 Thread Bruce Ashfield


On 2018-02-05 4:58 PM, Jakob Hasse wrote:

Hello Bruce,

Thanks for the reply!
No, the interpreter seems to be different, other executables are e.g.:

# file /usr/bin/python2.7
/usr/bin/python2.7: ELF 32-bit LSB executable, ARM, EABI5 version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for 
GNU/Linux 3.2.0, BuildID[sha1]=b7d18ea9c9088e4b238dc8aeaaf47d6d4941079c, 
stripped


# file /usr/bin/udevadm
/usr/bin/udevadm: ELF 32-bit LSB executable, ARM, EABI5 version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for 
GNU/Linux 3.2.0, BuildID[sha1]=cf639576658cfa150a456672666c2560d58c5f1b, 
stripped


custom app:
# file /usr/bin/goms
/usr/bin/goms: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 
3.2.0, BuildID[sha1]=2d6df18a0b70632a94caee30d4e21c35da235d34, stripped




So this is what Khem was saying, docker is built with softfloat
while the rest of the system is hard float.

Given that this is an older branch, the go build infrastructure
is different, but you'll need to look at the arch that is being
exported in the recipe and make sure that it is arm hard float, not
soft.

Bruce


All the Best,
Jakob

On 05.02.2018 19:05, Bruce Ashfield wrote:

On 02/02/2018 11:21 AM, Jakob Hasse wrote:

Hello,

file says:
# file /usr/bin/docker
/usr/bin/docker: ELF 32-bit LSB executable, ARM, EABI5 version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for 
GNU/Linux 3.2.0, 
BuildID[sha1]=87db889a25d481762a8d2c7aaa1bd52af2458915, not stripped




Sorry for the slow reply, I was away for a bit.

And does that description match your target (and the other executables)
that do work ? If the kernel doesn't recognize the binary interpreter
of an executable, the message you are seeing is what you get.

Cheers,

Bruce


Regards,
Jakob

On 02.02.2018 17:14, Bruce Ashfield wrote:

On 2018-02-02 10:57 AM, Jakob Hasse wrote:

Hello Bruce,

Thank you for the advice with the morty branch, this worked perfectly.

Now, however, docker is installed on my Yocto-system but I can't 
run it:


~# docker
-sh: /usr/bin/docker: No such file or directory


I've seen this before. It normally means that the executable isn't
in a format that your target recognizes. It could very well be the
go support in the older branch isn't building the right thing.

What does 'file' say about the executable ?

Bruce



Is "docker" the client to control and run containers (e.g. "docker 
run hello-world")?
On my Ubuntu machine, this works, I installed docker and docker.io 
via apt, then I could run "docker run hello-world".


All the Best and many thanks in advance!
Jakob

On 26.01.2018 14:05, Bruce Ashfield wrote:

On 2018-01-26 6:52 AM, Jakob Hasse wrote:

Hello,

we're trying to include meta-virtualization in to our project, in 
particular, we want to use docker. However, as soon as I include 
the layer in to our project, bitbake complains:


bitbake -C compile core-image-base
NOTE: Started PRServer with DBfile: 
/home/jakob/workspace/beerstation/cache/prserv.sqlite3, IP: 
127.0.0.1, PORT: 46136, PID: 5713

ERROR: Execution of event handler 'virt_bbappend_distrocheck' failed
Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck(e=object at 0x7f945e05d3c8>):

  python virt_bbappend_distrocheck() {
 >    skip_check = 
e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
  if 'virtualization' not in 
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:

TypeError: getVar() missing 1 required positional argument: 'expand'

ERROR: Command execution failed: Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/command.py", line 
101, in runAsyncCommand

 self.cooker.updateCache()
   File 
"/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/cooker.py", line 
1627, in updateCache
 bb.event.fire(bb.event.SanityCheck(False), 
self.databuilder.mcdata[mc])
   File 
"/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
201, in fire

 fire_class_handlers(event, d)
   File 
"/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
124, in fire_class_handlers

 execute_handler(name, handler, event, d)
   File 
"/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
96, in execute_handler

 ret = handler(event)
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck
 skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == 
"1"

TypeError: getVar() missing 1 required positional argument: 'expand'


Summary: T

[yocto] [PATCH 0/3] meta-poky: update default kernel versions to match oe-core

2018-02-06 Thread Bruce Ashfield

Hi all,

This series applies on top of one that I just sent for oe-core, it updates
the default kernels to match what is available in master.

Cheers,

Bruce

The following changes since commit c656a3351640da84c77588f1474fe3b43117f2c2:

  machines: bump default linux-yocto to v4.15 (2018-02-06 10:26:49 -0500)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (3):
  poky-lsb: update default kernel to v4.14
  poky: update default kernel to v4.15
  poky-tiny: bump to v4.14

 meta-poky/conf/distro/poky-lsb.conf  | 2 +-
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 meta-poky/conf/distro/poky.conf  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/3] poky-lsb: update default kernel to v4.14

2018-02-06 Thread Bruce Ashfield

4.14 is a LTS/LTSI kernel and we are dropping anything older than
4.12 in master. As such, we make 4.14 the default for poky-lsb.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-lsb.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky-lsb.conf 
b/meta-poky/conf/distro/poky-lsb.conf
index 24cfb08b1201..ecfe5d2f446f 100644
--- a/meta-poky/conf/distro/poky-lsb.conf
+++ b/meta-poky/conf/distro/poky-lsb.conf
@@ -12,4 +12,4 @@ PREFERRED_PROVIDER_virtual/libx11 = "libx11"
 KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
 
 # Use the LTSI Kernel for LSB Testing
-PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.9%"
+PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.14%"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/3] poky: update default kernel to v4.15

2018-02-06 Thread Bruce Ashfield

Updating the default kernel for qemu* to be v4.15. This allows easy
integration of the latest fixes/features for new BSPs. 4.14 is also
available as a LTS kernel option.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 3dac26fa3c7b..441986c190bf 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "4.12%"
+PREFERRED_VERSION_linux-yocto ?= "4.14%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 3/3] poky-tiny: bump to v4.14

2018-02-06 Thread Bruce Ashfield

Updating poky-tiny to the latest LTS kernel as the default version.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky-tiny.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf 
b/meta-poky/conf/distro/poky-tiny.conf
index 2032bfde3266..7b22a13cac6f 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -38,7 +38,7 @@ TCLIBC = "musl"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "4.12%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "4.14%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new 
packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
-- 
2.5.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel fragment not applied while other fragments are applied

2018-02-13 Thread Bruce Ashfield


On 02/13/2018 05:00 AM, Mircea Gliga wrote:

Hi

Short story: I'm using rocko and have a recipe for Linux kernel 4.14.14 
based on linux-yocto.inc, some kernel fragments end up in the resulting 
.config, other don't, if regenerate fragments using menuconfig + 
diffconfig seems ok.


Long story:
In my recipe linux-stable_4.14.bb I have an inc file:
     [...]
     require linux-stable.inc
     [...]

linux-stable.inc :

     inherit kernel
     require recipes-kernel/linux/linux-yocto.inc
     [...]
     SRC_URI += "file://defconfig \
     file://kernel_fragments/netfilter.cfg \
     file://kernel_fragments/overlayfs.cfg \
     file://kernel_fragments/verity.cfg \
     file://kernel_fragments/squashfs.cfg \
     file://kernel_fragments/modem.cfg \
     file://kernel_fragments/led_oneshot.cfg \
     file://kernel_fragments/ipsec.cfg \
     file://kernel_fragments/netbridge.cfg \
     file://kernel_fragments/atmel_hw_sha.cfg \


I have a set of kernel fragments. During `bitbake linux-stable -c 
kernel_configme -f` some of them end up in the .config file while others 
don't:
led_oneshot.cfg and overlayfs.cfg are not applied in the resulting 
.config while verity.cfg is applied.
They are all generated using menuconfig to config the kernel, then 
diffconfig to generate the fragment.


$ cat led_oneshot.cfg
CONFIG_LEDS_TRIGGER_ONESHOT=y

$ cat verity.cfg
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_MQ_DEFAULT is not set
# CONFIG_DM_DEBUG is not set
CONFIG_DM_BUFIO=y
# CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set
CONFIG_DM_CRYPT=y
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_ERA is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_RAID is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
CONFIG_DM_VERITY=y
# CONFIG_DM_VERITY_FEC is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_DM_INTEGRITY is not set

$ cat overlayfs.cfg
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
# CONFIG_OVERLAY_FS_INDEX is not set

$

Now, if I go in menuconfig I can see that CONFIG_OVERLAY_FS is indeed 
not enabled, I then enable it and generate a new fragment, 
fragmentOverlay.cfg:

$ cat fragmentOverlay.cfg
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
# CONFIG_OVERLAY_FS_INDEX is not set

$ md5sum *verlay*
14f88a8b2dcb256c38f6362161045831  fragmentOverlay.cfg
14f88a8b2dcb256c38f6362161045831  overlayfs.cfg

The new fragment is identical to the overlayfs.cfg (which is not applied).
I let both files in the SCR_URI:

SRC_URI += "[...]
     file://kernel_fragments/overlayfs.cfg \
     file://kernel_fragments/fragmentOverlay.cfg \
                 [...]"

And now after `bitbake linux-stable -c kernel_configme -f` the resulting 
.config has the overlay_fs enabled:


$ cat .config | grep OVERLAY_FS
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
# CONFIG_OVERLAY_FS_INDEX is not set

$ cat .config |grep CONFIG_LEDS_TRIGGER_ONESHOT
# CONFIG_LEDS_TRIGGER_ONESHOT is not set


Same contents in the fragments, one is applied while the other is not ...


There's absolutely no conditional processing around fragments, they are
always applied to the kernel. When a symbol doesn't make it into the
final .config, it is due to dependencies or a further fragment disabling
something.

In the LEDS_TRIGGER_ONESHOT example, which one of your fragments
or base configs is turning on LEDS_TRIGGERS and LEDS_CLASS ? That's
as far as I looked into the dependency tree, but there could be
more.

When a SRC_URI contains a 'defconfig', it triggers a very specific
base setup of the kernel options since it assumes that it is a
full defconfig. This means that merge_config is called with -n, which
translates to "allnoconfig" as the base setup. Hence, if you are
counting on something being set to the default, that step will turn
it off if you are using a 'defconfig'.

You can still use the defconfig and have a different mode for that
baseline setup. Just set KCONFIG_MODE="alldefconfig" in your bbappend
and that will be used instead.

Note: the semantics of this will change slightly when I send an
upcoming series that shuffles things around, but it won't change the
flow that I'm describing above.

If that tweak doesn't help, can I get access to you config to run some
tests here ? I have some more patches that have improved audit steps
that should highlight the symbols and their dependencies, but I need
to test/clean them up more.

Cheers,

Bruce



Do you have any hints ?

Thanks and regards!







--
___
yocto mailing list
yocto@yoctoproject.org
https://lists

< 8 9 10 11 12 13 14 15 >

1201 - 1300 of 1414 matches

Mail list logo