Date   

Re: LINUX_VERSION_EXTENSION has no effect #dunfell #yocto #kernel

mrkozmic@...
 

Bruce,
It's an honor to get help from the author himself!

I'm starting to understand why they have this:

do_configure_prepend() {
     cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
}

Since do_kernel_configme() creates the .config file in https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-yocto.bbclass?h=dunfell#n399
(I can't figure out why it fails to merge in our defconfig)

Then the ${WORKDIR}/defconfig is not used by kernel_do_configure() https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n595
So they do the copy of defconfig in do_configure_prepend(). 

Anyway,  do_kernel_configme() has already been run hence no CONFIG_LOCALVERSION is written to .config


I could just do this:
do_configure_prepend() {
     cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
     echo "CONFIG_LOCALVERSION=\"${LINUX_VERSION_EXTENSION}\"" >> "${B}/.config"
}

 

BUT
Your hint make me notice that they did: KCONFIG_MODE="--allnoconfig" which breaks the config merging.
After changing it to alldefconfig and removing do_configure_prepend it all works!

Thank you!
 

 

 


Re: LINUX_VERSION_EXTENSION has no effect #dunfell #yocto #kernel

mrkozmic@...
 

Bruce, I just realized that I replied only to you and not to the group. Hope it is ok that I post your answer here. 
 

On Sat, Oct 9, 2021 at 6:19 AM <mrkozmic@...> wrote:
>
> Bruce,
>
> Here .config is written in the kernel_configme task: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.yoctoproject.org%2Fcgit%2Fcgit.cgi%2Fpoky%2Ftree%2Fmeta%2Fclasses%2Fkernel-yocto.bbclass%3Fh%3Ddunfell%23n409&amp;data=04%7C01%7C%7C7757b810abc444e512cc08d98b32ecb1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637693873092757103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FURpcXvzhAKEpN%2BHHmmMpshn3CJNHJxUvFkktaGCf80%3D&amp;reserved=0
>

Yes, I'm the one that wrote all of the fragment handling and
processing, so unless something else is being injected into the tasks,
I know how it should work :)

> My kernel recipe (not written by me) is made up of several files. I found this:
> do_configure_prepend() {
>     cp "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" "${B}/.config" || bbfatal "CONFIG ${KBUILD_DEFCONFIG} NOT FOUND"
> }
> Which makes sense why it does not work. So I removed these lines and I see why someone put them there. My defconfig is not put into the .config file by the merge_config.sh script.
> It looks like the script does everything correctly, but the resulting .config is always the default, nothing is included from my defconfig.

Considering that linux-yocto has had support for using an in-tree
defconfig for a long time, indeed, that is a strange thing for someone
to write!

Is KBUILD_DEFCONFIG defined in your recipe ? If so, the kernel-yocto
bbclass will do a similar copy and use that as the baseline.

>
> The final .config is generated in merge_config.sh by
> make LD="$LD" KCONFIG_ALLCONFIG=$TMP_FILE $OUTPUT_ARG $ALLTARGET
> I have checked, and the $TMP_FILE is the same as my defconfig. The log from merge_script.sh lists all CONFIG_* that where requested, but not included in the final .config, they all come from my defconfig.
>
> Looks like make does not care about KCONFIG_ALLCONFIG=$TMP_FILE

No, that wouldn't be the case.

Just because you have something in a defconfig, or a configuration
fragment, doesn't mean that it ends up in the final .config. They are
still subject to the dependencies, defaults, selects, etc, of the
Kconfig files within the kernel tree as the configuration phase of the
kernel is executed.

If you have a defconfig in your workdir, the mode of merge config is
set to "-n", which is an allnoconfig, and then what you have in your
defconfig will be applied based on those conditions. If your defconfig
is based on a savedefconfig (which many of them are now, in particular
in tree ones).  If you want to use defaults  and then apply your
defconfig, you need to specify KCONFIG_MODE="alldefconfig" in your
kernel recipe (maybe you are already doing that, but it is worth
mentioning).

But given that KBUILD_DEFCONFIG copy that you found, clearly there are
some custom things happening, so I really can't say for sure.
 
 
Bruce

>



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: #zeus meta-intel #zeus

Anuj Mittal
 

On Fri, 2021-10-08 at 16:10 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:

Sorry for my ignorance, but I am missing your point, what exactly
does the recipe provide when built, intel-opencl-icd ?, will it pull
in igc ?
It will pull in igc. There's a separate recipe for igc in meta-intel.
compute-runtime will provide intel-opencl-icd but the package name is
different.

