Date   

Webcam Streaming

andjjimenez@...
 

Hello,

I need to create an image that allows me to stream from a webcam connected to a raspberry3b to an external device (like a computer) via Wi-Fi, I can connect the computer and the raspberry via wifi but the directories added to the image for streaming and controlling the webcam were unsuccessful, I have tried with gstream. Is there any recipe for this case? Also I am using the pocky warrior version
Thanks


Re: Getting kernel patch to work

Greg Wilson-Lindberg
 

Hi Denys,
I guess I have been rather blind when putting this together. That's what I get for not copying and pasting.

Thanks,
Greg

-----Original Message-----
From: Denys Dmytriyenko <denis@...>
Sent: Wednesday, March 11, 2020 4:55 PM
To: Greg Wilson-Lindberg <GWilson@...>
Cc: Anders Montonen <Anders.Montonen@...>; Yocto list discussion
<yocto@...>
Subject: Re: [yocto] Getting kernel patch to work

${} and not $()

On Wed, Mar 11, 2020 at 11:43:36PM +0000, Greg Wilson-Lindberg wrote:
Hi Anders,

Good catch, thanks for seeing that.


I also realized that I was missing a FILESEXTRAPATHS_prepend. I have tried
both:

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
and
FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

In both cases I don't see the expansion (i.e. I see '$(FILE_DIRNAME)/files:'
or '$(THISDIR)/files:') in the list of searched directories. I would think that I
should see the expanded directory path.

Here is the net beginning of my .bbappend file:

# additions to Kernel configuration

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
#FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"
SRC_URI+= "file://0001-drm-vc4-Keep-the-binner-BO-through-
suspend.patch"


Regards,
Greg


________________________________
From: yocto@... <yocto@...> on
behalf of Anders Montonen <Anders.Montonen@...>
Sent: Tuesday, March 10, 2020 11:07:33 PM
To: Yocto list discussion
Subject: Re: [yocto] Getting kernel patch to work

Hi,

On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...>
wrote:

SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-
GWL.patch"

It looks like you have a typo here, the last letter of SRC_URI isn't
capitalized.

-a


Re: SDKPATH: how to change?

Gabriele
 

Ciao Mauro,

you can change the directory during installation


More info with


Gabriele


On Thu, Mar 12, 2020 at 3:06 PM Mauro Ziliani <mauro@...> wrote:
Hi all

I work woth imx6dl-sabresd and Krogoth.

When I build the sdk ( -c populate_sdk) the final .sh file get the
installation path as

/opt/fsl-imx-x11 ...

So I think the path is build from ${DISTRO} var as

/opt/${DISTRO}


I need to produce 3 sdk with it own final path
/opt/fsl-imx-x11-dev1

/opt/fsl-imx-x11-dev2

/opt/fsl-imx-x11-dev3


The form should be

/opt/${DISTRO}-${MYDEVICE}

So I'd like to use a common .inc and change the MYDEVICE


But I don't find where the final sdk path is combined


Any idea?


MZ



SDKPATH: how to change?

Mauro Ziliani
 

Hi all

I work woth imx6dl-sabresd and Krogoth.

When I build the sdk ( -c populate_sdk) the final .sh file get the installation path as

/opt/fsl-imx-x11 ...

So I think the path is build from ${DISTRO} var as

/opt/${DISTRO}


I need to produce 3 sdk with it own final path
/opt/fsl-imx-x11-dev1

/opt/fsl-imx-x11-dev2

/opt/fsl-imx-x11-dev3


The form should be

/opt/${DISTRO}-${MYDEVICE}

So I'd like to use a common .inc and change the MYDEVICE


But I don't find where the final sdk path is combined


Any idea?


MZ


git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Matthias Schoepfer
 

Hi!

We have noticed the following issue: We keep the versions of out software by means of tags on the git repositories, i.e. during the build, somethings like git describe --tags gets called. In yocto, our recipe of SomeLibrary might look then similar to this:

SRC_URI = "git://our.private.gitserver.org/git/SomeLibrary.git;tags=v${PV}"

When we build the image, and *then* apply a tag to HEAD, that was already built before, it seems like the tags are not fetched (my guess is git fetcher sees that origins HEAD and local HEAD have the same hash and is fine with it).

The error is, that while the correct version is built, it will report itself with a wrong version.

Is this a bug?

Regards,

Matthias

