Re: [yocto] bbappend extra SRC_URI ignored
On 14.06.2018 14:16, Damien LEFEVRE wrote:
HI,
I'm working on meta-tegra layer and I'd like to append a recipe. The
original recipe looks like this:
https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
<https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb>
I've made a tegra-tools_28.2.0.bbappend to change the default
PM_CONFIG DEFAULT from 2 to 3 to get max performance in nvpmodel.conf
configuration file.
```
FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "
It looks like a common mistake of mixing append / prepend with +=.
I do not know this recipe or machine, but i would try with changing this
line
to: `SRC_URI_tegra186 += "file://nvpmodel.conf "` first
do_install_append_tegra186() {
install -d ${D}${sysconfdir}
install -m 0755 ${B}/usr/sbin/nvpmodel ${D}${sbindir}/
install -m 0644 ${WORKDIR}/nvpmodel.conf
${D}${sysconfdir}/nvpmodel.conf
install -d ${D}${sysconfdir}/init.d
install -m 0644 ${S}/nvpmodel.init ${D}${sysconfdir}/init.d/nvpmodel
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${S}/nvpmodel.service ${D}${systemd_system_unitdir}
}
```
Would you have any idea why the nvpmodel.conf prepend is ignored and
the file never ends up in ${WORKDIR}.
I've made sure the paths are correct. nvpmodel.conf exists and if I
put a typo like nvpmodel.conf_blabla bitbake throws a warning that it
cannot find the file. So I'm sure the file is found but somehow
bitbake ignores it.
I'm having this issue with this one single recipe only, none of the
others in my build system so I'm a bit puzzled.
Thanks,
-Damien
--
Maciej Pijanowski
Embedded Systems Engineer
http://3mdeb.com | @3mdeb_com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] require/include recipe.bb
How about moving the common part which is supposed to get included into the `.inc` file? To be fair, I have not seen any case of `include` or `require` statement with a recipe (.bb) file rather than with the (`.inc`) file. Did you? On 22.08.2018 15:34, Tomasz Michalski wrote: Hi I have recipes: recipe_1.0.0.bb <http://recipe_1.0.0.bb> recipe_1.0.1.bb <http://recipe_1.0.1.bb> ... recipe_3.4.0.bb <http://recipe_3.4.0.bb> If in some meta-layer I want to write some bbappend file to the latest fresh version I create file recipe_%.bbappend. I have file otherRecipe.bb which is not versioned and inherit to auto_package_version. In definition of otherRecipe I have DESCRIPTION = "some description" SECTION = "nameOfSection" LICENSE = "CLOSED" require recipe_1.0.0.bb <http://recipe_1.0.0.bb> (or include recipe_1.0.0.bb <http://recipe_1.0.0.bb>) How to change the above formula in order include the latest fresh recipe instead of concrete version? Replacing with "include recipe_%.bb" doesn't work. -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Antwort: How to make changes and build u-boot source code in yocto
On 07/03/2017 08:49 AM, s.jar...@esa-grimma.de wrote: Hej ho my Workflow for adjusting uboot (u-boot-at91): 1.) build the original uboot 2.) apply changes 3.) create patch 3.1.) if you reconfigure it -> save/copy the config 3.2.) if you adding code -> use meld or something similar to create a patch 4.) create u-boot-at91_%.bbappend 4.1) copy patch/config into that recipe dir 4.2) check u-boot-at91_%.bbappend paths etc. 5.) rebuild I you mess to much around in /tmp/work*** you should use "-c clean"/"-c cleanall" to reset it regards Stefan ESA Elektroschaltanlagen Grimma GmbH Broner Ring 30 04668 Grimma Telefon: +49 3437 9211 181 Telefax: +49 3437 9211 26 E-Mail: s.jar...@esa-grimma.de Internet: www.esa-grimma.de Geschäftsführer: Dipl.-Ing. Jörg Gaitzsch Jörg Reinker Sitz der Gesellschaft: Grimma Ust.-ID: DE 141784437 Amtsgericht: Leipzig, HRB 5159 Steuernummer: 238/108/00755 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Von: Prasoon Kumar An: yocto@yoctoproject.org Datum: 03.07.2017 08:34 Betreff: [yocto] How to make changes and build u-boot source code in yocto Gesendet von: yocto-boun...@yoctoproject.org Hi, Hi Prasoon, I am trying to make some changes in u-boot code and using bitbake u-boot to build. But it doesn't build. I also tried bitbake u-boot -c compile and bitbake u-boot deploy. This also didn't work. Can I Get some help on how to change and build u-boot. You may also take a look at devtool [1] when you are in phase of trying something out. Creating patch and bbappend file is indeed proper and final solution, but in development phase can take up much more of your time. In fact, you could use devtool to create patches and append file as well. In short, devtool uses local source code to build from instead of fetching from mirror every time. To use it: 1. Following command will extract and patch git repo in specified path: devtool modify -x u-boot ~/projects/poky/build/u-boot-devtool 2. Make some changes in source code. 3. Rebuild given recipe: devtool build u-boot 4. You can add some commits inside `u-boot-devtool` directory and update recipe with: devtool update-recipe u-boot It will create patch from each commit and automatically add them to appropriate directory and recipe file. For example: NOTE: Adding new patch 0001-test.patch NOTE: Updating recipe u-boot_2016.03.bb 5. When work with temporary source directory is done, run: devtool reset u-boot Se attached link for more information [1] http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-devtool-in-your-workflow Thanks, Prasoon-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SD card image fails for IMX7
On 12.09.2017 09:30, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote: Hello, Hi, I am using Yocto based build system for my project. The Yocto version used in pyro.( BB_VERSION = "1.34.0"). I am trying to build an SD card image by setting the, IMAGE_FSTYPES = "sdcard" and also set the SDCARD_GENERATION_COMMAND = "generate_imx_sdcard" . I don't know what's the current state of sdcard generation bbclass. However, I can assure you that it is not the most comofrtable way of disk image generation. I would encourage you to switch to wic tool already instead (especially if you are using pyro revision). An example wks file for i.MX SoC family can be found at: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/scripts/lib/image/canned-wks/imx-uboot-spl.wks To enable it, you would need to add following lines to machine configuration file: WKS_FILES = "imx-uboot-spl.wks" IMAGE_DEPENDS_wic_append = " virtual/bootloader" IMAGE_FSTYPES = "wic" After trying to build the image , I am seeing the following error messages, | NOTE: libpthread-stubs-native exists in sysroot, skipping | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_image_sdcard | 0+0 records in | 0+0 records out | 0 bytes copied, 0.000164164 s, 0.0 kB/s | Model: (file) | Disk /home/evk1206/Projects/test/build/tmp/work/cl_som_imx7-fsl-linux-gnueabi/iot-eval-image/1.0-r0/deploy-iot-eval-image-image-complete/iot-eval-image-cl-som-imx7-20170912065601.rootfs.sdcard: 1057MB | Sector size (logical/physical): 512B/512B | Partition Table: msdos | Disk Flags: | | Number Start End Size Type File system Flags | 1 4194kB 12.6MB 8389kB primary lba | 2 12.6MB 1053MB 1040MB primary | | 846+0 records in | 846+0 records out | 433152 bytes (433 kB, 423 KiB) copied, 0.00094238 s, 460 MB/s | mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows | mkfs.fat 4.1 (2017-01-24) | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_image_sdcard (log file is located at /home/evk1206/Projects/test/build/tmp/work/cl_som_imx7-fsl-linux-gnueabi/iot-eval-image/1.0-r0/temp/log.do_image_sdcard.28053) ERROR: Task (/home/evk1206/Projects/test/sources/meta-alen/recipes-core/images/iot-eval-image.bb:do_image_sdcard) failed with exit code '1' NOTE: Tasks Summary: Attempted 3415 tasks of which 3407 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/evk1206/Projects/test/sources/meta-alen/recipes-core/images/iot-eval-image.bb:do_image_sdcard Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. May I know how to fix this issue. Mit freundlichen Grüßen / Best regards *Vinothkumar Eswaran BEG-PT/PJ-EL* -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to install dtb file to boot directory
On 13.01.2018 20:32, Mostafa Farzane wrote: I sucssesfully installed kernel to boot directory by comment out RDEPENDS_kernel-base="" line in local.conf. now i need to install dtb file to boot directory as well. I tried use do_install_append in my kernel recipe but no success. Any suggestion? I may suggest installing packages `kernel-image` and `kernel-devicetree` to install both kernel image and devicetree in rootfs. To do that you would need to add: IMAGE_INSTALL_append = " kernel-image kernel-devicetree" in your's image recipe or local.conf. Let me know if this is any help for you. -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Editor (viewer) for device tree *.dts file? (I mean syntax highlighting)
I'm just using vim for everything. It highlights dts syntax. On 17.01.2018 16:37, Jerry Lian wrote: Sorry that this question is not related to Yocto, but just wondering if anybody knows: * are there editors/viewers (with syntax highlighting) for device tree *.dts file? Thanks, Jerry -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I generate a dtb for my board support package?
On 25.01.2018 14:16, Peter Spierenburg wrote: | make[2]: *** No rule to make target `sc589-ezkit.dts'. Stop. You are building linux-yocto. You need to either add a patch to SRC_URI which adds this dtb target to linux source, or build from a different repository, where this support is already included. I would check from which linux tree they build kernel in buildroot BSP. You will also need proper kernel configuration file for your board. -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [wic] Fixed size partitions (--grow)
Hello, I have a question regarding wic. If this is not appropriate list to ask, then please point me to correct one. wic seems like a really simple and powerful tool. My intention was to create disk image with multiple partitions with fixed size. While the first part seems doable, the second does not. I have found a suggestion there [1] that recent wic may support --grow and --maxsize switches. As I found out, it does not (correct me if I'm mistaken). So the question is, how hard would it be to implement those options and what would be necessary to do so. Those are available in kickstart [2]. As far as I understand, wic is based on kickstart project. Do you think it is desired that wic would have the ability to produce fixed size partition based on yocto images? Maybe You have some experience with this issue or other workarounds to achievie similar goal. Thanks [1] https://community.nxp.com/thread/389816 [2] https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst#id36 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Add own dts file to arch/arm/boot/dts
On 04/25/2017 07:53 AM, Malte Thiel wrote: Good day, Hello, How can I add my own dts file to the arch/arm/boot/dts folder? Within my yocto installation the whole path for the dts files is: tmp/work/sm2_imx6-poky-linux-gnueabi/linux-yocto-custom/4.1.15-2/git/arch/arm/boot/dts As you can see it lies within the "tmp" folder. Hence, I do not want to copy it manually into this branch. I tried playing around with "appendsrcfiles" while creating an extra recipe "add-screen-dts": recipetool appendsrcfiles --destdir arch/arm/boot/dts ../../sources/meta-own add-screen-dts ../../sources/meta-own/recipes-own/images/sm2-imx6-133-1280x800-single-lvds-SCX1001255GGU17.dts However, I do not have any success here. Thanks for helping me out! I believe you should enter to linux source directory posted above and place your dts there. Then you should prepare patch (using git format-patch for example). This patch should be placed in your meta layer into linux/linux-yocto-custom directory. At last, add this patch to SRC_URI variable in form of: file://patch-name.patch into your linux-yocto-custom.bb recipe. At least that's the way I would do it. Let me know if it is not clear enough. -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Cannot load Gtk3: Could not lookup GType
Hello, I'm trying to port custom perl application from Debian into Yocto (morty). I'm stuck at testing Gtk3 perl module. It looks to me that all necessary components are already there. It looks to me that the issue is rather related to Gtk3 or it's dependencies, rather than perl and it's modules. What do you think? I'm certainly not a Gtk expert. Do you have any idea how could I further debug this? Any hints what could be the issue? ``` root@qemux86-64:~/Gtk3-0.009# perl Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for Gtk3 Writing MYMETA.yml and MYMETA.json root@qemux86-64:~/Gtk3-0.009# make cp lib/Gtk3.pm blib/lib/Gtk3.pm root@qemux86-64:~/Gtk3-0.009# make Skip blib/lib/Gtk3.pm (unchanged) root@qemux86-64:~/Gtk3-0.009# make test PERL_DL_NONLAZY=1 "/usr/bin/perl5.22.1" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00-init.t Bailout called. Further testing stopped: Cannot load Gtk3: Could not lookup GType from function gdk_rectangle_get_type at t/00-init.t line 9. FAILED--Further testing stopped: Cannot load Gtk3: Could not lookup GType from function gdk_rectangle_get_type at t/00-init.t line 9. make: *** [Makefile:814: test_dynamic] Error 255 ``` I'm running in qemu right now. My setup is: * Perl verion: This is perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-linux * Relevant libraries: libcairo-gobject.so.2.11400.6 libcairo.so.2.11400.6 libgtk-3.so.0 libatk-1.0.so.0.22009.1 libgobject-2.0.so.0.4902.0 libpangocairo-1.0.so.0.4000.1 libgdk-3.so.0.1800.5 libgdk_pixbuf-2.0.so.0.3200.3 * Relevant perl modules: Cairo/GObject.pm Cairo.pm Glib/Object/Introspection.pm Glib.pm Thanks for any feedback -- Maciej Pijanowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Intel Galleio Board SSH Minimal Poky Image
On 16.04.2019 17:36, nick wrote: Greetings, Hello, What is the minimal image from the poky yocto recipes that has ssh enabled by default or is it just better to enable it in the core minimal image on system startup. I would go with the core-image-minimal or the core-image-full-cmdline (depending on the requirements) and enable the ssh-server via IMAGE_FEATURES: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-features-image Typically, at the start of development, by adding the following line in build/conf/local.conf: IMAGE_FEATURES_append = " ssh-server-openssh" Thanks, Nick -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto System Requirement for developing OS
On 27.04.2019 05:29, Chuck Wolber wrote: It depends on a lot of factors. But for actually building yocto images... I find that 1.5 gigs of RAM per CPU seems to be about right on the virtual machines we use to build images. ..Ch:W.. On Fri, Apr 26, 2019 at 17:29 raja.g kumar <mailto:rajakuma...@hotmail.com>> wrote: Hi Can I know the RAM ,Disk space and processor requirement for developing the os with yocto for IoT ? I think the only hard requirement is the storage size. Also the memory, to some extend. The quickstart guide mentions 50GB of space requirement: https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html#brief-compatible-distro The reasonable minimum I would recommend today is 4 threads, 4 - 8 GB of memory and 100GB of storage. You of course need storage to store all the build artifacts and downloaded stuff. The memory may be a bottleneck when linking huge applications (webkit, web browsers). The CPU mostly impacts the build time. Please suggest and it would be greatly helpful. Regards Rajakumar G Get Outlook for Android <https://aka.ms/ghei36> -- ___ yocto mailing list yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto -- “I would challenge anyone here to think of a question upon which we once had a scientific answer, however inadequate, but for which now the best answer is a religious one." -Sam Harris -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NPM Fetcher question
On 21.05.2019 21:54, Alexander Kanavin wrote: > I think Jean-Marie might be able to help as he recently did a bit of NPM > fixing? > > > Alex > > On Tue, 21 May 2019 at 19:52, Scott Rifenbark wrote: >> Hi, >> >> I am trying to determine if the information in >> https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM is relevant and >> up-to-date for current YP release. I am having trouble finding a resource >> familiar with this topic. I was using the Registry Modules part quite recently to add a recipe for NPM package using the "devtool add". It was not perfect experience. I was having problems with not all of the cheksums being filled in the lockdown file properly. Also, one of the dependency packages was a native one (compilation required) which had further implications. I was going to report my experience - in a short blog post at the very lest, but failed to do so yet. Let me know if you need anything specific, maybe I could help. >> >> Can anyone point me to the expert for this area? >> >> Thanks, >> Scott Rifenbark (docs) >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
On 27.05.2019 19:32, Belisko Marek wrote: > Hi Enrico, Hi, > > On Mon, May 27, 2019 at 5:44 PM Enrico wrote: >> Hi, >> >> i try to keep it maintained, but now i just have a lime2 for testing >> on real hardware, and i don't have the resources to do test builds for >> all the supported boards. >> Your help would be welcome, i can't check right now if i have the >> rights to add you as co-maintainer, anyway i will add you. > Thanks I have few sunxi based boards so can do tests also on my setup. > Pls ping me when you will add me. Thanks. >> Thanks for the help! >> >> Enrico > Marek >> On Mon, May 27, 2019 at 4:50 PM Belisko Marek >> wrote: >>> Hello, >>> >>> I'm just curious if meta-sunxi is still maintained? I was contributed >>> to layer back while and when look now thud branch is un-compilable >>> (dri2proto not replaced) and warrior branch not created yet. There is >>> 14 issues + 6 pending pull requests. Added maintainers also in CC. I >>> think it would be good to have sunxi properly maintained as boards >>> with sunxi processors are popular. I can give a hand as co-maintainer >>> if necessary. Thanks a lot. I think I have some of the dirty code for integration of the recent Mali blobs with the mainline kernel as described here: https://bootlin.com/blog/more-opengl-binaries-for-the-mali-support-on-allwinner-platforms-with-mainline-linux/ We were testing Qt + Wayland on mainline Linux IIRC. Let me know if you think this could be beneficial to the community. We are not actively using at the moment, though. meta-sunxi was not that active when we worked on that so maybe we were not motivated enough to polish things up and submit a PR. We use orange-pi-zero as a base for our product we use for on-hardware validation: https://3mdeb.com/products/open-source-hardware/rte/ so I believe we can help with maintenance of this platform / SoC (we use meta-sunxi for building images for it: https://github.com/3mdeb/meta-rte). We have quite a number of other Allwinner platforms as well (H3 and A20 mostly). >>> >>> BR, >>> >>> marek >>> >>> -- >>> as simple and primitive as possible >>> --------- >>> Marek Belisko - OPEN-NANDRA >>> Freelance Developer >>> >>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic >>> Tel: +421 915 052 184 >>> skype: marekwhite >>> twitter: #opennandra >>> web: http://open-nandra.com -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
t;>> distro, which is a lot different, but for me it was much easier to >>>>>>> integrate their patches, patching scripts and bootloader scripts to a >>>>>>> Yocto layer. That way the only thing I do is that from time to time I >>>>>>> just integrate their new patches and that's it. There's no development >>>>>>> in the layer is just re-use of the armbian work and a wrapper around >>>>>>> it. Therefore, it's hard, even no doable to put those different >>>>>>> architectures together. But definitely that decision also bothered me a >>>>>>> lot before I create the layer and I also don't like time to be spend on >>>>>>> the same thing from different people. Nevertheless, from my point of >>>>>>> view I couldn't find a way to put those things together. I've tried but >>>>>>> I couldn't do it. >>>>>>> >>>>>>> Therefore, it was easier for me to do it the way I've done it. And >>>>>>> after all, although it doesn't seem right, at the same time this is the >>>>>>> beauty of the open source. I think the layers are just incompatible in >>>>>>> the way that they are do things. Also it's not bad to have alternatives. >>>>>>> >>>>>>> Sunxi is a great community and I believe many of the armbian patches >>>>>>> are coming from there. Others not. Of course, having them all together >>>>>>> would be nice. But I don't think that it's possible because of the >>>>>>> different approach. >>>>> It would be great to integrate all those different layers in >>>>> meta-sunxi,the main problem is that usually they come with their own >>>>> bootloader/kernel/etc so you have to *maintain* all these >>>>> different configurations. >>>>> Infact in the past i refused to do such things because i didn't have >>>>> the time to maintain all those different versions, it was just easier >>>>> to support what was already in mainline uboot/kernel. >>>>> >>>>> But of course if someone wants to do it then it's welcome, the worst >>>>> thing that can happen is that once an arch gets unmaintained it will >>>>> be removed. >>>>> >>>>> One thing that can be done anyway is to have those external layers >>>>> linked in the readme, so at least people will know they exist. >>>>> >>>>> Enrico -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
On 31.05.2019 08:47, Belisko Marek wrote: > Hi Maciej, > > On Wed, May 29, 2019 at 1:08 PM Maciej Pijanowski > wrote: >> >> On 29.05.2019 09:39, Belisko Marek wrote: >>> Hi Dimitris, >>> >>> On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos >>> wrote: >>>> Hi Marek, >>>> >>>> that's correct. I have a branch though which I've started to experiment >>>> and add support for Mali. I didn't finished because I've tried to do this >>>> by myself from the scratch and soon I've hit a wall. Nevertheless, I've >>>> done the same for the rk3399 for nanopi-neo4 and during this process I've >>>> learned a lot on how to do it with some help from other people from the >>>> open source scene. The graphics stack was too complicated for me in the >>>> beginning. >>> You can maybe look to meta-sunxi there is sunxi-mali driver + >>> libraries which will add support for that. When I've set that package >>> to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation >>> gtk3+ and others. I've spend 2 hours looking and trying yesterday but >>> without any success. Also pls look at this communication: >>> https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we >>> can use opensource drivers + libs later). Thanks. >> What are you trying to achieve? Which kernel version are you using? >> Isn't the mali recipe in meta-sunxi quite dated already? Can it work >> with mainline kernel correctly? >> >> I would suggest to try the recent blobs as described in this post: >> https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/ >> >> As I've written previously, I have been using the Wayland / Qt with >> good performance on H3 using the mainline kernel. Is it something you >> are looking for? >> You can take a look at my dirty branch - maybe this will be any help: >> https://github.com/3mdeb/meta-sunxi/tree/weston-with-kms/recipes-graphics/mali > I've took some patches and now core-image-sato can be build. I have > just one question for mali kernel module. Does it need some dts > changes or it will work out of the box (I didn't see any dts changes > in your branch thus I'm asking). > Thanks. Depending on the board. I think since then, most of the baords already have mali node in the devicetree. Especially all the H3 baords should have it. >> Unfortunately, I had stopped working on that and presently do not have much >> time to clean up / get back to it. I can provide some support and / or get >> back to it if it seems valuable and there is some interest. >>>> Therefore now that I feel much more confident with it I'm going to re-try >>>> and finish with my branch. Armbian does have support, so I'll try to stick >>>> to the Armbian backend for maintenance reasons. >>>> >>>> I hope that this will be rather easy, because the dri driver should >>>> already be there, so the only thing I believe is needed is the blobs and >>>> to create symlinks for the various so libs to that blob. >>>> >>>> Anyway, I'll try to do that also. In the meantime I will also wait a bit >>>> to see if that merge between those two layers is possible and doable, >>>> which will help to short the time and effort to do that. >>>> >>>> Regards, >>>> Dimitris >>> BR, >>> >>> marek >>>> Belisko Marek schrieb am Mi., 29. Mai 2019, >>>> 08:37: >>>>> Hi Dimitris, >>>>> >>>>> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos >>>>> wrote: >>>>>> Hi Enrico, >>>>>> >>>>>> I'm totally positive to any possibility for such integration. >>>>>> Personally, that was the first thing I've tried to do before I start >>>>>> this layer, but I've failed as it got really complex and the overhead >>>>>> was too much after some point (at least for me). If you have look it's >>>>>> actually a mix of meta-sunxi and armbian, but I had to remove or change >>>>>> many stuff to fit the armbian in the layer. >>>>>> >>>>>> If you have time to have a look to my layer and you think that such kind >>>>>> of integration is possible and can be done in a more easy way, then from >>>>>> my side I'm
[yocto] git fetcher - AUTOREV and best practices
Hello,
As explained in the mega manual [1], when using the git:// fetcher,
setting the
SRCREV to ${AUTOREV} will result in building the latest commit from
given git
branch (master, if not specified otherwise).
Using AUTOREV feature in recipe has following implications as far as I
can see:
- the same recipe might get built using different git commit, depending
on when
the build was run, which breaks the reproducibility,
- it imposes some potential security risk - by specifying the exact
commit in
the recipe, we can at least say that this revision of this package is fine
and we want to build it; with AUTOREV we might not be aware of the
code we're
fetching
I'm wondering whether there are any best practices or strict rules
written down
for recipes getting upstream to follow in this area. When inspecting some of
the layers from the git.yoctoprojects.org, it appears that the AUTOREV
feature
is almost not used, besides a few exceptions.
I'm wondering whether it would make sense to raise a warning when git
fetcher
with AUTOREV is used, so it would be easier to build on top OE / Yocto with
reproducibility / security in mind.
I understand that this feature is mostly meant for development purposes. I'm
just looking for a tools how one could easily make sure that each
fetched source code
is verified prior compilation.
I've already looked at the https:// fetcher (which is mostly used for
fetching tarballs).
It requires the recipe to contain valid md5 and sha256 sums. Even if we
suppress the
error in case checksum mismatch in the recipe by setting the
BB_STRICT_CHECKSUM
to 0, we are still getting the warning, which is the desired behavior I
believe.
[1]:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV
[2]:
https://www.yoctoproject.org/docs/2.0.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_STRICT_CHECKSUM
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto stucks when building!
On 01.07.2019 09:39, Onur Eser wrote: > Hello, Hi > I am trying to build a yocto for i.MX6, with a QT5 layer, everything > is okay, but it freezes on 2666th task! When 4 tasks are running at > the same time in normal, when it comes to 2666th, it is only one task > and takes forever! (I made it wait for one night) > > Build Configuration: > BB_VERSION = "1.26.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "Ubuntu-16.04" > TARGET_SYS = "i586-poky-linux" > MACHINE = "qemux86" First of all, it seems you are not building for the iMX6, but for the qemux86. > DISTRO = "poky" > DISTRO_VERSION = "1.8.2" > TUNE_FEATURES = "m32 i586" > TARGET_FPU = "" > meta = "fido:87631919819b6f85f23f57689cd1065c64d7fb03" > meta-qt5 = "fido:90919b9d86988e7da01fa2c0a07246b5b5600a5d" > meta-fsl-arm = "fido:c9f259a4bf8472dfa3ff75f1c3fcbe5e0ded7aaf" > meta-solidrun-arm-imx6 = "fido:3e496c0895b0abf8d2aaca2c622246c1f9f3ed75" > meta-yocto > meta-yocto-bsp = "fido:87631919819b6f85f23f57689cd1065c64d7fb03" fido release is *really* old. Where did you get the documentation to start this build from? I think you might have difficult time getting support with such old release. > > NOTE: Preparing RunQueue > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > Currently 1 running tasks (2666 of 5960): > 0: attr-native-2.4.47-r0 do_compile (pid 3485) > > How to solve this? > Thanks, > Onur > -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Ddcutil
On 04.07.2019 19:02, Devendra Devadiga wrote: > Hi, Hi > > I am working on i.MX6 platform. > I got the BSP by yocto build. > I need the "ddcutil" package. > By yocto how I can get this package? > In openembedded, layers list I checked for ddcutil, but I didn't get that. > If source code for "ddcutil" is available can you share it with me? > If you share the source then it will be more helpful for me. I have an old recipe for this tool somewhere. It was never polished for upstream, and it likely have some issues with the latest ddcutil releases. How about I push the patch and you will help me with testing / improving that? Thanks, > > In the below mailing list, I came to know that someone built the > recipes for "ddcutil". > https://lists.yoctoproject.org/pipermail/yocto/2017-April/035740.html > > But I can't able to get that. > Please can you share the source code of "ddcutil"? > > Thanks and regards, > Devendra > -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Ddcutil
On 08.07.2019 14:20, Zoran Stojsavljevic wrote: >>> It was never polished for upstream... > Why? Any viable reason(s)? Simply no resources and use-case for that. I've used the ddcutils project only once and never touched it since then. > >>> ... and it likely have some issues with the latest ddcutil releases. > Which issues? Could you, Maciej, please, explain/elaborate > theme/problems observed by you in more details? I have no idea. I'm just guessing that an old, dirty recipe might not work properly now. I've pushed what I found here: https://github.com/3mdeb/meta-openembedded/commit/4d6e491cfa4197626eb1b897cd5417a0cc14ff4a If anyone is interested, please feel free to try. I'm not sure if it will build properly now. I can provide some support and explanation if needed to make the proper recipe. > > Thank you, > Zoran > ___ > > On Mon, Jul 8, 2019 at 1:12 PM Maciej Pijanowski > wrote: >> >> On 04.07.2019 19:02, Devendra Devadiga wrote: >> >> Hi, >> >> Hi >> >> >> I am working on i.MX6 platform. >> I got the BSP by yocto build. >> I need the "ddcutil" package. >> By yocto how I can get this package? >> In openembedded, layers list I checked for ddcutil, but I didn't get that. >> If source code for "ddcutil" is available can you share it with me? >> If you share the source then it will be more helpful for me. >> >> I have an old recipe for this tool somewhere. >> It was never polished for upstream, and it likely have some issues >> with the latest ddcutil releases. How about I push the patch and >> you will help me with testing / improving that? >> >> Thanks, >> >> >> In the below mailing list, I came to know that someone built the recipes for >> "ddcutil". >> https://lists.yoctoproject.org/pipermail/yocto/2017-April/035740.html >> >> But I can't able to get that. >> Please can you share the source code of "ddcutil"? >> >> Thanks and regards, >> Devendra >> >> -- >> Maciej Pijanowski >> Embedded Systems Engineer >> https://3mdeb.com | @3mdeb_com >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?
On 15.07.2019 08:45, Gabriele Zampieri wrote: > Hi, > > as far as I know, there is no mechanism to add custom bootargs and/or > bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch > the upstream uboot to achieve this task. I also haven't heard of any standardized way. It may depend on the target hardware and the BSP layer you are using. Apart from patching the U-Boot, there also might be boot.cmd script to modify or the config.txt in case of the RPI, for example. > > Best regards, > Gabriele > > Il giorno lun 8 lug 2019 alle ore 22:43 JH <mailto:jupiter@gmail.com>> ha scritto: > > Hi, > > Which Yocto files and which statement can I add my own U-Boot bootargs > and bootcmd? > > Thank you. > > - jupiter > -- > ___ > yocto mailing list > yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> > https://lists.yoctoproject.org/listinfo/yocto > > -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] List of Supported Python versions
The link to the search engine: https://layers.openembedded.org/layerindex/branch/master/recipes/ On 18.07.2019 07:41, jaymin.da...@vivaldi.net wrote: > Hello Team, > > Which Python, Python-OpenCV, Python-Numpy, Python-Scipy and OpenCV > (max)versions are supported in Yocto 2.0.3 (Jethro) distro version? > > Can I get list of notes in which version of all supported modules have > been mentioned? > > > Please let me know. > > Regards, > Jaymin -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] List of Supported Python versions
On 18.07.2019 07:41, jaymin.da...@vivaldi.net wrote: > Hello Team, Hello, > > Which Python, Python-OpenCV, Python-Numpy, Python-Scipy and OpenCV > (max)versions are supported in Yocto 2.0.3 (Jethro) distro version? > > Can I get list of notes in which version of all supported modules have > been mentioned? You can use the search engine to look for the packages you are interested in. I would recommend to use one of the more recent releases instead of the Jethro, which is almost 4 years old. > > > Please let me know. > > Regards, > Jaymin -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] List of Supported Python versions
On 18.07.2019 09:34, jaymin.da...@vivaldi.net wrote: > Hi Maciej, > > Thanks for the link. > If I want to use different(updated) version of a particular function, > e.g. Python, Is is possible? > As per link Jethro is supporting Python version 2.7.9. I want to > integrate Python version 2.7.16 and Python3 3.7. > So, Do I need to use another branch which is supporting these versions > or Is there any way to integrate these versions without changing > current(Jethro) branch? > > In my case, I have limitation. Can't change to any other branch. > I want to integrate Python3-Numpy, Python3-OpenCV, Python-Scipy and > Python3-scipy modules in the build. > Python3-Scipy is dependent on Python3-Numpy and Python3-Numpy is > dependent on OpenBLAS, ATLAS and few other libraries. While these > libraries are dependent on FORTRAN (libgfortran) compiler. Now, in my > current (Jethro) branch, when I am trying to build libgfortran, it > requires GCC version >=5. And, facing so many errors while building > GCC 5.2 in the Yocto build. While GCC 5.2.0 is already supported in > the Jethro. Do you mind sharing the reason being tied to this old branch? You could try to port newer recipes from more recent branches to the Jehtro. But I believe this may be more tedious and more time consuming than resolving the original isssue of yours (upgrading from Jethro to more recent branch). > > In simple, > How can I integrate Python3-Numpy, Python-Scipy, Python3-Scipy and > Python3-OpenCV packages without changing the branch? > What is the simplest way to integrate above packages? > > Please suggest. > > Regards, > Jaymin > > On 18-07-2019 12:24 PM, Maciej Pijanowski wrote: >> The link to the search engine: >> https://layers.openembedded.org/layerindex/branch/master/recipes/ >> >> On 18.07.2019 07:41, jaymin.da...@vivaldi.net wrote: >>> Hello Team, >>> >>> Which Python, Python-OpenCV, Python-Numpy, Python-Scipy and OpenCV >>> (max)versions are supported in Yocto 2.0.3 (Jethro) distro version? >>> >>> Can I get list of notes in which version of all supported modules have >>> been mentioned? >>> >>> >>> Please let me know. >>> >>> Regards, >>> Jaymin >> >> -- >> Maciej Pijanowski >> Embedded Systems Engineer >> https://3mdeb.com | @3mdeb_com >> >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Missing service file
On 18.07.2019 12:01, JH wrote:
> Hi,
>
> I set up a service file at following myapp.bb file, but that service
> file was not installed to /lib/systemd/system. What could I be wrong
> here?
Not installed means it's not in the final image on the target? Which
package gets installed into the
image? I guess the ${PN} package.
Have you inspected the recipe
work/YOUR_TARGET/RECIPE_NAME/RECIPE_VERSION/image dir?
Maybe it is present there, but not in the package you are installing
(check the content of the pacakges-split dir as well).
You may use the:
FILES_${PN} += "/lib/systemd/system/${PN}.service
to force packaging the file into the ${PN} package.
>
>
> SYSTEMD_SERVICE_${PN} = "${PN}.service"
> SYSTEMD_AUTO_ENABLE_${PN} = "enable"
>
> do_install() {
> ..
> install -m 0644 ${S}/lib/systemd/system/${PN}.service
> ${D}/${systemd_system_unitdir}
> }
>
> Thank you.
>
> Kind regards,
>
> - jh
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] U-boot enable not working for Raspberry Pi3
On 06.08.2019 18:55, Greg Wilson-Lindberg wrote: I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm trying to enable using Das U-boot to load Linux as a first step in trying to enable OSTree updates. In the meta-raspberrypi documentation is says to set: RPI_USE_U_BOOT = "1" Hi. I'm working with the U-Boot and RPI3 at the moment as well. I'm using warrior revision and not using the Qt at all though. In my case setting the above variable was enough to build the U-Boot and include it in the final image. In my case the platform boots into the Linux. I'm having issues with weird artifacts and resolution on the HDMI display, though. I believe this may be related to the U-Boot patching DTB to add the simplefb: https://github.com/u-boot/u-boot/blob/master/board/raspberrypi/rpi/rpi.c#L490 while I want to keep using the brcm fb with userland etc. (proprietary stuff). to enable u-boot for the raspberrypi. I have set that variable in the top level local.conf file but I don't seem to be getting any changes in the build. Nothing in the cooker log shows building u-boot, and the start up screen doesn't show any u-boot messages. It appears that I'm missing necessary to turn u-boot on, can anybody shed some light on what is going on? Regards, Greg Wilson-Lindberg www.sakuraus.com -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding dtb to machine.conf extending it
On 10.08.2019 12:14, Mauro Ziliani wrote: Hi all. Hi, I need to add my dtbo to overlays. I'm using RaspberryPI 3 with pyro and meta-raspberrypi I have to add tft35a.dtb to /boot/overlays in the file image. Can I extend raspberrypi3.conf? You can and it will work, but modification of external layers is considered as a bad practice. You would rather want to override the given variable you need to modify in local.conf or in your custom layer. MZ -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ask a question about filesystem in yocto
On 10.08.2019 09:20, www wrote:
Dear all,
Hi,
I'm new learner and user of yocto. When I used it, I encountered a
problem. I don't know how to resolve it, so I ask for help.
the problem is how can I create a new partition on yocto? if I have a
package named webui, it can be generate several execute files and
configuration files, the execute files will be install into
filesystem, such as "/usr/bin", and be packed to rofs. but I don't
want pack the configuration files to rofs, and I want create a new
image and the image will be a partition of the global image, and pack
the configuration file to it, when the system start running, it can be
separate mount to the filesystem.
When pack to rofs image, I don't know how to separate the execute file
and configuration file in the webui package and pack to different
part. Can someone help me to tell me how to solve this problem?
Please take a look at wic:
https://www.yoctoproject.org/docs/2.4.2/dev-manual/dev-manual.html#creating-partitioned-images-using-wic
You can for example exclude some subdirectory from main rootfs partition
and place it onto another partition instead.
Take a look at following wic flags:
--rootfs-dir
--exclude-path
You can define subdirs to split in local.conf or another config file
(e.g. distro config) using the WIC_CREATE_EXTRA_ARGS
and flags as: --rootfs-dir rootfs-main=${IMAGE_ROOTFS}
I am looking forward to your reply.
thanks，
Byron
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ask a question about filesystem in yocto
On 12.08.2019 07:53, www wrote:
>
> Hi Maciej Pijanowski，
Hi,
>
> Thank you for your kind help. I'll try it. Thank you.
Please reply to the mailing list as well when using the public mailings
lists,
so others can see the discussion.
>
> thanks,
> Byron
>
>
>
>
> 在 2019-08-10 16:26:19，"Maciej Pijanowski"
> 写道：
>
>
> On 10.08.2019 09:20, www wrote:
>> Dear all,
> Hi,
>>
>> I'm new learner and user of yocto. When I used it, I encountered
>> a problem. I don't know how to resolve it, so I ask for help.
>> the problem is how can I create a new partition on yocto? if I
>> have a package named webui, it can be generate several execute
>> files and configuration files, the execute files will be install
>> into filesystem, such as "/usr/bin", and be packed to rofs. but I
>> don't want pack the configuration files to rofs, and I want
>> create a new image and the image will be a partition of the
>> global image, and pack the configuration file to it, when the
>> system start running, it can be separate mount to the filesystem.
>>
>> When pack to rofs image, I don't know how to separate the execute
>> file and configuration file in the webui package and pack to
>> different part. Can someone help me to tell me how to solve this
>> problem?
> Please take a look at wic:
>
> https://www.yoctoproject.org/docs/2.4.2/dev-manual/dev-manual.html#creating-partitioned-images-using-wic
>
> You can for example exclude some subdirectory from main rootfs
> partition and place it onto another partition instead.
>
> Take a look at following wic flags:
> --rootfs-dir
> --exclude-path
>
> You can define subdirs to split in local.conf or another config
> file (e.g. distro config) using the WIC_CREATE_EXTRA_ARGS
> and flags as: --rootfs-dir rootfs-main=${IMAGE_ROOTFS}
>>
>> I am looking forward to your reply.
>>
>> thanks，
>> Byron
>>
>>
>>
>>
>>
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> https://3mdeb.com | @3mdeb_com
>
>
>
>
>
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA Issue: Files/directories were installed but not shipped
On 30.08.2019 07:20, SIMON BABY wrote:
> Hello,
> I am getting "ERROR: QA Issue: Files/directories were installed but not
> shipped". Can you please help to resolve. My logs and bb files are below.
> ERROR: QA Issue: zipcpp: Files/directories were installed but not shipped in
> any package:
> /usr
> /usr/include
> /usr/src
> /usr/lib
> /usr/include/zipc.h
> /usr/include/logger.h
> /usr/include/fmt
> /usr/include/fmt/format.h
> /usr/include/fmt/ranges.h
> /usr/include/fmt/printf.h
> *bb file:*
> #
> # This file is the zipcpp recipe.
> #
>
> DEPENDS = "zeromq cppzmq"
> SUMMARY = "ZeroMQ based IPC C++ library"
> SECTION = "base"
> LICENSE = "CLOSED"
>
> SRC_URI = "git://git@elsvsapp02/TDY/ZIPCpp.git;protocol=ssh;branch=develop"
> SRCREV = "${AUTOREV}"
>
> S = "${WORKDIR}/git"
>
> LIB_ARTIFACT = "libzipcpp.so"
> LIB_VERSION = "1"
>
> do_install() {
> install -d ${D}${libdir}
> install -m 0755 ${S}/bin/${LIB_ARTIFACT}.${LIB_VERSION}
> ${D}${libdir}/${LIB_ARTIFACT}.${LIB_VERSION}
> ln -rs ${D}${libdir}/${LIB_ARTIFACT}.${LIB_VERSION}
> ${D}${libdir}/${LIB_ARTIFACT}
> install -d ${D}${includedir}
> install -m 0644 ${S}/include/zipc.h ${D}${includedir}
> install -m 0644 ${S}/include/logger.h ${D}${includedir}
> install -d ${D}${includedir}/fmt
> install -m 0644 ${S}/include/fmt/* ${D}${includedir}/fmt
> }
>
> #do_install_append() {
> # rm -r ${D}/usr/share
> #}
>
> FILES_${PN} += "${libdir}/${LIB_ARTIFACT}.${LIB_VERSION}"
> FILES_${PN} += "${libdir}/${LIB_ARTIFACT}"
> PACKAGES = "${PN}"
What I would do is to remove those 3 lines to not override the default
packaging. This way,
the header files for example should be packaged correctly to the
${PN}-dev package.
If similar error still appears, you would need to add the remaining
files to some package
vie FILES_package-name. You might want to add a package with PACKAGES =+
"pacakage-name"
> Rgds
> Simon
>
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fetching Yocto layers
On 02.09.2019 15:51, Josef Holzmayr wrote: > I'd like to throw kas into the discussion too, I've been using it quite > successfully. > > https://github.com/siemens/kas +1 for kas. Previously I was using repo, custom scripts and custom Docker container for running the build. kas does all of that and makes significantly faster for me to start a new project. I have described my repo vs kas experience a while ago if someone would be interested: https://blog.3mdeb.com/2019/2019-02-07-kas/ I hope it's fine to link to one's blog post there? > > Greetz > > On Mon, Sep 02, 2019 at 03:34:28PM +0200, Alexander Kanavin wrote: >> On Mon, 2 Sep 2019 at 15:05, Brian Silverman wrote: >> >>> The tags chosen above are based on what we test and ship. So my issue is >>> that someone has to correctly follow the above instructions for different >>> versions of multiple layers if they want a reproducible build of a specific >>> version of mylayer-image. >>> >>> Is there a canonical why to encode this information within my layer? >>> Obviously I could script the above, store it in my layer, and have the user >>> run that script. But, that seems very unyocto-like. >>> >> At the moment Yocto project does not have an off-the shelf setup for >> multiple layers. You are welcome to provide and maintain one, until then it >> is indeed custom scripts, or tools like Google's 'repo', or maybe git >> submodules could work. >> >> Alex >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to share files between recipes?
On 19.09.2019 15:39, Patrick Doyle wrote:
> I have a set of data files (cryptographic keys) that I would like to
> share among several recipes in my build. They won't go into the
> rootfs, but they will be used by multiple recipes that construct the
> rootfs. So, to the best of my understanding, it seems like I should
> put them in sysroot and somehow access them from there.
>
> I constructed the following recipe:
> SUMMARY = "Development keys used by my image"
> DESCRIPTION = "Install the development keys in the sysroot so that they \
> can be referenced by other recipes."
>
> LICENSE = "Proprietary"
> LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/Proprietary;md5=0557f9d92cf58f2ccdd50f62f8ac0b28"
>
> SRC_URI = "file://keys"
>
> do_install() {
> install -d ${D}/${datadir}
> install -m 755 -d ${WORKDIR}/keys ${D}/${datadir}
> }
>
> FILES_${PN} += "${datadir}/keys/"
>
> But when I attempt to bitbake this recipe, I get the following error:
> ERROR: development-keys-1.0-r0 do_package: QA Issue: development-keys:
> Files/directories were installed but not shipped in any package:
> /usr
> /usr/share
>
> Ummm I don't put anything in /usr or /usr/share.
> I don't inherit from anything (other than base.bbclass) that puts
> anything in /usr or /usr/share.
You do. datadir is /usr/share.
>
> Does base.bbclass put anything in /usr or /usr/share?
> Why?
> I suppose I could follow the advice given in the error message and
>
> rm -rf ${D}/usr
>
> in my do_install() task, but I'd like to understand why and how those
> directories are being created in the first place?
>
> --wpd
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel module and drivers missing in final image
On 27.09.2019 14:01, JH wrote: > Hi, > > I included emmy-w1-driver-sdiosdio in packagegroup.bb, but all drivers > and kernel modules in emmy-w1-driver-sdiosdio are missing in the > deploy image, any clues why, how to debug it, how to fix it? It is not clear to me what do you mean by including it in packagegroup.bb and what stuff are you installing into the image. If you wish to install all modules which were built, simply add kernel-modules to your image via IMAGE_INSTALL variable. > Thank you. > > Kind regards, > > - jh -- Maciej Pijanowski Embedded Systems Engineer GPG: F1401D2E1CCB19EF https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] newcomers
On 03.10.2019 18:33, Steve Scott wrote: How would a newcomer get started? Is there an FAQ or Wiki that gives a developer overview of the project, patch submission process, etc.? This one is pretty accurate when it comes to patch submission process: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded It’s hard to jump on to the moving train… *From:*yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] *On Behalf Of *Stephen K Jolley *Sent:* Monday, September 30, 2019 8:50 AM *To:* openembedded-c...@lists.openembedded.org; yocto@yoctoproject.org *Subject:* [yocto] (no subject) All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 309 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “2.8”, “2.9’, "2.99" and "Future", the more pressing/urgent issues being in "2.8" and then “2.9”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp...@gmail.com <mailto:sjolley.yp...@gmail.com>) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs -- Thanks, */Stephen K. Jolley/* *Yocto Project Program Manager* *7867 SW Bayberry Dr., Beaverton, OR 97007* (*Cell*: (208) 244-4460 * *Email*:_s <mailto:stephen.k.jol...@intel.com>jolley.yp...@gmail.com <mailto:jolley.yp...@gmail.com>_ -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Partitioning SD cards
On 14.10.2019 14:13, Andy Pont wrote: > Hello, > > I am working on a custom platform where U-Boot will be programmed into > an SPI NOR flash device and the ext4 file systems will be in a > removable microSD card. The Linux kernel itself will be stored in the > /boot directory of the root file system. > > The customer wants the (16GB) microSD card formatted as 1GB to mount > at / and the remaining 15GB mounted as /home. > > In the recipe for my image I have defined the following to try to > create a suitable image for writing to the microSD card: > > IMAGE_FSTYPES_append = " wic" > IMAGE_ROOTFS_SIZE = “1048576” > > The image file that is being created is bigger than 1GB even though > the root file system is only a little over 450MB. Looking at the > contents of what gets written to the microSD card this looks as though > it is, in part, because it also includes the ~20MB “boot” partition > containing the boot files. > > A couple of questions… > > How do I stop the wic generation process including the FAT formatted > “boot” partition? This depends on the wic (.wks) file you are using. > > What is the best strategy for partitioning / formatting / mounting the > second partition as /home? Should it be part of the image build > process or a one-time task run at first boot? Use --exclude-path and --rootfs-dir flags in the .wks file. You can look at my example, where I extract one subdir from rootfs (/storage in this case) on a separate partition. https://github.com/3mdeb/meta-rte/blob/master/wic/sunxi-mmc-spl.wks The rootfs parts should be named somewhere, like in distro config: https://github.com/3mdeb/meta-rte/blob/master/conf/distro/rte.conf#L50 > > -Andy. > > > -- Maciej Pijanowski Embedded Systems Engineer GPG: F1401D2E1CCB19EF https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.3.1.bb: add new udev dir to FILES and append EXTRA_OECONF
On 07.11.2019 16:14, Norbert Kaminski wrote:
> The tpm2 tool freezes in a XEN distro. It stores the udev rules in
> /lib/udev directory,
> thus these changes append the FILES and EXTRA_OECONF to make tpm2 work
> properly.
>
> Signed-off-by: Norbert Kaminski
> ---
> meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.3.1.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.3.1.bb
> b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.3.1.bb
> index 3e77f71..10450e3 100644
> --- a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.3.1.bb
> +++ b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.3.1.bb
> @@ -74,6 +74,8 @@ FILES_libtss2-dev = " \
> ${libdir}/libtss2*so"
> FILES_libtss2-staticdev = "${libdir}/libtss*a"
>
> -FILES_${PN} = "${libdir}/udev"
> +FILES_${PN} = "${libdir}/udev ${base_prefix}/lib/udev"
> +
> +EXTRA_OECONF += "--with-udevrulesdir=${base_prefix}/lib/udev/rules.d/"
I suspect the problem appears when building for machine where libdir is
/usr/lib64, not /usr/lib?
It is likely not related to Xen in any way.
>
> RDEPENDS_libtss2 = "libgcrypt"
--
Maciej Pijanowski
Embedded Systems Engineer
GPG: F1401D2E1CCB19EF
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enable systemd service with parameter
On 17.11.2019 20:44, Mateusz Majchrzycki wrote:
Hi!
Hi,
I have a pretty unusual problem. I need to enable a systemd service
(openvpn) with a profile as a parameter (typically you do it by
'systemctl enable openvpn@profile'). But the profile on build time
doesn't exist (it is just symlink to non existing file).
My recipe bb looks like (I'm omitting SUMMARY etc.):
inherit systemd
SYSTEMD_SERVICE_${PN} = "openvpn@clientprofile.service"
SYSTEMD_AUTO_ENABLE = "enable"
DEPENDS = "openvpn"
SYSTEMD_PACKAGES = "${PN}"
do_install() {
install -d ${D}${sysconfdir}/openvpn/
ln -sf /data/etc/openvpn/clientprofile.conf
${D}${sysconfdir}/openvpn/clientprofile.conf
}
Unfortunately, on build I get the following error:
ERROR: openvpn-client-1.0-r3 do_package:
SYSTEMD_SERVICE_openvpn-client value openvpn@clientprofile.service
does not exist
ERROR: openvpn-client-1.0-r3 do_package: Function failed:
systemd_populate_packages
What am I doing wrong? I suppose the symlink is not a problem as
normally systemctl enables service with non-existent file as a
parameter (it fails on start, but not enabling).
Maybe you could just create that file
/data/etc/openvpn/clientprofile.conf and install it within the recipe?
It can be even empty. The service will keep failing. The build shall
pass. Sounds reasonable?
Best regards,
Mateusz
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] KVM kernel modules missing from Yocto kernel
On 18.11.2019 19:22, Wayne Li wrote: Dear Yocto Developers, I'm trying to incorporate KVM into a Yocto kernel me and my coworker build for a T4240 RDB (which has a PowerPC CPU). The problem is, no matter what I do the KVM kernel module (I'm expecting a kvm.ko or any .ko file along those lines) is not present in the image. First I tried adding the content of the .config file generated when configuring the kernel for KVM support into the kernel configuration file. This resulted in KVM source directories appearing in the kernel but no KVM related kernel modules are present. I explain this in more detail in a previous email conversation I had with the Yocto community (saved in a Github gist for readability): What is your kenel config? Is KVM built-in (y) or built as module (m)? https://gist.github.com/WayneZhenLi/d5d7a5e8c30e6d4b7cd4541d0c24cab5 Since then I've tried a few things. First, I added the following lines to the local.conf file (found in build_t4240rdb-64b/conf folder): MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kvm-image-minimal" I din't know which image you are building. Those variables are tricky, since they only applies when basing on the packagegroup-core-boot packagegroup. Please refer to the documentation. But that didn't seem to work as there weren't any new .ko files in the final image. Next I tried adding the following lines to the same local.conf file: CORE_IMAGE_EXTRA_INSTALL += "kernel-modules" CORE_IMAGE_EXTRA_INSTALL += "kvm-image-minimal" Why trying to install the image into image? kvm-image-minimal is not a package, it is image recipe. The build can definitely break in this case. This time I get an error saying "ERROR: kvm-image-minimal not found in the base feeds (t4240rdb-64b ppc64e6500 powerpc64 noarch any all)". Also if just run a "ERROR: bitbake kvm-image-minimal" to see what's going on with that particular recipe I get an error saying "kernel-module-kvm-intel" not found in the base feeds (t4240rdb-64b ppc64e6500 powerpc64 noarch any all). Would I have to write recipes for the packages listed in kvm-image-minimal such as kernel-module-kvm-intel or kernel-module-kvm? Note that I'm not even building the image for intel; I'm building it for PowerPC. Anyway, I just feel like writing recipes for the KVM kernel modules isn't the correct step. Like maybe I just messed up my with my configuration somehow? What are your thoughts? IMHO: Simply use IMAGE_INSTALL += "kernel-modules" (IMAGE_INSTALL += "kernel-module-kvm" will likely install just the KVM module) in your local.conf to install all built kernel modules. If KVM module won't be present in the rootfs, it means it was not built. Please inspect your kernel work dir (packages-split dir) to find out which packages were produced by the kernel recipe. It will be something like build/tmp/work/XX/linux-yocto/XX/packages-split -Thanks!, Wayne Li -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] GRUB without UEFI
Hi, I'm wondering whether anyone here uses Yocto to build images for legacy x86 systems (without UEFI) with GRUB as a bootloader. I know that the GRUB with UEFI is well supported in Yocto. I'm looking for a way to create a bootable disk (ideally using WIC) for legacy BIOS with GRUB preinstalled. i know there is a bootimg-pcbios wic plugin: http://git.yoctoproject.org/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source/bootimg-pcbios.py?id=38125456ffa6112941a3608fcba9ed2032353740 which uses SYSLINUX. Thoughts welcome. Thanks -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] patches to upgrade meta-jupyter layer packages
On 19.11.2019 01:15, Chandana Kalluri wrote: > Hello all, > > I have upgraded python packages from meta-jupyter layer to work with the zeus > branch. > I am planning to send out the patches to this yocto project mailing list > yocto@yoctoproject.org Please let me know if this is alright or if I need to > send them to a different mailing list. May be a good idea to add maintainers on CC: https://github.com/Xilinx/meta-jupyter#maintainers-patchessubmissions-community > > Thanks, > Chandana > -- Maciej Pijanowski Embedded Systems Engineer GPG: F1401D2E1CCB19EF https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
