[yocto] do_rootfs fails during bitbake pulsar-image

2019-01-24 Thread rajshekharsanda
Iam trying build an image for R-CAR H3 using GENIVI 14 (ROCKO).

*My Native System:*
OS: Ubuntu 16.04
RAM: 64 GB



*The build configuration is:*

BB_VERSION   = "1.36.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-poky-linux"
MACHINE  = "h3ulcb"
DISTRO   = "poky-ivi-systemd"
DISTRO_VERSION   = "14.0.0"
TUNE_FEATURES= "aarch64 cortexa57-cortexa53"
TARGET_FPU   = ""
SOC_FAMILY   = "rcar-gen3:r8a7795"
meta
meta-poky
meta-yocto-bsp
meta-ivi
meta-ivi-bsp
meta-optee
meta-oe
meta-rcar-gen3
meta-filesystems
meta-multimedia
meta-python
meta-rtlwifi-master  = ":"

*NOTE*: All the above packages are available locally in my native System.


*The error details are as follows:*

when doing bitbake pulsar-image. iam getting the following errors.

ERROR: pulsar-image-14.0.0-r0 do_rootfs: Could not invoke dnf. Command
'/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/recipe-sysroot-native/usr/bin/dnf
-y -c
/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/rootfs/etc/dnf/dnf.conf
--setopt=reposdir=/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/rootfs/etc/yum.repos.d
--repofrompath=oe-repo,/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/oe-rootfs-repo
--installroot=/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/rootfs
--setopt=logdir=/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/temp
--nogpgcheck install util-linux libopus0 screen alsa-utils libx264-148
bluez5 dnf node-startup-controller libsdl-1.2-0 connman-client
libgnome-keyring0 libsdl2-2.0-0 rpcbind libc6 perf libdrm2 alsa-lib
libc6-staticdev curl libjansson4 packagegroup-placeholder-component-p1
node-state-manager gstreamer1.0-libav usbutils gstreamer1.0-plugins-ugly
libinput10 wayland-ivi-extension make lame mesa strace libusbg
libgupnp-1.0-4 cmake initscripts rtl8812au libusb-0.1-4 udev alsa-tools
audiomanager node-health-monitor update-rc.d libmediaart-2.0-0
gstreamer1.0-plugins-base weston liba52-0 libfontconfig1 mpeg2dec vala
pkgconfig glibmm libfreeimage3 gstreamer1.0 libcommonapi-dbus3.1.12
packagegroup-abstract-component-p2 libgif7 autoconf wayland dbus-1
gstreamer1.0-omx gstreamer1.0-plugins-good shadow sed
gstreamer1.0-plugins-bad rpm run-postinsts base-passwd gcc libts-1.0-0
dlt-daemon openssh libflacdla-l2 flex wpa-supplicant
packagegroup-specific-component-p2 libfreetype6 libgcc1 connman libsolv0
packagegroup-core-boot-genivi pulseaudio alsa-plugins openssl tzdata
omx-user-module packagegroup-specific-component-p1 binutils libgee-0.8-2
packagegroup-abstract-component-p1 g++ libsdl-ttf-2.0-0 gdb libalacdla-l2
perl systemtap' returned 1:
Added oe-repo repo from
/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/oe-rootfs-repo
Last metadata expiration check: 0:00:00 ago on Wed 23 Jan 2019 04:32:09 AM
UTC.
No package alsa-lib available.
Error: Unable to find a match

ERROR: pulsar-image-14.0.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/buildpc/Genivi14/poky/build/tmp/work/h3ulcb-poky-linux/pulsar-image/14.0.0-r0/temp/log.do_rootfs.10547
ERROR: Task
(/home/buildpc/Genivi14/meta-ivi-14/meta-ivi/recipes-yocto-ivi/images/pulsar-image.bb:do_rootfs)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 5089 tasks of which 5088 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

/home/buildpc/Genivi14/meta-ivi-14/meta-ivi/recipes-yocto-ivi/images/pulsar-image.bb:
do_rootfs
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] wic command, partitioned image, multiple boot loader entries

2019-01-24 Thread Burke, David
I should add the following information:

- The UEFI boot manager used by my image is systemd-boot
- The version of wic being used is 0.2.0
- The version of Yocto Project is 2.2 (Morty)
- My hardware architecture is x86

According to the documentation on " systemd-boot" boot manager, each .conf 
entry in the /loader/entries directory represents one boot option / 
configuration.  So I am wanting to know, how do I setup my kickstart file or 
the configuration file specified after parameter "--configfile" in the 
kickstart file, to create more than one .conf file in the /loader/entries 
directory.