--
Dr.-Ing. Matthias Schöpfer
matthias.schoepfer@...


Re: Getting kernel patch to work

Denys Dmytriyenko
 

${} and not $()

On Wed, Mar 11, 2020 at 11:43:36PM +0000, Greg Wilson-Lindberg wrote:
Hi Anders,

Good catch, thanks for seeing that.


I also realized that I was missing a FILESEXTRAPATHS_prepend. I have tried both:

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
and
FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

In both cases I don't see the expansion (i.e. I see '$(FILE_DIRNAME)/files:' or '$(THISDIR)/files:') in the list of searched directories. I would think that I should see the expanded directory path.

Here is the net beginning of my .bbappend file:

# additions to Kernel configuration

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
#FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"
SRC_URI+= "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend.patch"


Regards,
Greg


________________________________
From: yocto@... <yocto@...> on behalf of Anders Montonen <Anders.Montonen@...>
Sent: Tuesday, March 10, 2020 11:07:33 PM
To: Yocto list discussion
Subject: Re: [yocto] Getting kernel patch to work

Hi,

On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...> wrote:

SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-GWL.patch"
It looks like you have a typo here, the last letter of SRC_URI isn't capitalized.

-a


Re: Getting kernel patch to work

Greg Wilson-Lindberg
 

Hi Anders,

Good catch, thanks for seeing that.


I also realized that I was missing a FILESEXTRAPATHS_prepend. I have tried both:

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
and
FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

In both cases I don't see the expansion (i.e. I see '$(FILE_DIRNAME)/files:' or '$(THISDIR)/files:') in the list of searched directories. I would think that I should see the expanded directory path.

Here is the net beginning of my .bbappend file:

# additions to Kernel configuration

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
#FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"
SRC_URI+= "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend.patch"


Regards,
Greg


From: yocto@... <yocto@...> on behalf of Anders Montonen <Anders.Montonen@...>
Sent: Tuesday, March 10, 2020 11:07:33 PM
To: Yocto list discussion
Subject: Re: [yocto] Getting kernel patch to work
 
Hi,

> On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...> wrote:
>
> SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-GWL.patch”

It looks like you have a typo here, the last letter of SRC_URI isn’t capitalized.

-a


Re: Splitting a recipe into multiple packages and inherit extrausers

Patrick Doyle <wpdster@...>
 

On Wed, Mar 11, 2020 at 1:26 PM Patrick Doyle via
Lists.Yoctoproject.Org <wpdster=gmail.com@...>
wrote:
I want the daemon to run as a non-root user, so I have "inherit
extrausers" in my recipe.

Suppose I only wanted to create that extra user iff the package
containing the daemon was included in the image. Is this possible?
How?
Apparently, the answer is that I should use "inherit adduser" instead
of "inherit extrausers". See
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-classes-useradd.

--wpd


Re: EXTRA_OECMAKE options are ignored #sdk #yocto

Khem Raj
 

On 3/11/20 3:37 AM, Armando Hernandez wrote:
Hi,
I built an eSDK.
Now I'm using devtool add to create a hello world recipe.
Once the recipe was in place, I added some cmake optoins via EXTRA_OECMAKE in htis way:
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE=BOTH \
 -CMAKE_FIND_ROOT_PATH=/home/user/SDK/sysroots/x86_64-pokysdk-linux \
                   "
Now, the problem is that after running devtool  build test-hello (where test-hello is my recipe as you might have assumed), these variables are overwritten with other values.
How can I successfully pass the correct cmake options via EXTRA_OECMAKE on the recipe?

please post your recipe



Splitting a recipe into multiple packages and inherit extrausers

Patrick Doyle <wpdster@...>
 

I may be overthinking/overtweaking this but...

I have a recipe with that creates a number of executables, one of
which is a daemon.

I have split that daemon off into its own separate package using the
PACKAGES =+ "${PN]-blah-blah-blah" construct.

I want the daemon to run as a non-root user, so I have "inherit
extrausers" in my recipe.

Suppose I only wanted to create that extra user iff the package
containing the daemon was included in the image. Is this possible?
How?

--wpd


Re: Uboot NetBoot IMX8

Trevor
 

Hi Nicolas,


Thanks!

Extracting as root did the trick, I was extracting using the desktop extracter before.

I didnt end up adding fsid=root option because that caused it not to mount at all for some reason.

Thanks,
Trevor





