[yocto] Illegal Instruction Generate for Intel Atom

This arose building asterisk switching from 13.7 to 13.11+. The executable core dumps immediately with an illegal instruction instruction, which gdb reported as 'andn'. This is part of BMI1, which was introduced with Haswell. I am targeting a (32-bit) Z5xx Atom processor, which predates this

Re: [yocto] Illegal Instruction Generate for Intel Atom

Hello Chris, Probably unrelated, but yesterday my krogoth build failed on an Atom *host/build* system. I was just about to debug this when I saw your email. The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 -m64. I am debugging this currently. Maybe check if the

[yocto] Debug packages and source files

In trying to debug my Xorg server problem, I've installed a number of xxx-dbg packages (using IPK/OPKG). One thing that I noticed is that for some of them, e.g. xserver-xorg, I got a full source tree which works great for debugging with GDB. Some other packages, e.g. xf86-video-imxfb-vivante

Re: [yocto] Illegal Instruction Generate for Intel Atom

Thanks Leon, I agree it is probably an unrelated coincidence. I am also using morty. I don't have the logs around any more but the logs had -march=core2 -mtune-core2 -m32, which was correct for the build. I did wonder whether the asterisk autoconf was too clever but I think in my case it

Re: [yocto] Debugging question

On 16 January 2017 at 04:29, Gary Thomas wrote: > * Any ideas how upgrading the X server now calls into openssl? >I've bisected this error down to the change in the X server >recipe to v1.19 from v1.18.4 > $ grep ssl * xserver-xorg.inc:XORG_CRYPTO ??= "openssl"

Re: [yocto] Debugging question

On 2017-01-16 11:40, Burton, Ross wrote: On 16 January 2017 at 04:29, Gary Thomas > wrote: * Any ideas how upgrading the X server now calls into openssl? I've bisected this error down to the change in the X server recipe to v1.19

Re: [yocto] Building on MacOS X

On 14 January 2017 at 19:45, Roger Smith wrote: > Is Building Yocto project on a POSIX system, a desire for the Yocto > project? It would allow support on all bsd UNIX’s including macOS > Making OE itself work isn't rocket science - fix a few Linuxisms in bitbake, port

[yocto] [meta-mingw][PATCH 1/7] mingw-64-runtime_3.1.bb: Adapt to SDK_ARCH -> SDK_SYS chanages for crosssdk