From: Burke, David 
Sent: Thursday, January 24, 2019 10:40 AM
To: 'yocto@yoctoproject.org' 
Subject: wic command, partitioned image, multiple boot loader entries

I'm using wic to create an EFI bootable "multi rootfs" image.  This image has 
two different Linux OS configurations, each in their own partition of course.  
I have been able to successfully create and boot the final wic image.  The 
question I have is how to I create more than one .conf file in the 
/loader/entries folder of the boot partition.  By default wic is only  creating 
only one entry (boot.conf) but I need to have two unique .conf files, one for 
each Linux OS partition that I want to boot from.  Unless someone knows another 
way.




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


Re: [yocto] Yocto Project support for Numeric/Scientific Python

2019-01-24 Thread Mike Looijmans
+1

Got lapack to compile, but no such luck with any "blas" package (like 
openblas). And that's a requirement for octave, which was what I was aiming at.

I'll share some recipes, tomorrow or so (today is stuffed with other work).


On 23-01-19 22:39, Philip Balister wrote:
> I care :)
> 
> On 01/23/2019 04:28 PM, Randy MacLeod wrote:
>> On 1/23/19 2:54 PM, Smith, Virgil (US) wrote:
>>> Is there a current or relatively recent recipe for SciPy and related
>>> libraries?
>>
>> People have worked on it at least once before but found some problems
>> with blas and atlas:
>>
>> https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348
>>
>> I'd say that there is interest.
>> I CCed Peter who started one of the threads
>> and BCCed 5 other people who seemed to be interested
>> since I didn't want to drag them all into the thread.
>>
>>
>>>
>>> Further and more importantly, is having a maintainer for (recipes for)
>>> those libraries a priority for the active members of the Project?
>>> (i.e. does interest rise above the general welcoming of participants
>>> to periodically asking “Hey has anyone put out a call to fill this
>>> slot?” if/when the slot is vacant).
>>
>> It's always nice to have a maintainer but community members sometimes
>> keep recipes up to date even if they aren't direct users.
>>
>>>
>>> BTW: If this is the wrong list for this query, please let me know.
>>
>> It a reasonable list for general discussion.
>> If you get to a point where patches are being submitted,
>> it should probably go to another list such as:
>>
>>>
>>> Why?  We are trying to gauge community interest before making long
>>> term plans.
>>>
>>> We would like to know if this horse is at all likely to have
>>> healthcare before betting on it (without sacrificing other patients to
>>> obtain the proper veterinary degree and keep up practice to treat it
>>> ourselves).
>> heh.
>>
>> Thanks!
>> ../Randy
>>
>>>
>>> NOTE:  I see from the RRS emails that Derek Straka is currently
>>> maintaining the python-numpy recipe.  THANK YOU!
>>>
>>>
>>> 
>>>
>>> Notice to recipient: This email is meant for only the intended
>>> recipient of the transmission, and may be a communication privileged
>>> by law, subject to export control restrictions or that otherwise
>>> contains proprietary information. If you receive this email by
>>> mistake, please notify us immediately by replying to this message and
>>> then destroy it and do not review, disclose, copy or distribute it.
>>> Thank you in advance for your cooperation.
>>>
>>
>>

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


[yocto] Yocto Project Team Development Environment

2019-01-24 Thread Scott Rifenbark
Hi,