From: yocto@... <yocto@...> on behalf of Nicolas Jeker <n.jeker@...>
Sent: Wednesday, March 11, 2020, 1:43 AM
To: yocto@...
Subject: Re: [yocto] Uboot NetBoot IMX8

On Wed, 2020-03-11 at 00:39 +0000, Trevor wrote:
> > Mar 11 00:21:16 b2qt-b9-imx8mq mount[2611]: mount: only root can
> > use "--types" option (effective UID is 1000)
>
>
> The mount error seems prevalent across all the errors.  somehow UID
> is 1000 when it should be 0 during boot?

By googling the error message I found a thread where somebody has the
same question, but I wouldn't recommend following the advice there
(running the yocto build as root). How do you extract the root
filesystem to your NFS directory? Maybe something is wrong there and
the files get extracted with UID 1000 as owner. For reference, I use
this command which seems to work fine:

sudo tar --strip-components=1 -C /srv/nfs/rootfs -xf images/apalis-
imx6-mainline/Apalis-iMX6-Mainline_Image.rootfs.tar.xz

Also check that there are no setuid/setgid bits set.

> On the Host side, here are the /etc/exports options for NFS:
>  *(rw,sync,insecure,no_subtree_check,no_root_squash)

I'm using pretty much the same NFS options, the only difference I could
spot is an additional 'fsid=root' in my exports which is NFSv4
specific.



Re: Should changing a task in the .bb file cause the task to be rerun?

Sean McKay
 

I actually went on vacation right after I sent that message. (Thank you for your incredibly quick reply, by the way!)
Once I get back late next week, I'll try to see how reproducible it is in our environment and if so, what the minimum steps are to do so.

Thanks!
-Sean

~Sean
Sent from my phone. Please forgive terseness and typos!


From: Mikko.Rapeli@... <Mikko.Rapeli@...>
Sent: Wednesday, March 11, 2020 12:45:21 PM
To: richard.purdie@... <richard.purdie@...>
Cc: McKay, Sean <sean.mckay@...>; yocto@... <yocto@...>
Subject: Re: [yocto] Should changing a task in the .bb file cause the task to be rerun?
 
On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
> On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
> > On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
> > > On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
> > > > This is probably a fairly short question (I hope):
> > > > I’m working on a branch based on zeus. I found a bug in the way that
> > > > one of our recipes was handling something during do_configure (which
> > > > caused an error to pop up in a do_compile task). When I modified the
> > > > do_configure task (do_configure_append, actually) to behave properly
> > > > (which involved changing the actual commands run in that function)
> > > > and reran bitbake -c compile <recipe>, the do_configure task wasn’t
> > > > rerun despite the change to the function’s code.
> > > > 
> > > > Is it safe to assume this means we’ve done something to mess up the
> > > > way our system is processing things? Or is that expected behavior
> > >
> > > Its not expected behaviour and yes, it sounds like something is messed
> > > up...
> >
> > This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
> > 3.0 zeus.
> >
> > That's why I always write:
> >
> > $ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile recipe
> >
> > when debugging changes in recipes to_compile and other dependent tasks.
> > I'm also cleaning up sstate to be sure it's not corrupt or filled with
> > somehow bad data.
>
> This is bad and shouldn't be happening. Can anyone provide some
> examples I can look at?
>
> You shouldn't ever need to run cleansstate in particular. If you have
> to, there is another underlying bug that should get fixed.

Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.

-Mikko


Re: Should changing a task in the .bb file cause the task to be rerun?

Robert P. J. Day
 

Quoting Mikko Rapeli <mikko.rapeli@...>:

On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
This is probably a fairly short question (I hope):
I’m working on a branch based on zeus. I found a bug in the way that
one of our recipes was handling something during do_configure (which
caused an error to pop up in a do_compile task). When I modified the
do_configure task (do_configure_append, actually) to behave properly
(which involved changing the actual commands run in that function)
and reran bitbake -c compile <recipe>, the do_configure task wasn’t
rerun despite the change to the function’s code.

Is it safe to assume this means we’ve done something to mess up the
way our system is processing things? Or is that expected behavior
Its not expected behaviour and yes, it sounds like something is messed
up...
This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
3.0 zeus.

That's why I always write:

$ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c
compile recipe

when debugging changes in recipes to_compile and other dependent tasks.
I'm also cleaning up sstate to be sure it's not corrupt or filled with
somehow bad data.
This is bad and shouldn't be happening. Can anyone provide some
examples I can look at?