You can try building the recipe.

Thanks,

Anuj


-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 12:01 PM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros. 
For further information on how to spot phishing, access
“Cybersecurity OneSpace Page” and report phishing by clicking the
button “Report Phishing” on the Outlook toolbar.


Sorry, I didn't understand the question. If you want to know which
version of OpenCL is supported, please see the README for version
that you're building. Also see:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj

On Fri, 2021-10-08 at 15:30 +0000, Monsees, Steven C (US) wrote:

Thank you, just for clarification ...

"Building the Neo driver", does that mean no OpenCL library support
?

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 11:07 AM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are
requested
to click on a link, decrypt/open an attachment, or enable macros. 
For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
 
 
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
opencl/compute-runtime”
I have been “told” that this compute-runtime recipe should
basically
build opencl (Neo) with all the required dependencies… I did not
think Yocto had support for OpenCL, and was looking to build Neo
under the SDK.
 
(1)   Is this true, does meta-intell under zeus now support
building
OpenCL and the OpenCL Graphics compiler under Yocto ?
compute-runtime recipe would allow you to build NEO driver. zeus is
no
longer maintained so the version there is old and not tested now
but
it should still build.

(2)   Of so, what would be the proper way to pull this into my
yocto
build ?
Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj



Re: LINUX_VERSION_EXTENSION has no effect #dunfell #yocto #kernel

Bruce Ashfield
 

On Fri, Oct 8, 2021 at 11:52 AM <mrkozmic@...> wrote:

I have defined LINUX_VERSION_EXTENSION in my kernel recipe.

I have no CONFIG_LOCALVERSION or CONFIG_LOCALVERSION_AUTO defined in my defconfig

After i run bitbake -c kernel_configme <my kernel recipe> I can see in my .config file:

CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set

and at the very end:

CONFIG_LOCALVERSION="<my extention>"
So far so good.

Then I execute bitbake -c configure <my kernel recipe>
and the .config file is changed. Now there is:
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
and there is no trace of CONFIG_LOCALVERSION="<my extention>"
Assuming what you are using as a kernel recipe is linux-yocto based,
the code that is adding the CONFIG_LOCALVERSION is a task that runs
after do_configure. So just running -c configure, it shouldn't be in
the .config (and the default kernel configure task, will copy your
defconfig -> .config, and then lets the kernel process it, so you will
have symbols in the .config that are not in your defconfig
explicitly).

If you can make your recipe available, I can probably offer more
specific comments.

Bruce


Yocto: dunfell
Kernel 5.4.70









--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: #zeus meta-intel #zeus

Monsees, Steven C (US)
 

Sorry for my ignorance, but I am missing your point, what exactly does the recipe provide when built, intel-opencl-icd ?, will it pull in igc ?

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 12:01 PM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


Sorry, I didn't understand the question. If you want to know which version of OpenCL is supported, please see the README for version that you're building. Also see:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj

On Fri, 2021-10-08 at 15:30 +0000, Monsees, Steven C (US) wrote:

Thank you, just for clarification ...

"Building the Neo driver", does that mean no OpenCL library support ?

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 11:07 AM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.  For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
 
 
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
opencl/compute-runtime”
I have been “told” that this compute-runtime recipe should basically
build opencl (Neo) with all the required dependencies… I did not
think Yocto had support for OpenCL, and was looking to build Neo
under the SDK.
 
(1)   Is this true, does meta-intell under zeus now support building
OpenCL and the OpenCL Graphics compiler under Yocto ?
compute-runtime recipe would allow you to build NEO driver. zeus is no
longer maintained so the version there is old and not tested now but
it should still build.

(2)   Of so, what would be the proper way to pull this into my yocto
build ?
Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj


Re: #zeus meta-intel #zeus

Anuj Mittal
 

Sorry, I didn't understand the question. If you want to know which
version of OpenCL is supported, please see the README for version that
you're building. Also see:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj

On Fri, 2021-10-08 at 15:30 +0000, Monsees, Steven C (US) wrote:

Thank you, just for clarification ...

"Building the Neo driver", does that mean no OpenCL library support ?

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 11:07 AM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested to
click on a link, decrypt/open an attachment, or enable macros.  For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
 
 
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
opencl/compute-runtime”
I have been “told” that this compute-runtime recipe should basically
build opencl (Neo) with all the required dependencies… I did not
think
Yocto had support for OpenCL, and was looking to build Neo under the
SDK.
 
