Date   

meta-intel with a Celeron 6305E

Ori Pessach
 

Hello,

I'm trying to run an existing image (based on Gatesgarth) on a Celeron 6305E NUC. The application running on this image is a media player which uses Gstreamer for decoding and displaying video.

Performance on this CPU is inadequate (probably due to lack of acceleration support for decoding and display), and I've been trying to figure out how to fix that. I tried pulling different tags of the meta-intel BSP layer, with no success. 

So I guess my question is this - Is this processor fully supported by meta-intel, and if so, when was support added for this generation of CPU/GPU and how can I get that to work with my image?

Thanks,

Ori Pessach


Re: [meta-security][hardknott][PATCH v2] sssd: re-package to fix QA issues

Armin Kuster
 

merged.

thanks
armin

On 12/2/21 6:02 PM, Kai wrote:
On 11/27/21 2:41 AM, akuster808 wrote:
merged.
Hi Armin,

Would you like to double check the commit, please? I don't see it in
branch hardknott.

Regards,
Kai


On 11/16/21 10:28 AM, Jeremy A. Puhlman wrote:
It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are
packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
     -dev package sssd-dev contains non-symlink .so
'/usr/lib/libsss_sudo.so' [dev-elf]

So create a new sub-package libsss-sudo to package file libsss_sudo.so
and make sssd rdepends on it.

JP: Updated for version differences.

Signed-off-by: Kai Kang <kai.kang@...>
Signed-off-by: Armin Kuster <akuster808@...>
(cherry picked from commit e81c15f851ca5396c78c8737967ee38db0ebe0cd)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@...>
---
  recipes-security/sssd/sssd_1.16.5.bb | 21 ++++++++++++++-------
  1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/recipes-security/sssd/sssd_1.16.5.bb
b/recipes-security/sssd/sssd_1.16.5.bb
index 02d0837..f13fc49 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_1.16.5.bb
@@ -120,10 +120,17 @@ SYSTEMD_SERVICE_${PN} = " \
  "
  SYSTEMD_AUTO_ENABLE = "disable"
  -FILES_${PN} += "${libdir} ${datadir}
${base_libdir}/security/pam_sss.so"
-FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
-
-# The package contains symlinks that trip up insane
-INSANE_SKIP_${PN} = "dev-so"
-
-RDEPENDS_${PN} = "bind dbus libldb libpam"
+PACKAGES =+ "libsss-sudo libsss-autofs"
+ALLOW_EMPTY_libsss-sudo = "1"
+ALLOW_EMPTY_libsss-autofs = "1"
+
+FILES_${PN}-dev += "${libdir}/sssd/modules/lib*.so"
+FILES_${PN} += "${base_libdir}/security/pam_sss*.so  \
+                ${datadir}/dbus-1/system-services/*.service \
+                ${libdir}/krb5/* \
+                ${libdir}/ldb/* \
+                "
+FILES_libsss-autofs = "${libdir}/sssd/modules/libsss_autofs.so"
+FILES_libsss-sudo = "${libdir}/libsss_sudo.so"
+
+RDEPENDS_${PN} = "bind dbus libldb libpam libsss-sudo libsss-autofs"


USB display

simon
 

Hello, I'm having some issue moving from an HDMI display to a USB display.

I figure out that I needed to enable these parameter in the kernel to use the USB monitor

CONFIG_DRM_UDL=y
CONFIG_FB_UDL=y

With those I'm able to see the terminal and login

However I'm still struggling and confused on how to get my GUI to show up with startx.

I don't know if I still need to install the displaylink driver since I've enabled UDL or if I need to set something with xorg to let him know to use the USB display.

I've tried to install the displaylink driver manually but I'm missing the DKMS component, not entirely sure what that is and how I would install this (or if I should).

I tried to follow some guide about displaylink with xorg and replacing it with udl and udlfb without success.

Thanks for your help

Simon


Re: native tool from target recipe

Ross Burton <ross@...>
 

