I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the production machine to program the empty boards right after being assembled.

While I had plenty of hurdles figuring out how to do this (I'm still pretty newbie with Yocyo), I managed to get everything just the way I wanted it. But when I get the tarball to the production machine, which runs the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The reason being that it's missing some library. Running LDD on the executable turns up this:

└─$> ldd usr/bin/imx_usb
linux-vdso.so.1 => (0x00007ffd7031d000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f986a47e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f986a0b4000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f986a86c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9869e97000)
/home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f986a696000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9869c8f000)

Why is the ld-linux-x86-64.so.2 using an absolute path while all the other libraries aren't?

If I install the library in the location above, then the executable starts working... So how do I make sure Yocto doesn't do this?

I'm looking into best practice LTS support for Google GN based projects. This includes Chromium, Flutter, SKIA, etc.

The weakness I see today for GN projects is that it's a build system within a build system, and doesn't support idiomatic download caching, download vs patching isn't clear as it should be, etc.

Two approaches to resolve this come to mind:
1. Do something similar to how meta-rust does it. Pre-process GN build files and generate Yocto recipes using a hostside tool (similar to cargo-bitbake for meta-rust). This would skip usage of gclient entirely, and the tradeoff is to incur download performance penalty.

2. Implement build parsing in a gclient/gn fetcher class.

I feel the first approach would be easier to maintain and provide better flexibility. It would incur a new host dependency, and require an additional step to generate an updated recipe.

I suspect the second approach would be an OE maintenance headache, as complexities would be directly exposed in OE. Is this why gclient fetcher support came and went?

I'm figuring/hoping there are a few opinions floating around on this subject.

Is there a better approach?

Thanks,
Joel

I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the production machine to program the empty boards right after being assembled.

While I had plenty of hurdles figuring out how to do this (I'm still pretty newbie with Yocyo), I managed to get everything just the way I wanted it. But when I get the tarball to the production machine, which runs the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The reason being that it's missing some library. Running LDD on the executable turns up this:

└─$> ldd usr/bin/imx_usb
    linux-vdso.so.1 =>  (0x00007ffd7031d000)
    libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f986a47e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f986a0b4000)
    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f986a86c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9869e97000)
    /home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f986a696000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9869c8f000)

Why is the ld-linux-x86-64.so.2 using an absolute path while all the other libraries aren't?

If I install the library in the location above, then the executable starts working... So how do I make sure Yocto doesn't do this?

Hi all,
I`m trying to debug coredump generated on embedded system running dunfel.

The issue I`m facing is with the source files path in "-dbg.rootfs" archive and within dedug portion of a package.
When loaded in QtCreator some sources can`t be found :
The part is missing is "*build/..*". Such notation is obviosly cancels itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found in build path for sqlite:
   build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
   build/Makefile:313:abs_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:315:abs_top_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:358:srcdir = ../sqlite-autoconf-3310100
So I tried to disable out-of-tree build for sqlite by replacing *'inherit autotools*' with '*inherit autotools-brokensep*'. After building and loading new debugfs QtCreator was able to found required sources:
Is this a known issue or me doing something wrong with build setup?

Since the recent patch to switch to UUIDs [0aa5e600: "use uuid
instead of hard-coding root device"] wic fstab-update is not able
to get the correct value for the used device anymore and falls to
the default 'sda'. Thus wrong /dev/sda entries are generated in fstab.

For partitions that should be updated automatically this can be avoided
by either generate entries using uuid or label.

Signed-off-by: MarkusVolk <f_l_k@...>
---
wic/rockchip.wks | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Add a common override for both nanopi-m4 MACHINEs.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/nanopi-m4.inc | 3 +++
1 file changed, 3 insertions(+)

There is no "nanopi-m4" defined in any yocto kernel metadata (yet?), therefore
remove this superfluous line.

Build (core-image-base) and run tested (both systemd and sysvinit) on:
- nanopi-m4

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/nanopi-m4.inc | 1 -
1 file changed, 1 deletion(-)

Now that we're booting via UUID, we no longer need these aliases in the DT.
Personally I wasn't able to prove to myself that they actually worked (at
least not with 5.13.y) and fiddling with these aliases didn't seem to affect
the mmc probe order on boot. Additionally it looks like some of these aliases
will be landing upstream shortly.

Build (core-image-base) and run tested (both systemd and sysvinit) on:
- rock64
- rock-pi-e

(i.e. the two rk3328 MACHINEs)

Signed-off-by: Trevor Woerner <twoerner@...>
---
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 -------------------
recipes-kernel/linux/linux-yocto%.bbappend | 3 ---
2 files changed, 30 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

Hi all,
I`m trying to debug coredump generated on embedded system running dunfel. The issue I`m facing is with the source files path in "-dbg.rootfs" archive and within dedug portion of a package.
When loaded in QtCreator some sources can`t be found :
The part is missing is "*build/..*". Such notation is obviosly cancels itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found in build path for sqlite:
   build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
   build/Makefile:313:abs_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:315:abs_top_srcdir = /home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
   build/Makefile:358:srcdir = ../sqlite-autoconf-3310100