(1)   Is this true, does meta-intell under zeus now support building
OpenCL and the OpenCL Graphics compiler under Yocto ?
compute-runtime recipe would allow you to build NEO driver. zeus is no
longer maintained so the version there is old and not tested now but it
should still build.

(2)   Of so, what would be the proper way to pull this into my yocto
build ?
Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj


LINUX_VERSION_EXTENSION has no effect #dunfell #yocto #kernel

mrkozmic@...
 

I have defined LINUX_VERSION_EXTENSION in my kernel recipe.

I have no CONFIG_LOCALVERSION or CONFIG_LOCALVERSION_AUTO defined in my defconfig

After i run bitbake -c kernel_configme <my kernel recipe> I can see in my .config file:

CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set

and at the very end:

CONFIG_LOCALVERSION="<my extention>"
So far so good.

Then I execute  
bitbake -c configure <my kernel recipe>
and the .config file is changed. Now there is:
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
and there is no trace of 
CONFIG_LOCALVERSION="<my extention>"

Yocto: dunfell
Kernel 5.4.70

 
 

 


Re: #zeus meta-intel #zeus

Monsees, Steven C (US)
 

Thank you, just for clarification ...

"Building the Neo driver", does that mean no OpenCL library support ?

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Friday, October 8, 2021 11:07 AM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
 
 
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
opencl/compute-runtime”
I have been “told” that this compute-runtime recipe should basically
build opencl (Neo) with all the required dependencies… I did not think
Yocto had support for OpenCL, and was looking to build Neo under the
SDK.
 
(1)   Is this true, does meta-intell under zeus now support building
OpenCL and the OpenCL Graphics compiler under Yocto ?
compute-runtime recipe would allow you to build NEO driver. zeus is no longer maintained so the version there is old and not tested now but it should still build.

(2)   Of so, what would be the proper way to pull this into my yocto
build ?
Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj


Re: #zeus meta-intel #zeus

Anuj Mittal
 

On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
 
 
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
opencl/compute-runtime”
I have been “told” that this compute-runtime recipe should basically
build opencl (Neo) with all the required dependencies…
I did not think Yocto had support for OpenCL, and was looking to
build Neo under the SDK.
 
(1)   Is this true, does meta-intell under zeus now support building
OpenCL and the OpenCL Graphics compiler under Yocto ?
compute-runtime recipe would allow you to build NEO driver. zeus is no
longer maintained so the version there is old and not tested now but it
should still build.

(2)   Of so, what would be the proper way to pull this into my yocto
build ?
Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj


Re: How to submit/create a new repository in http://git.yoctoproject.org/

Armin Kuster
 

Hello Tien,



On 10/7/21 9:02 PM, thloh85@... wrote:
Hi all,