On Fri, 3 Dec 2021 at 16:16, <kkubkowski@...> wrote:
Hi all,
I have what I believe is a basic question yet I cannot find any definitive answer: is it possible for a target recipe (e.g. u-boot or barebox) to provide a native tool (i.e. mkimage) for the build system without the need to rebuild the providing recipe as a native one? To be more specific: I am using barebox as a bootloader and it always builds mkimage for host. I would like to use it later during the build process in another recipe (e.g. after the kernel is built) but I don't want to rebuild the bootloader as a native package. Given how flexible the build system is I suppose it is doable, but what is "the proper" way?
The usual solution is for the recipe to allow building native and you
install the tools from that recipe for the target recipe to use.

The better solution is that the source knows how to build host tools
for the host and target binaries for the target. barebox does, so
just set HOSTCC=${BUILD_CC} when you call make.

Ross


native tool from target recipe

Kacper Kubkowski
 

Hi all,
I have what I believe is a basic question yet I cannot find any definitive answer: is it possible for a target recipe (e.g. u-boot or barebox) to provide a native tool (i.e. mkimage) for the build system without the need to rebuild the providing recipe as a native one? To be more specific: I am using barebox as a bootloader and it always builds mkimage for host. I would like to use it later during the build process in another recipe (e.g. after the kernel is built) but I don't want to rebuild the bootloader as a native package. Given how flexible the build system is I suppose it is doable, but what is "the proper" way?

Kind regards,
Kacper


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Quentin Schulz
 

On Fri, Dec 03, 2021 at 11:48:29AM +0100, Nicolas Dechesne wrote:
On Fri, Dec 3, 2021 at 11:03 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Nicolas,

On Fri, Dec 03, 2021 at 10:49:40AM +0100, Nicolas Dechesne wrote:
On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:
No longer necessary now that the transition from DocBook to Sphinx is
over

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
Reviewed-by: Quentin Schulz <foss+yocto@...>
I don't understand. With this change, we no longer build the pages we
reference here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=nyCl21erajBNcx6SkCKI_BEntNgbh6114vcdWp_vB5yDzorVFjmzdqp0WXIIpQyK&s=rw5wG0nk_9KQ8RLvE1-sbSicy4NslWaeMwoyTSUuIyY&e=

Or am I missing here?
Indeed. But this should be fixed, because we should handle this the same
way documentation/releases.html is, with a common one across all
releases. With the current implementation, only master has a list of all
outdated releases. e.g.
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_3.3_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=0ATdi4CSdy8VvhAKg6W6Qe5J7HEmGOLkDTVb13pe2bQyCiXzZxZGI_ePuUigui73&s=sW9qt9Z46xCwvoaxsU7RvUYqfKmOlSN8T_vDv0Yc_qE&e=
does not exist, but
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=0ATdi4CSdy8VvhAKg6W6Qe5J7HEmGOLkDTVb13pe2bQyCiXzZxZGI_ePuUigui73&s=vI9nhu-xEodig5uSD7RDYKswiZHG_8PDgnd2No0oXMA&e=
does (and weirdly enough 3.4 too).
Yes, this part is indeed poorly implemented. But I don't think we can
remove the transition branch until we fix it, so I don't think we can take
this patch now.
Agreed, I poorly reviewed it. Thanks for stoping us before the disaster
:)

perhaps we should maintain the overall documentation (for all versions) in
the same branch.. all these branches are making everything much
complicated.. Or perhaps we should split the documentation 'content' and
the documentation config and scripts. I am wondering how other projects are
doing it to support such complex doc setup (multiple versions to support
and to publish)!
I think all our issues always come down to this weird and inefficient
organization we have for docs and common files between doc releases.
We'll need to settle on something one day because I don't think what
we're doing today is working :/

Cheers,
Quentin


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Quentin Schulz
 

Hi Nicolas,

On Fri, Dec 03, 2021 at 10:49:40AM +0100, Nicolas Dechesne wrote:
On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:
No longer necessary now that the transition from DocBook to Sphinx is
over

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
Reviewed-by: Quentin Schulz <foss+yocto@...>
I don't understand. With this change, we no longer build the pages we
reference here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=nyCl21erajBNcx6SkCKI_BEntNgbh6114vcdWp_vB5yDzorVFjmzdqp0WXIIpQyK&s=rw5wG0nk_9KQ8RLvE1-sbSicy4NslWaeMwoyTSUuIyY&e=