From: Juro Bystricky With the change of crosssdk to use SDK_SYS instead of SDK_ARCH, we need to update the recipe to match the changes in master. [YOCTO #9281] Signed-off-by: Juro Bystricky ---

[yocto] [meta-mingw][PATCH 5/7] glib-2.0: Clean up unnecessary appends that are resolved in oe-core

The changes that are appended for '--enable-include=printf=yes' and packaging of charset.alias and gthread-2.0.def are handled in oe-core. Clean up these appends. Signed-off-by: Nathan Rossi --- recipes-core/glib-2.0/glib-2.0_%.bbappend | 3 --- 1 file changed, 3

[yocto] [meta-mingw][PATCH 6/7] libgcc_%.bbappend: Relocate and package dll's in bindir

Relocate and package the dll's provided by libgcc in bindir. It is convention that on mingw/windows dll files are installed into the bindir, this is done to avoid issues with search paths and allows for execution of binaries without the need to point at a libdir. Signed-off-by: Nathan Rossi

[yocto] [meta-mingw][PATCH 0/7] Adding support for building QEMU for Windows

This series is paired with a series that is sent for the oe-core meta layer. That series depends on changes in this series and vice-versa. The oe-core meta series can be reviewed via: https://patchwork.openembedded.org/series/4800/ Additional information about this work can be read in the

[yocto] [meta-mingw][PATCH 3/7] gettext: Enabling building shared libs/dlls

Enable building of shared libs/dlls for gettext. Signed-off-by: Nathan Rossi --- recipes-core/gettext/gettext_0.19.%.bbappend | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend

[yocto] [meta-mingw][PATCH 7/7] dtc_%.bbappend: Only build libfdt for mingw32

Whilst building libfdt on mingw32 is functional, building dtc for minw32 is not. This is due to dtc relying on certain POSIX functions as well as not handling the MSVCRT printf formatting. This change enables building and installing libfdt only for mingw32, disabling the build of

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

Hi Joe, On Thu, Jan 12, 2017 at 8:57 PM, Joe MacDonald wrote: > > Hi guys, > > [Re: [meta-selinux] What's the point of refpolicy-minimum?] On 17.01.12 (Thu 12:57) wenzong fan wrote: > > > On 01/10/2017 10:48 PM, Joe MacDonald wrote: > > >Wenzong / Shrikant, > > > > > >I

[yocto] [meta-mingw][PATCH 2/7] mingw-w64-headers: Add 'secure-api' PACKAGECONFIG

Add the 'secure-api' PACKAGECONFIG and enable it by default. The 'secure-api' feature enables the secure string functions that are provided in the MS C Runtime e.g. "strerror_s". These functions are needed for glib-2.0 compilation. Signed-off-by: Nathan Rossi ---

[yocto] [meta-mingw][PATCH 4/7] glib-2.0_%.bbappend: Prevent a bash dependency via bash-completion

Prevent glib-2.0 depending on bash indirectly due to the RDEPEND on bash-completion. The bash dependency is undesirable due to bash depending on POSIX compatibility (fork, etc) which is not provided by MinGW but instead MSYS or CYGWIN. The glib-2.0 configure does not allow for disabling of

Re: [yocto] Illegal Instruction Generate for Intel Atom

On 16 January 2017 at 14:47, Chris Trobridge wrote: > Managed to get the actual compiler lines and the initial args are "-m32 > -march=i586" but there is "-march=native" appended to the end of the line. > > Looks like asterisk itself is adding -march=native, so you'll

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8

On 16 January 2017 14:51:55 GMT+00:00, Gary Thomas wrote: >On 2017-01-16 15:48, Gary Thomas wrote: >> On 2017-01-16 08:26, Paul Barker wrote: >>> As discussed recently on the list, we can just keep LTS versions now >>> that v4.9 is available. >>> >>> I'm sending these so anyone

[yocto] bitbake -c menuconfig linux-fslc in a tmux window

Hello list, if I start the following command in a tmux window it doesn't work. bitbake -c menuconfig linux-fslc if I start this command in a extra gnome-terminal a new gnome-terminal pops-up and I can configure my kernel related stuff. in the poky /os-poky/meta/lib/oe/terminal.py there is some

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8

On 2017-01-16 08:26, Paul Barker wrote: As discussed recently on the list, we can just keep LTS versions now that v4.9 is available. I'm sending these so anyone who still needs v4.7 or v4.8 can shout 'stop!' before we remove them. Paul Barker (2): linux-raspberrypi: Drop v4.7

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8

On 2017-01-16 15:48, Gary Thomas wrote: On 2017-01-16 08:26, Paul Barker wrote: As discussed recently on the list, we can just keep LTS versions now that v4.9 is available. I'm sending these so anyone who still needs v4.7 or v4.8 can shout 'stop!' before we remove them. Paul Barker (2):

Re: [yocto] Illegal Instruction Generate for Intel Atom

Ok, Rebuilt system the for i586 and asterisk is still the one program to fail, still with that illegal andn instruction. So I can rule out the core2 tuning. The compiler log is next to useless, as the asterisk build hides the command lines but the makeopts files has the following, which

Re: [yocto] Illegal Instruction Generate for Intel Atom

Hi Chris, there is a hint here how you can find out what gcc is actually using; you could try with and without the -march=native: http://en.chys.info/2010/04/what-exactly-marchnative-means/ On Mon, Jan 16, 2017 at 3:47 PM, Chris Trobridge wrote: > the initial args

[yocto] [[PATCH][yocto-autobuilder] 1/2] buildsteps/CreateAutoConf.py: Add support for specify MACHINE by build prop

Sometimes is a good idea to could specify a machine to build via a build property. Signed-off-by: Aníbal Limón --- .../site-packages/autobuilder/buildsteps/CreateAutoConf.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[yocto] [[PATCH][yocto-autobuilder] 2/2] buildset-config.yocto-qa: Add nightly-oe-build-perf-test buildset

From: Monserrat Sedeno The new nightly-oe-build-perf-test buildset executes the build-perf-test-wrapper.sh into a worker and publish the results to specified folder by AB config. When the performance script finish it sends an notifcation email to yocto alias users, the worker machine needs to

Re: [yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi-rt: add

On Tue, Jan 17, 2017 at 1:12 AM, Trevor Woerner wrote: > Hi Paul, > > On Thu 2017-01-05 @ 09:59:16 PM, Paul Barker wrote: >> Also, are you thinking of moving the -rt recipe to the 4.9 series when >> upstream linux-raspberrypi declares that stable? > > I just want to confirm

Re: [yocto] Illegal Instruction Generate for Intel Atom

+Khem On Mon, Jan 16, 2017 at 4:40 PM, Burton, Ross wrote: > > On 16 January 2017 at 14:47, Chris Trobridge > wrote: > >> Managed to get the actual compiler lines and the initial args are "-m32 >> -march=i586" but there is "-march=native"

Re: [yocto] Illegal Instruction Generate for Intel Atom

Thanks Ross, I came to that conclusion too, and changes to the asterisk build system was really always the most likely source of the problem. On the plus side, I have learned a lot more about machine/processor configuration in the bsp layers pursuing that dead end. I went back through the

Re: [yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi-rt: add

Hi Paul, On Thu 2017-01-05 @ 09:59:16 PM, Paul Barker wrote: > Also, are you thinking of moving the -rt recipe to the 4.9 series when > upstream linux-raspberrypi declares that stable? I just want to confirm that 4.9 is going to be the next stable series? How do we know 4.8 isn't going to be the

Re: [yocto] Building on MacOS X

Hi, A couple of comments even though I'm coming late to the discussion. So, from what I've understood from the above, the main issue with the docker approach to building a yocto/oe image on the mac is that it was much slower... Here's some numbers that don’t quite agree with that assertion: I

[linux-yocto] [PATCH 0/3] yocto-kernel-cache: Update ethernet and add NVMe hardware support

Two first patches modularize and update ethernet driver support by dropping few old ones and adding couple of new ones. Third patch adds support for NVMe storage devices. This set of patches targets master-branch of yocto-kernel-cache. -- ___

[linux-yocto] [PATCH 2/3] Modularize PCI/PCIe ethernet drivers

Build PCI/PCIe ethernet drivers as modules. Also add some new common interfaces, mostly gigabit ones. Signed-off-by: Jussi Laako --- bsp/common-pc/common-pc-eth.cfg | 27 ++- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git

[linux-yocto] [PATCH 3/3] Add support for NVMe storage devices

Lot of new hardware supports and uses NVMe storage devices, enable support by default. Signed-off-by: Jussi Laako --- bsp/common-pc/common-pc-drivers.cfg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bsp/common-pc/common-pc-drivers.cfg

[linux-yocto] [PATCH 1/3] Modularize USB network drivers

Build USB network drivers as modules, drop support for some old devices and add couple of new ones. Signed-off-by: Jussi Laako --- features/usb-net/usb-net.cfg | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) diff --git