I'm from StarFive and am working on distro for our risc-v based processor.
We currently have a repository
(https://github.com/starfive-tech/meta-starfive) and wish to get the
repository to be part of git.yoctoproject.org.
Since you already have a layer, have you thought about registering it
with the layer-index ? http://layers.openembedded.org

- Armin
I couldn't find any information on the process to get the repository
into git.yoctoproject.org. Can someone help show me the process?


Thanks
Tien Hock



[meta-selinux][dunfell][PATCH] libselinux: Backport NULL pointer fix from 3.1

Jonas Brich
 

Attached the diff.


Thanks



BMW Car IT GmbH
Jonas Brich
Spezialist Entwicklung
Lise-Meitner-Str. 14
89081 Ulm

Tel.:  +49 731 3780 4292
Mail: jonas.brich@...
Web: http://www.bmw-carit.de
----------------------------------------------------------------------
BMW Car IT GmbH
Geschaeftsfuehrer: Kai-Uwe Balszuweit und Michael Böttrich
Sitz und Registergericht: Muenchen HRB 134810
----------------------------------------------------------------------


Re: How to submit/create a new repository in http://git.yoctoproject.org/

Alexander Kanavin
 

On Fri, 8 Oct 2021 at 14:05, Nicolas Dechesne <nicolas.dechesne@...> wrote:
hey,

On Fri, Oct 8, 2021 at 1:53 PM Alexander Kanavin <alex.kanavin@...> wrote:
There's also a more specific thing you'd need to resolve: I believe you'd need to pass all of the requirements listed here:

Not really. We definitely believe that the Yocto Project Compatible program is a valuable tool for our ecosystem. However, layers on git.yp.org are not required to be compatible. But that's a good suggestion for the future, perhaps ;) 

Still, that list has items that should be fulfilled even without seeking YP compatibility, for instance:

9. All layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements.

The layer linked above does not have that in its README. Passing the YP compatibility script is also a useful badge of quality.

Alex


Re: How to submit/create a new repository in http://git.yoctoproject.org/

Nicolas Dechesne
 

hey,

On Fri, Oct 8, 2021 at 1:53 PM Alexander Kanavin <alex.kanavin@...> wrote:
There's also a more specific thing you'd need to resolve: I believe you'd need to pass all of the requirements listed here:

Not really. We definitely believe that the Yocto Project Compatible program is a valuable tool for our ecosystem. However, layers on git.yp.org are not required to be compatible. But that's a good suggestion for the future, perhaps ;) 


Alex

On Fri, 8 Oct 2021 at 11:58, <tienhock.loh@...> wrote:
Hi Alex,

Actually we'd like to have it up and get everything (including meta-riscv by Khem) into git.yoctoproject.org so that everything in consolidated into a central location.
Does that make sense? Or it is expected that vendors do host their own repository? I see meta-intel, meta-xillinx, so I suspect platform vendor should also get the layers into git.yoctoproject.org

I just read that we'll need to join membership to get repos into the git. I will discuss this with the management.

Thanks for the quick response Alex. 






Re: How to submit/create a new repository in http://git.yoctoproject.org/

Alexander Kanavin
 

There's also a more specific thing you'd need to resolve: I believe you'd need to pass all of the requirements listed here:

Alex


On Fri, 8 Oct 2021 at 11:58, <tienhock.loh@...> wrote:
Hi Alex,

Actually we'd like to have it up and get everything (including meta-riscv by Khem) into git.yoctoproject.org so that everything in consolidated into a central location.
Does that make sense? Or it is expected that vendors do host their own repository? I see meta-intel, meta-xillinx, so I suspect platform vendor should also get the layers into git.yoctoproject.org

I just read that we'll need to join membership to get repos into the git. I will discuss this with the management.

Thanks for the quick response Alex. 



Re: How to submit/create a new repository in http://git.yoctoproject.org/

tienhock.loh@...
 

Hi Alex,

Actually we'd like to have it up and get everything (including meta-riscv by Khem) into git.yoctoproject.org so that everything in consolidated into a central location.
Does that make sense? Or it is expected that vendors do host their own repository? I see meta-intel, meta-xillinx, so I suspect platform vendor should also get the layers into git.yoctoproject.org

I just read that we'll need to join membership to get repos into the git. I will discuss this with the management.

Thanks for the quick response Alex. 


Re: How to submit/create a new repository in http://git.yoctoproject.org/

Alexander Kanavin
 

Hello Tien,

I have to ask first: is there a reason you'd like to have it there?

Alex


On Fri, 8 Oct 2021 at 06:02, <thloh85@...> wrote:
Hi all,

I'm from StarFive and am working on distro for our risc-v based processor.
We currently have a repository (https://github.com/starfive-tech/meta-starfive) and wish to get the repository to be part of git.yoctoproject.org
I couldn't find any information on the process to get the repository into git.yoctoproject.org. Can someone help show me the process?

Thanks
Tien Hock



Re: How to enable graphics acceleration on qemux86-64?

Alexander Kanavin
 

Something in your custom setup disables opengl in qemu-system-native.

Can you try core-image-weston with plain poky only?

This is the test we use to ensure it does work, it lists all the settings that have to be in place
(but in poky they are enabled by default, except the gtk frontend):

Alex


On Fri, 8 Oct 2021 at 10:26, Manuel Wagesreither <ManWag@...> wrote:
Hello all,

How can I enable graphics acceleration on qemux86-64? My image is using wayland with weston and the GUI is not exactly fast.

* When I do `runqemu slirp kvm gtk`, it throws the following error: `runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: Display 'gtk' is not available.`
* `runqemu slirp kvm sdl` works, but the weston GUI does not seem to be accelerated.
* `runqemu slirp kvm sdl gl` emits the following: `runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: OpenGL support is disabled`

Below I'm posting a snippet of `poky/scripts/runqemu` to have at hand the qemu options enabled by the runqemu options mentioned above:
```
            elif arg == 'sdl':
                if 'gl' in sys.argv[1:]:
                    self.qemu_opt_script += ' -vga virtio -display sdl,gl=on'
                elif 'gl-es' in sys.argv[1:]:
                    self.qemu_opt_script += ' -vga virtio -display sdl,gl=es'
                else:
                    self.qemu_opt_script += ' -display sdl'
            elif arg == 'gtk':
                if 'gl' in sys.argv[1:]:
                    self.qemu_opt_script += ' -vga virtio -display gtk,gl=on'
                elif 'gl-es' in sys.argv[1:]:
                    self.qemu_opt_script += ' -vga virtio -display gtk,gl=es'
                else:
                    self.qemu_opt_script += ' -display gtk'
```

Kind regards,
Manuel




How to enable graphics acceleration on qemux86-64?

Manuel Wagesreither
 

Hello all,

How can I enable graphics acceleration on qemux86-64? My image is using wayland with weston and the GUI is not exactly fast.

* When I do `runqemu slirp kvm gtk`, it throws the following error: `runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: Display 'gtk' is not available.`
* `runqemu slirp kvm sdl` works, but the weston GUI does not seem to be accelerated.
* `runqemu slirp kvm sdl gl` emits the following: `runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: OpenGL support is disabled`

Below I'm posting a snippet of `poky/scripts/runqemu` to have at hand the qemu options enabled by the runqemu options mentioned above:
```
elif arg == 'sdl':
if 'gl' in sys.argv[1:]:
self.qemu_opt_script += ' -vga virtio -display sdl,gl=on'
elif 'gl-es' in sys.argv[1:]:
self.qemu_opt_script += ' -vga virtio -display sdl,gl=es'
else:
self.qemu_opt_script += ' -display sdl'
elif arg == 'gtk':
if 'gl' in sys.argv[1:]:
self.qemu_opt_script += ' -vga virtio -display gtk,gl=on'
elif 'gl-es' in sys.argv[1:]:
self.qemu_opt_script += ' -vga virtio -display gtk,gl=es'
else:
self.qemu_opt_script += ' -display gtk'
```

Kind regards,
Manuel


[meta-security][PATCH] recipes-security/chipsec: platform security assessment framework

LiweiSong
 

Add chipsec, tools to dump and analyzing hardware, system firmware
components, like PCH register, ioport or iomem configuration space.

Signed-off-by: Liwei Song <liwei.song@...>
---
recipes-security/chipsec/chipsec_git.bb | 35 +++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 recipes-security/chipsec/chipsec_git.bb

diff --git a/recipes-security/chipsec/chipsec_git.bb b/recipes-security/chipsec/chipsec_git.bb
new file mode 100644
index 000000000000..3339dc142107
--- /dev/null
+++ b/recipes-security/chipsec/chipsec_git.bb
@@ -0,0 +1,35 @@
+SUMMARY = "CHIPSEC: Platform Security Assessment Framework"
+
+DESCRIPTION = "CHIPSEC is a framework for analyzing the security \
+ of PC platforms including hardware, system firmware \
+ (BIOS/UEFI), and platform components."
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=bc2d1f9b427be5fb63f6af9da56f7c5d"
+
+SRC_URI = "git://github.com/chipsec/chipsec.git;branch=master \
+ "
+
+SRCREV = "b2a61684826dc8b9f622a844a40efea579cd7e7d"
+
+COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
+
+S = "${WORKDIR}/git"
+EXTRA_OEMAKE = "CC='${CC}' LDFLAGS='${LDFLAGS}' CFLAGS='${CFLAGS}'"
+
+DEPENDS = "virtual/kernel nasm-native python3-setuptools-native"
+RDEPENDS:${PN} += "python3 python3-modules"
+
+inherit module distutils3
+
+do_compile:append() {
+ cd ${S}/drivers/linux
+ oe_runmake KSRC=${STAGING_KERNEL_BUILDDIR}
+}
+
+do_install:append() {
+ install -m 0644 ${S}/drivers/linux/chipsec.ko ${D}${PYTHON_SITEPACKAGES_DIR}/chipsec/helper/linux
+}
+
+FILES:${PN} += "${exec_prefix} \
+"
--
2.17.1


How to submit/create a new repository in http://git.yoctoproject.org/

thloh85@...
 

Hi all,

I'm from StarFive and am working on distro for our risc-v based processor.
We currently have a repository (https://github.com/starfive-tech/meta-starfive) and wish to get the repository to be part of git.yoctoproject.org. 
I couldn't find any information on the process to get the repository into git.yoctoproject.org. Can someone help show me the process?

Thanks
Tien Hock

2821 - 2840 of 57793