I am looking for real-world feedback from people involved with YP
development in a team environment.  I have a section (
https://yoctoproject.org/docs/2.6.1/dev-manual/dev-manual.html#usingpoky-changes-collaborate)
that discusses that environment.

If anyone is inclined, it would be cool to get some feedback on the
section.

Thanks very much!
Scott
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Trouble Enabling UART on Raspberry Pi when booting with U-Boot

2019-01-24 Thread Karl Eaves
Hello,

I am a fairly new to developing with yocto. I have been able to
successfully build a raspberry pi image with all the dtoverlays required
to enable UART and RTC on the raspberry pi. However, when I added the
meta-updater and meta-updater-raspberry pi layers, they required me to
boot using U-Boot, which does not work when using  dtoverlays =
"pi3-disable-bt", etc in the config.txt.

Following other hints online, I was able to create a patch that added my
own custom dtb

 1.
From 8582311b1921f5a6de4322531c141a93f902637d Mon Sep 17 00:00:00 2001
 2.
From: Mike Allen 
 3.
Date: Fri, 4 Jan 2019 13:02:51 -0600
 4.
Subject: [PATCH] custom dts
 5.
 
 6.
---
 7.
 .../boot/dts/bcm2710-rpi-3-b-plus-wispr.dts   | 27 +++
 8.
 1 file changed, 27 insertions(+)
 9.
 create mode 100644 arch/arm/boot/dts/bcm2710-rpi-3-b-plus-wispr.dts
10.
 
11.
diff --git a/arch/arm/boot/dts/bcm2710-rpi-3-b-plus-wispr.dts
b/arch/arm/boot/dts/bcm2710-rpi-3-b-plus-wispr.dts
12.
new file mode 100644
13.
index ..1e26363b3eed
14.
--- /dev/null
15.
+++ b/arch/arm/boot/dts/bcm2710-rpi-3-b-plus-wispr.dts
16.
@@ -0,0 +1,43 @@
17.
+/* Custom dts file for raspberry pi 3 b plus for WISPr Systems */
18.
+
19.
+#include "bcm2710-rpi-3-b-plus.dts"
20.
+
21.
+ {
22.
+#address-cells = <1>;
23.
+#size-cells = <0>;
24.
+status = "okay";
25.
+
26.
+pcf8523: pcf8523@68 {
27.
+compatible = "nxp,pcf8523";
28.
+reg = <0x68>;
29.
+status = "okay";
30.
+};
31.
+};
32.
+
33.
+{
34.
+   pinctrl-names = "default";
35.
+   pinctrl-0 = <_pins>;
36.
+   status = "okay";
37.
+};
38.
+
39.
+_pins{
40.
+   brcm,pins;
41.
+   brcm,function;
42.
+   brcm,pull;
43.
+};
44.
+
45.
+{
46.
+   status = "disabled";
47.
+};
48.
+
49.
+/ {
50.
+__overrides__ {
51.
+pcf8523 = <0>,"+7";
52.
+addr = <>, "reg:0";
53.
+};
54.
+
55.
+aliases {
56.
+serial0 = "/soc/serial@7e201000";
57.
+serial1 = "/soc/serial@7e215040";
58.
+};
59.
+};
60.
\ No newline at end of file
61.
--
62.
2.17.1

I'm pretty sure the patch is working for i2c, because i2cdetect -y 1
produces the correct result with the patch and fails when I take it out.

The pi3-disable-bt patches are not working however. Using gpio
allreadall I was able to see that the GPIO pins are somehow being set to
ALT1 and ALT5, with the values respectively being HIGH and LOW as shown
below

 1.
||---|--|
 2.
| Pin | Mode | Value |
 3.
||---|--|
 4.
|---0---|-ALT1---|--HIGH-|
 5.
|---1---|-ALT5---|--LOW-|
 6.
|---2---|-ALT1---|--HIGH-|
 7.
|---3---|-ALT5---|--Low-|
 8.
|---4---|-ALT1---|--HIGH-|

This pattern continues throughout except for pin 19 which is set to IN
and pin 43 which is set to ALT2. On my working image  all of these pins
are set to IN, except pin 15 and 16 which are set to ALT0 (this is the
correct behavior).

I was able to change the modes of pin 15 and 16, (pins on the raspberry
pi which allow for UART serial communication) using gpio -g mode 15 ALT0
and gpio -g mode 16 ALT0. However, on my image that works correctly, pin
15 and 16 are both set to HIGH. On the image with u-boot, pin 16 is set
to LOW. I have tried to set it to high but it always changes back to
default, which I cannot figure out how to change...

Thanks for any help or ideas,

Karl

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


Re: [yocto] libstdc++fs on toolchain

2019-01-24 Thread João Gonçalves
>
> > I've tested with gcc 7.3 and with gcc 8.2 and and none have the
> libstdc++fs
> > library.
> > On my host machine the library is at
> > /usr/lib/gcc/x86_64-linux-gnu/7/libstdc++fs.a
> >
> > Does anyone know how to include this library on a yocto generated
> toolchain?
>
> At least on x86 targets, it's available from gcc-runtime recipe and
> libstdc++-staticdev binary package on sumo/yocto 2.5 and later.
>

Yes, It is available on libstdc++-staticdev, thank you
But now it wasn't installed on toolchain sysroot  (built with my image
do_populate_sdk)

I tested adding libstdc++-staticdev to IMAGE_INSTALL.

Adding it to TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK make the
populate_sdk fail.

Isn't  the TOOLCHAIN_HOST_TASK the right way to add a package only to the
toolchain?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] libstdc++fs on toolchain