You shouldn't ever need to run cleansstate in particular. If you have
to, there is another underlying bug that should get fixed.
Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.
Have you verified with "bitbake -e" that the configure task was really
appended to WRT the build? That's the first thing I would check.

rday


Re: Should changing a task in the .bb file cause the task to be rerun?

Mikko Rapeli
 

On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
This is probably a fairly short question (I hope):
I’m working on a branch based on zeus. I found a bug in the way that
one of our recipes was handling something during do_configure (which
caused an error to pop up in a do_compile task). When I modified the
do_configure task (do_configure_append, actually) to behave properly
(which involved changing the actual commands run in that function)
and reran bitbake -c compile <recipe>, the do_configure task wasn’t
rerun despite the change to the function’s code.

Is it safe to assume this means we’ve done something to mess up the
way our system is processing things? Or is that expected behavior
Its not expected behaviour and yes, it sounds like something is messed
up...
This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
3.0 zeus.

That's why I always write:

$ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile recipe

when debugging changes in recipes to_compile and other dependent tasks.
I'm also cleaning up sstate to be sure it's not corrupt or filled with
somehow bad data.
This is bad and shouldn't be happening. Can anyone provide some
examples I can look at?

You shouldn't ever need to run cleansstate in particular. If you have
to, there is another underlying bug that should get fixed.
Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.

-Mikko


EXTRA_OECMAKE options are ignored #sdk #yocto

Armando Hernandez
 

Hi,

I built an eSDK.
Now I'm using devtool add to create a hello world recipe.
Once the recipe was in place, I added some cmake optoins via EXTRA_OECMAKE in htis way:
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE=BOTH \
                   -CMAKE_FIND_ROOT_PATH=/home/user/SDK/sysroots/x86_64-pokysdk-linux \
                   "

Now, the problem is that after running devtool  build test-hello (where test-hello is my recipe as you might have assumed), these variables are overwritten with other values.

How can I successfully pass the correct cmake options via EXTRA_OECMAKE on the recipe?


Re: Uboot NetBoot IMX8

Laurent Gauthier
 

Hi all,

I would second what Nicolas pointed out:

* on the server side you want to make sure that you extract the rootfs tar file as user root.

Kind Regards, Laurent.


On Wed, Mar 11, 2020 at 8:43 AM Nicolas Jeker <n.jeker@...> wrote:
On Wed, 2020-03-11 at 00:39 +0000, Trevor wrote:
> > Mar 11 00:21:16 b2qt-b9-imx8mq mount[2611]: mount: only root can
> > use "--types" option (effective UID is 1000)
>
>
> The mount error seems prevalent across all the errors.  somehow UID
> is 1000 when it should be 0 during boot?

By googling the error message I found a thread where somebody has the
same question, but I wouldn't recommend following the advice there
(running the yocto build as root). How do you extract the root
filesystem to your NFS directory? Maybe something is wrong there and
the files get extracted with UID 1000 as owner. For reference, I use
this command which seems to work fine:

sudo tar --strip-components=1 -C /srv/nfs/rootfs -xf images/apalis-
imx6-mainline/Apalis-iMX6-Mainline_Image.rootfs.tar.xz

Also check that there are no setuid/setgid bits set.

> On the Host side, here are the /etc/exports options for NFS:
>  *(rw,sync,insecure,no_subtree_check,no_root_squash)

I'm using pretty much the same NFS options, the only difference I could
spot is an additional 'fsid=root' in my exports which is NFSv4
specific.




--
Laurent Gauthier
Phone: +33 630 483 429
http://soccasys.com


Re: Menuconfig for imx8mq-var-dart #yocto

Christian Lohr <christian.lohr.ext@...>
 

Hello,

 

I’m new to Yocto to, so take my advice with care. You should use “bitbake linux-variscite -c menuconfig”, and I think the following line in the conf/local.conf should be deleted:

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

 

Take a look in these files:

meta-variscite-imx/conf/machine/imx8mm-var-dart.conf

18:PREFERRED_PROVIDER_virtual/kernel_imx8mm-var-dart ?= "linux-variscite"

 

meta-variscite-imx/conf/machine/imx8mq-var-dart.conf

18:PREFERRED_PROVIDER_virtual/kernel_imx8mq-var-dart ?= "linux-variscite"

 