Or am I missing here?
Indeed. But this should be fixed, because we should handle this the same
way documentation/releases.html is, with a common one across all
releases. With the current implementation, only master has a list of all
outdated releases. e.g.
https://docs.yoctoproject.org/3.3/releases.html#outdated-release-manuals
does not exist, but
https://docs.yoctoproject.org/releases.html#outdated-release-manuals
does (and weirdly enough 3.4 too).

I assume we want this in all branches. Therefore I think we should move
documentation/transition from that branch to master and copy the whole
directory for each non-master branch (with the git checkout master trick
from an earlier patch from Michael). I think this makes more sense than
keeping a transition branch? Especially since I assume we want to move
every 6 months one release from "Supported release manuals" to "Outdated
releae manuals" ?

Cheers,
Quentin


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Quentin Schulz
 

On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:
No longer necessary now that the transition from DocBook to Sphinx is over

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
Reviewed-by: Quentin Schulz <foss+yocto@...>

Thanks,
Quentin


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: make all versions list releases known to master

Quentin Schulz
 

Hi Michael,

On Wed, Dec 01, 2021 at 02:49:31PM +0100, Michael Opdenacker wrote:
This allows all versions of Bitbake and Yocto Project manuals
to see the manuals for the latest versions.

This also simplifies the release process, not having to update the
releases.rst file for all releases every time a new release is made.

Note that such synchronization is already done for the
switchers.js file (but in a different way). This way, advertised
releases are in sync with switchers.js.
Why don't we migrate this different method (find) to the one you
implement in this commit too?