2019-01-24 Thread Mikko.Rapeli
On Thu, Jan 24, 2019 at 03:24:00PM +, João Gonçalves wrote:
> Hello,
> I'm trying to build a c++ cross toolchain to compile to imx6 (armv7). But I
> need libstdc++fs library, which does not come with it. Until gcc 8.0 this
> is an experimental library.
> 
> I've tested with gcc 7.3 and with gcc 8.2 and and none have the libstdc++fs
> library.
> On my host machine the library is at
> /usr/lib/gcc/x86_64-linux-gnu/7/libstdc++fs.a
> 
> Does anyone know how to include this library on a yocto generated toolchain?

At least on x86 targets, it's available from gcc-runtime recipe and
libstdc++-staticdev binary package on sumo/yocto 2.5 and later.

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


[yocto] libstdc++fs on toolchain

2019-01-24 Thread João Gonçalves
Hello,
I'm trying to build a c++ cross toolchain to compile to imx6 (armv7). But I
need libstdc++fs library, which does not come with it. Until gcc 8.0 this
is an experimental library.

I've tested with gcc 7.3 and with gcc 8.2 and and none have the libstdc++fs
library.
On my host machine the library is at
/usr/lib/gcc/x86_64-linux-gnu/7/libstdc++fs.a

Does anyone know how to include this library on a yocto generated toolchain?

Thank you,
Joao Goncalves
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] How to prevent dnf to check for dependencies during do_rootfs task

2019-01-24 Thread Måns Zigher
Hi,

I have a recipe where I am getting a set of binaries files from a third
party. These files are not well put together. For example they are linked
to none versioned so-files for example

 0x0001 (NEEDED) Shared library: [libnss3.so]
 0x0001 (NEEDED) Shared library: [libnssutil3.so]
 0x0001 (NEEDED) Shared library: [libnspr4.so]
 0x0001 (NEEDED) Shared library: [libffmpeg.so]
 0x0001 (NEEDED) Shared library: [libuuid.so]
 0x0001 (NEEDED) Shared library: [libasound.so]
 0x0001 (NEEDED) Shared library: [libmetrics.so]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libcutils.so]
 0x0001 (NEEDED) Shared library:
[libglibc_bridge.so]
 0x0001 (NEEDED) Shared library: [libcurl.so]

Some of these files are not supplied by the third party so for example
libuuid.so is not supplied by them and this causes some friction when using
rpm as the package. The dnf package manager will complain that nothing is
supplying libuuid.so which is correct. I have tried to solve this by
including libuuid.so.1 to the package and then create a link libuuid.so
that points to the libuuid.so.1 library but dnf is not satisfied with that.
I have made sure that the link is part of the package so it is not a mater
of getting it included in the dev package. Renaming libuuid.so.1 to
libuuid.so will not solve this problem because dnf checks the elf headers
and detects that the SONAME is libuuid.so.1. I have considered using
patchelf to modify the SONAME but at one point I get an error from the
linker so I don't think it is the best approach. When looking at rpmbuild I
can see that there is an option --no-deps so is there a way to supply these
flags when creating the rpm package? Or supply some flags to dnf to prevent
it from checking dependencies? Or are the only option  to get the third
party to supply something usable?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] preferred version 6.% of gcc-sanitizers not available

2019-01-24 Thread Damien LEFEVRE
Hi,

I have updated my stack to sumo and the platform image builds fine.

Now I'm adding an application which builds against CUDA 9 and due to some
bugs with gcc 7, gcc 6 is highest supported version. The issues has been
fixed in CUDA 10, but I cannot upgrade at time point of time.

So I went to my distro config and added:
GCCVERSION = "6.%"

Then I noticed that poky sumo removed gcc 5 and 6. So I created and
overwrite layer to add back the older compilers. The layer.conf looks like
this

BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "stack-core"
BBFILE_PATTERN_stack-core = "^${LAYERDIR}/"
BBFILE_PRIORITY_stack-core = "10"

LAYERDEPENDS_stack-core = "core"

LAYERSERIES_COMPAT_stack-core = "sumo"

Then in meta-stack/poky/meta/recipes-devtools/gcc/ I copied the old
compiler recipes from pyro-17.0.4 tag.

I deleted the cache and temp folder.

After all of this I still get this build message and later the build fails.
NOTE: preferred version 6.% of gcc-sanitizers not available (for item
gcc-sanitizers)
NOTE: versions of gcc-sanitizers available: 7.3.0

What am I missing?

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