As far as I know, the kernel recipe “linux-yocto” gets overrided by these Machine configuration files.

 

Best regards,

 

 

Christian Lohr

Im Auftrag von:

Carl Zeiss Meditec AG
Göschwitzer Strasse 51-52

07745 Jena, Deutschland

christian.lohr.ext@...

 

Von: yocto@... <yocto@...> Im Auftrag von Amrun Nisha.R
Gesendet: Mittwoch, 11. März 2020 07:22
An: yocto@...
Betreff: [yocto] Menuconfig for imx8mq-var-dart #yocto

 

I want to use the menu config for the imx8mq-var-dart machine. I have updated the conf/local.conf with imx8mq-var-dart configurations. 

 

MACHINE ??= 'imx8mq-var-dart'
DISTRO ?= 'fsl-imx-wayland'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"

COMPATIBLE_MACHINE_imx8mq-var-dart = "imx8mq-var-dart"
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"

EXTRA_IMAGES_FEATURES += "
tools-debug \
eclipse-debug \
read-only-rootfs \
"

IMAGE-INSTALL-append = " \
tcf-agent \
openssh-sft-server \
"

 

While running the command "bitbake linux-yocto -c menuconfig", it is throwing error as 

 

ERROR: Nothing PROVIDES 'linux-yocto'
linux-yocto was skipped: incompatible with machine imx8mq-var-dart (not in COMPATIBLE_MACHINE)
linux-yocto was skipped: incompatible with machine imx8mq-var-dart (not in COMPATIBLE_MACHINE)
linux-yocto was skipped: incompatible with machine imx8mq-var-dart (not in COMPATIBLE_MACHINE)

How can i work with menuconfig for imx8mq-var-dart?


Re: Uboot NetBoot IMX8

Nicolas Jeker
 

On Wed, 2020-03-11 at 00:39 +0000, Trevor wrote:
Mar 11 00:21:16 b2qt-b9-imx8mq mount[2611]: mount: only root can
use "--types" option (effective UID is 1000)

The mount error seems prevalent across all the errors. somehow UID
is 1000 when it should be 0 during boot?
By googling the error message I found a thread where somebody has the
same question, but I wouldn't recommend following the advice there
(running the yocto build as root). How do you extract the root
filesystem to your NFS directory? Maybe something is wrong there and
the files get extracted with UID 1000 as owner. For reference, I use
this command which seems to work fine:

sudo tar --strip-components=1 -C /srv/nfs/rootfs -xf images/apalis-
imx6-mainline/Apalis-iMX6-Mainline_Image.rootfs.tar.xz

Also check that there are no setuid/setgid bits set.

On the Host side, here are the /etc/exports options for NFS:
*(rw,sync,insecure,no_subtree_check,no_root_squash)
I'm using pretty much the same NFS options, the only difference I could
spot is an additional 'fsid=root' in my exports which is NFSv4
specific.


Re: Getting kernel patch to work

Anders Montonen
 

Hi,

On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...> wrote:

SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-GWL.patch”
It looks like you have a typo here, the last letter of SRC_URI isn’t capitalized.

-a


Menuconfig for imx8mq-var-dart #yocto

Amrun Nisha.R
 

I want to use the menu config for the imx8mq-var-dart machine. I have updated the conf/local.conf with imx8mq-var-dart configurations. 
 
MACHINE ??= 'imx8mq-var-dart'
DISTRO ?= 'fsl-imx-wayland'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"

COMPATIBLE_MACHINE_imx8mq-var-dart = "imx8mq-var-dart"
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"

EXTRA_IMAGES_FEATURES += "
tools-debug \
eclipse-debug \
read-only-rootfs \
"

IMAGE-INSTALL-append = " \
tcf-agent \
openssh-sft-server \
"
 
While running the command "bitbake linux-yocto -c menuconfig", it is throwing error as 
 
ERROR: Nothing PROVIDES 'linux-yocto'
linux-yocto was skipped: incompatible with machine imx8mq-var-dart (not in COMPATIBLE_MACHINE)
linux-yocto was skipped: incompatible with machine imx8mq-var-dart (not in COMPATIBLE_MACHINE)
linux-yocto was skipped: incompatible with machine imx8mq-var-dart (not in COMPATIBLE_MACHINE)

How can i work with menuconfig for imx8mq-var-dart?

9061 - 9080 of 57807