So I tried to disable out-of-tree build for sqlite by replacing *'inherit autotools*' with '*inherit autotools-brokensep*'. After building and loading new debugfs QtCreator was able to found required sources:
Is this a known issue or me doing something wrong with build setup?

Hi, I'm building a yocto release from the thud branch. The size of the OS image is very critical, so I need to remove as much as I can. Looking at the dependency information, I can see that the "file" package is not required by any other package, but yet it is installed. I really have to remove this package because it is quite large with its magic database, but I can't find who is installing it and why.

I am compiling in 32 bit mode.



From: Khem Raj <raj.khem@...>
Sent: Monday, October 4, 2021 5:15 PM
To: Greg Wilson-Lindberg <GWilson@...>
Cc: yocto@...
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4



It should have automatically found user land package as one of providers but if it is not doing so that means it’s being ignored because it’s not compatible arch or something

Are you compiling 32bit mode ?





On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg <GWilson@...> wrote:

Hi Khem,
Yes, the Raspberry Pi boards do use closed source drivers. What I need is how do I include the proper package that will bring in the necessary virtual/egl for the Raspberry Pi 4.

Greg

-----Original Message-----
From: Khem Raj <raj.khem@...>
Sent: Monday, October 4, 2021 14:17
To: Greg Wilson-Lindberg <GWilson@...>;
yocto@...
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4



On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:

Hello list,

I'm working on a Qt supplied boot2qt Yocto build currently based on
Zeus that is running on a Raspberry Pi 4. I recently updated the qt
version to 5.15.6 and Qt changed something in the Yocto configuration
that they are using and now one of the recipes that we use is failing
saying that in needs 'virtual/egl' but that it is not provided by any recipe.

In the searching that I have done I have found that the raspberry pi 4
is particular on which package supplies the virtual/egl but I haven't
seen anything that indicates what I should do to re-enable it.

Can anyone tell me what I need to do to enable the correct driver to
get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
how I could search through the packages that are enabled on the old
and new Yocto trees so that I can figure out what changed between the
releases and re-enable the virtual/egl.

it should be provided by userland package if you are using closed source
graphics driver.

Best Regards,

Greg Wilson-Lindberg

This is only cover letter, I do not see patches on mailing list..

Regards,
Naveen

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Arnaud Pouliquen
Sent: Wednesday, September 29, 2021 5:41 PM
To: yocto@...
Cc: Kumar Gala <kumar.gala@...>; Kevin Townsend
<kevin.townsend@...>
Subject: [yocto] [meta-zephyr 0/2] add support of the zephyr-openamp-rsc-
table sample on STM32MP157

Add capability to genereate the "zephyr-openamp-rsc-table" sample in yocto
build.

This example demonstrates inter-processor communication based on a
resource table, with the objective of responding to the Linux kernel rpmsg
sample.

This sample is compatible with the stm32mp157c_dk2 board.
The support of the board is also added in this series.

Arnaud Pouliquen (2):
conf: machine: add stm32mp157c-dk2 support
zephyr-kernel: add openamp-rsc-table sample

conf/machine/stm32mp157c-dk2.conf | 8 ++++++++
.../zephyr-kernel/zephyr-openamp-rsc-table.bb | 10 ++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/stm32mp157c-dk2.conf create mode
100644 recipes-kernel/zephyr-kernel/zephyr-openamp-rsc-table.bb

--
2.17.1

Greetings !

I could able to add Mosquitto in Yocto Zeus , but as default websockets
is disabled in Mosquitto . Can anyone help me how to enable websockets
in Mosquitto in yocto zeus.

Thanks in Advance