I could see a variable storing all "force-latest" files or someting like
that to make it obvious why they have a specific handling.

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
---
scripts/run-docs-build | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 4451018..5d6d24a 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -39,8 +39,11 @@ cp -r ./_build/final/* $outputdir/bitbake/next
# A decision was made to keep updating all the Sphinx generated docs for the moment,
# even the ones corresponding to no longer supported releases
# https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_message_2193&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=41QznJ3f-1jbT6A1N9c2-XE7vAUbnla1A6cM0yaU8thgWg_WVfeII9dfe8Uq2JTO&s=YCQsQAquPWLLWl11yDzvgP9zkF-UkMF0c8B3BASBDbk&e=
+# We copy the releases.rst file from master so that all versions of the docs
+# see the latest releases.
for branch in 1.46 1.48 1.50 1.52; do
git checkout $branch
+ git checkout master doc/releases.rst
That's one way to do it, not sure this is really what we want but at
least it lowers the maintenance burden so it's a good improvement.

Cheers,
Quentin


Zynq Board unreachable

m.kleber@...
 

Hi,

I created a build for a digilent zybo zynq7. And I create a small server code I need to run on the board.
When I connect the board with ethernet cable to my laptop and try to ping the board I will get the following answer:
$ ping fe80::3478:6c8d:ad4e:43f8%eth0
PING fe80::3478:6c8d:ad4e:43f8%eth0(fe80::3478:6c8d:ad4e:43f8%eth0) 56 data bytes
From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=1 Destination unreachable: Address unreachable
From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=2 Destination unreachable: Address unreachable
From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=3 Destination unreachable: Address unreachable

I've configured the eth0 in /etc/network/interfaces.
The laptop get the connection to the board but can' t reach it or the gateway.
There is no firewall or iptables rules.

Anyone an idea how to deal with it?

B/R
Mike


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: remove gatesgarth

Quentin Schulz
 

Hi Michael, Richard,

On Wed, Nov 24, 2021 at 06:10:56PM +0000, Richard Purdie wrote:
On Wed, 2021-11-24 at 18:16 +0100, Michael Opdenacker wrote:
Together with the corresponding Bitbake version, which are no
longer supported.

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
---
scripts/run-docs-build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 3db4a97..5e1d649 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -35,7 +35,7 @@ mkdir $outputdir/bitbake/next
cp -r ./_build/final/* $outputdir/bitbake/next

# stable branches
-for branch in 1.46 1.48 1.50 1.52; do
+for branch in 1.46 1.50 1.52; do
git checkout $branch
make clean
make publish
@@ -68,7 +68,7 @@ mkdir $outputdir/next
cp -r ./_build/final/* $outputdir/next

# stable branches
-for branch in dunfell gatesgarth hardknott honister; do
+for branch in dunfell hardknott honister; do
cd $ypdocs
git checkout $branch
make clean
I'm a bit torn on this. They are no longer officially supported releases now but
it may make sense to rebuild all the sphinx docs in this script rather than some
subset?
I think we want to make sure we have all docs up-to-date, even for the
branches that aren't maintained anymore. Especially since it's not
taking a lot of CPU time to build them, it's fine IMO. We could always
make minor changes to old docs. E.g. the releases.rst might get updates
until we figure something out.

Cheers,
Quentin


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Nicolas Dechesne
 



On Fri, Dec 3, 2021 at 11:03 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Nicolas,

On Fri, Dec 03, 2021 at 10:49:40AM +0100, Nicolas Dechesne wrote:
> On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <
> quentin.schulz@...> wrote:
>
> > On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:
> > > No longer necessary now that the transition from DocBook to Sphinx is
> > over
> > >
> > > Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
> >
> > Reviewed-by: Quentin Schulz <foss+yocto@...>
> >
>
> I don't understand. With this change, we no longer build the pages we
> reference here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_releases.html-23outdated-2Drelease-2Dmanuals&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=nyCl21erajBNcx6SkCKI_BEntNgbh6114vcdWp_vB5yDzorVFjmzdqp0WXIIpQyK&s=rw5wG0nk_9KQ8RLvE1-sbSicy4NslWaeMwoyTSUuIyY&e=
>
> Or am I missing here?
>

Indeed. But this should be fixed, because we should handle this the same
way documentation/releases.html is, with a common one across all
releases. With the current implementation, only master has a list of all
outdated releases. e.g.
https://docs.yoctoproject.org/3.3/releases.html#outdated-release-manuals
does not exist, but
https://docs.yoctoproject.org/releases.html#outdated-release-manuals
does (and weirdly enough 3.4 too).

Yes, this part is indeed poorly implemented. But I don't think we can remove the transition branch until we fix it, so I don't think we can take this patch now. 

perhaps we should maintain the overall documentation (for all versions) in the same branch.. all these branches are making everything much complicated.. Or perhaps we should split the documentation 'content' and the documentation config and scripts. I am wondering how other projects are doing it to support such complex doc setup (multiple versions to support and to publish)!
 

I assume we want this in all branches. Therefore I think we should move
documentation/transition from that branch to master and copy the whole
directory for each non-master branch (with the git checkout master trick
from an earlier patch from Michael). I think this makes more sense than
keeping a transition branch? Especially since I assume we want to move
every 6 months one release from "Supported release manuals" to "Outdated
releae manuals" ?

I think we had the 'transition' pages in master initially, and we moved that to its own branch. I believe it's something we discussed with Richard.. but i forgot the details. 
 

Cheers,
Quentin
> >


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Nicolas Dechesne
 



On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <quentin.schulz@...> wrote:
On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:
> No longer necessary now that the transition from DocBook to Sphinx is over
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@...>

Reviewed-by: Quentin Schulz <foss+yocto@...>

I don't understand. With this change, we no longer build the pages we reference here:

Or am I missing here? 
 

Thanks,
Quentin




Re: [meta-security][hardknott][PATCH v2] sssd: re-package to fix QA issues

kai
 

On 11/27/21 2:41 AM, akuster808 wrote:
merged.
Hi Armin,

Would you like to double check the commit, please? I don't see it in branch hardknott.

Regards,
Kai


On 11/16/21 10:28 AM, Jeremy A. Puhlman wrote:
It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
-dev package sssd-dev contains non-symlink .so '/usr/lib/libsss_sudo.so' [dev-elf]

So create a new sub-package libsss-sudo to package file libsss_sudo.so
and make sssd rdepends on it.

JP: Updated for version differences.

Signed-off-by: Kai Kang <kai.kang@...>
Signed-off-by: Armin Kuster <akuster808@...>
(cherry picked from commit e81c15f851ca5396c78c8737967ee38db0ebe0cd)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@...>
---
recipes-security/sssd/sssd_1.16.5.bb | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_1.16.5.bb
index 02d0837..f13fc49 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_1.16.5.bb
@@ -120,10 +120,17 @@ SYSTEMD_SERVICE_${PN} = " \
"
SYSTEMD_AUTO_ENABLE = "disable"
-FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss.so"
-FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
-
-# The package contains symlinks that trip up insane
-INSANE_SKIP_${PN} = "dev-so"
-
-RDEPENDS_${PN} = "bind dbus libldb libpam"
+PACKAGES =+ "libsss-sudo libsss-autofs"
+ALLOW_EMPTY_libsss-sudo = "1"
+ALLOW_EMPTY_libsss-autofs = "1"
+
+FILES_${PN}-dev += "${libdir}/sssd/modules/lib*.so"
+FILES_${PN} += "${base_libdir}/security/pam_sss*.so \
+ ${datadir}/dbus-1/system-services/*.service \
+ ${libdir}/krb5/* \
+ ${libdir}/ldb/* \
+ "
+FILES_libsss-autofs = "${libdir}/sssd/modules/libsss_autofs.so"
+FILES_libsss-sudo = "${libdir}/libsss_sudo.so"
+
+RDEPENDS_${PN} = "bind dbus libldb libpam libsss-sudo libsss-autofs"

--
Kai Kang
Wind River Linux


Re: raspberrypi0-2w

Joel Winarske
 


On Thu, Dec 2, 2021 at 7:08 AM safouane maaloul <maaloulsafouane@...> wrote:
Hello, I  writed a conf file  to get the raspberrypi0-2 to work in 32 mode to have the camera packages raspivid. It works just fine. But the problem I don't have wlan0 interface. I tried everything but I didn't succeed in getting to work. Here is my conf file:

#@TYPE: Machine
#@NAME: RaspberryPi0 2 Wifi Development Board
#@DESCRIPTION: Machine configuration for the RaspberryPi0 2 Wifi in 32 bits mode

include conf/machine/raspberrypi3.conf

MACHINEOVERRIDES := "${@'${MACHINEOVERRIDES}'
.replace(':${MACHINE}',':raspberrypi3:${MACHINE}')}"

MACHINE_EXTRA_RRECOMMENDS += "\
    linux-firmware-rpidistro-bcm43436 \
    linux-firmware-rpidistro-bcm43436s \
    bluez-firmware-rpidistro-bcm43430b0-hcd \
    linux-firmware-rpidistro-bcm43430 \
"




Best regards,

--
SAFOUANE MAALOUL




Re: raspberrypi0-2w

Khem Raj
 

On Thu, Dec 2, 2021 at 7:08 AM safouane maaloul
<maaloulsafouane@...> wrote:

Hello, I writed a conf file to get the raspberrypi0-2 to work in 32 mode to have the camera packages raspivid. It works just fine. But the problem I don't have wlan0 interface. I tried everything but I didn't succeed in getting to work. Here is my conf file:

#@TYPE: Machine
#@NAME: RaspberryPi0 2 Wifi Development Board
#@DESCRIPTION: Machine configuration for the RaspberryPi0 2 Wifi in 32 bits mode

include conf/machine/raspberrypi3.conf

MACHINEOVERRIDES := "${@'${MACHINEOVERRIDES}'
.replace(':${MACHINE}',':raspberrypi3:${MACHINE}')}"

MACHINE_EXTRA_RRECOMMENDS += "\
linux-firmware-rpidistro-bcm43436 \
linux-firmware-rpidistro-bcm43436s \
bluez-firmware-rpidistro-bcm43430b0-hcd \
linux-firmware-rpidistro-bcm43430 \
"
also add following to machine conf file.

RPI_KERNEL_DEVICETREE = " \
broadcom/bcm2710-rpi-zero-2.dtb \
"





Best regards,

--
SAFOUANE MAALOUL
maaloulsafouane@...




[nativesdk] compilation problem with nativesdk

mlalu
 

Hi everyone,

I'm trying to write a recipe to build openjdk-9 with the Yocto project dunfell.
I want to install the jre (the runtime environment of Java) on my target and install the jdk (the development toolkit of java) on my build machine and only on my build machine.

I succeeded to build openjdk and to install the jre on my target (I can run Java applications on my target).
The fetch/patch/configure/compile tasks are made on a .inc file included on my openjre-9.bb recipe which included only the install task.

Now, I want to install the jdk as part of the Yocto SDK to make it accessible on my build machine. So I created a opendjdk-9.bb recipe wich include my .inc file and added
BBCLASSEXTEND = "nativesdk" in the recipe with the install task.

I added " RDEPENDS_${PN} += "nativesdk-openjdk-9" on a nativesdk-packagegroup-sdk-host.bbappend

and I added TOOLCHAIN_HOST_TASK_append = " nativesdk-openjdk-9" on my image recipe.
Now my problem is that my recipe openjdk-9.bb doesn't compile, I have "Cannot find autoconf" error while compiling.
I don't understand why because the compilation task is described on the .inc file which is the same for the openjre-9.bb recipe (which works) and the openjdk-9.bb recipe (which doesn't work).
I hope you can help me to understand the "nativesdk" extension.

--
Maureen






This e-mail including any attachments may contain information which is privileged or confidential or constitute non-public information.It is to be conveyed only to the intended recipient(s). If you received this e-mail in error, please notify the sender immediately by e-mail or telephone and delete the e-mail  from your system without reading, copying or disclosing its contents to any other person. 


raspberrypi0-2w

safouane maaloul
 

Hello, I  writed a conf file  to get the raspberrypi0-2 to work in 32 mode to have the camera packages raspivid. It works just fine. But the problem I don't have wlan0 interface. I tried everything but I didn't succeed in getting to work. Here is my conf file:

#@TYPE: Machine
#@NAME: RaspberryPi0 2 Wifi Development Board
#@DESCRIPTION: Machine configuration for the RaspberryPi0 2 Wifi in 32 bits mode

include conf/machine/raspberrypi3.conf

MACHINEOVERRIDES := "${@'${MACHINEOVERRIDES}'
.replace(':${MACHINE}',':raspberrypi3:${MACHINE}')}"

MACHINE_EXTRA_RRECOMMENDS += "\
    linux-firmware-rpidistro-bcm43436 \
    linux-firmware-rpidistro-bcm43436s \
    bluez-firmware-rpidistro-bcm43430b0-hcd \
    linux-firmware-rpidistro-bcm43430 \
"




Best regards,

--
SAFOUANE MAALOUL


Re: downloads.yoctoproject.org down?

Andreas Müller
 

On Wed, Dec 1, 2021 at 10:00 PM Michael Halstead
<mhalstead@...> wrote:

downloads.yoctoproject.org is back online with additional redundancy.

The cause of the outage will take some time to investigate as the drive with the logs is not accessible currently.
Yes download worked for me. You saved my life for today :)

Thanks

Andreas


Re: downloads.yoctoproject.org down?

Michael Halstead
 

downloads.yoctoproject.org is back online with additional redundancy.

The cause of the outage will take some time to investigate as the drive with the logs is not accessible currently. 

On Wed, Dec 1, 2021 at 12:06 PM Andreas Müller <schnitzeltony@...> wrote:
On Wed, Dec 1, 2021 at 7:59 PM Steve Sakoman <steve@...> wrote:
>
> On Wed, Dec 1, 2021 at 8:45 AM Andreas Müller <schnitzeltony@...> wrote:
> >
> > Hi,
> >
> > Trying to install buildtools (dunfell) I get
> >
> > ./sources/openembedded-core/scripts/install-buildtools
> > INFO: Fetching buildtools installer
> > ERROR: Could not download file from
> > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.2_M1/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1%2Bsnapshot-20200617.sh
> >
> > Has anybody a chance to help me not being killed :)
>
> Yes, some of the infrastructure is down right now.  Michael knows and
> is hard at work fixing the issue.
So there is hope

Thanks a lot all involved!

Andreas





--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

1961 - 1980 of 57400