Re: [yocto] Kernel modules packaged but not installed
Hi Bruce,
I've also tried adding the `kernel-modules` in the IMAGE_INSTALL,
but that doesn't help either, because as I've mentioned this package
is empty.
The individual module packages are indeed populated and adding each
one individually in the IMAGE_INSTALL makes them install in the final
image.
So the problem is that the `kernel-modules` doesn't add all the module
packages in one package and it's empty. Therefore, when it's installed
it installs nothing.
Regards,
Dimitris
Bruce Ashfield schrieb am Mi., 6. Nov. 2019,
17:20:
> On Wed, Nov 6, 2019 at 11:06 AM Dimitris Tassopoulos
> wrote:
> >
> > Hi all. I have a weird issue with the kernel modules not being installed
> in the image and also not packaged.
> > I see the packages for individual "kernel-module-*.ipk" modules but the
> "kernel-modules_*.ipk" is always
> > empty.
> >
> > I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has
> all the modules in there, just fine.
> >
> > In my image file I've also set this:
> > MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> Have you tried something stronger than the RRECOMMENDS ? i.e. either
> adding one of the modules, or the kernel-modules meta package to
> IMAGE_INSTALL ?
>
> Bruce
>
> >
> > This is the kernel recipe:
> >
> https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-kernel/linux/linux-stable_4.19.bb
> >
> > And this is the conf folder
> > https://gitlab.com/dimtass/meta-allwinner-hx/tree/master/conf
> >
> > For some reason I can't figure out why modules are not ending up in the
> image.
> >
> > If I do it manually in a do_install_append like this:
> > do_install_append() {
> > # Install kernel-modules
> > install -d ${D}${nonarch_base_libdir}
> > oe_runmake INSTALL_MOD_PATH=${D} modules_install
> > }
> >
> > then it works, but I guess that shouldn't be the right way.
> >
> > Any suggestions or ideas?
> >
> > Thanks!
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel modules packaged but not installed
Hi all. I have a weird issue with the kernel modules not being installed in
the image and also not packaged.
I see the packages for individual "kernel-module-*.ipk" modules but the
"kernel-modules_*.ipk" is always
empty.
I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has
all the modules in there, just fine.
In my image file I've also set this:
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
This is the kernel recipe:
https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-kernel/linux/linux-stable_4.19.bb
And this is the conf folder
https://gitlab.com/dimtass/meta-allwinner-hx/tree/master/conf
For some reason I can't figure out why modules are not ending up in the
image.
If I do it manually in a do_install_append like this:
do_install_append() {
# Install kernel-modules
install -d ${D}${nonarch_base_libdir}
oe_runmake INSTALL_MOD_PATH=${D} modules_install
}
then it works, but I guess that shouldn't be the right way.
Any suggestions or ideas?
Thanks!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to extract files from wic.gz image?
Hi JH, I believe the most important feature of the wic images is to be able to flash your SD card faster than just extract and dd the full image on the SD card. For that reason you can use the bmap-tool which already supports the gz compression (as also .bz2). To do that you also need the bmap file for this image. If it's not already there then you can add it your in your image like this: IMAGE_FSTYPES += "wic.bmap" (see also here: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#flashing-images-using-bmaptool ) Then you can just run: $ sudo bmaptool copy dev-image-20190528085324.rootfs.wic.gz /dev/sdX and you copy the gz image on your SD much much faster. Regards, Dimitris On Sat, Jun 1, 2019 at 12:40 PM JH wrote: > Thanks Zoran and Tom, I can use dd to install the image to SD card on > IMX EVK, now I need to install the image to NAND flash of a customized > IMX device via USB HID, it cannot use the dd, IMX provided UUU utility > which I am new to it and I have to decompose the image to > zImage-initramfs and losetup -P does work, dd does not work either. > > $ losetup -P dev-image-20190528085324.rootfs.wic > losetup: solar-dev-image-solarevk-20190518084330.rootfs.wic: failed to > use device: No such device > > Thanks for your helps anyway. > > Kind regards, > > - jupiter > > On 5/31/19, Tom Rini wrote: > > On Fri, May 31, 2019 at 10:21:40PM +1000, JH wrote: > >> Hi, > >> > >> What command and tools to extract files from Yocto / bitbake image > >> such as dev-image-20190528085324.rootfs.wic.gz? > >> > >> I am using IMX UUU to install dev-image-20190528085324.rootfs.wic.gz > >> to IMX, I was advised to extract the archive and use "uuu
Re: [yocto] meta-sunxi maintained?
Hi Marek, I see (and now remember) that there is a recipe for libgles for Mali400 and A10/20. Are you interested for this architecture or newer (like H2, H3, H5) ? I can only make a wild guess that maybe because the driver is a bit old, then if you try to build new recipes then there might be some issues. This also is the difference between the layers that I've mentioned before. The meta-sunxi is clean and raw layer. Meaning that you get more flexibility to add/remove things and also have a more generic layer. On the other hand, the other layer is not really configurable and flexible in the same depth but it takes the full armbian distro and wraps it. So, if the distro works, then the layer should work only with those components (of course you can do modifications). That's the difference in the approach I meant in the previous mail. I don't have any A10/20 hardware to test, but I could spin a build and look at the errors you get. If you send my your local conf file and your environment setup and build command I ca trigger a build and see if there's anything I can help with. Regards, Dimitris On Wed, May 29, 2019 at 9:39 AM 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. > > > > 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 all in. > >> > I believe that re-using the armbian patches is easier as it makes > maintenance much easier, there are more supported SBCs and also there is > much more testing involved in armbian and frequent updates fix those bugs. > >> I did check your layer and it seems that you're not using sunxi-mali > >> for opengl HW acceleration only mesa so SW rendering? Thanks. > >> > > >> > Please consider it and I can help as much as I can and my time allows > for that integration. > >> > > >> > Regards, > >> > Dimitris > >> > > >> > > >> Marek > >> > > >> > On Tue, May 28, 2019 at 12:56 PM Enrico < > ebut...@users.sourceforge.net> wrote: > >> >> > >> >> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos < > dimt...@gmail.com> wrote: > >> >> > > >> >> > > > >> >> > > I w
Re: [yocto] meta-sunxi maintained?
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. 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 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 all in. > > I believe that re-using the armbian patches is easier as it makes > maintenance much easier, there are more supported SBCs and also there is > much more testing involved in armbian and frequent updates fix those bugs. > I did check your layer and it seems that you're not using sunxi-mali > for opengl HW acceleration only mesa so SW rendering? Thanks. > > > > Please consider it and I can help as much as I can and my time allows > for that integration. > > > > Regards, > > Dimitris > > > > > Marek > > > > On Tue, May 28, 2019 at 12:56 PM Enrico > wrote: > >> > >> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos < > dimt...@gmail.com> wrote: > >> > > >> > > > >> > > I was thinking about this also, too. The only reason is that in > meta-sunxi they do a great job and they keep their layer clean, which is > great I think. The other layers are just based on the armbian 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 > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
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 all in. I believe that re-using the armbian patches is easier as it makes maintenance much easier, there are more supported SBCs and also there is much more testing involved in armbian and frequent updates fix those bugs. Please consider it and I can help as much as I can and my time allows for that integration. Regards, Dimitris On Tue, May 28, 2019 at 12:56 PM Enrico wrote: > On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos > wrote: > > > > > > > > I was thinking about this also, too. The only reason is that in > meta-sunxi they do a great job and they keep their layer clean, which is > great I think. The other layers are just based on the armbian 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 > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
Hi Belisko, I was thinking about this also, too. The only reason is that in meta-sunxi they do a great job and they keep their layer clean, which is great I think. The other layers are just based on the armbian 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. I hope this explains your question and even more that explains that was not a decision to divide things or create more hassle for the same chips. Regards, Dimitris Belisko Marek schrieb am Di., 28. Mai 2019, 11:49: > Hi Dimitris, > > On Tue, May 28, 2019 at 11:01 AM Dimitris Tassopoulos > wrote: > > > > Hi Belisko, > > > > you can also have a look in to this layer: > http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/ > > It's for allwinner H2,H3 and H5 boards that already have support on > Armbian. > > Pretty much is just a Yocto layer with all the patches and BSP support > from Armbian. > > It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT > patches. > > Warrior support was added recently, too. > OK thanks. I think I'll stick with meta-sunxi ;). What about join > forces and maintains one layer properly instead having it separated? > > > > A similar one is also this: > http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/ > > > > Dimitris > > > > On Mon, May 27, 2019 at 7:33 PM Belisko Marek > wrote: > >> > >> Hi Enrico, > >> > >> 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 < > marek.beli...@gmail.com> 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. > >> > > > >> > > 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 > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/yocto > > > > marek > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
Hi Belisko, you can also have a look in to this layer: http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/ It's for allwinner H2,H3 and H5 boards that already have support on Armbian. Pretty much is just a Yocto layer with all the patches and BSP support from Armbian. It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT patches. Warrior support was added recently, too. A similar one is also this: http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/ Dimitris On Mon, May 27, 2019 at 7:33 PM Belisko Marek wrote: > Hi Enrico, > > 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. > > > > > > 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 > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] get_kernelversion_headers not replacing '_' by '-'
The same also happens with the deb packager. But it works with rpm. For deb '_' is not allowed character, so I guess ithe same for ipkg. You need to either change the 'LOCALVERSION' of the kernel or use rpm. Dimitris On Thu, Apr 4, 2019 at 11:07 AM Fernando AE wrote: > Hello all, > > I discovered that if a '_' in present in the kernel version string, > the task package_write_ipk during the kernel build will fail. > > In Yocto 2.6, get_kernelversion_headers is defined at > meta/classes/linux-kernel-base.bbclass. > > In the attached file, I set KERNEL_VERSION="kernel_version" in my linux > recipe. > > Any thoughts? > > Kind regards, > Fernando > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] customising a bsp
Hi Serj,
I'm using the -r / -R options in bitbake in order to customize the image
via global
variables and be able to build different configurations for the same
machine and
distro. You you use the same option to create e.g. different versions. Have
a look
in the documentation
https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html
search for these lines:
-r PREFILE, --read=PREFILE
-R POSTFILE, --postread=POSTFILE
What those do is that you can add an extra configuration file wich either
prepends
or appends the local.conf file. I'm using it both ways, but for your case I
think you
need to add your default versions with ?= in the local.conf and then
override them
with an external conf file and use --read option.
So, let's say that you have the minimal-image then you can have a number or
versioned configuration files (e.g. version-1.0.conf, version-1.2.conf,
e.t.c.) then
you setup your environment as usual using your environment setup scripts or
just calling oe-init-build-env for your machine and then you'll be able to
build
different versions like this:
bitbake -R version-1.0.conf minimal-image
You can also build a single recipe using the version file
bitbake -R version-1.2.conf virtual/kernel
Then, if you like, you can create a wrapper script that actually simplifies
the call
and just pass the version. For example, you can create an executable bash
script
and these
#!/bin/bash
> CONF_VERSION="1.0"
> while getopts v:h" OPTION
> do
> case $OPTION in
> v) CONF_VERSION=${OPTARG} ;;
> h) echo "Print some help" ;;
> *) echo "Print some help" ;;
> esac
> done
> bitbake --postread=${CONF_VERSION} ${1}
And then call the script using -v to pass the version. Of course, that
assumes
that all version files are in the same folder with the local.conf. I
usually make
such scripts but they are doing much more stuff, for example use variables
from the extra conf file to run other tasks.
Hope that helps.
Cheers,
Dimitris
Sergio Torres Soldado schrieb am Sa., 30. März
2019, 18:34:
> Hi,
>
> What is the best alternative to setting variables in local.conf? The
> specific use-case is customising a meta-raspberrypi build, which has a
> bunch of variables that are picked up by the MACHINE code to influence
> build configurations. I want to version these customisations hence removing
> them from local.conf.
>
> I have tried adding a machine definition in a separate layer that
> includes the same files as those from the machines in meta-raspberry pi but
> there is logic that depends on the machine name and building an image fails.
>
> Many thanks,
> Serj.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
Hi Alexander, in this case the 3g is added by default from the poky distro in the DISTRO_FEATURES_DEFAULT var in: *meta/conf/distro/include/default-distrovars.inc* And because the poky distro is the base distro for the image this is inherited. Therefore it needs to be removed with the DISTRO_FEATURES_remove unless there is another way, which I'm not aware to easily remove/adjust without having to create a new distro. Regards, Dimitris On Fri, Mar 29, 2019 at 10:38 AM Alexander Kanavin wrote: > You can do that using > > bitbake -e and looking for how DISTRO_FEATURES is formed in > the output of the command. > > Alex > > On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin > wrote: > > > > On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos > wrote: > > > > > To do that, add this to your build/conf/local.conf file > > > > > >> DISTRO_FEATURES_remove = " 3g" > > > > This works around the issue after the fact. It's better to track down > > where 3g is added in the first place, and adjust that. > > > > Alex > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
Hi Mikko, thanks for pointing out the buildhistory.
I need to have a look at it also as I haven't used it yet.
Also, it's very nice to see it documented so well.
Thanks!
On Fri, Mar 29, 2019 at 9:59 AM wrote:
> On Fri, Mar 29, 2019 at 09:50:20AM +0100, Dimitris Tassopoulos wrote:
> > Hi all,
> >
> > I was thinking that the mail list shouldn't be only for problems and
> > questions and that from time to time, it would be nice to see some
> guides,
> > tutorials or success stories from people that follow the list.
> >
> > Anyway, a few days ago someone had an issue with one of the BSPs I'm
> > maintaining and I wrote him a small guide on how to -try- to resolve
> future
> > issues like that. Then I thought that I haven't found a small tutorial
> > like this. Maybe it already exists, but nevertheless I haven't seen it.
> > Of course, those things are in the documentation, but they are documented
> > as individual tools (which is the correct thing to do), but it's not very
> > clear how to use all those things together to perform more complex tasks.
> >
> > So, in my case the issue was that ofono was installed in the image and
> that
> > needed to be removed. Probably a lot of you already know the answer but
> for
> > me that I've never bothered with that I had to track it down how it got
> in
> > there.
> >
> > Everything from now on assumes that you've setup up your bitbake
> environment
> > of your build with whatever setup scripts you're using (e.g.
> > *oe-init-build-env*)
> >
> > There are several ways to do introspection on an image. For example,
> > let's say that you found a file in the in rootfs and you want to know
> which
> > recipe added that file. Then you can use this command:
> >
> > oe-pkgdata-util find-path /usr/sbin/ofonod
> >
> >
> > *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
> > `find-path` is pretty obvious what it does. This will return:
> >
> > ofono: /usr/sbin/ofonod
> >
> >
> > So now you know that it's indeed the *ofono* recipe that adds this file.
> > Next,
> > you need how this did get in the image (probably some other dependency
> > because you didn't). Then you can use the `-g` parameter with bitbake
> like
> > this:
> >
> > bitbake -g allwinner-image
> >
> >
> > This will create a file called `recipe-depends.dot`. This is a dot file
> that
> > has all the dependencies in the image. You can use the same command to
> get
> > the dependencies for a recipe, but now we care about the image.
> >
> > Next step is to search in that file, why that key is there. Why is `-w`
> and
> > key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
> > and you
> > run this command:
> >
> > oe-depends-dot -k ofono -w recipe-depends.dot
> >
> >
> > This will return the recipe that has this as dependency.
> >
> >
> > > Because: allwinner-image packagegroup-base
> >
> >
> > That means that the key is there because of allwinner-image (this is the
> > image
> > recipe, but it can be any other image) and because the *allwinner-image*
> > inherits the
> > *packagegroup-base*. So this packagegroup is the guilty.
> >
> > Let's find this thing now. Get in the meta layer sources folder and run
> this
> >
> > find . | grep packagegroup-base
> >
> >
> > This will return
> >
> > > ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
> >
> >
> > Great. Open this file to an editor and find where is *ofono*. Gotcha, is
> in:
> >
> > RDEPENDS_packagegroup-base-3g
> >
> >
> > Then it's the *packagegroup-base-3g* that does that. Probably that's a
> > recipe
> > or package group file, so you can run:
> >
> > find . | grep packagegroup-base-3g
> >
> >
> > But you get nothing... Then probably this is declared somewhere a file
> with
> > another name, so let's search inside the files in the poky layer:
> >
> > grep -nriI ackagegroup-base-3g
> >
> >
> > And we get:
> >
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
> > > ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g",
> "",
> > > d)} \
> > > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
> > > ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
> > > '',d)} \
> > > poky/meta/recipes-core/packagegr
[yocto] Image introspection
Hi all,
I was thinking that the mail list shouldn't be only for problems and
questions and that from time to time, it would be nice to see some guides,
tutorials or success stories from people that follow the list.
Anyway, a few days ago someone had an issue with one of the BSPs I'm
maintaining and I wrote him a small guide on how to -try- to resolve future
issues like that. Then I thought that I haven't found a small tutorial
like this. Maybe it already exists, but nevertheless I haven't seen it.
Of course, those things are in the documentation, but they are documented
as individual tools (which is the correct thing to do), but it's not very
clear how to use all those things together to perform more complex tasks.
So, in my case the issue was that ofono was installed in the image and that
needed to be removed. Probably a lot of you already know the answer but for
me that I've never bothered with that I had to track it down how it got in
there.
Everything from now on assumes that you've setup up your bitbake environment
of your build with whatever setup scripts you're using (e.g.
*oe-init-build-env*)
There are several ways to do introspection on an image. For example,
let's say that you found a file in the in rootfs and you want to know which
recipe added that file. Then you can use this command:
oe-pkgdata-util find-path /usr/sbin/ofonod
*oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
`find-path` is pretty obvious what it does. This will return:
ofono: /usr/sbin/ofonod
So now you know that it's indeed the *ofono* recipe that adds this file.
Next,
you need how this did get in the image (probably some other dependency
because you didn't). Then you can use the `-g` parameter with bitbake like
this:
bitbake -g allwinner-image
This will create a file called `recipe-depends.dot`. This is a dot file that
has all the dependencies in the image. You can use the same command to get
the dependencies for a recipe, but now we care about the image.
Next step is to search in that file, why that key is there. Why is `-w` and
key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
and you
run this command:
oe-depends-dot -k ofono -w recipe-depends.dot
This will return the recipe that has this as dependency.
> Because: allwinner-image packagegroup-base
That means that the key is there because of allwinner-image (this is the
image
recipe, but it can be any other image) and because the *allwinner-image*
inherits the
*packagegroup-base*. So this packagegroup is the guilty.
Let's find this thing now. Get in the meta layer sources folder and run this
find . | grep packagegroup-base
This will return
> ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
Great. Open this file to an editor and find where is *ofono*. Gotcha, is in:
RDEPENDS_packagegroup-base-3g
Then it's the *packagegroup-base-3g* that does that. Probably that's a
recipe
or package group file, so you can run:
find . | grep packagegroup-base-3g
But you get nothing... Then probably this is declared somewhere a file with
another name, so let's search inside the files in the poky layer:
grep -nriI ackagegroup-base-3g
And we get:
poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> d)} \
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
> ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
> '',d)} \
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
> d.setVar("ADD_3G", "packagegroup-base-3g")
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g
> = "Cellular data support"
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g
> = "\
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g
> = "\
So it's actually in the same file that we already opened. Here you can
facepalm,
but we didn't know that, so this would be the procedure anyways to track it
down.
Now, search for *packagegroup-base-3g* inside the
*poky/meta/recipes-core/packagegroups/packagegroup-base.bb
*
and you see this line:
${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> d)} \
Therefore the *3g* in the *DISTRO_FEATURES* actually added *ofono*. That
means that,
we need to remove the *3g* string from our *DISTRO_FEATURES*.
To do that, add this to your build/conf/local.conf file
DISTRO_FEATURES_remove = " 3g"
Now just to be sure, run this to clean *ofono* from cache and everywhere
else:
bitbake -c cleanall ofono
And then rebuild the image:
bitbake image-name
Now you'll see that *ofono* won't b e downloaded or get built and it won't
be in your image.
I hope the above guide helps a bit.
I would be glad to get better suggestions or other people experience on
how they introspect their images and solve
Re: [yocto] [OE-core] Information about non-traditional uses of the Yocto Project and OpenEmbedded
Hi Gus, very interesting stuff you have there. Thanks for the heads up. Dimitris On Mon, Mar 25, 2019 at 4:10 PM Angus Lees wrote: > Oh I lie, some of my Android-SDK stuff survives: > https://github.com/anguslees/openembedded-android/wiki > > Here's a relevant scummvm forum post to put it in historical context: > https://forums.scummvm.org/viewtopic.php?p=57260=bcf54148cb83752212a19262b76551c8#p57260 > ... And my announce to the android-ndk list, that promptly resulted in the > Android powers-that-be shutting it down with prejudice. I believe the > quote was "this threatens the future of Android" ;) > https://groups.google.com/d/topic/android-ndk/Ps1RWb21zRw/discussion > > - Gus > > On Thu, 21 Mar 2019 at 15:36, Angus Lees wrote: > >> I use yocto to build an immutable disk image for several architectures of >> Kubernetes servers (currently armv7, aarch64, x86-64). It's basically a >> CoreOS Container Linux clone, except smaller and more portable. I like >> yocto/OE's powerful cross-compilation, minimalism, read-only rootfs, A/B >> image upgrades (I'm using rauc), etc. >> https://gitlab.com/containos/containos >> >> Previously I've used yocto/openembedded to build: >> - minimal x86-64 docker images, and pre-built package repository ( >> https://github.com/anguslees/boxfactory - no longer maintained now that >> alpine is a thing). >> - an early Android C/C++ sdk development environment (ie: nativesdk) - >> before the official "Android NDK" became useful. I added support for >> `repo` tool, bionic, etc - I was even doing canadian-cross to build the SDK >> on Linux/glibc, to run on win32/mingw, and compile for armv7/bionic :P >> Unfortunately this got killed by politics and never saw the light of day, >> but it was used to build the early releases of the "ScummVM" Android app >> (possibly the first native app on the Android marketplace). >> >> Indeed, I don't think I've ever used it for an actual embedded platform :P >> >> - Gus >> >> On Thu, 28 Feb 2019 at 07:01, Philip Balister >> wrote: >> >>> During the last OpenEmbedded developer meeting, it became clear that >>> people are using the Yocto project/OpenEmbedded in spaces outside what >>> we think of as traditional embedded. Lieu Ta is working on a >>> presentation for the Linux Foundation Leadership Summit and we would >>> like to collect as many "unusual" applications are possible from >>> companies we can publicly acknowledge. Unusual is edge, containers, >>> desktop, etc. Or even really interesting embedded applications :) >>> >>> Please drop me an email (off list is fine) with enough info for us to >>> add you to a slide and acknowledge your work. >>> >>> Thanks, >>> >>> Philip >>> -- >>> ___ >>> Openembedded-core mailing list >>> openembedded-c...@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>> >> >> >> -- >> - Gus >> > > > -- > - Gus > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Seeking recommendation for low cost dev board with Gigabit Ethernet that as a Yocto BSP
Hi Bob, I don't think that there's a JTAG but I guess you can use the serial port for debugging. Personally, I'm just printing messages to UART with pr_info, not even kgdb. But you may have different needs and I think that kgdb is just a kernel option. Regards, Dimitris Bob Cochran schrieb am Fr., 22. März 2019, 22:45: > On 3/22/19 5:13 PM, Dimitris Tassopoulos wrote: > > Hi Bob, > > for low cost BSPs you can have a look at some allwinner boards from > FriendlyElec and OrangePi. > > > That's excellent. Thank you. Do any of these boards have accessible JTAG > for debugging the kernel? Is this something you have done in supporting > the BSPs?I see a UART port is listed as a debug port. Is the idea to > use KGDB via this port? > > Bob > > > > I've created meta layer to support most of the H2, H3 and H5 arm cores > here: > > https://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/ > > So you can grab any of those boards that has a GbE. Now, regarding the > need of binary firmwares > for the NICs I can't tell you which of the boards the do fill your needs, > but I guess you can have > a look. > > Some boards the support GbE are: > FriendlyElec: > - NanoPi-Neo2 ~20USD ( > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2) > - NanoPi-K1 Plus ~35USD ( > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus) > - NanoPi Neo Plus2 ~35USD ( > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Plus2) > > OrangePi: > - Orange Pi Zero Plus ~15EUR ( > https://www.aliexpress.com/store/product/Orange-Pi-Zero-Plus-H5-Chip-Quad-Core-Open-source-Cortex-A53-512MB-development-board-beyond/1553371_32828347476.html > ) > - Orange Pi PC2 ~20USD ( > https://www.aliexpress.com/store/product/New-Orange-Pi-PC-2-H5-64bit-Support-the-Lubuntu-linux-and-android-mini-PC-Beyond/1553371_32761481418.html > ) > - Orange Pi Zero Plus2 ~24USD ( > https://www.aliexpress.com/store/product/Orange-Pi-Zero-Plus-2-H5-Quad-core-Bluetooth-mini-PC-Beyond-Raspberry-Pi-2-Wholesale/1553371_32801249806.html > ) > - Orange Pi Prime ~41USD ( > https://www.aliexpress.com/store/product/Orange-Pi-Prime-Development-Board-H5-Quad-core-Support-linux-and-android-Beyond-Raspberry-Pi-2/1553371_32803048527.html > ) > > Soon (probably this weekend), I'll release a new meta layer that supports > the NanoPi-Neo4 board, > which has an RK3399 + GbE. If you're interested I'll send you the link for > the repo. That costs ~50USD > (http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO4) > > Now, regarding the H2, H3 and H5 I do also support RT kernels for the 4.14 > and the 4.19. > So these are your options: > - 4.14.78 SMP > - 4.19.21 SMP > - 4.14.78 PREEMPT-RT > - 4.19.15 PREEMPT-RT > > I do updates from time to time on the layer, but not that often. > > Hope that helps a bit. > > Dimitris > > > Bob Cochran schrieb am Fr., 22. März 2019, 18:12: > >> Hello All, >> >> Can anyone recommend a ~$50 dev board that runs Yocto and has a single >> Gigabit Ethernet port? >> >> The boards we are aware of either have 100Mbit Ethernet, don't meet the >> price target, or has a Gigabit Ethernet port that has reduced >> capabilities via firmware (Ethernet driver isn't open source). >> >> Thank you, >> >> Bob >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Seeking recommendation for low cost dev board with Gigabit Ethernet that as a Yocto BSP
Hi Bob, for low cost BSPs you can have a look at some allwinner boards from FriendlyElec and OrangePi. I've created meta layer to support most of the H2, H3 and H5 arm cores here: https://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/ So you can grab any of those boards that has a GbE. Now, regarding the need of binary firmwares for the NICs I can't tell you which of the boards the do fill your needs, but I guess you can have a look. Some boards the support GbE are: FriendlyElec: - NanoPi-Neo2 ~20USD (http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2 ) - NanoPi-K1 Plus ~35USD ( http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus) - NanoPi Neo Plus2 ~35USD ( http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Plus2) OrangePi: - Orange Pi Zero Plus ~15EUR ( https://www.aliexpress.com/store/product/Orange-Pi-Zero-Plus-H5-Chip-Quad-Core-Open-source-Cortex-A53-512MB-development-board-beyond/1553371_32828347476.html ) - Orange Pi PC2 ~20USD ( https://www.aliexpress.com/store/product/New-Orange-Pi-PC-2-H5-64bit-Support-the-Lubuntu-linux-and-android-mini-PC-Beyond/1553371_32761481418.html ) - Orange Pi Zero Plus2 ~24USD ( https://www.aliexpress.com/store/product/Orange-Pi-Zero-Plus-2-H5-Quad-core-Bluetooth-mini-PC-Beyond-Raspberry-Pi-2-Wholesale/1553371_32801249806.html ) - Orange Pi Prime ~41USD ( https://www.aliexpress.com/store/product/Orange-Pi-Prime-Development-Board-H5-Quad-core-Support-linux-and-android-Beyond-Raspberry-Pi-2/1553371_32803048527.html ) Soon (probably this weekend), I'll release a new meta layer that supports the NanoPi-Neo4 board, which has an RK3399 + GbE. If you're interested I'll send you the link for the repo. That costs ~50USD (http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO4) Now, regarding the H2, H3 and H5 I do also support RT kernels for the 4.14 and the 4.19. So these are your options: - 4.14.78 SMP - 4.19.21 SMP - 4.14.78 PREEMPT-RT - 4.19.15 PREEMPT-RT I do updates from time to time on the layer, but not that often. Hope that helps a bit. Dimitris Bob Cochran schrieb am Fr., 22. März 2019, 18:12: > Hello All, > > Can anyone recommend a ~$50 dev board that runs Yocto and has a single > Gigabit Ethernet port? > > The boards we are aware of either have 100Mbit Ethernet, don't meet the > price target, or has a Gigabit Ethernet port that has reduced > capabilities via firmware (Ethernet driver isn't open source). > > Thank you, > > Bob > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] INHIBIT_SYSROOT_STRIP
My use case, as I've told to Scott, was building a bare metal firmware for a cortex m0 with an external GCC toolchain. Although, the toolchain's binaries are strippable, there are some other blob files that are needed for the build, which are not. Cheers, Dimitris Scott Rifenbark schrieb am Mi., 6. März 2019, 19:55: > Got it. Thanks Khem. > > On Wed, Mar 6, 2019 at 10:22 AM Khem Raj wrote: > >> On Wed, Mar 6, 2019 at 9:48 AM Scott Rifenbark >> wrote: >> > >> > I think we should probably at least document the variable in the YP >> Reference Manual's glossary. Correct? >> > >> >> yes and also mention that we only expect it to be used in rare special >> curcumstances, e,g, prebuilt binaries etc. >> >> > Scott >> > >> > On Wed, Mar 6, 2019 at 9:24 AM Khem Raj wrote: >> >> >> >> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark >> wrote: >> >> > >> >> > Dimitris, >> >> > >> >> > Good find... I will see about documenting this. >> >> > >> >> >> >> Although its not encouranged to use it, its to be used as a last resort >> >> we use it sparingly. >> >> >> >> > Scott >> >> > >> >> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos < >> dimt...@gmail.com> wrote: >> >> >> >> >> >> Hi all, >> >> >> >> >> >> this is not a request for help. >> >> >> >> >> >> Today, I've found a very nice option which is not documented >> >> >> which is the INHIBIT_SYSROOT_STRIP and is used in the >> sysroot_strip() >> >> >> inside the poky/meta/classes/staging.bbclass. >> >> >> >> >> >> I had an issue with a recipe that had a few binaries that I wanted >> to add to the >> >> >> recipe-sysroot-native in order to build another package and I was >> getting errors >> >> >> because the do_populate_sysroot couldn't strip those binaries. I've >> searched in >> >> >> the source and found that the author of that code was handling this >> case, but it's >> >> >> not documented (at least in the latest mega-manual). >> >> >> >> >> >> Therefore, I'm dropping this message as a reference to other that >> might need it. >> >> >> >> >> >> Regards, >> >> >> Dimitris >> >> >> -- >> >> >> ___ >> >> >> yocto mailing list >> >> >> yocto@yoctoproject.org >> >> >> https://lists.yoctoproject.org/listinfo/yocto >> >> > >> >> > -- >> >> > ___ >> >> > yocto mailing list >> >> > yocto@yoctoproject.org >> >> > https://lists.yoctoproject.org/listinfo/yocto >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] INHIBIT_SYSROOT_STRIP
Hi all, this is not a request for help. Today, I've found a very nice option which is not documented which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip() inside the poky/meta/classes/staging.bbclass. I had an issue with a recipe that had a few binaries that I wanted to add to the recipe-sysroot-native in order to build another package and I was getting errors because the do_populate_sysroot couldn't strip those binaries. I've searched in the source and found that the author of that code was handling this case, but it's not documented (at least in the latest mega-manual). Therefore, I'm dropping this message as a reference to other that might need it. Regards, Dimitris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need Support- Variable exporting
AFAIK, you can't have dynamic variables in the local.conf that you can control from bitbake. If you want to dynamically pass a variable to bitbake, you need to use the `-e` option and pass an environment file with you dynamic variables in there. Or use a custom script that calls bitbake and with some `sed` magic replace dummy variables in your local.conf. Regards, Dimitris On Mon, Nov 19, 2018 at 1:21 PM bhuvana easwari wrote: > Hi, > > I need support on the below issue. > > 1) Actually we are trying to build two machine from one meta-layer based > on some choice. > 2) Both devices having different configuration files. > 3) Now we have to export a variable from machine configuration conf file > to layer.conf > 4) Based on the exported variable value,we are choosing device specific > conf file. > > Can you please give some input on this > > Regards, > Bhuvaneswari K > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wic creates invalid image
Hi Alex, If you don't want the extended partitions you need to create a gpt partition, you can do this by adding this to your wks file. bootloader --ptable gpt Regards, Dimitris On Tue, 13 Nov 2018, 20:23 Alex Kiernan On Tue, Nov 13, 2018 at 7:13 PM Donal Morrissey > wrote: > > > > Hi There, > > I have a problem with an image being created by wic. If I add more than > 4 partition definitions to the wks file, the generated image will include > an additional partition with no Fstype, and spanning the full length of the > additional partitions. > > > > Take the following wks file: > > > > part --source rawcopy --sourceparams="file= path>/image-r0/uboot.env" --ondisk "mmcblk0" --align 4096 --no-table > > part --source bootimg-partition --ondisk "mmcblk0" --fstype=vfat --label > boot --align 4096 --active --fixed-size 40 > > part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label primary > --align 4096 --fixed-size 147456k --exclude-path data/ > > part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label secondary > --align 4096 --fixed-size 147456k --exclude-path data/ > > part --ondisk "mmcblk0" --fstype=ext4 --label appdata1 --align 4096 > --fixed-size 147456k > > part --ondisk "mmcblk0" --fstype=ext4 --label appdata2 --align 4096 > --fixed-size 147456k > > bootloader --ptable msdos > > > > wic will create a .direct file with the following structure: > > Num StartEnd Size Fstype > > 1 12582912 54525951 41943040 fat16 > > 2 54525952205520895150994944 ext4 > > 3 205520896356515839150994944 ext4 > > 4 360709632666894335306184704 > > 5 360710144511705087150994944 ext4 > > 6 515899392666894335150994944 ext4 > > > > Note the start and end addresses of partition 4, it spans from the start > of partitions 5 (appdata1) to the end of partition 6 (appdata2). > > > > If I modify the wks file and remove the entry for appdata2, the created > direct file is valid: > > > > Num StartEnd Size Fstype > > 1 12582912 54525951 41943040 fat16 > > 2 54525952205520895150994944 ext4 > > 3 205520896356515839150994944 ext4 > > 4 356515840507510783150994944 ext4 > > > > Any suggestions on what is going on here? > > > > I've not checked, but I'd assume it's switched to extended partitions, > since MBR only has 4 primary partitions. > > -- > Alex Kiernan > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto x64-linux with bootia32.efi
That's great news!
Glad to help. It's frustrating some times, but I hope that also someone
else may come with a better solution.
Regarding secureboot, I guess that if you use the same keys, then there
shouldn't be any issue. But I haven't use it, so I can't tell from
experience.
Regards,
Dimitris
On Tue, 13 Nov 2018, 08:28 Knoppix it works!
> It copied files to ESP (efi system partition).
> I hope it will work with secure boot concept too.
>
> *Mr. Dimitris *thank you so so much. I *am so glad to you* for your
> politeness and help.
>
> My best compliments..
>
> On Mon, Nov 12, 2018 at 5:51 PM Dimitris Tassopoulos
> wrote:
>
>> Yeah, I think everybody is pretty busy. This project is huge and there
>> aren't many contributors.
>>
>> Anyway, in case you use wks files, then you can create a file named
>> *test.wks.in
>> <http://test.wks.in>* (make sure you add
>> the .in at the end). Then add this (or similar depending your image):
>>
>> bootloader --ptable gpt
>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
>> --fstype=vfat --ondisk sda --label boot --active --align 1024
>> part / --source rootfs --ondisk sda --fstype=ext4 --label root --align
>> 1024 --exclude-path boot/
>>
>> The above will force wic tool not to use the default efi file that yocto
>> produces and it will use the content of the /boot
>> folder your image creates. Therefore, if you add your custom recipe that
>> copies the efi file you want, *but also* the
>> the rest of the boot files (like confs) then you can override the
>> image-efi and use your custom files from the recipe.
>>
>> For example, keep a copy of the whole boot folder that you already have,
>> then replace the efi file with your
>> precompiled and then create a recipe to copy all those files to your
>> image's /boot folder.
>>
>> I think that this may do the trick.
>>
>> The important keywords in the wks file are the `--rootfs-dir` in the
>> /boot part, which means that you force wic
>> to use your image's /boot folder. And the `--exclude-path` which forces
>> wic tool not to touch your /boot folder.
>>
>> Best regards,
>> Dimitris
>>
>> On Mon, Nov 12, 2018 at 3:37 PM Knoppix wrote:
>>
>>> Yes I did this before I sent this email. First I created x86_32 system
>>> and backup boot files. Then i created regular x64 system and move
>>> bootia32.efi file to the boot partition. (I did manualy)
>>> And yes I'm using wic and I have wks file. (I dont know how can i copy
>>> my bootia32.efi to boot partition when yocto has create image)
>>>
>>> But very soon I should implement secure boot with the system.
>>> So I think copy precompilted bootia32.efi will not work with secure
>>> system. (I am not sure)
>>>
>>> By the way this is the first mail which I took any maillist system. I'm
>>> so happy to experiment this feeling :) until now nobody answers me.
>>> Kind regards.
>>>
>>> On Mon, Nov 12, 2018 at 5:20 PM Dimitris Tassopoulos
>>> wrote:
>>>
>>>> You're right about the toolchain, this will hit wall, because the
>>>> x86_64 will build fail to build the x86 efi.
>>>>
>>>> Are you using wic and a wks file for your image?
>>>>
>>>> There might be a way to override the x86_64 efi bootloader with a
>>>> pre-compiled one.
>>>> If you do, then I may have a solution for you.
>>>>
>>>> Regards,
>>>> Dimitris
>>>>
>>>> On Mon, Nov 12, 2018 at 2:39 PM Knoppix wrote:
>>>>
>>>>> Mr. Tassopoulos
>>>>>
>>>>> Thank you so much for your answer.
>>>>>
>>>>> I am trying to do this because my device (atom cpu) has 64bit cpu but
>>>>> its efi doesn't support 64. Efi is x86. I learned that ".. The vast
>>>>> majority of EFI-based x86-64 computers use 64-bit EFIs and therefore use a
>>>>> bootx64.efi default boot loader file. A handful of early Macs and some
>>>>> Atom-based tablets have 64-bit CPUs but 32-bit EFIs ..."
>>>>> http://www.rodsbooks.com/efi-bootloaders/principles.html
>>>>>
>>>>> But I dont understand: if my target machine is x86_64 then yocto will
>>>>> prepare native/host toolchain to gcc-x64 but when we force to install grub
>>>>> as i386 what will happen? yocto will install a second toolchain for i386?
>>>>> And also shouldn't
Re: [yocto] [poky] bug #8729 grub bootloader
Hi Anuj,
thanks for the reply. First I need to say that it was insightful from your
side to use virtual/grub-bootconf
and this made things much easier. I only had to add `BBCLASSEXTEND =
"native"` in the grub-efi in
order to get `grub-editconf` for the host and create environment files on
the fly.
I had a look in your recommendation and it works after some tweaking. The `
efi-bootdisk.wks.im` file
has an example of this case, as your links suggested. It seems though that
the environment variable
`${IMAGE_ROOTFS}` in the file is not translated correctly during the
bitbake build and it fails with an
error. For example in my case the error was:
Couldn't get bitbake variable from
/rnd/yocto/grub-dev/build/tmp/sysroots/qemux86/imgdata/${IMAGE_ROOTFS}/boot.env.
After I changed the `${ROOTFS}` in `--rootfs-dir=${IMAGE_ROOTFS}/boot` with
the absolute path
then it worked. For me it's nor an issue but it's good for you to know.
Without someone pointing this
out it would be very difficult to discover the above use-case as it's not
clearly documented.
Also, it would be nice when bitbake detects that both `loader=grub-efi` and
`grub-efi_%.bb` are used
to print a warning about this overlapping and suggest the use of
`--rootfs-dir` and `--exclude-path`.
I'll continue from this point now.
Thanks again,
Dimitris
On Wed, Nov 7, 2018 at 1:58 AM Mittal, Anuj wrote:
> Hi Dimitris
>
> On Tue, 2018-11-06 at 16:12 +0100, Dimitris Tassopoulos wrote:
> >
> > In this case the bootimg-efi.py script creates the extra partition, a
> > different grub.cfg and also
> > edits the /etc/fstab and mounts this partition over /boot and
> > therefore virtual/grub-bootconf
> > becomes unused.
> >
> > This raises the following questions:
> > - Why there are two different facilities to achieve the same thing?
> > - Why the second overrides the first one, instead of sharing the same
> > files?
> > - How to proceed from now on?
> >
>
> I think this needed --exclude-path in wks to be used to take effect.
> Please see:
>
>
>
> http://lists.openembedded.org/pipermail/openembedded-core/2018-February/147837.html
>
> and bug:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10073
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] bug #8729 grub bootloader
Hi all. I'm working on bug #8729 and I'm trying to implement the multi-boot functionality for grub. I've partially done and I've created a virtual/grub-bootconf that can be used like that: PREFERRED_RPROVIDER_virtual/grub-bootconf = "grub-multibootconf" That's working ok and installs the proper grub cfg script and the environment files used for the boot counter and other stuff. The problem is that I've just hit the wall because it seems there are two different facilities that create the grub config file. One is the grub-efi & virtual/grub-bootconf. But when an wic image is build then this is overridden and a new partition is created which is also mounted in the /boot when the OS boots. The second facility is triggered by setting this in the wks file: --source bootimg-efi --sourceparams="loader=grub-efi" In this case the bootimg-efi.py script creates the extra partition, a different grub.cfg and also edits the /etc/fstab and mounts this partition over /boot and therefore virtual/grub-bootconf becomes unused. This raises the following questions: - Why there are two different facilities to achieve the same thing? - Why the second overrides the first one, instead of sharing the same files? - How to proceed from now on? In my opinion there should be only one facility that creates this and there should be a common shared way for all the use cases. I have a working example if anyone is interested. Regards, Dimitris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-docs][PATCH] Added info for ovfm
I've forgot to format... >From 89711eb7143bd832fb150442b9ca63fdf80d53fb Mon Sep 17 00:00:00 2001 From: Dimitris Tassopoulos Date: Mon, 5 Nov 2018 23:18:25 +0100 Subject: [PATCH] Added description of the ovmf option in runqemu The current documentation doesn't have any info for the ovmf option. In case you build a QEMU image with the grub-efi bootloader, then the qemu image needs the ovmf firmware to boot. Therefore, when using the runqemu script you need to pass the ovmf option. I believe this is needed as without this info there's no hint how to boot a UEFI image. I've added a sample example with the other existing ones and the option in the dev-manual-qemu.xml. I've also linked the grub-efi to the class, so it's linked in the mega-manual. I've build the documentation: $ make DOC=mega-manual and tested the edit and that the link works. --- documentation/dev-manual/dev-manual-qemu.xml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/documentation/dev-manual/dev-manual-qemu.xml b/documentation/dev-manual/dev-manual-qemu.xml index 4e7b5de4e..365b5c577 100644 --- a/documentation/dev-manual/dev-manual-qemu.xml +++ b/documentation/dev-manual/dev-manual-qemu.xml @@ -508,6 +508,7 @@ runqemu tmp/deploy/images/qemux86/qemuboot.conf runqemu qemux86-64 core-image-sato ext4 runqemu qemux86-64 wic-image-minimal wic + runqemu qemux86-64 core-image-minimal wic ovmf runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial runqemu qemux86 iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz... runqemu qemux86 qemuparams="-m 256" @@ -678,6 +679,12 @@ qemux86" or "qemux86-64". publicvnc: Enables a VNC server open to all hosts. + +ovmf: +Enables support for UEFI within QEMU. This option can be used with the +grub-efi +class. + -- On Mon, Nov 5, 2018 at 11:22 PM Dimitris Tassopoulos wrote: > Hi all, since I don't have permission to push, I'm sending the patch by > email. > This is the commit message and patch > > Added description of the ovmf option in runqemu > > The current documentation doesn't have any info for the ovmf option. > In case you build a QEMU image with the grub-efi bootloader, then the > qemu image needs the ovmf firmware to boot. Therefore, when using the > runqemu script you need to pass the ovmf option. I believe this is > needed as without this info there's no hint how to boot a UEFI image. > > I've added a sample example with the other existing ones and the option > in the dev-manual-qemu.xml. I've also linked the grub-efi to the class, > so it's linked in the mega-manual. I've build the documentation: > > $ make DOC=mega-manual > > and tested the edit and that the link works. > > index 4e7b5de4e..365b5c577 100644 > @@ -508,6 +508,7 @@ > runqemu tmp/deploy/images/qemux86/qemuboot.conf > runqemu qemux86-64 core-image-sato ext4 > runqemu qemux86-64 wic-image-minimal wic > + runqemu qemux86-64 core-image-minimal wic ovmf > runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial > runqemu qemux86 > iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz... > runqemu qemux86 qemuparams="-m 256" > @@ -678,6 +679,12 @@ qemux86" or "qemux86-64". > publicvnc: > Enables a VNC server open to all hosts. > > + > +ovmf: > +Enables support for UEFI within QEMU. This option can > be used with the > + linkend='ref-classes-grub-efi'>grub-efi > +class. > + > > > > > > Regards, > Dimitris > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH] Added info for ovfm
Hi all, since I don't have permission to push, I'm sending the patch by email. This is the commit message and patch Added description of the ovmf option in runqemu The current documentation doesn't have any info for the ovmf option. In case you build a QEMU image with the grub-efi bootloader, then the qemu image needs the ovmf firmware to boot. Therefore, when using the runqemu script you need to pass the ovmf option. I believe this is needed as without this info there's no hint how to boot a UEFI image. I've added a sample example with the other existing ones and the option in the dev-manual-qemu.xml. I've also linked the grub-efi to the class, so it's linked in the mega-manual. I've build the documentation: $ make DOC=mega-manual and tested the edit and that the link works. index 4e7b5de4e..365b5c577 100644 @@ -508,6 +508,7 @@ runqemu tmp/deploy/images/qemux86/qemuboot.conf runqemu qemux86-64 core-image-sato ext4 runqemu qemux86-64 wic-image-minimal wic + runqemu qemux86-64 core-image-minimal wic ovmf runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial runqemu qemux86 iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz... runqemu qemux86 qemuparams="-m 256" @@ -678,6 +679,12 @@ qemux86" or "qemux86-64". publicvnc: Enables a VNC server open to all hosts. + +ovmf: +Enables support for UEFI within QEMU. This option can be used with the +grub-efi +class. + Regards, Dimitris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recipes documentation
Hi all, this is a proposal for a feature, I hope it's the right way to do it. It would be nice if there would be a standard way to document recipes and then be able to read this documentation from the command line. Something like the man pages. For example, there could be either a variable in the recipe (e.g. MAN = "") or maybe better an additional file so there's no much "noise" in the recipe. For example it would be nice if there was an optional file like .man and there use preferably a markdown (or whatever) format to document the recipe. By documenting the recipe, I mean to have a short/long description how to use it properly or other valuable information. As the yocto project gets bigger and more complicated, it would be nice if there was a facility like that. There might be already and I'm not aware of that. In this case, can someone please point me to the right direction? Regards, Dimitris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel development using externalsrc
Another thing you could do is to work with git branches and have a bbappend
file to set the branch and commit hash. You will still need to push the
changes to the remote git repo, but you don't have to merge to your master
branch.
Then if you don't like just drop the branch or cherry-pick only the commits
that are valuable to the master.
Regards,
Dimitris
On Sat, 3 Nov 2018, 15:25 Uwe Geuder On Fri, Nov 2, 2018 at 5:47 PM CHMIELARZ Radoslaw
> radoslaw.chmielarz-at-leica-geosystems.com wrote:
>
> > The company I work for uses yocto to build an image with a custom
> > linux kernel. The documentation
> > (https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html)
> > suggests a setup where the kernel is under git and the kernel recipe
> > specifies this git repository hence the workflow is the following:
> >
> > Make changes in local kernel directory
> > Submit changes to git (and presumably push to shared space)
> > Run yocto build which fetches the changes
> >
> > However since I don’t want to push the changes to git server before I
> > test locally I have added the kernel sources using
> > externalsrc.
>
> Devtool is of course what they recommend, but can always change the git
> repo to a local one in a .bbappend, so you save the push step and Yocto
> build saves fetching over the network. (Making a git commit for each
> build attempt is very little overhead and I would recommend it anyway as
> a good working practice. You can clean up using "git rebase -i" once you
> are happy with your code and before you publish it.)
>
> In one of my development branches I find
>
> SRC_URI = "\
>
> git:///home/myname/projects/yoctobuild/pkgsrc/somerepo/;protocol=file;branch=debug/#675-v2.16.0
> \
> file://some.patch \
> file://other.patch \
> "
>
> SRCREV = "${AUTOREV}"
>
> I have not done it for the kernel, but I see no reason why it would not
> work there.
>
> (Obviously the absolute path is nothing you would be able to share
> unmodified with others. Maybe it can be made a bit more portable using
> ${THISDIR}, but I have not had any need to try it.)
>
> > Unfortunately this has the drawback that
> > linux-libc-headers runs do_configure and do_install phase which
> > invalidates glibc-initial and requires a recompilation of a couple of
> > hundreds of packages. I would like to avoid it.
> >
>
> How editing the kernel source would cause rebuilds trailing
> linux-libc-haeaders I cannot see in my build here
>
> $ bitbake-diffsigs -t linux-libc-headers configure
> NOTE: Starting bitbake server...
> ERROR: Only one matching sigdata file found for the specified task
> (linux-libc-headers do_configure)
>
> Well, maybe I have never changed the kernel in this build area, so let's
> check what it depends on:
>
> $ bitbake-dumpsig -t linux-libc-headers configure
> NOTE: Starting bitbake server...
> ERROR: Metadata does not support finding signature data files
>
> Hmm, no idea what that means. Until someone tells us what's wrong let's
> use stamp files instead
>
> $ bitbake-dumpsig
> tmp/stamps/corei7-64-poky-linux/linux-libc-headers/4.15.7-r0.do_configure.sigdata...
> This task depends on the checksums of files: []
> Hash for dependent task
> /home/geuder/projects/yoctobuild/meta-nel/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb.do_prepare_recipe_sysroot
> is 5ac6adcdd9edfe2705fd461a42942613
>
> $ bitbake-dumpsig
> tmp/stamps/corei7-64-poky-linux/linux-libc-headers/4.15.7-r0.do_prepare_recipe_sysroot.sigdata...
> This task depends on the checksums of files: []
> Hash for dependent task
> /home/geuder/projects/yoctobuild/meta-nel/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb.do_fetch
> is 362b694aea2202ce72ad259579d001ad
>
> $ bitbake-dumpsig
> tmp/stamps/corei7-64-poky-linux/linux-libc-headers/4.15.7-r0.do_fetch.sigdata...
> Variable SRC_URI value is
> ${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}
> Tasks this task depends on: []
> This task depends on the checksums of files: []
>
> So my build gets kernel headers from kernel.org (mirror), it does not
> use the kernel source I use to build my kernel. Maybe that's different
> for you?
>
> Of course the output of the bitbake-dumpsig commands is massively
> shortened, I just picked those lines that seemed likely candidates to
> cause rebuilds. To get the whole truth in your build call...
>
> $ bitbake-diffsigs -t linux-libc-headers configure
>
> ... after you made a small kernel edit and rebuilt.
>
> Regards,
>
> Uwe
>
> Uwe Geuder
> Neuro Event Labs Oy
> Tampere, Finland
> uwe.gexder at neuroeventlabs.com (Bot check: fix one obvious typo)
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] qemu and grub
Hi all. Usually I have a small x86_64 board that I test images. But for the first time I've tried to use yocto to do some development on grub. I've used qemu to do grub development before and I know that this works fine. I just use grub-mkrescue to create images with my grub script and then boot. Now I've tried to do the same with yocto after setting these to local.conf MACHINE ??= "qemux86" IMAGE_FSTYPES += " wic wic.vmdk" WKS_FILE ?= "directdisk-multi-rootfs.wks" IMAGE_INSTALL_append = " grub-efi" In my wks file I've set: part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label boot --active --align 1024 part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 part /rescue --source rootfs --ondisk sda --fstype=ext4 --label secondary --align 1024 bootloader --ptable gpt --timeout=10 --append="rootwait rootfstype=ext4 video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8" So, the problem is that the resulting images are using syslinux instead of grub and also the runqemu doesn't work with the produced images and complains the some of the parameters of the architecture is wrong. Any ideas? Regards, Dimitris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] nativesdk-libxcrypt-4.0.1 is failing
Cool, thanks again Ross. On Mon, Oct 29, 2018 at 4:01 PM Burton, Ross wrote: > Yes, it needs to be backported. > > Ross > On Mon, 29 Oct 2018 at 14:58, Dimitris Tassopoulos > wrote: > > > > Hi Ross, > > > > thanks for the reply. Shouldn't these kind of fixes that break a poky > branch (like Sumo now, > > which is still in use) be merged also to the affected branches and not > only future branches > > like Thud? > > > > Also, for the record anyone who has this issue, just create this file in > you layer: > > recipes-core/libxcrypt/libxcrypt_%.bbappend > > > > And then add this single line: > > SRCBRANCH = "develop" > > > > Regards, > > Dimitris > > > > On Mon, Oct 29, 2018 at 3:46 PM Burton, Ross > wrote: > >> > >> The fix is already queued in master-next, so will be n master/thud > shortly. > >> > >> Ross > >> On Mon, 29 Oct 2018 at 13:44, Dimitris Tassopoulos > wrote: > >> > > >> > Hi all, > >> > > >> > it seems that the libxcrypt recipe in poky is failing because the git > repo > >> > doesn't have a master branch anymore. The default branch has changed > >> > to `develop` and the recipe can't fetch the repo when I'm building > the SDK > >> > for my image. > >> > > >> > A temporary solution is to override the URL with a bbappend, but in > general > >> > this has broken the recipe. This is the error that I'm getting. > >> > > >> > WARNING: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Failed to fetch URL > git://github.com/besser82/libxcrypt.git;branch=master, attempting MIRRORS > if available > >> > ERROR: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Fetcher failure: Unable > to find revision 089479bb24acd168613757a6f12d63caa95416b4 in branch master > even from upstream > >> > ERROR: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Fetcher failure for > URL: 'git://github.com/besser82/libxcrypt.git;branch=master'. Unable to > fetch URL from any source. > >> > ERROR: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Function failed: > base_do_fetch > >> > ERROR: Logfile of failure stored in: > /rnd/yocto/nativeos/build/tmp/work/x86_64-nativesdk-nativeosmassdk-linux/nativesdk-libxcrypt/4.0.1-r0/temp/log.do_fetch.19081 > >> > ERROR: Task > (virtual:nativesdk:/rnd/yocto/nativeos/sources/poky/meta/recipes-core/libxcrypt/libxcrypt_4.0.1.bb:do_fetch) > failed with exit code '1' > >> > > >> > P.S another good reason to enable the own mirrors early in the > development phase. > >> > -- > >> > ___ > >> > yocto mailing list > >> > yocto@yoctoproject.org > >> > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] nativesdk-libxcrypt-4.0.1 is failing
Hi all, it seems that the libxcrypt recipe in poky is failing because the git repo doesn't have a master branch anymore. The default branch has changed to `develop` and the recipe can't fetch the repo when I'm building the SDK for my image. A temporary solution is to override the URL with a bbappend, but in general this has broken the recipe. This is the error that I'm getting. WARNING: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Failed to fetch URL git:// github.com/besser82/libxcrypt.git;branch=master, attempting MIRRORS if available ERROR: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Fetcher failure: Unable to find revision 089479bb24acd168613757a6f12d63caa95416b4 in branch master even from upstream ERROR: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Fetcher failure for URL: 'git://github.com/besser82/libxcrypt.git;branch=master'. Unable to fetch URL from any source. ERROR: nativesdk-libxcrypt-4.0.1-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /rnd/yocto/nativeos/build/tmp/work/x86_64-nativesdk-nativeosmassdk-linux/nativesdk-libxcrypt/4.0.1-r0/temp/log.do_fetch.19081 ERROR: Task (virtual:nativesdk:/rnd/yocto/nativeos/sources/poky/meta/recipes-core/libxcrypt/libxcrypt_4.0.1.bb:do_fetch) failed with exit code '1' P.S another good reason to enable the own mirrors early in the development phase. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: preempt-rt for 4.14.71 fails to build
I've already send this to that list a few days ago, but since I didn't got any reply there I've also asked here in case that someone else shares the same experience. Dimitris On Wed, 10 Oct 2018, 21:48 Bruce Ashfield, wrote: > On 2018-10-10 2:18 PM, Dimitris Tassopoulos wrote: > > Hi all! > > > > I've tried to build the latest preempt-rt kernel from the > > `v4.14/standard/preempt-rt/base` > > and it fails to build. These are the hashes I've used: > > > > This should go to the linux-yocto list, since that's where > people interested in the linux-yocto kernel variants will > notice it. > > In this case, there was a bad merge. If you check the > preempt-rt branches of 4.14 there's a fix queued, but I > haven't sent SRCREV updates yet. > > Bruce > > > ``` > > LINUX_VERSION = "4.14.71" > > SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3" > > SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3" > > ``` > > > > And the errors I get are: > > ``` > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: > > > In function '__rt_mutex_lock': > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48: > > > error: passing argument 3 of 'rt_mutex_fastlock' from incompatible > > pointer type [-Werror=incompatible-pointer-types] > >rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock); > > ^ > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: > > > note: expected 'struct ww_acquire_ctx *' but argument is of type 'int > > (*)(struct rt_mutex *, int, struct hrtimer_sleeper *, enum > > rtmutex_chainwalk, struct ww_acquire_ctx *)' > > rt_mutex_fastlock(struct rt_mutex *lock, int state, > > ^ > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2: > > > error: too few arguments to function 'rt_mutex_fastlock' > >rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock); > >^ > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: > > > note: declared here > > rt_mutex_fastlock(struct rt_mutex *lock, int state, > > ^ > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: > > > In function 'rt_mutex_lock': > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2: > > > error: too many arguments to function 'rt_mutex_lock_state' > >rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0); > >^~~ > > > /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20: > > > note: declared here > > static int __sched rt_mutex_lock_state(struct rt_mutex *lock, int > state) > > ``` > > > > Is there any change that the latest rt44 patches are nor applied? > > > > Thanks! > > Dimitris > > > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: preempt-rt for 4.14.71 fails to build
Hi all! I've tried to build the latest preempt-rt kernel from the `v4.14/standard/preempt-rt/base` and it fails to build. These are the hashes I've used: ``` LINUX_VERSION = "4.14.71" SRCREV_machine = "c37a14708f5b618602f84f83f902346e055824c3" SRCREV_meta = "1fb0b0379fb5883ce5af7485374e3f78ee4272d3" ``` And the errors I get are: ``` /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: In function '__rt_mutex_lock': /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:48: error: passing argument 3 of 'rt_mutex_fastlock' from incompatible pointer type [-Werror=incompatible-pointer-types] rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock); ^ /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: note: expected 'struct ww_acquire_ctx *' but argument is of type 'int (*)(struct rt_mutex *, int, struct hrtimer_sleeper *, enum rtmutex_chainwalk, struct ww_acquire_ctx *)' rt_mutex_fastlock(struct rt_mutex *lock, int state, ^ /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2044:2: error: too few arguments to function 'rt_mutex_fastlock' rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock); ^ /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:1935:1: note: declared here rt_mutex_fastlock(struct rt_mutex *lock, int state, ^ /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c: In function 'rt_mutex_lock': /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2069:2: error: too many arguments to function 'rt_mutex_lock_state' rt_mutex_lock_state(lock, TASK_UNINTERRUPTIBLE, 0); ^~~ /rnd/yocto/nativeos/build/tmp/work-shared/congatec/kernel-source/kernel/locking/rtmutex.c:2028:20: note: declared here static int __sched rt_mutex_lock_state(struct rt_mutex *lock, int state) ``` Is there any change that the latest rt44 patches are nor applied? Thanks! Dimitris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake error
Sometimes, I also got some weird errors like that when copying and pasting
projects (or meta layers) from one machine to other. That's because the
flags and some file stats are not copied.
On Thu, 13 Sep 2018, 18:57 Alexander Kanavin,
wrote:
> It seems as though the build system is unable to create this directory:
>
>
> /home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8
>
> You probably have a permission problem there, working from /home/b but
> attempting to create /home/yocto.
>
> Alex
>
> 2018-09-13 15:15 GMT+02:00 idealsim :
> > Hi, i'm trying to build an image with Yocto on a new machine (ubuntu
> 16.04
> > LTS)but i have this error that i can't resolve. Can you help ?
> >
> > ERROR: Execution of event handler 'uninative_event_fetchloader' failed
> > Traceback (most recent call last):
> > File
> "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> > line 55, in uninative_event_fetchloader(e= at
> > 0x7f2015027790>):
> > if not os.path.exists(tarballpath):
> > >bb.utils.mkdirhier(tarballdir)
> > if d.getVar("UNINATIVE_URL", True) == "unset":
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> > 716, in
> >
> mkdirhier(directory='/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8'):
> > if e.errno != errno.EEXIST:
> > >raise e
> >
> > OSError: [Errno 13] Permission denied:
> '/home/b/yocto-krogoth/../../yocto'
> >
> > ERROR: Command execution failed: Traceback (most recent call last):
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py",
> line
> > 104, in runAsyncCommand
> > commandmethod(self.cmds_async, self, options)
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py",
> line
> > 325, in buildTargets
> > command.cooker.buildTargets(pkgs_to_build, task)
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/cooker.py",
> line
> > 1423, in buildTargets
> > bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data)
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> > 178, in fire
> > fire_class_handlers(event, d)
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> > 110, in fire_class_handlers
> > execute_handler(name, handler, event, d)
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> > 82, in execute_handler
> > ret = handler(event)
> > File
> "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> > line 55, in uninative_event_fetchloader
> > bb.utils.mkdirhier(tarballdir)
> > File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> > 716, in mkdirhier
> > raise e
> > OSError: [Errno 13] Permission denied:
> '/home/b/yocto-krogoth/../../yocto'
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
