Re: [yocto] Failed to build gdb
ailed | make[2]: *** [gdb] Error 1 | make[2]: Leaving directory '/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/gdb' | Makefile:8827: recipe for target 'all-gdb' failed | make[1]: *** [all-gdb] Error 2 | make[1]: Leaving directory '/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi' | Makefile:850: recipe for target 'all' failed | make: *** [all] Error 2 | ERROR: Function failed: do_compile (log file is located at /media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/temp/log.do_compile.11637) ERROR: Task (/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/meta/recipes-devtools/gdb/gdb_7.12.1.bb:do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 933 tasks of which 932 didn't need to be rerun and 1 failed. Summary: 1 task failed: /media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/meta/recipes-devtools/gdb/gdb_7.12.1.bb:do_compile Summary: There were 2 ERROR messages shown, returning a non-zero exit code. I had no problem building with this configuration (up to date master): Build Configuration: BB_VERSION= "1.34.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "arm-my-distro-linux-gnueabi" MACHINE = "raspberrypi3" DISTRO= "my-distro" DISTRO_VERSION= "2.3+snapshot-20170615" TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" TARGET_FPU= "hard" meta = "master:b1d5267f0e31605b346af40778da0ac1ff298b78" meta-raspberrypi = "master:081405feaa544b5b5c55a3ac72e629f3f3869a26" What's your configuration? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] devshell not working for Qt or Boundary Devices based yocto
On 2017-06-15 01:58, Jimi Damon wrote: Hi , I'm trying out two different yocto distributions and in each one the devshell doens't work. Instead it just gets to the Summary line and returns to my normal shell ( bash ) . What are you expecting to happen? 'devshell' is just that - a shell environment (e.g. bash) where you are set up to "develop" (tinker, explore, etc) the given recipe. I'm invoking it with bitbake -c devshell core-image-minimal bitbake --version = 1.32.0 I'm getting my distribution from |repo init -u http:||//github||.com||/boundarydevices/boundary-bsp-platform||-b morty| |or from Qt's boot2qt system using "b2qt-init-build-env init --device nitrogen6x| || Any ideas what is going wrong ? Thanks, -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Wireshark but no Tshark?
On 2017-06-12 19:19, Michael Calve wrote: I was able to create a username and password, and use this as credentials for SSH. However, I can't run some of the commands that I can when using picocom, and thus operating as root. Such as? On Mon, Jun 12, 2017 at 10:34 AM, Michael Calve <michael.ca...@vectare.com <mailto:michael.ca...@vectare.com>> wrote: Okay thank you very much for the clarification. Is there a set password for the root username? I'm attempting to send files across and run scripts abord the joule from my host system! On Mon, Jun 12, 2017 at 3:50 AM, Jussi Kukkonen <jussi.kukko...@intel.com <mailto:jussi.kukko...@intel.com>> wrote: On 7 June 2017 at 20:59, Michael Calve <michael.ca...@vectare.com <mailto:michael.ca...@vectare.com>> wrote: Hi, I've seen that Wireshark is portable to Yocto, however Tshark is not? Is there other/better software for reading pcaps and getting field data??? Hi, tshark is part of wireshark: it should be built by the wireshark recipe in meta-networking. If you want a smaller footprint tool, try tcpdump (also in meta-networking). It's not as featureful as tshark but uses the same sniffing library and wireshark can display tcpdump results just fine. Jussi -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Changing terminal font in sato
On 2017-06-08 14:05, Jussi Kukkonen wrote: On 1 June 2017 at 18:58, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: > > How does one change the terminal font (size) used by matchbox-terminal > in the sato desktop? I tried the 'matchbox-appearance' app and it didn't > have any affect, nor could I see a way to change the font. Hi, sorry for late answer, matchbox-terminal is a _very_ thin app based on VteTerminal widget: Modifying Vte font is a single API call but that is not exposed in the app (as it has no configuration at all). In the short term your options are to use another more serious terminal or send patches for mb-terminal... OK, thanks. Any recommendations for an alternative, other than 'xterm' (whose "main.c" has said "Warning! there be dragons here!" for more than 20 years :-) -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What's up with python3
On 2017-06-08 13:52, Burton, Ross wrote: On 8 June 2017 at 08:28, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: I've listed all the recipes used in my build (from bitbake -g => recipe-depends.dot) and sucked out the ones that claim to depend on python3. I don't see why, for example, python(2) depends on python3? I'm 90% sure that this all comes through opkg-utils being the provider for update-alternatives. You could verify this by disabling the python PACKAGECONFIG in opkg-utils. I'm impressed! That eliminated all of them :-) What would I lose by do this, in general, as it's pretty obvious that python3 is not needed by any of the recipes I use? -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What's up with python3
On 2017-06-08 13:09, Alexander Kanavin wrote: On 06/08/2017 10:28 AM, Gary Thomas wrote: I'm building using Poky/Yocto master 576821ea0a7558b626ccc87e9ae0e9ee40864956 and I've noticed that python3 (target) is being built for my image, but it doesn't end up in the actual image. None of my own recipes mention python3 at all, yet virtually every recipe that's used in the build depend on it. I've listed all the recipes used in my build (from bitbake -g => recipe-depends.dot) and sucked out the ones that claim to depend on python3. I don't see why, for example, python(2) depends on python3? Can someone explain this? I've added the appropriate files to this email. I'm mostly curious, but also a bit concerned that my builds are doing more than they need (and hence just taking longer than they might need to) Typically for two reasons: a) a recipe needs to execute python during build, and host python is not suitable for some reason - so native python is built and used; Not that: I filtered out all uses of python3-native - these are only *target* dependencies b) a supplementary package needs python, while the main package does not - most often this is the -ptest package, which will not end up in the image, unless you ask. None of my recipes build -ptest stuff: $ find tmp/deploy/ipk/ -name "*ptest*" -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Changing terminal font in sato
How does one change the terminal font (size) used by matchbox-terminal in the sato desktop? I tried the 'matchbox-appearance' app and it didn't have any affect, nor could I see a way to change the font. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Why can't I install eudev-hwdb
On 2017-06-01 15:46, Burton, Ross wrote: On 1 June 2017 at 14:38, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: Thanks for the suggestion. Sadly, still no go. No idea then. CCing Alejandro... Very interesting - I'm building two different system images for this target and I tried to apply the BAD_RECOMMENDS to only one of them. The target images (pure result of bitbake) did the right thing, one image had eudev-hwdb and the other did not. The image without eudev-hwdb seems to be never able to install it using opkg install/upgrade, but only if the package would need to be downloaded from the IPK server. I copied the appropriate IPK package to that image manually and opkg happily installed it from the direct file. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Why can't I install eudev-hwdb
On 2017-06-01 15:31, Burton, Ross wrote: On 1 June 2017 at 08:43, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: In my local.conf, I have this (to save space in my embedded image): BAD_RECOMMENDATIONS = "udev-rules-imx eudev-hwdb" Try installing just udev-hwdb, my RPROVIDES patch in oe-core dea267 may be been wrong. Thanks for the suggestion. Sadly, still no go. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Why can't I install eudev-hwdb
In my local.conf, I have this (to save space in my embedded image): BAD_RECOMMENDATIONS = "udev-rules-imx eudev-hwdb" Is there a different way I can trim these packages, e.g. leave them in for some images and leave them out for others? Also, today, I wanted to just test/try eudev-hwdb, so on my image I ran: # opkg update Downloading http://192.168.1.12/my-imx6ul-feeds/all/Packages.gz. Updated source 'poky_am-all'. Downloading http://192.168.1.12/my-imx6ul-feeds/cortexa7hf-neon/Packages.gz. Updated source 'poky_am-cortexa7hf-neon'. Downloading http://192.168.1.12/my-imx6ul-feeds/my_imx6ul/Packages.gz. Updated source 'poky_am-my_imx6ul'. # opkg install eudev-hwdb No packages installed or removed. Note: I had rebuilt the package-index on my build machine for this target before trying this. On the build machine, I see this (some fields trimmed): $ ls -l tmp/deploy/ipk/cortexa7hf-neon/eudev* 431904 May 25 07:09 tmp/deploy/ipk/cortexa7hf-neon/eudev_3.2.1-r0.11_cortexa7hf-neon.ipk 1718910 May 25 07:09 tmp/deploy/ipk/cortexa7hf-neon/eudev-dbg_3.2.1-r0.11_cortexa7hf-neon.ipk 5354 May 25 07:09 tmp/deploy/ipk/cortexa7hf-neon/eudev-dev_3.2.1-r0.11_cortexa7hf-neon.ipk 947704 May 25 07:09 tmp/deploy/ipk/cortexa7hf-neon/eudev-hwdb_3.2.1-r0.11_cortexa7hf-neon.ipk On my target, I get: # opkg list eudev* eudev - 3.2.1-r0.11 - eudev is a fork of systemd's udev eudev-dbg - 3.2.1-r0.11 - eudev is a fork of systemd's udev - Debugging files eudev-dev - 3.2.1-r0.11 - eudev is a fork of systemd's udev - Development files eudev-hwdb - 3.2.1-r0.11 - eudev is a fork of systemd's udev However, even when I see the correct list of packages, I still get the 'No packages installed' message :-( -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache question
On 2017-06-01 06:32, Paul Eggleton wrote: On Thursday, 1 June 2017 3:44:49 PM NZST Gary Thomas wrote: On 2017-06-01 05:28, Paul Eggleton wrote: It ought to be. At face value it should be finding the files in either place - we'd need to debug the code to find out why it isn't. Is that something you might be able to help me with? Happy to give it a go, just let me know what you need Thanks. A first step would probably be to enable debug output with -d and see what it reports in terms of the files being searched for. I didn't see much more info here: $ bitbake-diffsigs -d -t gcc-cross-arm compile NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40390, PID: 10044 DEBUG: Signature file (previous): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e DEBUG: Signature file (latest): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_compile.sigdata.84ca7d1957f1644215d99765ece65d9e Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from d65095d4b9aff89f6990bd17c0ab210b to 1378c7a11d96284c3d53894d6434b590 Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes d65095d4b9aff89f6990bd17c0ab210b or 1378c7a11d96284c3d53894d6434b590 NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40390, PID: 10044 NOTE: Terminating PRServer... gthomas@europa:p0382_2016-01-13$ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name "*1378c7a11d96284c3d53894d6434b590*" tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590 tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.1378c7a11d96284c3d53894d6434b590 I've seen very nice back-trail type output where the program recursively lists the tasks with changes until it finally settles, so I gave that a go manually: $ bitbake-diffsigs -d -d -t gcc-cross-arm configure NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34193, PID: 10104 DEBUG: Signature file (previous): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b DEBUG: Signature file (latest): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590 Hash for dependent task gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot changed from 150112323551011e0e87f99f47ad79c4 to c45aaef0cb01f463f9a1b30bd815cd28 Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot with hashes 150112323551011e0e87f99f47ad79c4 or c45aaef0cb01f463f9a1b30bd815cd28 NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34193, PID: 10104 NOTE: Terminating PRServer... gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm populate_sysroot NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 36611, PID: 10208 DEBUG: Signature file (previous): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_populate_sysroot.sigdata.60dbc717c23db51fc4322fe94cf60913 DEBUG: Signature file (latest): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_populate_sysroot.sigdata.2ed367f21ff6b6f36b05dde1983bc81d Hash for dependent task binutils/binutils-cross_2.28.bb.do_install changed from 160c34a18c757a239c78889e6b4125b7 to 271845fc54aeec43d79afaf24cf0ebb4 Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/binutils/binutils-cross_2.28.bb.do_install with hashes 160c34a18c757a239c78889e6b4125b7 or 271845fc54aeec43d79afaf24cf0ebb4 NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 36611, PID: 10208 NOTE: Terminating PRServer... gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs -d -d -t binutils-cross-arm install NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 37882, PID: 10221 DEBUG: Signature file (previous): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_install.sigdata.160c34a18c757a239c78889e6b4125b7 DEBUG: Signature file (latest): /build/p0382_2016-01-13/tmp/stamps/x86_64-linux/binutils-cross-arm/2.28-r0.do_install.sigdata.271845fc54aeec43d79afaf24cf0ebb4 Hash for dependent task binutils/binutils-cross_2.28.bb.do_compile changed from 77a651f90acba2ae988ef9d906fce3b6 to 0f0a9186b50974acc0dde8674141aeda Unable to find matching sigdata for /local/poky-cutting-edge/m
Re: [yocto] sstate-cache question
On 2017-06-01 05:28, Paul Eggleton wrote: Hi Gary, My apologies, I just realised I never sent this reply. On Tuesday, 23 May 2017 5:27:57 PM NZST you wrote: On 2017-05-22 22:35, Paul Eggleton wrote: On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote: I have a build where I've never manually removed anything from the sstate-cache and this same build has been used for hundreds of builds over the last 18 months. I just tried to find out why gcc-cross-arm had to be rebuilt (it seems to happen almost every time I update my Poky/Yocto tree (master)). Here's what I got: $ bitbake-diffsigs -t gcc-cross-arm compile Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to d65095d4b9aff89f6990bd17c0ab210b Unable to find matching sigdata for /local/poky-cutting-edge/meta/ recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b So if I didn't remove those files, where did they go? Am I doing something wrong running this tool? (running the same command for qemu-native seemed to work correctly) Is this with master, pyro, morty or some other version? Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06 OK so this is definitely after my recent fixes then. If you search for files with those hashes in their name do they show up? Only .siginfo files: $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*" sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi: 6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*" sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi: 6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo However, I do find some in tmp/stamps: $ ls tmp/stamps/x86_64-linux/gcc-cross-arm 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210 I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'? It ought to be. At face value it should be finding the files in either place - we'd need to debug the code to find out why it isn't. Is that something you might be able to help me with? Happy to give it a go, just let me know what you need Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] etnaviv image
] fragment-steps=0:vertex-steps=0: FPS: 61 FrameTime: 16.393 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 31 FrameTime: 32.258 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 62 FrameTime: 16.129 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 46 FrameTime: 21.739 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 29 FrameTime: 34.483 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 45 FrameTime: 22.222 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 45 FrameTime: 22.222 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms === glmark2 Score: 46 === 0.46 0.24 0.09 1/98 621 not the greatest results, a couple crashes, but better than swrast! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache question
On 2017-05-23 07:27, Gary Thomas wrote: On 2017-05-22 22:35, Paul Eggleton wrote: Hi Gary, On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote: I have a build where I've never manually removed anything from the sstate-cache and this same build has been used for hundreds of builds over the last 18 months. I just tried to find out why gcc-cross-arm had to be rebuilt (it seems to happen almost every time I update my Poky/Yocto tree (master)). Here's what I got: $ bitbake-diffsigs -t gcc-cross-arm compile Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to d65095d4b9aff89f6990bd17c0ab210b Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes- devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b So if I didn't remove those files, where did they go? Am I doing something wrong running this tool? (running the same command for qemu-native seemed to work correctly) Is this with master, pyro, morty or some other version? Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06 If you search for files with those hashes in their name do they show up? Only .siginfo files: $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*" sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*" sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo However, I do find some in tmp/stamps: $ ls tmp/stamps/x86_64-linux/gcc-cross-arm 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210 I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'? I do occasionally wipe tmp & downloads, so that may explain these errors. I just updated my Poky/Yocto master (a3d160f9e5826140cc8d6b2ed1b38bf022443b08) and it happened again. I'm still interested in why gcc-cross-arm had to be rebuilt _again_, so I ran: $ bitbake-diffsigs -t gcc-cross-arm compile NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466, PID: 7995 Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from d65095d4b9aff89f6990bd17c0ab210b to 1378c7a11d96284c3d53894d6434b590 Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes d65095d4b9aff89f6990bd17c0ab210b or 1378c7a11d96284c3d53894d6434b590 NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 45466, PID: 7995 NOTE: Terminating PRServer... $ find tmp/stamps -name "*d65095d4b9aff89f6990bd17c0ab210b*" -or -name "*1378c7a11d96284c3d53894d6434b590*" tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.1378c7a11d96284c3d53894d6434b590 tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b tmp/stamps/x86_64-linux/gcc-cross-arm/6.3.0-r0.do_configure.1378c7a11d96284c3d53894d6434b590 So, a similar error/outcome, but in this case the necessary files do seem to be present. I did notice that the only files with those signatures were for do_configure, so I tried: $ bitbake-diffsigs -t gcc-cross-arm configure NOTE: Started PRServer with DBfile: /build/p0382_2016-01-13/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 34530, PID: 8063 Hash for dependent task gcc/gcc-cross_6.3.bb.do_prepare_recipe_sysroot c
Re: [yocto] How to include libraries?
On 2017-05-24 15:49, Gary Thomas wrote: On 2017-05-24 15:26, Burton, Ross wrote: On 24 May 2017 at 13:20, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: I have an image which needs to include the libcups2 package from the cups recipe. If I try adding this to my image recipe CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" I get this error: ERROR: Required build target 'my-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-demo-image', 'libcups2'] However, I can get it to build with this MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" What's the difference between these two approaches and why doesn't the first one work at all? Does the latter actually work? Recommends won't fail if the package doesn't exist, or is getting pulled in via another route. I've a feeling that you actually want the pre-renaming name here so try cups-lib. Thanks, I'm rebuilding the image (after a Poky/master pull) and will let you know. BTW, that would be awfully confusing to require cups-lib when building but my package manager (opkg) only knows about the [renamed] package libcups2. You were correct, using MACHINE_EXTRA_RRECOMMENDS didn't work, but explicitly including cups-lib did. Not very intuitive :-( -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can Yocto treat layers like an external package?
On 2017-05-24 16:39, Koehler, Yannick (HPN Aruba) wrote: In our development with Yocto, we use vendor provided layers. At this time we have to pull those manually (using git or submodule or other technics) to get the vendor layer on disk before bitbake can start. Does Yocto allow to automatically pull a yocto layer given a uri, branch and other information, similar way as it can pull the source of a package? This way, we could omit the vendor layer stuff from our git and instead have Yocto fetch the layer from its source (honoring all the premirror and mirror stuff). The layer specification would be similar to SRC_URI format with an additional parameter to indicate locally where to put the files, maybe with a default of vendor/ structure? git://g...@mylayer.company.com/layer-name.git;protocol=ssh;branch=master This would pull into vendors/layer-name Prior to parse all reccipes? Not part of the default Yocto setup, but what you are asking for seems to be a perfect fit for the [Android/Google] repo tool. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] webkitgtk2 progress bar
I see that the latest master update has brought a progress bar for this (and presumably other 'cmake' based packages) - very nice :-) Now [tongue-in-cheek], can someone do something about the horrendous build times for such packages (webkitgtk2 can take up to 3 hours on my [no so slow] build host!)? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dynamic-layers?
On 2017-05-24 12:30, Takashi Matsuzawa wrote:
Hello, Yocto.
I am a bit confused with dynamic-layers included in some of the recent layers
in various BSPs.
e.g.
https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf
># The .bbappend and .bb files are included if the respective layer
># collection is available.
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend'
% layer \
> for layer in BBFILE_COLLECTIONS.split())}"
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
layer \
> for layer in BBFILE_COLLECTIONS.split())}"
In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc. for
conditional inclusion.
And I think they are included only their names (browser-layer, etc.) are
BBFILE_COLLECIONS.
Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS when
I want to include browser-layer in my build.
Is it something to be done in my local.conf or customized distro conf file?
No, it's in /conf/layer.conf for the in question.
--
--------
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include libraries?
On 2017-05-24 15:26, Burton, Ross wrote: On 24 May 2017 at 13:20, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: I have an image which needs to include the libcups2 package from the cups recipe. If I try adding this to my image recipe CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" I get this error: ERROR: Required build target 'my-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-demo-image', 'libcups2'] However, I can get it to build with this MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" What's the difference between these two approaches and why doesn't the first one work at all? Does the latter actually work? Recommends won't fail if the package doesn't exist, or is getting pulled in via another route. I've a feeling that you actually want the pre-renaming name here so try cups-lib. Thanks, I'm rebuilding the image (after a Poky/master pull) and will let you know. BTW, that would be awfully confusing to require cups-lib when building but my package manager (opkg) only knows about the [renamed] package libcups2. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to include libraries?
I have an image which needs to include the libcups2 package from the cups recipe. If I try adding this to my image recipe CORE_IMAGE_EXTRA_INSTALL_append = " libcups2" I get this error: ERROR: Required build target 'my-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['my-demo-image', 'libcups2'] However, I can get it to build with this MACHINE_EXTRA_RRECOMMENDS_append = " libcups2" What's the difference between these two approaches and why doesn't the first one work at all? Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache question
On 2017-05-22 22:35, Paul Eggleton wrote: Hi Gary, On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote: I have a build where I've never manually removed anything from the sstate-cache and this same build has been used for hundreds of builds over the last 18 months. I just tried to find out why gcc-cross-arm had to be rebuilt (it seems to happen almost every time I update my Poky/Yocto tree (master)). Here's what I got: $ bitbake-diffsigs -t gcc-cross-arm compile Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to d65095d4b9aff89f6990bd17c0ab210b Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes- devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b So if I didn't remove those files, where did they go? Am I doing something wrong running this tool? (running the same command for qemu-native seemed to work correctly) Is this with master, pyro, morty or some other version? Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06 If you search for files with those hashes in their name do they show up? Only .siginfo files: $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*" sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*" sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo However, I do find some in tmp/stamps: $ ls tmp/stamps/x86_64-linux/gcc-cross-arm 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210 I guess the sstate-cache info alone is not sufficient to use 'bitbake diffsigs'? I do occasionally wipe tmp & downloads, so that may explain these errors. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache question
On 2017-05-22 16:53, Gary Thomas wrote: I have a build where I've never manually removed anything from the sstate-cache and this same build has been used for hundreds ^directory^ of builds over the last 18 months. I just tried to find out why gcc-cross-arm had to be rebuilt (it seems to happen almost every time I update my Poky/Yocto tree (master)). Here's what I got: $ bitbake-diffsigs -t gcc-cross-arm compile Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to d65095d4b9aff89f6990bd17c0ab210b Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b So if I didn't remove those files, where did they go? Am I doing something wrong running this tool? (running the same command for qemu-native seemed to work correctly) Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate-cache question
I have a build where I've never manually removed anything from the sstate-cache and this same build has been used for hundreds of builds over the last 18 months. I just tried to find out why gcc-cross-arm had to be rebuilt (it seems to happen almost every time I update my Poky/Yocto tree (master)). Here's what I got: $ bitbake-diffsigs -t gcc-cross-arm compile Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from 208373dd9ae01101a26a9412eb50b110 to d65095d4b9aff89f6990bd17c0ab210b Unable to find matching sigdata for /local/poky-cutting-edge/meta/recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure with hashes 208373dd9ae01101a26a9412eb50b110 or d65095d4b9aff89f6990bd17c0ab210b So if I didn't remove those files, where did they go? Am I doing something wrong running this tool? (running the same command for qemu-native seemed to work correctly) Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] gles2 on raspi3
On 2017-04-20 18:55, Khem Raj wrote: On Thu, Apr 20, 2017 at 12:13 AM, Trevor Woerner <twoer...@gmail.com> wrote: On Thu 2017-04-20 @ 05:41:44 AM, Herve Jourdain wrote: Yes, VC4 indeed works for both 32bits and 64bits. It was first introduced . for 32bits, actually Regarding why still using userland: at this point in . time, we have accelerated HW codec (H.264, MPEG2, some audio) only if using. userland If one doesn't need that, then VC4 is, in my opinion, the way to . go. Otherwise, userland still needs to be used . What decoder is needed to play youtube videos? Using Andreas' meta-raspi-light (which removes userland and only uses vc4) I've spent the last hour or so watching youtube videos from my raspberrypi3 (32-bit build) in chromium, accelerated, with sound (both via the HDMI and the jack), both on the big monitor and the 7" waveshare touchscreen. Not to mention I can now run openGL and GLESx apps accelerated. try to play 1080p video and you will see the difference. I use my pi3 as media center using kodi, I am waiting for vc4 driver to get feature/performance parity with userland until then we have to keep using it atleast for media centric usecases. Are you building kodi using meta-multimedia? If so, could you share your local.conf? I wasn't able to do that with userland. In fact, it was quite a struggle just to get it to build! Maybe I did something wrong with userland, but vc4 is successful, and certainly easier to work with. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Noobie questions
On 2017-04-17 16:27, bahjat khan wrote:
Hi Gary,
n.b. it's polite to keep responses on the mailing list so that everyone
benefits!
Thanks for the response!
How will i know what to change in the local.conf file?
Is there a Yocto article that tells me what the different variables in .bb and
.conf files mean?
The Yocto (OpenEmbedded) documentation is quite thorough.
https://www.yoctoproject.org/documentation
*From:* yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> on behalf of
Gary Thomas <g...@mlbassoc.com>
*Sent:* 17 April 2017 12:59
*To:* yocto@yoctoproject.org
*Subject:* Re: [yocto] Noobie questions
On 2017-04-16 20:23, bahjat khan wrote:
Hi Guys,
I'm extremely new to the yocto project, i've done quite a bit of reading on it
but i'm still very confused.
I've set my self a simple task of changing the kernel for a Yocto image that i
build, the commands i use to build this
yocto image are:
$ git clone http://git.yoctoproject.org/git/poky
$ cd poky
$ git checkout -b fido origin/fido
$ source oe-init-build-env
$bitbake core-image-minimal
$runqemu qemux86
Check out a newer revision - fido is VERY OLD. Probably best to use morty
which is the upcoming 2.3 release
|$ git clone http://git.yoctoproject.org/git/poky $ cd poky $ git checkout -b
fido origin/fido $ source oe-init-build-env
$bitbake core-image-minimal $runqemu qemux86|
I understand that i need to make changes to the poky.conf file to specify what
kernel i want to use (i have a standard
choice between 3.14 and 3.19).
No, make such changes in your local.conf
However if i want to use a different kernel such as 4.4, i do this by making
the changes in the poky.conf file, copying
linux-yocto_3.19.bb file and renaming it to linux-yocto_4.4.bb. I also change
the SRC_URI to
"git://git.yoctoproject.org/linux-yocto-4.4.git;barcelone=1;branch=${KRBRANCH},${KMETA};name=machine,meta"
It doesn't seem to find the place where it needs to download 4.4 from even
though it's on the yocto website. I can
download it by simply typing "git clone "
Also i haven't changed the SRCREV_machine_qemuarm ?= "" numbers,
because i don't know what they are or what
the variable SRCREV_machine_qemuarm is.
You should never need to mess with these settings.
With these warnings, it reverts back to 3.19 kernel.
I hope i've explained my problem well, but if you are still confused please let
me know.
--
--------
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Task dependencies
On 2017-04-13 09:34, Gary Thomas wrote:
I'm trying to understand why 'perl' is being built for my target
even though I don't mention it in any of the package recipes used
to build that target. When I used 'taskexp', I found that 'perl:do_build'
only has a single dependent task, namely 'my-image:do_build'
note: no perl packages end up in my image.
This is just one example where it seems bitbake is doing a lot of
unnecessary (certainly un-asked-for) work.
How can I unravel this mystery?
Thanks for any pointers
I think I've figured this out - my image includes a couple of
packages (i2c-tools, ntp) that each have some component that
needs perl although I don't install those components. So it
now makes sense that perl has to be built for my target even
though I'm not actually using it.
For example, in i2c-tools I see
RDEPENDS_${PN}-misc = "${PN} perl"
and since I don't actually install i2c-tools-misc, perl isn't
needed.
That said, I had to discover this by manually looking through the
task-depends.dot file as I did not see how to come up with this
answer using -u taskdep alone.
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Task dependencies
I'm trying to understand why 'perl' is being built for my target even though I don't mention it in any of the package recipes used to build that target. When I used 'taskexp', I found that 'perl:do_build' only has a single dependent task, namely 'my-image:do_build' note: no perl packages end up in my image. This is just one example where it seems bitbake is doing a lot of unnecessary (certainly un-asked-for) work. How can I unravel this mystery? Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiconfig samples not put in the build dir.
On 2017-04-12 09:15, Paulo Neves wrote: Hello Gary. I didn't know it was not a coreutil. To do it in another way i think this simple code will grow. Before refactoring could I have other opinions? We have a very limited environment and even so the rename exists. It is part of the util-linux-ng from the kernel... Not really my call to make. Also, please keep this discussion on the mailing list so that everyone benefits. On Wed, Apr 12, 2017 at 9:10 AM, Gary Thomas <g...@mlbassoc.com> wrote: On 2017-04-12 09:02, Paulo Neves wrote: I expect it to rename all the .conf.sample files from .conf.sample to .conf. Give it a try ;) This introduces a new dependency for the rename tool/program which is a Perl script. It seems to me that much effort has been made recently to minimize these scripts, removing bash-isms, etc, and adding this dependency would drift from that path. Just my 2c On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas <g...@mlbassoc.com> wrote: On 2017-04-12 08:48, Paulo Neves wrote: Hello, I thought it would be consistent to have the multiconfig samples to also be populated just like the local.conf. I produced a patch accordingly: From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001 From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> Date: Mon, 3 Apr 2017 11:23:12 +0200 Subject: [PATCH 1/2] multiconfig samples are now put in the build dir. The users of multiconfig which use the templateconf mechanism may also want the multiconfig samples to be retrieved from the template configuration directories. This patch allows for that. It only copies the .conf.sample files. It does not create the multiconfig directory if the templateconf directory does not exist or have any sample files. --- scripts/oe-setup-builddir | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" fi - unset SHOWYPDOC if [ -z "$OECORELOCALCONF" ]; then OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/local.conf" ]; then cat <&1 > /dev/null ); then + mkdir -p "$BUILDDIR/conf/multiconfig/" +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/" +(cd "$BUILDDIR/conf/multiconfig/" && +rename .conf.sample .conf *.conf.sample) This doesn't look right to me - what are you expecting the 'rename' command to do? +echo "Multiconfig samples detected copying them also.\n" +fi SHOWYPDOC=yes fi if [ -z "$OECORELAYERCONF" ]; then OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then cat < -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiconfig samples not put in the build dir.
On 2017-04-12 09:02, Paulo Neves wrote: I expect it to rename all the .conf.sample files from .conf.sample to .conf. Give it a try ;) This introduces a new dependency for the rename tool/program which is a Perl script. It seems to me that much effort has been made recently to minimize these scripts, removing bash-isms, etc, and adding this dependency would drift from that path. Just my 2c On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas <g...@mlbassoc.com> wrote: On 2017-04-12 08:48, Paulo Neves wrote: Hello, I thought it would be consistent to have the multiconfig samples to also be populated just like the local.conf. I produced a patch accordingly: From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001 From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> Date: Mon, 3 Apr 2017 11:23:12 +0200 Subject: [PATCH 1/2] multiconfig samples are now put in the build dir. The users of multiconfig which use the templateconf mechanism may also want the multiconfig samples to be retrieved from the template configuration directories. This patch allows for that. It only copies the .conf.sample files. It does not create the multiconfig directory if the templateconf directory does not exist or have any sample files. --- scripts/oe-setup-builddir | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" fi - unset SHOWYPDOC if [ -z "$OECORELOCALCONF" ]; then OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/local.conf" ]; then cat <&1 > /dev/null ); then + mkdir -p "$BUILDDIR/conf/multiconfig/" +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/" +(cd "$BUILDDIR/conf/multiconfig/" && +rename .conf.sample .conf *.conf.sample) This doesn't look right to me - what are you expecting the 'rename' command to do? +echo "Multiconfig samples detected copying them also.\n" +fi SHOWYPDOC=yes fi if [ -z "$OECORELAYERCONF" ]; then OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then cat < -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiconfig samples not put in the build dir.
On 2017-04-12 08:48, Paulo Neves wrote: Hello, I thought it would be consistent to have the multiconfig samples to also be populated just like the local.conf. I produced a patch accordingly: From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001 From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> Date: Mon, 3 Apr 2017 11:23:12 +0200 Subject: [PATCH 1/2] multiconfig samples are now put in the build dir. The users of multiconfig which use the templateconf mechanism may also want the multiconfig samples to be retrieved from the template configuration directories. This patch allows for that. It only copies the .conf.sample files. It does not create the multiconfig directory if the templateconf directory does not exist or have any sample files. --- scripts/oe-setup-builddir | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" fi - unset SHOWYPDOC if [ -z "$OECORELOCALCONF" ]; then OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/local.conf" ]; then cat <&1 > /dev/null ); then + mkdir -p "$BUILDDIR/conf/multiconfig/" +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/" +(cd "$BUILDDIR/conf/multiconfig/" && +rename .conf.sample .conf *.conf.sample) This doesn't look right to me - what are you expecting the 'rename' command to do? +echo "Multiconfig samples detected copying them also.\n" +fi SHOWYPDOC=yes fi if [ -z "$OECORELAYERCONF" ]; then OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then cat < -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] opkg behavior
I'm using opkg (IPK) packaging with my Yocto builds (using recent master 633ad6c9f). For the most part, this seems to work well, but occasionally I'll rebuild a recipe along with the packaging indexes on my build machine only to find that opkg doesn't want to upgrade to the changes. Here's an example: * Update the package databases on the target board root@teton-p7621:~# opkg update Downloading http://192.168.1.12/teton-p7621-feeds/all/Packages.gz. Updated source 'poky_am-all'. Downloading http://192.168.1.12/teton-p7621-feeds/cortexa7hf-neon/Packages.gz. Updated source 'poky_am-cortexa7hf-neon'. Downloading http://192.168.1.12/teton-p7621-feeds/teton_p7621/Packages.gz. Updated source 'poky_am-teton_p7621'. * Try to update the package I just rebuilt. Normally, this does the right thing root@teton-p7621:~# opkg install production-tests No packages installed or removed. * Odd, check the packaging root@teton-p7621:~# opkg list-installed | grep prod production-tests - 1.0-r0.74 * Force the install by removing the existing package, etc root@teton-p7621:~# opkg remove production-tests Removing production-tests (1.0) from root... root@teton-p7621:~# opkg install production-tests Installing production-tests (1.0) on root Downloading http://192.168.1.12/teton-p7621-feeds/teton_p7621/production-tests_1.0-r0.76_teton_p7621.ipk. Configuring production-tests. So from this you can see that the package has been rebuilt (using the PR server) and that I can indeed install the new version. That said, why did opkg not "upgrade" as expected. Note: I often use the 'opkg upgrade' command but I recently updated my Poky/Yocto repository which caused nearly every package to be rebuilt and I didn't want to have to download everything (none of which affected my current program which is just a python script), so I chose the 'opkg install ...' method instead, which does seem to work sometimes. Any ideas what I can look at or tweak to get this to work the way I expect? Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GCC on ARM
On 2017-03-31 07:07, Khem Raj wrote: On 3/30/17 9:07 PM, Gary Thomas wrote: [slightly off-topic] I work with a number of embedded ARM devices, all with different processors, hence somewhat different tuning and build directories: Raspberry-Pi (1,2,3 - mostly 3): TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" build dirs: tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi BeagleBoneBlack: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" build dirs: tmp/work/armv7ahf-neon-poky-linux-gnueabi i.MX6: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" build dirs: tmp/work/cortexa9hf-neon-poky-linux-gnueabi tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi What I'm wondering is, except for the obvious programs that use SoC specific functions like the IPU/GPU on the i.MX6, how different are these really? So much so that they have to all have unique binaries? Surely I could build busybox or python and run the same binary on all three? You can chose a least common denominator and use that as DEFAULTTUNE for all your machines. May be like armv7at2-neon That's good to know, thanks. What would I be giving up? Anything of substance/importance? -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] GCC on ARM
[slightly off-topic] I work with a number of embedded ARM devices, all with different processors, hence somewhat different tuning and build directories: Raspberry-Pi (1,2,3 - mostly 3): TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" build dirs: tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi BeagleBoneBlack: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" build dirs: tmp/work/armv7ahf-neon-poky-linux-gnueabi i.MX6: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" build dirs: tmp/work/cortexa9hf-neon-poky-linux-gnueabi tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi What I'm wondering is, except for the obvious programs that use SoC specific functions like the IPU/GPU on the i.MX6, how different are these really? So much so that they have to all have unique binaries? Surely I could build busybox or python and run the same binary on all three? -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] arm-angstrom-linux-gnueabi-gcc: fatal error: no input files
On 2017-03-30 14:46, Fabien Lahoudere wrote:
Seems to be related to missing CFLAGS to compile.
IMO you should look at how other recipe build qt4 apps.
The primary problem is that between the time the info you are following
(probably
many years old now - Angstrom has been quite stale since 2015) and now, a lot
has
changed. Most acutely, there is now an expected separation between where
sources
live (${S}) and builds occur (${B}) and your recipe needs to take that into
consideration.
As Fabien said, look at how other (in this case qt4) recipes work.
On Thu, 2017-03-30 at 14:38 +0200, Yuvarajesh Valleru wrote:
Thanks, It worked. But experienced another error.
ERROR: helloworld-1.0-r0 do_compile: Function failed: do_compile (log
file is located at
/home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
r0/temp/log.do_compile.31394)
ERROR: Logfile of failure stored in:
/home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
r0/temp/log.do_compile.31394
Log data follows:
DEBUG: Executing shell function do_compile
/home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
r0/helloworld.cpp:1:23:
fatal error: QTextStream: No such file or directory
compilation terminated.
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at
/home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
r0/temp/log.do_compile.31394)
ERROR: Task
(/home/cc/src/oe-core/build/../layers/meta-laye/recipes-
hi/helloworld/helloworld_1.0.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 591 tasks of which 590 didn't need to be
rerun and 1 failed.
NOTE: Writing buildhistory
Summary: 1 task failed:
/home/cc/src/oe-core/build/../layers/meta-layer/recipes-hi/helloworld/helloworld_1.0.bb:do_compile
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
Am 30.03.2017 um 12:54 schrieb Fabien Lahoudere:
Try
do_compile() {
${CC} ${S}/helloworld.cpp -o ${S}/helloworld
}
On Thu, 2017-03-30 at 12:43 +0200, Yuvarajesh Valleru wrote:
Here is the tree for my recipe and also attached the error.
/home/cc/src/oe-core/build/../layers/meta-layer/recipes-hi/helloworld/
├── files
│ ├── helloworld.cpp
│ └── helloworld.pro
└── helloworld_1.0.bb
1 directory, 3 files
ERROR: helloworld-1.0-r0 do_compile: Function failed: do_compile (log
file is located at
/home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-
gnueabi/helloworld/1.0-
r0/temp/log.do_compile.23742)
ERROR: Logfile of failure stored in:
/home/cc/src/oe-core/build/tmp-glibc/work/armv7at2hf-
neon-
angstrom-linux-gnueabi/helloworld/1.0-r0/temp/log.do_compile.23742
Log data follows:
DEBUG: Executing shell function do_compile
arm-angstrom-linux-gnueabi-gcc: error: helloworld.cpp: No such file or directory
arm-angstrom-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at
/home/cc/src/oe-core/build/tmp-
glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/helloworld/1.0-
r0/temp/log.do_compile.23742)
ERROR: Task (/home/cc/src/oe-core/build/../layers/meta-layer/recipes-
hi/helloworld/helloworld_1.0.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 591 tasks of which 584 didn't need to be rerun
and 1 failed.
NOTE: Writing buildhistory
Summary: 1 task failed:
/home/cc/src/oe-core/build/../layers/meta-layer/recipes-
hi/helloworld/helloworld_1.0.bb:do_compile
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can I change the value of D in a task?
On 2017-03-22 09:58, 윤영석 wrote:
Hi,
I want to change the value of D in tasks, like do_install, do_compile ...
- It is useless to change outside.
Why do you want to do this?
What should I do?
I tried the following but it did not work.
1.
do_install () {
D = ""
}
2.
do_install () {
export D = ""
}
Thanks
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Random failure
On 2017-03-16 13:08, Gary Thomas wrote: I've been running the same sequence many times today - basically updating a source file for a recipe, then rebuilding it. Out of the 40+ times I've run it, I get these intermittent errors about 1 in 10 times. Nothing changed except for one of the source files included in my recipe. Here's the output: === $ MACHINE=teton-p7621 bitbake production-tests && MACHINE=teton-p7621 bitbake package-index NOTE: Started PRServer with DBfile: /build/p7619_2016-02-23/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 44600, PID: 7064 Loading cache: 100% |#| Time: 0:00:00 Loaded 1717 entries from dependency cache. Parsing recipes: 100% |###| Time: 0:00:00 Parsing of 1219 .bb files complete (1218 cached, 1 parsed). 1717 targets, 335 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.33.2" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "arm-amltd-linux-gnueabi" MACHINE = "teton-p7621" DISTRO= "amltd" DISTRO_VERSION= "2.2+snapshot-20170316" TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard cortexa7" TARGET_FPU= "hard" meta = "master:b1f09df0f664052e39d939b759a63b05d767b8ec" meta-amltd= "master:a57fa8ec07224f1d1d87e0357158bcbe7a4bc010" meta-teton-imx6-p761x = "master:a0b1a6c5e1f76ca74d93b26018eb0753a2306a29" Initialising tasks: 100% || Time: 0:00:00 Checking sstate mirror object availability: 100% || Time: 0:00:00 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: production-tests-1.0-r0 do_configure: Function failed: do_configure (log file is located at /build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/temp/log.do_configure.7131) ERROR: Logfile of failure stored in: /build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/temp/log.do_configure.7131 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Removing manifest: /build/p7619_2016-02-23/tmp/sysroots-components/teton_p7621/production-tests/sysroot-providers/production-tests | DEBUG: Removing manifest: /build/p7619_2016-02-23/tmp/sysroots-components/teton_p7621/production-tests/sysroot-providers/ | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | find: ‘/build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/license-destdir’: No such file or directory | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/temp/log.do_configure.7131) ERROR: Task (/local/poky-cutting-edge/meta-teton-imx6-p761x/packages/misc/production-tests_1.0.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 454 tasks of which 448 didn't need to be rerun and 1 failed. === If I immediately rerun the same sequence, the error goes away. Any ideas what might be causing this? It's more of an annoyance than anything else, but it also might point to a deeper problem? I'm still seeing these failures a lot and it seems to be related to how busy my system is doing other things. For example, every day the 'locate' database is rebuilt and while that happens, this error seems to be much more likely. It's also obvious that this is a timing related issue given that it occurs randomly and non-repeatably. It's a bit frustrating to have it happen so much but if there are any clues I can gather, I'm happy to provide more information if it helps. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bumping all packages versions
On 2017-03-20 16:52, Matthew Stanger wrote: Hi, I'm running Yocto 1.7.1 and was wondering if there was a simple way to roll/bump all package versions. For example in every .bb I want to bump PV = $version higher. I'm trying to do this as we've designed our headless system to update using opkg but now we are struggling to find a simple way to update package versions, we're trying to stay away from manually doing it as there is a lot of room for error when touching so many packages. First, is there a way to brute force bump all package versions and 2nd is there a way to only bump packages that have changed code (like auto git hash diff or something) without manually bumping the PV version in the .bb? What is the proper way to handle you distro's versioning at the package level? Are you using the PR server? That's pretty much what it's for. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Random failure
I've been running the same sequence many times today - basically updating a source file for a recipe, then rebuilding it. Out of the 40+ times I've run it, I get these intermittent errors about 1 in 10 times. Nothing changed except for one of the source files included in my recipe. Here's the output: === $ MACHINE=teton-p7621 bitbake production-tests && MACHINE=teton-p7621 bitbake package-index NOTE: Started PRServer with DBfile: /build/p7619_2016-02-23/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 44600, PID: 7064 Loading cache: 100% |#| Time: 0:00:00 Loaded 1717 entries from dependency cache. Parsing recipes: 100% |###| Time: 0:00:00 Parsing of 1219 .bb files complete (1218 cached, 1 parsed). 1717 targets, 335 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.33.2" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "arm-amltd-linux-gnueabi" MACHINE = "teton-p7621" DISTRO= "amltd" DISTRO_VERSION= "2.2+snapshot-20170316" TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard cortexa7" TARGET_FPU= "hard" meta = "master:b1f09df0f664052e39d939b759a63b05d767b8ec" meta-amltd= "master:a57fa8ec07224f1d1d87e0357158bcbe7a4bc010" meta-teton-imx6-p761x = "master:a0b1a6c5e1f76ca74d93b26018eb0753a2306a29" Initialising tasks: 100% || Time: 0:00:00 Checking sstate mirror object availability: 100% || Time: 0:00:00 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: production-tests-1.0-r0 do_configure: Function failed: do_configure (log file is located at /build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/temp/log.do_configure.7131) ERROR: Logfile of failure stored in: /build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/temp/log.do_configure.7131 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Removing manifest: /build/p7619_2016-02-23/tmp/sysroots-components/teton_p7621/production-tests/sysroot-providers/production-tests | DEBUG: Removing manifest: /build/p7619_2016-02-23/tmp/sysroots-components/teton_p7621/production-tests/sysroot-providers/ | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | find: ‘/build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/license-destdir’: No such file or directory | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /build/p7619_2016-02-23/tmp/work/teton_p7621-amltd-linux-gnueabi/production-tests/1.0-r0/temp/log.do_configure.7131) ERROR: Task (/local/poky-cutting-edge/meta-teton-imx6-p761x/packages/misc/production-tests_1.0.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 454 tasks of which 448 didn't need to be rerun and 1 failed. === If I immediately rerun the same sequence, the error goes away. Any ideas what might be causing this? It's more of an annoyance than anything else, but it also might point to a deeper problem? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-minimal-xfce error
On 2017-03-14 10:20, ravikiran j wrote:
Hi everybody,
I am getting some errors in building of *core-image-minimal-xfce *image.
I am using ubuntu 14.04 build system and Yocto 2.1.
I added the meta-openembedded layer into poky and configured the bblayers.con
ffile as follows.
POKY_BBLAYERS_CONF_VERSION = "2"
4
5 BBPATH = "${TOPDIR}"
6 BBFILES ?= ""
7
8 BBLAYERS ?= " \
*9 /home/mistral/yocto/poky/meta \
10 /home/mistral/yocto/poky/meta-poky \
11 /home/mistral/yocto/poky/meta-yocto-bsp \
12 /home/mistral/yocto/poky/meta-openembedded/meta-oe \
13 /home/mistral/yocto/poky/meta-openembedded/meta-gnome \
14 /home/mistral/yocto/poky/meta-openembedded/meta-multimedia \
15 /home/mistral/yocto/poky/meta-openembedded/meta-python \
16 /home/mistral/yocto/poky/meta-openembedded/meta-xfce \
17 "
*
i am getting following error after *bitbake* *core-image-minimal-xfce
ERROR: ExpansionError during parsing
/home/mistral/yocto/poky/meta-openembedded/meta-xfce/recipes-xfce/xfce4-power-manager/xfce4-power-manager_1.6.0.bb
<http://xfce4-power-manager_1.6.0.bb>: Failure expanding variable
PACKAGECONFIG, expression was
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} which triggered exception
AttributeError: 'module' object has no
attribute 'filter'
*
What is the problem and how to solve this problem ?
It looks like you have a mixture of branches, probably the latest
master from meta-openembedded and krogoth (v2.1) from Poky/Yocto
These need to be in sync or you'll run into problems like this.
--
--------
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Confusing message
Yes, I've seen this for years, but today it bothered me. Exactly how am I to interpret this message from bitbake? NOTE: Tasks Summary: Attempted 574 tasks of which 507 didn't need to be rerun and all succeeded. This was a result of 'bitbake meta-extsdk-toolchain' and I still haven't figured out what that did... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] missing "whoami" command trying to build FIT image for mpc8315e-rdb ref board
On 2017-03-13 12:50, Robert P. J. Day wrote: trying for the first time to build a FIT image, so started with current poky checkout, configured and built for mpc8315e-rdb and core-image-minimal, everything worked fine (as it always does). now, as i read it, to generate a FIT image output file, i need add only: KERNEL_IMAGETYPES_append = " fitImage" to my local.conf, is that right? but this is what happens: $ bitbake core-image-minimal ... snip ... Initialising tasks...done. NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Running task 1301 of 2494 (/home/rpjday/oe/dist/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.9.bb:do_compile) NOTE: recipe linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0: task do_compile: Started ERROR: linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0 do_compile: oe_runmake failed ERROR: linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0 do_compile: Function failed: do_compile (log file is located at /home/rpjday/oe/builds/mpc8315e/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0/temp/log.do_compile.23408) ERROR: Logfile of failure stored in: /home/rpjday/oe/builds/mpc8315e/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0/temp/log.do_compile.23408 Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 8 HOSTCC=gcc HOSTCPP=gcc -E uImage CC=powerpc-poky-linux-gcc -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd | NOTE: make -j 8 HOSTCC=gcc HOSTCPP=gcc -E fitImage CC=powerpc-poky-linux-gcc -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd | ERROR: oe_runmake failed | make[2]: Circular arch/powerpc/lib/crtsavres.o <- prepare dependency dropped. | CHK include/config/kernel.release | Using /home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source as source for kernel | GEN ./Makefile | CHK include/generated/uapi/linux/version.h | CHK include/generated/utsrelease.h | CHK include/generated/timeconst.h | CHK include/generated/bounds.h | CHK include/generated/asm-offsets.h | CALL /home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/scripts/checksyscalls.sh | CHK include/generated/compile.h | /home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/scripts/mkcompile_h: line 46: whoami: command not found | CALL /home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/arch/powerpc/kernel/systbl_chk.sh | CALL /home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/arch/powerpc/kernel/prom_init_check.sh | CHK kernel/config_data.h | make[2]: *** No rule to make target 'fitImage'. Stop. | Makefile:150: recipe for target 'sub-make' failed | make[1]: *** [sub-make] Error 2 | Makefile:24: recipe for target '__sub-make' failed | make: *** [__sub-make] Error 2 | ERROR: Function failed: do_compile (log file is located at /home/rpjday/oe/builds/mpc8315e/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0/temp/log.do_compile.23408) NOTE: recipe linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0: task do_compile: Failed ERROR: Task (/home/rpjday/oe/dist/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.9.bb:do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 2470 tasks of which 2469 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/rpjday/oe/dist/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.9.bb:do_compile Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. $ obviously(?), selecting a FIT image triggers a call to "whoami" in that kernel mkcompile_h script, and there is no such command in the native sysroot. or am i doing something wrong? This might be a result of the recent PATH changes. Maybe try adding this to your local.conf: HOSTTOOLS_NONFATAL += " whoami" Let the list know if that helps. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] Errors building
If I build for RaspberryPi-3 with vc4graphics enabled, I get
this error building omxplayer:
| In file included from linux/RBP.h:45:0,
| from linux/RBP.cpp:22:
| ./DllBCM.h:34:22: fatal error: bcm_host.h: No such file or directory
| #include
| ^
| compilation terminated.
| Makefile:44: recipe for target 'linux/RBP.o' failed
| make: *** [linux/RBP.o] Error 1
| make: *** Waiting for unfinished jobs
| In file included from OMXCore.h:32:0,
| from OMXClock.h:27,
| from OMXReader.cpp:29:
| DllOMX.h:36:25: fatal error: IL/OMX_Core.h: No such file or directory
| #include
| ^
| compilation terminated.
| Makefile:44: recipe for target 'OMXReader.o' failed
If I disable the vc4graphics, I can't build webkitgtk:
|
/build/rpi3_2016-09-13/tmp/work/cortexa7t2hf-neon-vfpv4-amltd-linux-gnueabi/webkitgtk/2.14.5-r0/webkitgtk-2.14.5/Source/WebCore/platform/graphics/egl/GLContextEGLX11.cpp:
In static member function 'static void* WebCore::GLContextEGL::createWindowSurfaceX11(EGLDisplay, EGLConfig,
GLNativeWindowType)':
|
/build/rpi3_2016-09-13/tmp/work/cortexa7t2hf-neon-vfpv4-amltd-linux-gnueabi/webkitgtk/2.14.5-r0/webkitgtk-2.14.5/Source/WebCore/platform/graphics/egl/GLContextEGLX11.cpp:42:91:
error: invalid static_cast from type 'GLNativeWindowType {aka long long unsigned int}' to type 'EGLNativeWindowType {aka
void*}'
| return eglCreateWindowSurface(display, config,
static_cast(window), nullptr);
Using current master of Poky/Yocto & meta-raspberrypi
meta = "master:d454dc2fc17711d3efe6dbe5aca3c734f0ed158b"
meta-raspberrypi = "master:c768a3d1aed8d16d08afe12fddb359914e0a203a"
Ideas? Ideally, I'd like both of these packages in my image for the rpi3.
Thanks
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Files missing in SDK
-nativesdk-amltdsdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/amltd/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/example tmp/work/x86_64-nativesdk-amltdsdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/amltd/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/include tmp/work/x86_64-nativesdk-amltdsdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/amltd/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin Maybe the SDK generation is trying to look at how the board files are packaged and extract the corresponding bits for the SDK from the nativesdk package? I'm happy to share any of these bits if someone wants to help me understand how to fix the issue. Thanks again -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
(module does not exist, 0) [3087510.394] (==) Matched modesetting as autoconfigured driver 0 [3087510.394] (==) Matched fbdev as autoconfigured driver 1 [3087510.394] (==) Assigned the driver to the xf86ConfigLayout [3087510.394] (II) LoadModule: "modesetting" [3087510.394] (WW) Warning, couldn't open module modesetting [3087510.394] (II) UnloadModule: "modesetting" [3087510.394] (II) Unloading modesetting [3087510.394] (EE) Failed to load module "modesetting" (module does not exist, 0) [3087510.394] (II) LoadModule: "fbdev" [3087510.395] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [3087510.400] (II) Module fbdev: vendor="X.Org Foundation" [3087510.400] compiled for 1.18.4, module version = 0.4.4 [3087510.400] Module class: X.Org Video Driver [3087510.400] ABI class: X.Org Video Driver, version 20.0 [3087510.400] (II) FBDEV: driver for framebuffer: fbdev [3087510.400] (--) using VT number 1 [3087510.408] (WW) Falling back to old probe method for fbdev [3087510.408] (II) Loading sub module "fbdevhw" [3087510.408] (II) LoadModule: "fbdevhw" [3087510.409] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [3087510.420] (II) Module fbdevhw: vendor="X.Org Foundation" [3087510.420] compiled for 1.18.4, module version = 0.0.2 [3087510.420] ABI class: X.Org Video Driver, version 20.0 [3087510.421] (II) FBDEV(0): using default device [3087510.421] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [3087510.421] (II) FBDEV(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [3087510.421] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32 [3087510.421] (==) FBDEV(0): RGB weight 888 [3087510.421] (==) FBDEV(0): Default visual is TrueColor [3087510.421] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0) [3087510.421] (II) FBDEV(0): hardware: BCM2708 FB (video memory: 1500kB) [3087510.421] (II) FBDEV(0): checking modes against framebuffer device... [3087510.421] (II) FBDEV(0): checking modes against monitor... [3087510.421] (--) FBDEV(0): Virtual size is 800x480 (pitch 800) [3087510.421] (**) FBDEV(0): Built-in mode "current" [3087510.421] (==) FBDEV(0): DPI set to (96, 96) [3087510.422] (II) Loading sub module "fb" [3087510.422] (II) LoadModule: "fb" [3087510.422] (II) Loading /usr/lib/xorg/modules/libfb.so [3087510.459] (II) Module fb: vendor="X.Org Foundation" [3087510.459] compiled for 1.18.4, module version = 1.0.0 [3087510.459] ABI class: X.Org ANSI C Emulation, version 0.4 [3087510.459] (**) FBDEV(0): using shadow framebuffer [3087510.459] (II) Loading sub module "shadow" [3087510.459] (II) LoadModule: "shadow" [3087510.459] (II) Loading /usr/lib/xorg/modules/libshadow.so [3087510.482] (II) Module shadow: vendor="X.Org Foundation" [3087510.482] compiled for 1.18.4, module version = 1.1.0 [3087510.482] ABI class: X.Org ANSI C Emulation, version 0.4 [3087510.482] (==) Depth 24 pixmap format is 32 bpp [3087510.505] (==) FBDEV(0): Backing store enabled [3087510.506] (==) FBDEV(0): DPMS enabled [3087510.507] (==) RandR enabled [3087510.831] (II) config/udev: Adding input device SIGMACH1P USB Keykoard (/dev/input/event1) [3087510.831] (**) SIGMACH1P USB Keykoard: Applying InputClass "evdev keyboard catchall" [3087510.831] (II) LoadModule: "evdev" [3087510.832] (WW) Warning, couldn't open module evdev [3087510.832] (II) UnloadModule: "evdev" [3087510.832] (II) Unloading evdev [3087510.832] (EE) Failed to load module "evdev" (module does not exist, 0) [3087510.832] (EE) No input driver matching `evdev' [3087510.835] (II) config/udev: Adding input device SIGMACH1P USB Keykoard (/dev/input/event2) [3087510.835] (**) SIGMACH1P USB Keykoard: Applying InputClass "evdev keyboard catchall" [3087510.835] (II) LoadModule: "evdev" [3087510.835] (WW) Warning, couldn't open module evdev [3087510.836] (II) UnloadModule: "evdev" [3087510.836] (II) Unloading evdev [3087510.836] (EE) Failed to load module "evdev" (module does not exist, 0) [3087510.836] (EE) No input driver matching `evdev' [3087510.837] (II) config/udev: Adding input device FT5406 memory based driver (/dev/input/event0) [3087510.837] (**) FT5406 memory based driver: Applying InputClass "evdev touchscreen catchall" [3087510.837] (II) LoadModule: "evdev" [3087510.838] (WW) Warning, couldn't open module evdev [3087510.838] (II) UnloadModule: "evdev" [3087510.838] (II) Unloading evdev [3087510.838] (EE) Failed to load module "evdev" (module does not exist, 0) [3087510.838] (EE) No input driver matching `evdev' [3087510.839] (II) config/udev: Adding input device FT5406
[yocto] What happened to 'depexp'?
I realized today that 'depexp' is no longer available, leaving only 'taskexp' (more detailed, but I find harder to use). What happened to 'depexp'? Is 'taskexp' supposed to be the replacement? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
On 2017-03-10 01:55, Steve Plant wrote: OK, I have spent the last day googling my heart out trying to find the Xorg.log file without any luck. The problem is that due to the rpi hanging on boot, the only way I can access the SD card to look for the file is place it in a USB SD card reader and use my VirtualBox based Debian to "ls" directores etc. Having established that there is no file located at /var/log/Xorg.log (there isn't a log directory) but there is a symbolic link in the var directory - goes nowhere. After goggling I discovered that the file could also be in the ~/.local/share/xorg/Xorg.0.log, however if I try to look there I get "permission denied" and cannot seem to get to the root directory of the card and I can't find a way around this as I'm trying to access this directory through the USB card reader. Looked everywhere with no answers, Is there anyone who could help me here?? /var/log is on a volatile file system (i.e. it does not live on the SD card) If you can get into your board via SSH, you can copy the file and send it *From:* Khem Raj <raj.k...@gmail.com> *Sent:* Wednesday, 8 March 2017 5:17 p.m. *To:* Steve Plant *Cc:* yocto@yoctoproject.org *Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE. On 17-03-08 12:40:51, Steve Plant wrote: Hi All, Very new to all this linux world, and especially Yocto. I'm working on a embedded project at the moment using a raspberry pi2 board. I have used toaster with Morty 2.2 to compile an image using"rpi-basic-image", to this I have added the following bitbake variables: Bitbake variables DISTRO poky DL_DIR /home/steve/poky/downloads IMAGE_FSTYPES ext3 jffs2 tar.bz2 rpi-sdimg IMAGE_INSTALL_append packagegroup-core-x11-base packagegroup-lxde-base connman PACKAGE_CLASSES package_rpm SSTATE_DIR /home/steve/poky/sstate-cache DISABLE_OVERSCAN 1 GPU_MEM_1024 512 I have dd'ed the image to an SD card increased the sdb2 partition to the max size and powered up the rpi. Everything looks fine to start with, as it displays the four raspberrys in the top left, then the white "Yocto Project" splash screen complete with small blue dot to the side appears, the progress bar moves across to 100 percent, then the screen turns black with a white cursor in the middle and it appears to freeze with only a very dim one second flash of the "act" led. I have then connected the 7" touchscreen and apart from the added multicolored square at the very beginning I get the exact same boot up problem, hangs on the black screen with white cursor (good to see its all resized correctly for the TfT through!!) Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I successfully copied over and ran the rpi-basic-image with no problem, ending up with a usable console. Looking for any help here, I'm thinking I've missed adding a package, or some type of local.conf instruction. any suggestions would be appreciated. Can you send the content of /var/log/Xorg.log file ? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Files missing from SDK
On 2017-03-07 23:26, Paul Eggleton wrote: On Tuesday, 7 March 2017 5:44:05 PM NZDT Gary Thomas wrote: On 2017-03-06 21:56, Paul Eggleton wrote: On Tuesday, 7 March 2017 2:28:22 AM NZDT Gary Thomas wrote: On 2017-03-06 13:22, Burton, Ross wrote: On 3 March 2017 at 06:39, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: I'm trying to build SDKs for my board, both the native style using populate_sdk_ext as well as including the SDK packages in my image. My image includes some extended libraries of my own packaging (am335x-pru-support) that I need to get into these SDKs. This package (via debian renaming) turns into libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files (St) libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0> On my board/image, I can get the files I need but only if I manually include libprussdrv-dev> # opkg files libprussdrv-dev | sort /usr/bin/pasm /usr/include/pruss/ /usr/include/pruss/pruss_intc_mapping.h /usr/include/pruss/prussdrv.h /usr/lib/libprussdrv.so How can I get these automatically added to my SDK images? To build the board SDK, I'm adding these packages to my image: CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk packagegroup-core-standalone-sdk-target"> I suppose I could add libprussdrv-dev to that list, but I'd like it a bit more automated.> For the native SDK, I tried adding this to local.conf: TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support" which only got me the 'pasm' tool in my sysroot, but nothing else. If libprussdrv1 is in your image then the -dev package should be pulled into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs already. Thanks, that did it for the embedded SDK That shouldn't actually be necessary. IMAGE_FEATURES controls what goes into the image, adding dev-pkgs to that is going to include those in the image, not just the SDK. We have a SDKIMAGE_FEATURES and the default value of that includes dev-pkgs. If libprussdrv1 is in the image and SDKIMAGE_FEATURES is at the default (or otherwise includes dev-pkgs) I have to say I'm not sure what would be preventing this from working. The same should mean that standalone SDKs (populate_sdk-style) contain the headers too. Worse case, TOOLCHAIN_TARGET_TASK_append = " libprussdrvi-dev". Sadly, this still doesn't work. With the TOOLCHAIN* line above, I get: ERROR: Nothing RPROVIDES 'libprussdrv1-dev' Without it, no changes - the bits are still missing. As with almost all variables, in TOOLCHAIN_TARGET_TASK you want the recipe- space name of the package, not the final (post debian-renamed) name. I tried that as well, and it got a lot farther along, but failed in the final steps: ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Unable to install packages. Command '/build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative -tarball/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative- tarball/1.0-r0/opkg.conf -t /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative- tarball/1.0-r0/temp/ipktemp/ -o /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative- tarball/1.0-r0/sdk/image/opt/amltd/2.2+snapshot/sysroots/none --force_postinstall --prefer-arch-to-version install libprussdrv-dev' returned 255: Collected errors: * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'libprussdrv-dev'. ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk It sounds like you're setting TOOLCHAIN_TARGET_TASK at the configuration level, thus affecting uninative-tarball as well. Set it in your image recipe (or a class / inc file used from there) and that should work. Thanks, that solved that problem. I'm now getting the missing files in my [host] SDK, getting much closer. I'm still missing some others though - files from [meta-ti]recipes-ti/devtools/ti-cgt-pru_2.1.4.bb I am getting the appropriate files when I build using bitbake, as well as on my target when I include the sdk components, just not when I build a host SDK using -c populate_sdk_ext That's a very differently packaged recipe (lots of magic), so I'll take it up with the meta-ti list Thanks for your help -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world --
Re: [yocto] Files missing from SDK
On 2017-03-06 21:56, Paul Eggleton wrote: On Tuesday, 7 March 2017 2:28:22 AM NZDT Gary Thomas wrote: On 2017-03-06 13:22, Burton, Ross wrote: On 3 March 2017 at 06:39, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: I'm trying to build SDKs for my board, both the native style using populate_sdk_ext as well as including the SDK packages in my image. My image includes some extended libraries of my own packaging (am335x-pru-support) that I need to get into these SDKs. This package (via debian renaming) turns into libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files (St) libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0> On my board/image, I can get the files I need but only if I manually include libprussdrv-dev> # opkg files libprussdrv-dev | sort /usr/bin/pasm /usr/include/pruss/ /usr/include/pruss/pruss_intc_mapping.h /usr/include/pruss/prussdrv.h /usr/lib/libprussdrv.so How can I get these automatically added to my SDK images? To build the board SDK, I'm adding these packages to my image: CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk packagegroup-core-standalone-sdk-target"> I suppose I could add libprussdrv-dev to that list, but I'd like it a bit more automated.> For the native SDK, I tried adding this to local.conf: TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support" which only got me the 'pasm' tool in my sysroot, but nothing else. If libprussdrv1 is in your image then the -dev package should be pulled into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs already. Thanks, that did it for the embedded SDK That shouldn't actually be necessary. IMAGE_FEATURES controls what goes into the image, adding dev-pkgs to that is going to include those in the image, not just the SDK. We have a SDKIMAGE_FEATURES and the default value of that includes dev-pkgs. If libprussdrv1 is in the image and SDKIMAGE_FEATURES is at the default (or otherwise includes dev-pkgs) I have to say I'm not sure what would be preventing this from working. The same should mean that standalone SDKs (populate_sdk-style) contain the headers too. Worse case, TOOLCHAIN_TARGET_TASK_append = " libprussdrvi-dev". Sadly, this still doesn't work. With the TOOLCHAIN* line above, I get: ERROR: Nothing RPROVIDES 'libprussdrv1-dev' Without it, no changes - the bits are still missing. As with almost all variables, in TOOLCHAIN_TARGET_TASK you want the recipe- space name of the package, not the final (post debian-renamed) name. I tried that as well, and it got a lot farther along, but failed in the final steps: ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Unable to install packages. Command '/build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/opkg.conf -t /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/temp/ipktemp/ -o /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-tarball/1.0-r0/sdk/image/opt/amltd/2.2+snapshot/sysroots/none --force_postinstall --prefer-arch-to-version install libprussdrv-dev' returned 255: Collected errors: * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'libprussdrv-dev'. ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Files missing from SDK
On 2017-03-06 13:22, Burton, Ross wrote: On 3 March 2017 at 06:39, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: I'm trying to build SDKs for my board, both the native style using populate_sdk_ext as well as including the SDK packages in my image. My image includes some extended libraries of my own packaging (am335x-pru-support) that I need to get into these SDKs. This package (via debian renaming) turns into libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files (St) libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 On my board/image, I can get the files I need but only if I manually include libprussdrv-dev # opkg files libprussdrv-dev | sort /usr/bin/pasm /usr/include/pruss/ /usr/include/pruss/pruss_intc_mapping.h /usr/include/pruss/prussdrv.h /usr/lib/libprussdrv.so How can I get these automatically added to my SDK images? To build the board SDK, I'm adding these packages to my image: CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk packagegroup-core-standalone-sdk-target" I suppose I could add libprussdrv-dev to that list, but I'd like it a bit more automated. For the native SDK, I tried adding this to local.conf: TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support" which only got me the 'pasm' tool in my sysroot, but nothing else. If libprussdrv1 is in your image then the -dev package should be pulled into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs already. Thanks, that did it for the embedded SDK The same should mean that standalone SDKs (populate_sdk-style) contain the headers too. Worse case, TOOLCHAIN_TARGET_TASK_append = " libprussdrvi-dev". Sadly, this still doesn't work. With the TOOLCHAIN* line above, I get: ERROR: Nothing RPROVIDES 'libprussdrv1-dev' Without it, no changes - the bits are still missing. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Files missing from SDK
On 2017-03-03 07:39, Gary Thomas wrote: I'm trying to build SDKs for my board, both the native style using populate_sdk_ext as well as including the SDK packages in my image. My image includes some extended libraries of my own packaging (am335x-pru-support) that I need to get into these SDKs. This package (via debian renaming) turns into libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files (St) libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 On my board/image, I can get the files I need but only if I manually include libprussdrv-dev # opkg files libprussdrv-dev | sort /usr/bin/pasm /usr/include/pruss/ /usr/include/pruss/pruss_intc_mapping.h /usr/include/pruss/prussdrv.h /usr/lib/libprussdrv.so How can I get these automatically added to my SDK images? To build the board SDK, I'm adding these packages to my image: CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk packagegroup-core-standalone-sdk-target" I suppose I could add libprussdrv-dev to that list, but I'd like it a bit more automated. For the native SDK, I tried adding this to local.conf: TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support" which only got me the 'pasm' tool in my sysroot, but nothing else. Thanks for any pointers Does no-one have ideas how I can get these additional files into my SDK(s)? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Strange error
I wanted to change (disable) extra getty tasks in my target image. I'm using sysvinit, so I added this line to my .conf: SYSVINIT_ENABLED_GETTYS = "" I thought that would get the sysvinit-inittab package rebuilt as do_install uses that variable, but alas it did not. So I took out the big hammer and tried: $ bitbake sysvinit-inittab -c cleanall $ bitbake sysvinit-inittab Now I get this error: ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb.do_install, the basehash value changed from 2b888d6b72e00c404fc7e17436e465eb to 0fd6c915488c10c37cdfd6a674354e65. The metadata is not deterministic and this needs to be fixed. ERROR: Taskhash mismatch 15202ef0ff19a8f7a485533510dab7e8 versus 81fae57019b1a17967258945560affc1 for /local/poky-cutting-edge/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb.do_install So I took out an even bigger hammer: $ find sstate-cache/ -name "*sysvinit-inittab*" | xargs -t rm -f $ bitbake sysvinit-inittab -c cleanall $ bitbake sysvinit-inittab and I still get the same errors. How can this be? How do I get to rebuild my sysvinit-inittab recipe and make the results stick? Thanks for any pointers -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Files missing from SDK
I'm trying to build SDKs for my board, both the native style using populate_sdk_ext as well as including the SDK packages in my image. My image includes some extended libraries of my own packaging (am335x-pru-support) that I need to get into these SDKs. This package (via debian renaming) turns into libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 - Development files (St) libprussdrv1 - 2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0 On my board/image, I can get the files I need but only if I manually include libprussdrv-dev # opkg files libprussdrv-dev | sort /usr/bin/pasm /usr/include/pruss/ /usr/include/pruss/pruss_intc_mapping.h /usr/include/pruss/prussdrv.h /usr/lib/libprussdrv.so How can I get these automatically added to my SDK images? To build the board SDK, I'm adding these packages to my image: CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk packagegroup-core-standalone-sdk-target" I suppose I could add libprussdrv-dev to that list, but I'd like it a bit more automated. For the native SDK, I tried adding this to local.conf: TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support" which only got me the 'pasm' tool in my sysroot, but nothing else. Thanks for any pointers -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Devtool: Script Not found
On 2017-03-02 17:14, SatyaNarayana Sampangi wrote:
Thanks Leonardo Sandoval and Ross,
I am using beagle bone black, for which meta-ti layer and poky versions
compatible is daisy 1.6 as mention in the
official website of yocto. If I upgrade the poky to the latest version, then
compatibity will be lost. Pls help me out here.
Not sure where you got that information, but the BeagleBoneBlack works just
fine with much more recent branches. I'm using current master, but morty
should be fine.
On Thu, Mar 2, 2017 at 9:18 PM, Leonardo Sandoval
<leonardo.sandoval.gonza...@linux.intel.com
<mailto:leonardo.sandoval.gonza...@linux.intel.com>> wrote:
On Thu, 2017-03-02 at 19:56 +0530, SatyaNarayana Sampangi wrote:
> Hi Paul,
>
>
> I am not finding the devtool script under the
> /${HOME}/yocto/poky/scripts, so I copied that script from the website
> and changed the permissions.
>
>
> I did sourcing also,
>
>
when you said 'sourcing' you mean you prepare the environment with the
oe-init-build-env? Looks to me that you are missing this step.
> but when I run the script, I am getting
>
>
>
>
> devtool
> Traceback (most recent call last):
> File "/home/satya/yoctoBSP/poky/scripts/devtool", line 38, in
>
> from devtool import DevtoolError, setup_tinfoil
> ImportError: No module named 'devtool'
>
>
> Can you pls help me here. whereI am going wrong.
>
>
> Thanks in Advance,
>
>
> Regards,
> Satya
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Shared library question
On 2017-02-27 21:11, Max Krummenacher wrote:
Hi
Am Montag, den 27.02.2017, 15:03 +0100 schrieb Gary Thomas:
I trying to create a package am335x-pru-support which creates a
shared library used by another package pru-examples. The library
files installed with am335x-pru-support are (from /image)
-rwxr-xr-x 4 gthomas gthomas 17074 Feb 27 13:40 usr/lib/libprussdrv.a
lrwxrwxrwx 1 gthomas gthomas16 Feb 27 13:40 usr/lib/libprussdrv.so ->
libprussdrv.so.1
lrwxrwxrwx 1 gthomas gthomas18 Feb 27 13:40 usr/lib/libprussdrv.so.1 ->
libprussdrv.so.1.0
-rwxr-xr-x 1 gthomas gthomas 22092 Feb 27 13:40 usr/lib/libprussdrv.so.1.0
-rw-r--r-- 4 gthomas gthomas 8074 Feb 27 13:40 usr/include/pruss/prussdrv.h
-rw-r--r-- 4 gthomas gthomas 4286 Feb 27 13:40
usr/include/pruss/pruss_intc_mapping.h
These files are split by the packager as:
gthomas@europa:packages-split$ find am335x-pru-support | sort
am335x-pru-support
am335x-pru-support/usr
am335x-pru-support/usr/lib
am335x-pru-support/usr/lib/libprussdrv.so.1
am335x-pru-support/usr/lib/libprussdrv.so.1.0
gthomas@europa:packages-split$ find am335x-pru-support-dev | sort
am335x-pru-support-dev
am335x-pru-support-dev/usr
am335x-pru-support-dev/usr/include
am335x-pru-support-dev/usr/include/pruss
am335x-pru-support-dev/usr/include/pruss/prussdrv.h
am335x-pru-support-dev/usr/include/pruss/pruss_intc_mapping.h
am335x-pru-support-dev/usr/lib
am335x-pru-support-dev/usr/lib/libprussdrv.so
These files get staged correctly to pru-examples recipe-specific-sysroot
and I can build and link against them, using DEPENDS="am335x-pru-support".
The problem is that when my build (target recipe) uses
$(CC) my_target_program.c $(LDFLAGS) -lprussdrv
it gets satisfied by /usr/lib/libprussdrv.so and not /usr/lib/libprussdrv.so.1
This in turn appears to keep the pru-examples package from having
a runtime dependency against the am335x-pru-support package and the
necessary library file does not end up on my target.
I've tried to work through this, following many recipes as examples,
e.g. meta/recipes-multimedia/libogg (pattern for am335x-pru-support)
and meta/recipes-multimedia/flac (pattern for pru-examples). The
libogg/flac combo works correctly, mine does not :-(
Any pointers on what I might be doing wrong? I'm so close to getting
this stuff going, it's just the packaging that's going to claim the
last hairs from my head...
When linking a shared object file you have to pass the linker a soname which
adds compatible version
information into the share object file.
Have a look here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/recipes-bsp?id=7ff327a4e3e8e19d1e3f848
865b6b27ba9f6250b
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Alternatively you can drop the libprussdrv.so.1 and libprussdrv.so.1.0, and
force with FILES... the
libprussdrv.so into the not -dev package.
Probably you would also want to INSANE_SKIP_${PN} = "dev-so".
Perfect, that worked a treat!
Thanks
--
--------
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Shared library question
I trying to create a package am335x-pru-support which creates a shared library used by another package pru-examples. The library files installed with am335x-pru-support are (from /image) -rwxr-xr-x 4 gthomas gthomas 17074 Feb 27 13:40 usr/lib/libprussdrv.a lrwxrwxrwx 1 gthomas gthomas16 Feb 27 13:40 usr/lib/libprussdrv.so -> libprussdrv.so.1 lrwxrwxrwx 1 gthomas gthomas18 Feb 27 13:40 usr/lib/libprussdrv.so.1 -> libprussdrv.so.1.0 -rwxr-xr-x 1 gthomas gthomas 22092 Feb 27 13:40 usr/lib/libprussdrv.so.1.0 -rw-r--r-- 4 gthomas gthomas 8074 Feb 27 13:40 usr/include/pruss/prussdrv.h -rw-r--r-- 4 gthomas gthomas 4286 Feb 27 13:40 usr/include/pruss/pruss_intc_mapping.h These files are split by the packager as: gthomas@europa:packages-split$ find am335x-pru-support | sort am335x-pru-support am335x-pru-support/usr am335x-pru-support/usr/lib am335x-pru-support/usr/lib/libprussdrv.so.1 am335x-pru-support/usr/lib/libprussdrv.so.1.0 gthomas@europa:packages-split$ find am335x-pru-support-dev | sort am335x-pru-support-dev am335x-pru-support-dev/usr am335x-pru-support-dev/usr/include am335x-pru-support-dev/usr/include/pruss am335x-pru-support-dev/usr/include/pruss/prussdrv.h am335x-pru-support-dev/usr/include/pruss/pruss_intc_mapping.h am335x-pru-support-dev/usr/lib am335x-pru-support-dev/usr/lib/libprussdrv.so These files get staged correctly to pru-examples recipe-specific-sysroot and I can build and link against them, using DEPENDS="am335x-pru-support". The problem is that when my build (target recipe) uses $(CC) my_target_program.c $(LDFLAGS) -lprussdrv it gets satisfied by /usr/lib/libprussdrv.so and not /usr/lib/libprussdrv.so.1 This in turn appears to keep the pru-examples package from having a runtime dependency against the am335x-pru-support package and the necessary library file does not end up on my target. I've tried to work through this, following many recipes as examples, e.g. meta/recipes-multimedia/libogg (pattern for am335x-pru-support) and meta/recipes-multimedia/flac (pattern for pru-examples). The libogg/flac combo works correctly, mine does not :-( Any pointers on what I might be doing wrong? I'm so close to getting this stuff going, it's just the packaging that's going to claim the last hairs from my head... Thanks n.b. I'm happy to share any of the recipes, I just left them out for brevity. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi_4.9.bb: Update to 4.9.12
On 2017-02-26 03:00, Andrei Gherzan wrote:
On Sat, Feb 25, 2017 at 10:16:24AM -0800, Khem Raj wrote:
On Sat, Feb 25, 2017 at 1:11 AM, Paul Barker <p...@paulbarker.me.uk> wrote:
On Fri, 24 Feb 2017 16:03:59 -0800
Khem Raj <raj.k...@gmail.com> wrote:
Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
b/recipes-kernel/linux/linux-raspberrypi_4.9.bb index
dcca369..b41a8ef 100644 ---
a/recipes-kernel/linux/linux-raspberrypi_4.9.bb +++
b/recipes-kernel/linux/linux-raspberrypi_4.9.bb @@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.9.10"
+LINUX_VERSION ?= "4.9.12"
-SRCREV = "095c4480e1f623bdc8a221a171ef13b2223706b1"
+SRCREV = "c1271995832a090a94eb3b1c1678cb51b84ef1ca"
SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y
\
file://0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch
\ "
rpi-4.9.y is now the default branch upstream and they've started
merging in new stable releases instead of rebasing. So how soon do we
want to make 4.9.y the default in meta-raspberrypi?
I've already tested a 4.9 series kernel with u-boot on an rpi and an
rpi3 so I'm happy that it all looks good.
I'm away this weekend so I can't send the patch right now myself. If
no-one else jumps on it I'll send a patch towards the end of the week
to change the default.
Lets apply this patch so we get away from this rebasing business quickly.
however I would like to wait for us to make it default may be a week or so
I have some issues bringing up wlan0 with 4.9 and would like to see why I get
ifup wlan0
Successfully initialized wpa_supplicant
rfkill: WLAN soft blocked
Could not set interface wlan0 flags (UP): Operation not possible due to RF-kill
That is interesting. I've seen it on old kernel versions too. Everytime
disappeared by itself.
Khem,
Exactly which version (kernel rev / SRCREV) do you have this with and which
RaspberryPi? I've had my rpi3 running continuously for more than a week with
no such problems, running 4.9.10/095c4480e1
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][morty][PATCH 2/2] linux-raspberrypi_4.9.bb: Upgrade to 4.9.10
On 2017-02-19 12:18, Paul Barker wrote:
From: Khem Raj <raj.k...@gmail.com>
Fix dtbo builds for arm64
Signed-off-by: Khem Raj <raj.k...@gmail.com>
Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
---
...-Add-rules-for-.dtbo-files-for-dts-overla.patch | 29 ++
recipes-kernel/linux/linux-raspberrypi_4.9.bb | 5 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
create mode 100644
recipes-kernel/linux/linux-raspberrypi-4.9/0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch
diff --git
a/recipes-kernel/linux/linux-raspberrypi-4.9/0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch
b/recipes-kernel/linux/linux-raspberrypi-4.9/0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch
new file mode 100644
index 000..e8bc52e
--- /dev/null
+++
b/recipes-kernel/linux/linux-raspberrypi-4.9/0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch
@@ -0,0 +1,29 @@
+From 922ce1fd0eb810b713f6ffa9a7ab97c11b6e38cf Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.k...@gmail.com>
+Date: Fri, 10 Feb 2017 17:57:08 -0800
+Subject: [PATCH] build/arm64: Add rules for .dtbo files for dts overlays
+
+We now create overlays as .dtbo files.
+
+Signed-off-by: Khem Raj <raj.k...@gmail.com>
+---
+ arch/arm64/Makefile | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
+index 3635b8662724..822fefeb1cd0 100644
+--- a/arch/arm64/Makefile
b/arch/arm64/Makefile
+@@ -113,6 +113,9 @@ zinstall install:
+ %.dtb: scripts
+ $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
+
++%.dtbo: | scripts
++ $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
++
+ PHONY += dtbs dtbs_install
+
+ dtbs: prepare scripts
+--
+2.11.1
+
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
index cffea1a..dcca369 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
@@ -1,8 +1,9 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.9.4"
+LINUX_VERSION ?= "4.9.10"
-SRCREV = "8b0be887f834e7eccf0de3edf630003880779a5f"
+SRCREV = "095c4480e1f623bdc8a221a171ef13b2223706b1"
SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y \
+
file://0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch \
"
require linux-raspberrypi.inc
+1 since the previous revision has gone walk-about :-(
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] WiFi on rpi3?
On 2017-02-17 03:09, Khem Raj wrote: On 1/20/17 3:52 AM, Gary Thomas wrote: On 2017-01-20 12:30, Gary Thomas wrote: Can someone give me pointers to get the onboard WiFi on the RaspberryPi3 going? What kernel settings/hoops I need to do, what packages I might need, etc? Thanks Actually, I've found that with an older kernel (4.1.21) the WiFi device is discovered, but with the newer kernels (4.4.x and 4.9.x) it's not. Any clues? Please try out the patch I posted to ml https://lists.yoctoproject.org/pipermail/yocto/2017-February/034624.html or from my gh fork. https://github.com/kraj/meta-raspberrypi/commit/6ce6e57782c23fd21ad47286ac8b809ce989ea78 and let us know. This works great on my rpi3, thanks! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] xserver-xf86-config: remove evdev configuration
On 2017-02-16 12:49, Andreas Müller wrote:
xorg-xserver recommends xf86-input-libinput since oe-core's commit
| commit 2d005faff6341a81a2afae28860101ba9db51ae8
| Author: Jussi Kukkonen <jussi.kukko...@intel.com>
| Date: Wed Oct 26 11:37:38 2016 +0300
|
|conf: Use xf86-input-libinput by default
| ...
As nice side effect warnings for missing evdev in Xorg.0.log are gone.
Signed-off-by: Andreas Müller <schnitzelt...@googlemail.com>
Indeed, this lets the X server work again without the need for xf86-input-evdev
Thanks
---
.../rpi/xorg.conf.d/10-evdev.conf | 40 --
.../xorg-xserver/xserver-xf86-config_0.1.bbappend | 22 ++--
2 files changed, 10 insertions(+), 52 deletions(-)
delete mode 100644
recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
diff --git
a/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
b/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
deleted file mode 100644
index cc83ab2..000
---
a/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
+++ /dev/null
@@ -1,40 +0,0 @@
-#
-# Catch-all evdev loader for udev-based systems
-# We don't simply match on any device since that also adds accelerometers
-# and other devices that we don't really want to use. The list below
-# matches everything but joysticks.
-
-Section "InputClass"
-Identifier "evdev pointer catchall"
-MatchIsPointer "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev keyboard catchall"
-MatchIsKeyboard "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev touchpad catchall"
-MatchIsTouchpad "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev tablet catchall"
-MatchIsTablet "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev touchscreen catchall"
-MatchIsTouchscreen "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
index 062de2d..b361eef 100644
--- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -1,19 +1,17 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-SRC_URI_append_rpi = " file://xorg.conf.d/10-evdev.conf \
- file://xorg.conf.d/98-pitft.conf \
- file://xorg.conf.d/99-calibration.conf \
- "
+SRC_URI_append_rpi = " \
+file://xorg.conf.d/98-pitft.conf \
+file://xorg.conf.d/99-calibration.conf \
+"
do_install_append_rpi () {
- install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
- install -m 0644 ${WORKDIR}/xorg.conf.d/10-evdev.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
-
- PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
- if [ "${PITFT}" = "1" ]; then
- install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
- install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
- fi
+PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
+if [ "${PITFT}" = "1" ]; then
+ install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
+install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
+install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
+fi
}
FILES_${PN}_rpi += "${sysconfdir}/X11/xorg.conf
${sysconfdir}/X11/xorg.conf.d/*"
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] xserver-xf86-config: remove evdev configuration
On 2017-02-16 12:49, Andreas Müller wrote:
xorg-xserver recommends xf86-input-libinput since oe-core's commit
| commit 2d005faff6341a81a2afae28860101ba9db51ae8
| Author: Jussi Kukkonen <jussi.kukko...@intel.com>
| Date: Wed Oct 26 11:37:38 2016 +0300
|
|conf: Use xf86-input-libinput by default
| ...
As nice side effect warnings for missing evdev in Xorg.0.log are gone.
Signed-off-by: Andreas Müller <schnitzelt...@googlemail.com>
So, does this let my simple config (HDMI+USB keyboard/mouse) work with no
further fiddling?
---
.../rpi/xorg.conf.d/10-evdev.conf | 40 --
.../xorg-xserver/xserver-xf86-config_0.1.bbappend | 22 ++--
2 files changed, 10 insertions(+), 52 deletions(-)
delete mode 100644
recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
diff --git
a/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
b/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
deleted file mode 100644
index cc83ab2..000
---
a/recipes-graphics/xorg-xserver/xserver-xf86-config/rpi/xorg.conf.d/10-evdev.conf
+++ /dev/null
@@ -1,40 +0,0 @@
-#
-# Catch-all evdev loader for udev-based systems
-# We don't simply match on any device since that also adds accelerometers
-# and other devices that we don't really want to use. The list below
-# matches everything but joysticks.
-
-Section "InputClass"
-Identifier "evdev pointer catchall"
-MatchIsPointer "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev keyboard catchall"
-MatchIsKeyboard "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev touchpad catchall"
-MatchIsTouchpad "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev tablet catchall"
-MatchIsTablet "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
-
-Section "InputClass"
-Identifier "evdev touchscreen catchall"
-MatchIsTouchscreen "on"
-MatchDevicePath "/dev/input/event*"
-Driver "evdev"
-EndSection
diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
index 062de2d..b361eef 100644
--- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -1,19 +1,17 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-SRC_URI_append_rpi = " file://xorg.conf.d/10-evdev.conf \
- file://xorg.conf.d/98-pitft.conf \
- file://xorg.conf.d/99-calibration.conf \
- "
+SRC_URI_append_rpi = " \
+file://xorg.conf.d/98-pitft.conf \
+file://xorg.conf.d/99-calibration.conf \
+"
do_install_append_rpi () {
- install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
- install -m 0644 ${WORKDIR}/xorg.conf.d/10-evdev.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
-
- PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
- if [ "${PITFT}" = "1" ]; then
- install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
- install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
- fi
+PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
+if [ "${PITFT}" = "1" ]; then
+ install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
+install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
+install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf
${D}/${sysconfdir}/X11/xorg.conf.d/
+fi
}
FILES_${PN}_rpi += "${sysconfdir}/X11/xorg.conf
${sysconfdir}/X11/xorg.conf.d/*"
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-base.inc: Add xf86-input-evdev to XSERVER
On 2017-02-16 08:37, Jussi Kukkonen wrote:
On 16 February 2017 at 04:14, Gary Thomas <g...@mlbassoc.com
<mailto:g...@mlbassoc.com>> wrote:
On 2017-02-16 02:45, Andrei Gherzan wrote:
On Mon, Feb 13, 2017 at 12:25:48AM +0900, Yusuke Mitsuki wrote:
In order to fix problem that mouse does not work.
This is removed c40558173ffd96c499d101155f6c4c2be85d9f0f.
However mouse does not worked from this.
---
conf/machine/include/rpi-base.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index e069e70..051c717 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -11,6 +11,7 @@ XSERVER = " \
xserver-xorg \
${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
"xserver-xorg-extension-glx", "", d)} \
${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
"xf86-video-modesetting", "xf86-video-fbdev", d)} \
+xf86-input-evdev \
"
KERNEL_DEVICETREE ?= " \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>
CC-ing schnitzelt...@googlemail.com
<mailto:schnitzelt...@googlemail.com> as he might have an opinion about
this. I personally don't really hold on any of the options.
I think it's the right thing to do, in fact, I was preparing a
similar patch myself. The change that removed this argued that
it was not the responsibility of the BSP layer, but if you look
around at other BSP layers, almost all of them do include this
driver as part of their X server setup. It also lets X work
again on the RaspberryPi "out of the box" with the simplest
configuration - HDMI display + USB keyboard & mouse.
+1
Out of interest: Why is xf86-input-libinput not appropriate for these setups? I
honestly did not know of a use case
where -evdev would work but -libinput would not...
I'm not sure (and I don't have a setup right now to test). I've always
used -evdev as that was the recommended driver for many years now.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] rpi-base.inc: Add xf86-input-evdev to XSERVER
On 2017-02-16 02:45, Andrei Gherzan wrote:
On Mon, Feb 13, 2017 at 12:25:48AM +0900, Yusuke Mitsuki wrote:
In order to fix problem that mouse does not work.
This is removed c40558173ffd96c499d101155f6c4c2be85d9f0f.
However mouse does not worked from this.
---
conf/machine/include/rpi-base.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index e069e70..051c717 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -11,6 +11,7 @@ XSERVER = " \
xserver-xorg \
${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
"xserver-xorg-extension-glx", "", d)} \
${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "xf86-video-modesetting",
"xf86-video-fbdev", d)} \
+xf86-input-evdev \
"
KERNEL_DEVICETREE ?= " \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
CC-ing schnitzelt...@googlemail.com as he might have an opinion about
this. I personally don't really hold on any of the options.
I think it's the right thing to do, in fact, I was preparing a
similar patch myself. The change that removed this argued that
it was not the responsibility of the BSP layer, but if you look
around at other BSP layers, almost all of them do include this
driver as part of their X server setup. It also lets X work
again on the RaspberryPi "out of the box" with the simplest
configuration - HDMI display + USB keyboard & mouse.
+1
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Getting build dependencies correct
I'm trying to work with a new tool that creates executables for my target. This tool has a shared library and some include files. What I need to figure out is how to run the tool in my build environment such that it uses those files to create an executable for my target board. The tool is created by some recipe xxx. I have enabled both the target version and the xxx-native version (using BBCLASSEXTEND) and end up with these files in the tmp/sysroots gthomas@europa:p8701_2016-10-22$ find tmp/sysroots-components/armv7ahf-neon/am335x-pru-support tmp/sysroots-components/armv7ahf-neon/am335x-pru-support tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/sysroot-providers tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/sysroot-providers/am335x-pru-support tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/lib tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/lib/libprussdrv.so.0 tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/lib/libprussdrv.so.0.0 tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/include tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/include/pruss tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/include/pruss/pruss_intc_mapping.h tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/include/pruss/prussdrv.h gthomas@europa:p8701_2016-10-22$ find tmp/sysroots-components/x86_64/am335x-pru-support-native/ tmp/sysroots-components/x86_64/am335x-pru-support-native/ tmp/sysroots-components/x86_64/am335x-pru-support-native/sysroot-providers tmp/sysroots-components/x86_64/am335x-pru-support-native/sysroot-providers/am335x-pru-support-native tmp/sysroots-components/x86_64/am335x-pru-support-native/usr tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/lib tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/lib/libprussdrv.so.0 tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/lib/libprussdrv.so.0.0 tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/include tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/include/pruss tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/include/pruss/pruss_intc_mapping.h tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/include/pruss/prussdrv.h tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/bin tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/bin/pasm The question becomes how to make use of this in a separate recipe that wants to use both the 'pasm' tool, as well as the include files and library from the 'pruss' support. I tried to use DEPENDS="am335x-pru-support" as well as DEPENDS="am335x-pru-support-native" in my recipe, but the correct sysroot is never found (e.g. is not in my search path). Any help on how to proceed would be greatly appreciated. I'm happy to share the actual recipes if needed (I just left them out to avoid too much noise...) Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to gracefully disable a setscene task?
On 2017-02-11 02:24, Khem Raj wrote:
On Fri, Feb 10, 2017 at 3:05 PM, Xiaohui Liu <whu...@gmail.com> wrote:
Hi everyone,
I tried to disable a setscene task as below:
do_populate_lic_setscene () {
exit 1
}
you could use something like
deltask do_populate_lic_setscene
It works but shows a warning:
WARNING: Logfile for failed setscene task is
/data/users/xhliu/poky/build-arm/tmp/work/armada39x-poky-linux-gnueabi/linux-terragraph/4.4.8-r0/temp/log.do_populate_lic_setscene.2825388
WARNING: Setscene task 1
(/data/users/xhliu/poky/meta-terragraph/recipes-kernel/linux/linux-terragraph_4.4.8.bb,
do_populate_lic_setscene) failed with exit code '1' - real task will be run
instead
Any way to disable it without the warning? Thanks in advance.
Why would you want to do this?
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trimming images
On 2017-02-09 15:33, Gary Thomas wrote:
On 2017-02-09 15:21, Burton, Ross wrote:
On 9 February 2017 at 13:53, Gary Thomas <g...@mlbassoc.com
<mailto:g...@mlbassoc.com>> wrote:
This used to work - what am I doing wrong now?
usbutils depends on hwdb as it's mostly useless without it. Maybe this is the
cause?
I'm sure it is (and it's a recent change, 2017-02-02, while I was on holiday)
Is there some way to disable this, certainly in a case where I
don't care about the device database?
I can see in the usbutils recipe
RDEPENDS_${PN} = "udev-hwdb"
If I have this, shouldn't that override it? or maybe it's because
the actual package is eudev-hwdb and not udev-hwdb?
BAD_RECOMMENDATIONS = " eudev-hwdb"
Is there some other way I can tell the build system I don't need/want
that package?
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trimming images
On 2017-02-09 15:35, Burton, Ross wrote: On 9 February 2017 at 14:33, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: usbutils depends on hwdb as it's mostly useless without it. Maybe this is the cause? I'm sure it is (and it's a recent change, 2017-02-02, while I was on holiday) Is there some way to disable this, certainly in a case where I don't care about the device database? Two options: 1) don't install usbutils 2) send a patch to change the depends to a recommends Yes, that worked - patch to come soon. Is it possible to make this "image" specific? I have some ramdisk based images as well as full fledged "disk" images and I really only care about the size issues for the ramdisk ones. Is there a way to say "for my ramdisk image, leave this out, for everything else, it's OK"? -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trimming images
On 2017-02-09 15:21, Burton, Ross wrote: On 9 February 2017 at 13:53, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: This used to work - what am I doing wrong now? usbutils depends on hwdb as it's mostly useless without it. Maybe this is the cause? I'm sure it is (and it's a recent change, 2017-02-02, while I was on holiday) Is there some way to disable this, certainly in a case where I don't care about the device database? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trimming images
I just upgraded to the latest Yocto master and now this doesn't seem to have any effect: BAD_RECOMMENDATIONS = "eudev-hwdb" I still end up with eudev-hwdb in my image (a wasted 6+MB in my tiny ramdisk!) This used to work - what am I doing wrong now? Thanks for any pointers -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/9] Add raspberrypi3-64.conf
On 2017-02-09 06:48, Khem Raj wrote:
From: Herve Jourdain <herve.jourd...@neuf.fr>
Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
conf/machine/raspberrypi3-64.conf | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 conf/machine/raspberrypi3-64.conf
diff --git a/conf/machine/raspberrypi3-64.conf
b/conf/machine/raspberrypi3-64.conf
new file mode 100644
index 000..5598e50
--- /dev/null
+++ b/conf/machine/raspberrypi3-64.conf
@@ -0,0 +1,15 @@
+#@TYPE: Machine
+#@NAME: RaspberryPi 3 Development Board
+#@DESCRIPTION: Machine configuration for the RaspberryPi 3 in 64 bits mode
+
+MACHINEOVERRIDES = "raspberrypi3:raspberrypi:${MACHINE}"
+
+MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-bcm43430"
+
+require conf/machine/include/arm/arch-armv8.inc
+include conf/machine/include/rpi-base.inc
+
+SERIAL_CONSOLE = "115200 ttyS0"
+VC4_CMA_SIZE ?= "cma-256"
+
+UBOOT_MACHINE = "rpi_3_config"
I know it's 2017, but what are the real advantages of rpi3-64 over rpi3?
Should I care (or use it)?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot question
On 2017-02-09 08:49, Anders Darander wrote: * Gary Thomas <g...@mlbassoc.com> [170209 05:25]: On 2017-02-08 20:36, Paul Eggleton wrote: I think the problem is that the task that prepares the sysroot (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass uses this: addtask make_scripts after do_prepare_recipe_sysroot before do_compile BTW you say you patterned your recipe after the skeleton example, except hello-mod at least currently inherits module rather than module-base + kernel- module-split - is there a compelling reason not to inherit module? I may have been mistaken about the original source - it looks like I used a similar module strategy from meta-freescale. I did [just now] try using "inherit module" and the build dies a horrible death with this error | make: *** No rule to make target 'modules_install'. Stop. Well, that is simple to solve. module.bbclasses sets MODULES_INSTALL_TARGET ?= "modules_install" just override that with your own install target. (Or fix the module's Makefile). The last option is to simply override do_install in your recipe. I already override do_install(), so that's not enough. I changed my [task] dependencies to match what you've quoted and everything works as before. !Thanks! I'd still recommend doing as little as possible in each recipe, and leverage the standard modules. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot question
On 2017-02-08 20:36, Paul Eggleton wrote:
Hi Gary,
On Wednesday, 8 February 2017 12:12:25 PM NZDT Gary Thomas wrote:
On 2017-02-08 11:42, Gary Thomas wrote:
I had a recipe that used to work and now fails after the change
to the split sysroots. I'm building an out-of-tree kernel module
and patterned my recipe after the meta-skeleton example. My recipe
has this setup:
inherit module-base kernel-module-split
do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
KERNEL_VERSION=${KERNEL_VERSION}\
CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
AR="${KERNEL_AR}" \
O=${STAGING_KERNEL_BUILDDIR} \
install
}
The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
found. I know it's available, just not sure what needs to change to be
able to find it.
$ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr
oot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi
/5.4.0/arm-amltd-linux-gnueabi-gcc
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr
oot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc
It looks like the failure is actually happening in a class method
(make_scripts) My recipe also contains this
addtask make_scripts after do_patch before do_compile
which doesn't seem to be setting the ${PATH} correctly anymore.
Any ideas what might be missing?
Note: just moving the call to do_make_scripts to the top of do_compile
instead of running it as a separate task fixes the problem.
I think the problem is that the task that prepares the sysroot
(do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass
uses this:
addtask make_scripts after do_prepare_recipe_sysroot before do_compile
BTW you say you patterned your recipe after the skeleton example, except
hello-mod at least currently inherits module rather than module-base + kernel-
module-split - is there a compelling reason not to inherit module?
I may have been mistaken about the original source - it looks like I
used a similar module strategy from meta-freescale. I did [just now]
try using "inherit module" and the build dies a horrible death with
this error
| make: *** No rule to make target 'modules_install'. Stop.
I changed my [task] dependencies to match what you've quoted and everything
works as before. !Thanks!
--
--------
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-raspberrypi issue
On 2017-02-01 18:24, Khem Raj wrote:
On 2/1/17 8:08 AM, Usman Haider wrote:
Hi,
I am new to yocto and just started working on it. I am having issue
with meta-raspberrypi. I did inside poky
$ git checkout -b work_branch -t origin/daisy
$ git clone git://git.yoctoproject.org/meta-raspberrypi
<http://git.yoctoproject.org/meta-raspberrypi>
you need to checkout daisy branch of meta-raspberrypi as well.
That said, daisy is REALLY OLD. You'd probably be much better off with
something recent, e.g. morty.
$ source oe-init-build-env rpi-build
updated the local.conf and bblayer.conf files inside rpi-build
In local.conf
BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
MACHINE ?= "raspberrypi"
In bblayer.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
/home/vm/poky/meta \
/home/vm/poky/meta-yocto \
/home/vm/poky/meta-yocto-bsp \
/home/vm/poky/meta-raspberrypi \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/vm/poky/meta \
/home/vm/poky/meta-yocto \
"
When I run bitbake rpi-basic-image, I get following
*
vm@sdr-vm:~/poky/rpi-build$ bitbake rpi-basic-image
WARNING: Host distribution "Ubuntu-16.04" has not been validated with
this version of the build system; you may possibly experience unexpected
failures. It is recommended that you use a tested distribution.
Parsing recipes: 100% |#| Time:
00:02:37
Parsing of 882 .bb files complete (0 cached, 882 parsed). 1241 targets,
63 skipped, 0 masked, 0 errors.
ERROR: No recipes available for:
/home/vm/poky/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10%.bbappend
/home/vm/poky/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.2.0.bbappend
ERROR: Command execution failed: Exited with 1
*
What could be the issue?
--
Usman
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a list somewhere of OE/YP-supported system perf/monitoring tools?
On 2017-02-08 07:48, Maciej Borzęcki wrote: On Tue, Feb 7, 2017 at 3:31 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote: colleague asked me for a list of OE/YP recipes for monitoring system performance/resource utilization/profiling, i'm unaware of any single list that tracks that sort of thing so i'll just ask what people are aware of. just off the top of my head: * sysstat * atop * collectd * netdata * rrdtool * dstat * pcp http://pcp.io/ There is also bootchart (and friends) to gather information about system startup and initialization. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot question
On 2017-02-08 11:42, Gary Thomas wrote:
I had a recipe that used to work and now fails after the change
to the split sysroots. I'm building an out-of-tree kernel module
and patterned my recipe after the meta-skeleton example. My recipe
has this setup:
inherit module-base kernel-module-split
do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
KERNEL_VERSION=${KERNEL_VERSION}\
CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
AR="${KERNEL_AR}" \
O=${STAGING_KERNEL_BUILDDIR} \
install
}
The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
found. I know it's available, just not sure what needs to change to be
able to find it.
$ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-gcc
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc
Any suggestions on how I fix this?
Thanks
It looks like the failure is actually happening in a class method (make_scripts)
My recipe also contains this
addtask make_scripts after do_patch before do_compile
which doesn't seem to be setting the ${PATH} correctly anymore.
Any ideas what might be missing?
Note: just moving the call to do_make_scripts to the top of do_compile
instead of running it as a separate task fixes the problem.
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] sysroot question
I had a recipe that used to work and now fails after the change
to the split sysroots. I'm building an out-of-tree kernel module
and patterned my recipe after the meta-skeleton example. My recipe
has this setup:
inherit module-base kernel-module-split
do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
KERNEL_VERSION=${KERNEL_VERSION}\
CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
AR="${KERNEL_AR}" \
O=${STAGING_KERNEL_BUILDDIR} \
install
}
The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
found. I know it's available, just not sure what needs to change to be
able to find it.
$ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-gcc
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc
Any suggestions on how I fix this?
Thanks
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] esdk without using Poky?
On 2017-01-04 14:25, Gary Thomas wrote: On 2017-01-04 13:54, Patrick Ohly wrote: On Wed, 2017-01-04 at 12:05 +0100, Gary Thomas wrote: On 2016-11-04 04:41, Paul Eggleton wrote: On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote: I've tested your patches for this (from the OE-core mailing list) and I can now build and use the eSDK for my board :-) Great! I do have a couple observations/questions: * I added my missing tool with this line in my local.conf TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru" Why did this cause many of the nativesdk tools to have to be rebuilt? So just FYI this will only work for the standard SDK, it's not the right way to add these tools for the eSDK - in fact it may break the eSDK due to bringing things into the native sysroot that shouldn't be there. At the moment I think the only way to properly add this to the eSDK is to do this: SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot" We don't document this, and it's a little awkward in any case. I'll work on it. This was working great for me until I just upgraded to the latest [poky] master (rev dbb247cac5fbf7b037e4955f9793828451723924). With the SDK_TARGETS line in my local.conf, I get this error: ERROR: Error for /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magicard-demo-image_1.0.bb, dependency ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot ^^^ does not contain exactly one ':' character. Task 'rdepends' should be specified in the form 'packagename:task' Any ideas what changed and how I get it working again? I enhanced the error checking, and the rdepends varflag in your example indeed isn't valid. ":do_populate_sysroot" got appended twice to the recipe name. That error got ignored silently earlier. populate_sdk_ext.bbclass appends ":do_populate_sysroot" when setting do_sdk_depends[rdepends], so you should use just: SDK_TARGETS += "ti-cgt-pru-native" Thanks that worked - at least I can build, I haven't checked the esdk yet. Sadly, this is broken once again. I just upgraded my Poky/Yocto to rev d45d4a5a21ab4209b87331dddf515ecdb62367fa and if I have the SDK_TARGETS += "ti-cgt-pru-native" in my local.conf, I get this hard error: ERROR: Task do_sdk_depends in /home/gary/tmp/p8701_2017-01-31/opt/amltd/poky/meta-rainier-am335x-p8701/packages/images/installer-image.bb rdepends upon non-existent task do_package_write_ipk in virtual:native:/home/gary/tmp/p8701_2017-01-31/opt/amltd/poky/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb ERROR: Command execution failed: 1 Any ideas how to proceed? Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] More new messages
Seems updating to the latest master has brought a lot of new messages. I'm seeing lots like these: WARNING: libsndfile1-1.0.27-r0 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_install: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_install: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_populate_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_populate_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: pulseaudio-9.0-r0 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_install: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: sbc-1.3-r0 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_package: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libsamplerate0-0.1.9-r1 do_populate_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? WARNING: libass-0.13.2-r0 do_configure: QA Issue: libass: configure was passed unrecognised options: --enable-enca [unknown-configure-option] WARNING: imx-alsa-plugins-1.0.26-r0 do_prepare_recipe_sysroot: Manifest /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot not found? Any ideas? Perhaps this has something to do with having a very old (constantly updated, never removed since 2016-01-13) sstate-cache? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Strange bitbake error
On 2017-01-25 07:50, Gary Thomas wrote:
For the last couple of days, I've been seeing my bitbake builds
just shutdown, without actually completing, like this:
Initialising tasks: 100%
|###| Time:
0:00:10
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
WARNING: /local/poky-cutting-edge/bitbake/lib/bb/runqueue.py:1159:
ResourceWarning: unclosed file <_io.BufferedWriter
name=31>
self.worker = {}
This happened after completing ~650 out of 5786 tasks.
If I rerun the build it will likely complete without any more errors.
Any clues what might be happening? Is there any information (logs, etc)
that might help me understand?
BTW I'm using the latest Poky (62d7d4130202d8ede16abf9e7d779361ca70847e)
updated just a few hours ago.
Sorry for the noise - it looks like my system was out of memory
and the bitbake processes were being killed by the kernel oom :-(
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Strange bitbake error
For the last couple of days, I've been seeing my bitbake builds
just shutdown, without actually completing, like this:
Initialising tasks: 100%
|###| Time:
0:00:10
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
WARNING: /local/poky-cutting-edge/bitbake/lib/bb/runqueue.py:1159: ResourceWarning: unclosed file <_io.BufferedWriter
name=31>
self.worker = {}
This happened after completing ~650 out of 5786 tasks.
If I rerun the build it will likely complete without any more errors.
Any clues what might be happening? Is there any information (logs, etc)
that might help me understand?
BTW I'm using the latest Poky (62d7d4130202d8ede16abf9e7d779361ca70847e)
updated just a few hours ago.
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 2017-01-20 14:05, Kristian Amlie wrote: On 18/01/17 12:28, Burton, Ross wrote: On 18 January 2017 at 09:51, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> wrote: How would one change the recipe to reflect that? Is there an override that effectively says "not -native"? do_install_class-target. This is exactly the annoyance I've hit as well. Did you have any success with this? I can probably give it a spin as well if you want me to. I have a patch that I'll post tomorrow -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] WiFi on rpi3?
On 2017-01-20 12:30, Gary Thomas wrote: Can someone give me pointers to get the onboard WiFi on the RaspberryPi3 going? What kernel settings/hoops I need to do, what packages I might need, etc? Thanks Actually, I've found that with an older kernel (4.1.21) the WiFi device is discovered, but with the newer kernels (4.4.x and 4.9.x) it's not. Any clues? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] WiFi on rpi3?
Can someone give me pointers to get the onboard WiFi on the RaspberryPi3 going? What kernel settings/hoops I need to do, what packages I might need, etc? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/7] introduce rockchip offical linux support to meta-rockchip
On 2017-01-19 12:30, Burton, Ross wrote: (CCing the layer maintainers as listed in the README to ensure this gets noticed) Shouldn't this have [meta-rockchip] (or some such) in the subject? - it's certainly not OE-core or even Poky AFAICT On 19 January 2017 at 10:09, Jacob Chen <jacob-c...@iotwrt.com <mailto:jacob-c...@iotwrt.com>> wrote: This series of patches add below features, will add more supports in the future(medias, more chips). 1. rockchip 4.4 kernel Rockchip 4.4 kernel is currently the latest version of the rockchip offical kernel, will be an upstream tracking branch. We regularly release the kernel through github. It support all rockchip 64-bit chips and a few 32-bit chips. 2. rockchip next-dev U-boot Rockchip next-dev U-boot is the next generation of rockchip u-boot, will also be an upstream tracking branch. At present, this branch is just a rebased upstream u-boot. 3. graphics We have plans for the acceleration in wayland, x11 in the rockchip platform, but in this series of patches, we only include the mali bianry support. 4. rockchip-next-image Being different from the previous rk-u-boot which use parameter, next-dev u-boot use gpt partition, so it needs to generate a different image. Jacob Chen (7): recipes-kernel: linux-rockchip: Add new recipe for 4.4 machine: Add machine file for the rk3288 linux Boards machine: firefly: use linux-rockchip by default recipes-graphics: Add support for mali-userspace recipes-bsp: add u-boot-rockchip support rk3288.inc: add some variables rockchip-next-image: introduce image for rockchip next-dev u-boot classes/rockchip-next-image.bbclass| 130 + conf/machine/evb-rk3288.conf | 12 ++ conf/machine/fennec-rk3288.conf| 12 ++ conf/machine/firefly-rk3288.conf | 4 + conf/machine/include/rk-linux.inc | 20 conf/machine/include/rk3288.inc| 10 +- conf/machine/tinker-rk3288.conf| 13 +++ recipes-bsp/u-boot/u-boot-rockchip_next.bb <http://u-boot-rockchip_next.bb> | 17 +++ recipes-graphics/mali-userspace/mali-userspace.inc | 57 + .../mali-userspace/mali-userspace_t76x.bb <http://mali-userspace_t76x.bb> | 18 +++ recipes-graphics/mesa/mesa_%.bbappend | 9 ++ recipes-kernel/linux/linux-rockchip_4.4.bb <http://linux-rockchip_4.4.bb> | 20 12 files changed, 321 insertions(+), 1 deletion(-) create mode 100644 classes/rockchip-next-image.bbclass create mode 100644 conf/machine/evb-rk3288.conf create mode 100644 conf/machine/fennec-rk3288.conf create mode 100644 conf/machine/include/rk-linux.inc create mode 100644 conf/machine/tinker-rk3288.conf create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_next.bb <http://u-boot-rockchip_next.bb> create mode 100644 recipes-graphics/mali-userspace/mali-userspace.inc create mode 100644 recipes-graphics/mali-userspace/mali-userspace_t76x.bb <http://mali-userspace_t76x.bb> create mode 100644 recipes-graphics/mesa/mesa_%.bbappend create mode 100644 recipes-kernel/linux/linux-rockchip_4.4.bb <http://linux-rockchip_4.4.bb> -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 2017-01-18 10:35, Burton, Ross wrote:
On 18 January 2017 at 09:13, Gary Thomas <g...@mlbassoc.com
<mailto:g...@mlbassoc.com>> wrote:
* glib-2.0-native depends on ${DISTRO_FEATURES}
To me this seems silly as "native" should be "native" and
not depend on any distribution settings. Here's the code
that's causing it (in do_install)
if [ -f
${D}${datadir}/installed-tests/glib/gdbus-serialization.test ]; then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false",
"true", d)}; then
rm
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
Obviously this isn't important for a native package. Any
suggestions on how I might keep this from creeping in?
The tests are only installed for target builds anyway, so that do_install part
could be target-specific.
How would one change the recipe to reflect that? Is there an
override that effectively says "not -native"?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache and native recipes
On 2017-01-18 10:13, Gary Thomas wrote:
I've been trying to understand (as was recently posted here by
another user) why native recipes are not being well shared/reused
by the sstate-cache mechanism. I have a build machine where I
do lots of builds for various targets. I would think (hope!)
that xxx-native packages would be the same for every build and
if I have the sstate mirror set up correctly, be shared appropriately.
To this end, I have one "master" build that I always run first
whenever the metadata changes, then point all the other builds
at that tree.
For the most part, this works pretty well, but there are still
some places where it doesn't. Here are a couple of examples
which I've investigated:
* glib-2.0-native depends on ${DISTRO_FEATURES}
To me this seems silly as "native" should be "native" and
not depend on any distribution settings. Here's the code
that's causing it (in do_install)
if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ];
then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false",
"true", d)}; then
rm
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
Obviously this isn't important for a native package. Any
suggestions on how I might keep this from creeping in?
BTW, once glib-2.0-native can't be shared, a number of other native
packages will also have to be rebuilt because of build dependencies.
I discovered this when qemu-native was being rebuilt on almost all
of my targets...
* xxx-native packages are not shared if ${DISTRO} is different.
Again, this seems wrong as "native" packages should really only
depend on the build ${HOST}, not ${DISTRO}
I'm looking at this for the sole purpose of reducing the load on my
build machine. Any package that can be shared and not have to be
rebuilt just makes it more productive :-)
Thanks for any ideas or comments
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate-cache and native recipes
I've been trying to understand (as was recently posted here by
another user) why native recipes are not being well shared/reused
by the sstate-cache mechanism. I have a build machine where I
do lots of builds for various targets. I would think (hope!)
that xxx-native packages would be the same for every build and
if I have the sstate mirror set up correctly, be shared appropriately.
To this end, I have one "master" build that I always run first
whenever the metadata changes, then point all the other builds
at that tree.
For the most part, this works pretty well, but there are still
some places where it doesn't. Here are a couple of examples
which I've investigated:
* glib-2.0-native depends on ${DISTRO_FEATURES}
To me this seems silly as "native" should be "native" and
not depend on any distribution settings. Here's the code
that's causing it (in do_install)
if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ];
then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false",
"true", d)}; then
rm
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
Obviously this isn't important for a native package. Any
suggestions on how I might keep this from creeping in?
* xxx-native packages are not shared if ${DISTRO} is different.
Again, this seems wrong as "native" packages should really only
depend on the build ${HOST}, not ${DISTRO}
I'm looking at this for the sole purpose of reducing the load on my
build machine. Any package that can be shared and not have to be
rebuilt just makes it more productive :-)
Thanks for any ideas or comments
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] x86 testing
I'm trying to track down some recent changes in the X server (using the latest Poky/Yocto master). I've had failures on a number of the embedded targets I work with, so I thought I'd give it a go on platforms with a larger base - x86 machines. It used to be that I could run qemu and it would pop up a separate window that emulated a display+keyboard+mouse. That doesn't seem to be the same now, or at least I don't see how to make it work. Advice on this would be great as I need to test the "native" X setup, not VNC connections. I'd also be happy to try this on real hardware, e.g. my wife's laptop, but I need some way to do that non-destructively. Again, pointers would be greatly appreciated. Once I get this figured out, I'll disappear back down my embedded rabbit hole... Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change toochains to gcc 4.9.3
On 2017-01-17 11:41, Richard Zhang wrote: Hi when I want to change gcc version to 4.9.3. I just change gcc & libgcc,but gcc-truntime still 5.3. Is there a rapid method to change everything I need? Of course you'll need the correct recipes, but just add these lines to local.conf: GCCVERSION ?= "4.9.%" SDKGCCVERSION ?= "4.9.%" -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
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): linux-raspberrypi: Drop v4.7 linux-raspberrypi: Drop v4.8 .../0001-fix-dtbo-rules.patch | 44 -- recipes-kernel/linux/linux-raspberrypi_4.7.bb | 9 - recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 3 files changed, 61 deletions(-) delete mode 100644 recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb +1 at least for 4.7 given that with today's repo I get this: ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Package Version (4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built (4.7.10). Please update the PV variable to match the kernel source. ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Function failed: do_kernel_version_sanity_check (log file is located at /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925) ERROR: Logfile of failure stored in: /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925 ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.7.bb:do_kernel_version_sanity_check) failed with exit code '1' However, there is this error when I tried to switch to 4.9: ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Fetcher failure: Unable to find revision 4052b0da7dbab0df22ca8733cf50b3e573e221e0 in branch rpi-4.9.y even from upstream ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Fetcher failure for URL: 'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y'. Unable to fetch URL from any source. ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.9.2+gitAUTOINC+4052b0da7d-r0/temp/log.do_fetch.13098 ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_fetch) failed with exit code '1' Using meta-raspberrypi:e1f69daa805cb02ddd123ae2d4d48035cb5b41d0 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
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 linux-raspberrypi: Drop v4.8 .../0001-fix-dtbo-rules.patch | 44 -- recipes-kernel/linux/linux-raspberrypi_4.7.bb | 9 - recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 3 files changed, 61 deletions(-) delete mode 100644 recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb +1 at least for 4.7 given that with today's repo I get this: ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Package Version (4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built (4.7.10). Please update the PV variable to match the kernel source. ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Function failed: do_kernel_version_sanity_check (log file is located at /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925) ERROR: Logfile of failure stored in: /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_check.27925 ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.7.bb:do_kernel_version_sanity_check) failed with exit code '1' -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Debugging question
On 2017-01-16 11:40, Burton, Ross wrote: On 16 January 2017 at 04:29, Gary Thomas <g...@mlbassoc.com <mailto:g...@mlbassoc.com>> 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" xserver-xorg.inc:PACKAGECONFIG[openssl] = "--with-sha1=libcrypto,,openssl" The X server took the reasonable approach of refusing to reimplement cryptographic functions and instead relies on an external library, of which openssl (well, libcrypto, part of openssl) is one option. Thanks, I missed that. That said, this wasn't really related to the problem anyway. libcrypt causes that illegal instruction - on purpose - to check for certain hardware capabilities and handles it. Just running 'continue' in GDB lets the X server get a lot further. I was able to isolate the problem down to a data structure being trashed. I'm not sure yet how/why, but I think there may have been some important changes that the i.MX6 Vivante hardware driver isn't currently up to speed on. Still investigating. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[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 which is the hardware driver for the i.MX6Q display (VPU/GPU) has none :-( Any ideas why the difference and more importantly, how I might arrange to get the sources for xf86-video-imxfb-vivante? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate pruning
Any constructive ideas for cleaning out a ver long standing sstate cache? I have one build tree that is now approaching a year old (I do builds there all the time, sometimes many times per day). The sstate-cache is HUGE. Any ideas on how I can purge/cleanup? Note: 'atime' is probably not useful as I have copied the whole thing a few times... $ du -s /build/p0382_2016-01-13/sstate-cache/ 186576060 /build/p0382_2016-01-13/sstate-cache/ Thanks for any input -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Confusing error
On 2017-01-12 11:19, Gary Thomas wrote: Lately I've been seeing errors like these: ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. WARNING: u-boot-fw-utils-2011.06-r1 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_printenv' No GNU_HASH in the elf binary: '/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_setenv' [ldflags] Sorry, ignore this error (overly ambitious cut). My question for this thread it just about the metadata errors... ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. I'm not sure what triggers these errors - I do have more than one bitbake build running (separate directories). I have a local copy of the metadata and it was not touched during these builds. I'm using Poky/Yocto rev 840e221ea7c35177fda37af618c4727fa7754789 but I've seen them for a couple of months now. Ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Confusing error
Lately I've been seeing errors like these: ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. WARNING: u-boot-fw-utils-2011.06-r1 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_printenv' No GNU_HASH in the elf binary: '/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_setenv' [ldflags] ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not deterministic and this needs to be fixed. I'm not sure what triggers these errors - I do have more than one bitbake build running (separate directories). I have a local copy of the metadata and it was not touched during these builds. I'm using Poky/Yocto rev 840e221ea7c35177fda37af618c4727fa7754789 but I've seen them for a couple of months now. Ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] esdk without using Poky?
On 2016-11-04 04:41, Paul Eggleton wrote: On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote: I've tested your patches for this (from the OE-core mailing list) and I can now build and use the eSDK for my board :-) Great! I do have a couple observations/questions: * I added my missing tool with this line in my local.conf TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru" Why did this cause many of the nativesdk tools to have to be rebuilt? So just FYI this will only work for the standard SDK, it's not the right way to add these tools for the eSDK - in fact it may break the eSDK due to bringing things into the native sysroot that shouldn't be there. At the moment I think the only way to properly add this to the eSDK is to do this: SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot" We don't document this, and it's a little awkward in any case. I'll work on it. This was working great for me until I just upgraded to the latest [poky] master (rev dbb247cac5fbf7b037e4955f9793828451723924). With the SDK_TARGETS line in my local.conf, I get this error: ERROR: Error for /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magicard-demo-image_1.0.bb, dependency ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot does not contain exactly one ':' character. Task 'rdepends' should be specified in the form 'packagename:task' Any ideas what changed and how I get it working again? Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error during webkit compilation for rasberry pi3
On 2016-12-11 16:49, Mont3z Claros wrote: Hi Khem, this layer is: https://layers.openembedded.org/layerindex/branch/master/layer/meta-webkit/ I've also tried to use the webkit recipe from poky but I've got the same error. In this case I used a different configuration because poky doesn't have webkitgtk-bin (mini browser). To test that I've tried to build a modified version of meta-web-kiosk (https://github.com/mont3z/meta-web-kiosk). This is still a work in progress but basically it replaces midori by epiphany. local.conf: MACHINE = "raspberrypi3" DISTRO_FEATURES_append = " x11 gles2" command: bitbake core-image-web-kiosk bblayes.conf: BBLAYERS ?= " \ /home/mont3z/yocto/poky/meta \ /home/mont3z/yocto/poky/meta-poky \ /home/mont3z/yocto/poky/meta-yocto-bsp \ /home/mont3z/yocto/meta-openembedded/meta-oe \ /home/mont3z/yocto/meta-raspberrypi \ /home/mont3z/yocto/meta-web-kiosk \ " I also found this discussion about rpi2. I'll try to run some of those configurations: https://github.com/Igalia/meta-webkit/issues/1 I built webkit for rpi3 just fine (yesterday 2016-12-11) using just poky: e38775a1d82e6dc60fc96cf243ecb94be964d9b2 meta-raspberrypi: 44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9 these were the current master as of then. What version(s) are you trying to use? On Sat, Dec 10, 2016 at 1:02 PM, Khem Raj <raj.k...@gmail.com> wrote: On Sat, Dec 10, 2016 at 7:52 AM, Mont3z Claros <mont3z.cla...@gmail.com> wrote: Hi all, I don't know what I'm doing wrong but I'm getting an error during compilation of webkit for raspberry pi3. Please see below the error and my configurations, Thanks, Mont3z local.conf: MACHINE = "raspberrypi3" DISTRO_FEATURES_append = " x11 gles2" IMAGE_INSTALL_append = " webkitgtk-bin" Error: | ERROR: oe_runmake failed | In file included from /home/mont3z/yocto/poky/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/webkitgtk/2.14.2-r0/webkitgtk-2.14.2/Source/WebCore/platform/graphics/cairo/GraphicsContext3DCairo.cpp:51:0: | /home/mont3z/yocto/poky/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/webkitgtk/2.14.2-r0/webkitgtk-2.14.2/Source/WebCore/platform/graphics/opengl/Extensions3DOpenGLES.h:109:5: error: 'PFNGLFRAMEBUFFERTEXTURE2DMULTISAMPLEIMGPROC' does not name a type | PFNGLFRAMEBUFFERTEXTURE2DMULTISAMPLEIMGPROC m_glFramebufferTexture2DMultisampleIMG; | ^~~ command: bitbake core-image-sato bblayes.conf: BBLAYERS ?= " \ /home/mont3z/yocto/poky/meta \ /home/mont3z/yocto/poky/meta-poky \ /home/mont3z/yocto/poky/meta-yocto-bsp \ /home/mont3z/yocto/meta-openembedded/meta-oe \ /home/mont3z/yocto/meta-webkit \ what does this layer do ? /home/mont3z/yocto/meta-raspberrypi \ " -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto project in raspberry pi 3
On 2016-12-07 11:15, Rushin Thakkar wrote: hello there i am trying to do yocto project on raspberry pi 3. when i run bitbake rpi-basic-image. this task 0: bcm2835-bootfiles-20151021-r3 do_fetch (pid 4922) is taking too much time. after that You should use latest master where we have switched to tarball fetch especially http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=716b6a9cd7f24a8bacd539bb40519d185e3f963a i am getting message like ERROR: Fetcher failure: Fetch command failed with exit code 128, output: Cloning into bare repository '/home/rushin/yoctopi/poky/build/downloads/git2/github.com.raspberrypi.firmware.git'... fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed ERROR: Function failed: Fetcher failure for URL: 'git://github.com/raspberrypi/firmware.git;protocol=git;branch=master'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /home/rushin/yoctopi/poky/build/tmp/work/raspberrypi2-poky-linux-gnueabi/bcm2835-bootfiles/20151021-r3/temp/log.do_fetch.3385 ERROR: Task 207 (/home/rushin/yoctopi/poky/meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb, do_fetch) failed with exit code '1' can you tell me how to download this file manually?? Doing it manually will take just as long and end up downloading 6GB+ of [mostly useless] data. You really need to update to the latest version of this recipe which no longer uses GIT to fetch the files (replaced by much smaller TAR files) like in download folder there is file called wpa_supplicant-2.4.tar.gz . i can download this file. but how to get these files like wpa_supplicant-2.4.tar.gz.done,wpa_supplicant.sh.done?? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ***SPAM*** Re: [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland
On 2016-12-06 19:22, Herve Jourdain wrote: Hi Gary, Could you try a local to your layer gstreamer1.0-plugins-bad_%.bbappend, that would contain: PACKAGECONFIG_remove_rpi = " dispmanx" And see if it solves your problem? Yes, it does solve the problem, thanks. Although written this way and putting it in local.conf forced every package that uses PACKAGECONFIG to be rebuilt :-( Perhaps a softer approach might be: PACKAGECONFIG_remove_pn-gstreamer1.0-plugins-bad = "dispmax" Too bad though that this needs to be disabled to get X11 to work as it would seem to be very useful in a high-need graphic environment. I've never built for "vc-graphics-hardfp", as I'm not sure if there are benefits in using it over either using the userland or vc4, so I'm not sure whether it can work without dispmanx, nor why it would not compile with dispmanx enabled. But if this works, then we might need to consider to add an additional case for not enabling dispmanx. Cheers, Herve -----Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: mardi 6 décembre 2016 16:58 To: Andrei Gherzan <and...@gherzan.ro> Cc: Herve Jourdain <herve.jourd...@neuf.fr>; yocto@yoctoproject.org Subject: ***SPAM*** Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland On 2016-12-06 16:48, Andrei Gherzan wrote: On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote: On 2016-12-06 13:45, Herve Jourdain wrote: Hi Gary, But dispmanx is really only provided by userland, it does not exist in other flavors of egl/libgles. Actually, dispmanx should not be selected in PACKAGECONFIG if userland is not in use for EGL/GLES. Fine, but I'm looking for a solution where I can choose to use vc-graphics-hardfp so X11 works again and I can also have gst-player which depends on gstreamer-1.0-bad Any ideas? Disabling dispamanx is not working? How might I do that? It's not clear from [at least] that recipe. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland
On 2016-12-06 16:48, Andrei Gherzan wrote: On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote: On 2016-12-06 13:45, Herve Jourdain wrote: Hi Gary, But dispmanx is really only provided by userland, it does not exist in other flavors of egl/libgles. Actually, dispmanx should not be selected in PACKAGECONFIG if userland is not in use for EGL/GLES. Fine, but I'm looking for a solution where I can choose to use vc-graphics-hardfp so X11 works again and I can also have gst-player which depends on gstreamer-1.0-bad Any ideas? Disabling dispamanx is not working? How might I do that? It's not clear from [at least] that recipe. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
