yocto@lists.yoctoproject.org

Re: U-Boot sama5d3 xplained issue

Khem Raj

#51522

perhaps asking it on https://github.com/linux4sam/u-boot-at91 via
github issues might be helpful too.

Show quoted text

On Sat, Nov 21, 2020 at 4:26 AM David Novak <david.novak@...> wrote:

I'm working on this project with Pratham. Let me provide a few more details.

We've defined

UBOOT_MACHINE ?= "sama5d3_xplained_nandflash_config"

Inside

u-boot-at91/sama5d3_xplained_nandflash_config

we change CONFIG_BOOTDELAY, but it has no effect on the newly built image. The boot delay remains the same as it was before we changed it.

Based on the UBOOT_MACHINE, can we be certain we are changing the correct file?

How do we get the build process to include our changes?

Thanks,
David

On 11/19/2020 5:37 PM, Prathamesh Ovalekar wrote:

Hello everyone,

System: sama5d3_xplained board

I have a question regarding the configuration and build of u-boot.
We have a build that was implemented earlier. I am trying to make some changes to it.

Change 1: Change the auto boot delay to 1 second.
Change 2: Add an auto boot command to set a gpio.

I am aware of the environment variables:  CONFIG_BOOTDELAY and CONFIG_BOOTCOMMAND (needed for the changes above.)
I tried modifying the  " configs/sama5d3_xplained_nandflash_defconfig "

Question 1: Do I need to create an *.config file using the make menuconfig?

Question 2: How do I create the u-boot.bin . Does this  depend on the Linux build?
                    I know that there is an environment variable: CONFIG_BOOTARGS that needs to be populated.

--
Pratham Ovalekar

Re: Python function caching question

Khem Raj

#51521

On Sun, Nov 22, 2020 at 6:17 PM Michael Callahan
<coder.callahan@...> wrote:

I am having trouble with sstate caching of my os-release.bbappend and
am stuck.  The simple example file looks like something below, where I
am setting a variable from a computed python function.  What's the magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes?  I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
    import subprocess
    cmd = "git describe --long"
    return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION
perhaps mark the task which is using this variable as nostamp.

Python function caching question

Michael Callahan <coder.callahan@...>

#51520

I am having trouble with sstate caching of my os-release.bbappend and
am stuck.  The simple example file looks like something below, where I
am setting a variable from a computed python function.  What's the magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes?  I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
    import subprocess
    cmd = "git describe --long"
    return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION

Re: Best convention for FILES variable

Chuck Wolber

#51519

On Sat, Nov 21, 2020 at 7:48 AM Robert P. J. Day <rpjday@...> wrote:

%< SNIP %<

pedantically speaking, since you're using "+=", you don't need those
leading spaces.

Indeed you are correct. I believe I mistakenly conflated that particular aspect of "_append" with "+=".

Thank you for pointing this out.

..Ch:W..

--

"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire

strange meta-security bbappend file with two percent signs

Robert P. J. Day

#51518

while the bitbake user manual insists:

"The use of the ” % ” character is limited in that it only works
directly in front of the .bbappend portion of the append file’s name.
You cannot use the wildcard character in any other location of the
name."

i just ran across this in the meta-security layer:

  recipes-kernel/linux/linux-%_5.%.bbappend

what is one supposed to make of that?

rday

Re: Best convention for FILES variable

Robert P. J. Day

#51517

On Sat, 21 Nov 2020, Chuck Wolber wrote:



On Sat, Nov 21, 2020 at 12:21 AM Chuck Wolber <chuckwolber@...> wrote:

%< SNIP %<
 
      And finally, I have adjusted to using the following pattern, and found that it
      has improved maintainability a great deal. It applies to DEPENDS and RDEPENDS
      as well. Yes, it is a bit tedious, but the benefits far outweigh the cost
      (IMHO).

FILES_fooz += " lib/foozlib.so"
FILES_fooz += " /usr/lib/foozlib-2.so"
FILES_fooz += " /usr/bin/fooz"
FILES_fooz += " /bin/fooz"
FILES_fooz += " /usr/share/fooz"  pedantically speaking, since you're using "+=", you don't need those
leading spaces.

rday

ESDK script failue

jadhavvaibhav377@...

#51516

HI all,
I am trying to build ESDK for a custom layer. while building I am getting following ESDK preparing_build_system.log
NOTE: Running noexec task 1 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_rm_work_all)
NOTE: Running noexec task 2 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/unifdef/unifdef_2.11.bb:do_rm_work_all)
NOTE: Running noexec task 3 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-extended/unzip/unzip_6.0.bb:do_rm_work_all)
NOTE: Running noexec task 4 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-extended/cwautomacros/cwautomacros_20110201.bb:do_rm_work_all)
NOTE: Running noexec task 5 of 6485 (/home/user/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/systemd/systemd-systemctl-native.bb:do_rm_work_all)
NOTE: Running noexec task 6 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy-native.bb:do_rm_work_all)
NOTE: Running noexec task 7 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/zlib/zlib_1.2.11.bb:do_rm_work_all)
NOTE: Running noexec task 8 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/gettext/gettext-minimal-native_0.19.8.1.bb:do_rm_work_all)
NOTE: Running noexec task 9 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_rm_work_all)
NOTE: Running noexec task 10 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_rm_work_all)
NOTE: Running noexec task 11 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_rm_work_all)
NOTE: Running noexec task 12 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb:do_rm_work_all)
NOTE: Running noexec task 13 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_rm_work_all)
NOTE: Running noexec task 14 of 6485 (virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_rm_work_all)
NOTE: Running noexec task 15 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_rm_work_all)
NOTE: Running task 16 of 6485 (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/gcc/gcc-source_8.3.bb:do_rm_work)
ERROR: Task glibc-locale.do_populate_lic attempted to execute unexpectedly and should have been setscened
Task /home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb:do_package_write_deb, unihash e0a368ff2b6e1e9c8b81756d93ee2ccacf62a26ef112afdf93a750212abbee43, taskhash e0a368ff2b6e1e9c8b81756d93ee2ccacf62a26ef112afdf93a750212abbee43
Task /home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-support/libevdev/libevdev_1.8.0.bb:do_package, unihash b8e9bb8121df216d8e04c89b613b55b8fb138c0c87372a6101199d3812712643, taskhash b8e9bb8121df216d8e04c89b613b55b8fb138c0c87372a6101199d3812712643
Task /home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.3.1.bb:do_package, unihash 605c26cc78f9f60b6642191fff1baa54443f18466b41a78f8c4cb067fbb8e96c, taskhash 605c26cc78f9f60b6642191fff1baa54443f18466b41a78f8c4cb067fbb8e96c
.
.
Task /home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-graphics/mini-x-session/mini-x-session_0.1.bb:do_package_write_deb, unihash f30c12605b93d3e4b7d9519b021d7eae37259148d21462ff0a28b2731f63c2c8, taskhash f30c12605b93d3e4b7d9519b021d7eae37259148d21462ff0a28b2731f63c2c8
Task /home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-extended/iptables/iptables_1.8.3.bb:do_populate_sysroot, unihash 31db09ce9dbf5d4ca6700d43ea2aef440a9001e88a47e1866b9587bb813083c2, taskhash 31db09ce9dbf5d4ca6700d43ea2aef440a9001e88a47e1866b9587bb813083c2
Task virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb:do_populate_lic, unihash 5cce2806bd80bc0cdc6ab1552171b48f1815dc7892b9b5b39ee7f91d9a242302, taskhash 5cce2806bd80bc0cdc6ab1552171b48f1815dc7892b9b5b39ee7f91d9a242302
Task /home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-support/gnutls/gnutls_3.6.8.bb:do_package_qa, unihash eb4c9c968f488b26dfdb77deda7271059320738acd43bef11d8a8b4c43e5d0d3, taskhash eb4c9c968f488b26dfdb77deda7271059320738acd43bef11d8a8b4c43e5d0d3
This is usually due to missing setscene tasks. Those missing in this build were: {
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/alsa-state/alsa-state.bb:do_populate_sysroot',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/formfactor/formfactor_0.0.bb:do_package',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/formfactor/formfactor_0.0.bb:do_package_qa',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/formfactor/formfactor_0.0.bb:do_package_write_deb',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/formfactor/formfactor_0.0.bb:do_packagedata',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/formfactor/formfactor_0.0.bb:do_populate_lic',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-bsp/formfactor/formfactor_0.0.bb:do_populate_sysroot',
.
.
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb:do_package',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb:do_package_qa',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb:do_package_write_deb',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb:do_packagedata',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb:do_populate_lic',
'/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb:do_populate_sysroot'
.
.
'virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-support/re2c/re2c_1.0.1.bb:do_populate_lic',
'virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-support/re2c/re2c_1.0.1.bb:do_populate_sysroot',
.
.
'virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-support/sqlite/sqlite3_3.30.1.bb:do_populate_lic',
'virtual:native:/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-support/sqlite/sqlite3_3.30.1.bb:do_populate_sysroot'
}
ERROR: Task (/home/user/openembedded/openembedded-core/build/tmp-glibc/deploy/sdk/new/layers/openembedded-core/meta/recipes-core/glibc/glibc-locale_2.30.bb:do_populate_lic) failed with exit code 'setscene whitelist'
NOTE: Tasks Summary: Attempted 19 tasks of which 0 didn't need to be rerun and 1 failed.
Can anyone please tell how can i resolve this issue.

Regards,
Vaibhav Jadhav

loading huawei_cdc_ncm #kernel

Zoltan Kerenyi Nagy

#51515

Hi,

I'd li to include as a kernel module the huawei_cdc_ncm.c file and autoloaded as a kernel object.

I did this in the main recipie file, but it's not enogh:

KERNEL_MODULE_AUTOLOAD += "cdc_ncm.ko"

I guess I should have a bb file for the huawei_cdc_ncm.c, but I didnt find any on the net.
Could you please help me?

Thanks

Zolee

Re: U-Boot sama5d3 xplained issue

David Novak <david.novak@...>

#51514

I'm working on this project with Pratham. Let me provide a few more details.

We've defined

UBOOT_MACHINE ?= "sama5d3_xplained_nandflash_config"

Inside

u-boot-at91/sama5d3_xplained_nandflash_config

we change CONFIG_BOOTDELAY, but it has no effect on the newly built image. The boot delay remains the same as it was before we changed it.

Based on the UBOOT_MACHINE, can we be certain we are changing the correct file?

How do we get the build process to include our changes?

Thanks,
David

Show quoted text

On 11/19/2020 5:37 PM, Prathamesh Ovalekar wrote:

Hello everyone,

System: sama5d3_xplained board

I have a question regarding the configuration and build of u-boot.
We have a build that was implemented earlier. I am trying to make some changes to it.

Change 1: Change the auto boot delay to 1 second.
Change 2: Add an auto boot command to set a gpio.

I am aware of the environment variables: CONFIG_BOOTDELAY and CONFIG_BOOTCOMMAND (needed for the changes above.)
I tried modifying the " configs/sama5d3_xplained_nandflash_defconfig "

Question 1: Do I need to create an *.config file using the make menuconfig?

Question 2: How do I create the u-boot.bin . Does this depend on the Linux build?
I know that there is an environment variable: CONFIG_BOOTARGS that needs to be populated.
--
Pratham Ovalekar

multilib: lib32-libgdiplus complaining about qemuwrapper

Pelle Windestam

#51513

Hi all,

I am using Yocto 2.5 and have a working multilib-enabled image based on poky which includes libgdiplus (64-bit). Due to requirements I had to add the 32-bit version, so I added lib32-libgdiplus to my image recipe. This caused the following error output from bitbake:

WARNING: tmlinux-image-1.0-r0 do_rootfs: The postinstall intercept hook 'update_gio_module_cache-lib32' failed, details in /home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/temp/log.do_rootfs
ERROR: tmlinux-image-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['100-lib32-libglib-2.0-0']
ERROR: tmlinux-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/temp/log.do_rootfs.30106
ERROR: Task (/home/pelle/development/var-fsl-yocto/sources/meta-tagmaster/recipes-core/images/tmlinux-image.bb:do_rootfs) failed with exit code '1'

While searching for the root cause of this, I discovered a change to update_gio_module_cache (https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/scripts/postinst-intercepts/update_gio_module_cache?id=87631af64032b18ea354b27cc586ec13391bd143) that I thought might help. I applied this change (and the changes from https://github.com/openembedded/openembedded-core/commit/d10fd6ae3fe46290c6e3a5250878966d9f12ca3f for the qemuwrapper-cross_1.0.bb recipe) to my local code, and once again tried building the image. The error message from bitbake is the same, but in the do_rootfs log I find this:

/home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/intercept_scripts-bd1c31820bf736a004f4ebe71461d6fa3ae23f7d97783c8f28a606e086741d8a/update_gio_module_cache-lib32: 15: /home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/intercept_scripts-bd1c31820bf736a004f4ebe71461d6fa3ae23f7d97783c8f28a606e086741d8a/update_gio_module_cache-lib32: lib32-qemuwrapper: not found

If I search my tmp directory, there is nothing called "lib32-qemuwrapper", but there is "lib32-qemuwrapper-cross". 

Does anyone have any ideas or suggestions?

//Pelle

Fix future timestamps

Fundu Bits

#51512

Hi,

I see future timestamps on binaries in the boot partition created by my custom wks.

It was ok, until I had to use upstream Grub (at 2.05) with the commit

20def1a3c39529 "fat: Support file modification times"

I have to write an extra script to touch binaries at the end of image creation, is there any flag/option for local.conf to force valid timestamps on binaries?

Thanks.

[meta-selinux][PATCH] libselinux-python: inherit python3targetconfig

Yi Zhao

#51511

The python3 target configuration has been split into own class in
oe-core commit 5a118d4e7985fa88f04c3611f8db813f0dafce75.
Inherit it to fix the build error.

Fixes:
selinuxswig_python_wrap.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status

Signed-off-by: Yi Zhao <yi.zhao@...>
---
 recipes-security/selinux/libselinux-python.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/selinux/libselinux-python.inc b/recipes-security/selinux/libselinux-python.inc
index 3760fd8..7149d94 100644
--- a/recipes-security/selinux/libselinux-python.inc
+++ b/recipes-security/selinux/libselinux-python.inc
@@ -7,7 +7,7 @@ LICENSE = "PD"
 
 FILESEXTRAPATHS_prepend := "${THISDIR}/libselinux:"
 
-inherit python3native
+inherit python3native python3targetconfig
 
 DEPENDS += "python3 swig-native libpcre libsepol"
 RDEPENDS_${PN} += "libselinux python3-core python3-shell"
-- 
2.25.1

Re: yocto recipt from host ide

Sergey Ivanov <icegood1980@...>

#51510

Thanks for efforts but none of the instructions does job well till the end (as many others that i've tried before). Main reasons :

1) For both: as i said, the project is with dependencies and cmake-based. It means, that in my cmake i have find_package things, that should be correctly resolved against stage sysroot (not against host!). It is especially crucial for qt, since without proper configuration you will not even be able to open project.

2) For qt:

2.1) there is no cmake override in setting, of course will not work. I've already tried to add override from <my_recipe>1.0.0-r0/recipe-sysroot-native but given cmake doesn't work for me.

2.2) i've almost taken as granted that i should deal with device first, but, as i said, i'm not even interest in the building of project, just 100% correct symbols resolution. While i will need a device (maybe) for other things like debugging in near future.

For resolution pitfalls you may found smth. like this:
https://bugreports.qt.io/browse/QTCREATORBUG-24269

and i just tired to explain how everything is wrong there in this regard, so bug is closed

3) For vscode:

they don't seem to be even correctly deal with custom sysroot and given instruction has nothing common with it. And seems there everything is wrong as well:
https://github.com/microsoft/vscode-cpptools/issues/1575

So, i'm interested in answers from devs that have 100% working environment (preferably own one) that cover 100% symbol resolution issue. And it could be just another IDE.

пт, 20 нояб. 2020 г. в 09:33, Josef Holzmayr <jester@...>:

Show quoted text

Am Fr., 20. Nov. 2020 um 02:47 Uhr schrieb Khem Raj <raj.khem@...>:
>
> On Thu, Nov 19, 2020 at 1:48 PM Sergey Ivanov <icegood1980@...> wrote:
> >
> > Hi there.
> > Could anyone share a good approach/documentation/etc on how to
> > properly configure and use sysroot and sdk for a specific cmake - based c++ receipt
> > to be able to build it from IDE (vscode, qtcreator) on linux host i.e.
> >
> > 1) ide's --sysroot will be taken from
> > yocto-root/build/tmp/work/aarch64-poky-linux/<my_recipe>1.0.0-r0/recipe-sysroot
> > 2) compilers and cmake (i believe) will be taken from
> > yocto-root/build/tmp/work/aarch64-poky-linux/<my_recipe>1.0.0-r0/recipe-sysroot-native
> > 3) no mix of includes from host will be taken into account during the compilation
> >
> > If none of ide above could do this stuff, then please recommend your one
> >
> > For this moment i don't want run/debug the application right from ide, i just want to have all symbols be correctly resolved from there.
> >
>
> does this help ?
> https://www.ics.com/blog/configuring-qt-creator-yocto-development

also, https://github.com/Wind-River/vscode-wrlinux/

>
> > --
> > Kind regards,
> > Sergey Ivanov
> >
> >
> >
>
>
>

--

Kind regards,
Sergey Ivanov

yocto recipt from host ide

Sergey Ivanov <icegood1980@...>

#51509

Hi there.

Could anyone share a good approach/documentation/etc on how to

properly configure and use sysroot and sdk for a specific cmake - based c++ receipt

to be able to build it from IDE (vscode, qtcreator) on linux host i.e.

1) ide's --sysroot will be taken from
yocto-root/build/tmp/work/aarch64-poky-linux/<my_recipe>1.0.0-r0/recipe-sysroot

2) compilers and cmake (i believe) will be taken from
yocto-root/build/tmp/work/aarch64-poky-linux/<my_recipe>1.0.0-r0/recipe-sysroot-native

3) no mix of includes from host will be taken into account during the compilation

If none of ide above could do this stuff, then please recommend your one

For this moment i don't want run/debug the application right from ide, i just want to have all symbols be correctly resolved from there.

--

Kind regards,
Sergey Ivanov

U-Boot sama5d3 xplained issue

Prathamesh Ovalekar <pratham.ovalekar@...>

#51508

Hello everyone,

System: sama5d3_xplained board

I have a question regarding the configuration and build of u-boot.
We have a build that was implemented earlier. I am trying to make some changes to it.

Change 1: Change the auto boot delay to 1 second.
Change 2: Add an auto boot command to set a gpio.

I am aware of the environment variables: CONFIG_BOOTDELAY and CONFIG_BOOTCOMMAND (needed for the changes above.)
I tried modifying the " configs/sama5d3_xplained_nandflash_defconfig "

Question 1: Do I need to create an *.config file using the make menuconfig?

Question 2: How do I create the u-boot.bin . Does this depend on the Linux build?
I know that there is an environment variable: CONFIG_BOOTARGS that needs to be populated.

--
Pratham Ovalekar

Re: yocto recipt from host ide

Josef Holzmayr

#51507

Am Fr., 20. Nov. 2020 um 02:47 Uhr schrieb Khem Raj <raj.khem@...>:

On Thu, Nov 19, 2020 at 1:48 PM Sergey Ivanov <icegood1980@...> wrote:

Hi there.
Could anyone share a good approach/documentation/etc on how to
properly configure and use sysroot and sdk for a specific cmake - based c++ receipt
to be able to build it from IDE (vscode, qtcreator) on linux host i.e.

1) ide's --sysroot will be taken from
yocto-root/build/tmp/work/aarch64-poky-linux/<my_recipe>1.0.0-r0/recipe-sysroot
2) compilers and cmake (i believe) will be taken from
yocto-root/build/tmp/work/aarch64-poky-linux/<my_recipe>1.0.0-r0/recipe-sysroot-native
3) no mix of includes from host will be taken into account during the compilation

If none of ide above could do this stuff, then please recommend your one

For this moment i don't want run/debug the application right from ide, i just want to have all symbols be correctly resolved from there.
does this help ?
https://www.ics.com/blog/configuring-qt-creator-yocto-developmentalso, https://github.com/Wind-River/vscode-wrlinux/


--
Kind regards,
Sergey Ivanov

Hardware video decode on RPi3

Rudolf J Streif

#51506

I am trying to play back mp4 video (venerable Big Buck Bunny at this time) on RPi3.

I added gstreamer1.0, gstreamer1.0-omx and the plugins to the image.

libgstomx.so is installed in usr/lib/gstreamer-1.0 on target.

However, gst-inspect-1.0 | grep omx does not return any results.

Consequently,

gst-launch-1.0  filesrc location="/home/root/kiosk/kiosk/videos/bunny.mp4" ! qtdemux ! h264parse ! omxh264dec ! kmssink
WARNING: erroneous pipeline: no element "omxh264dec"

I guess I am missing something somewhere but I don't know what.

Thanks,
Rudi

OpenPGP_0x8D8CA82927339B75.asc

OpenPGP_signature

Re: Raspberry PI enabling MMC1

Erik Boto

#51505

On Thu, Nov 19, 2020 at 7:21 PM chuck kamas via lists.yoctoproject.org
<chuckkamas=yahoo.com@...> wrote:

Making some progress here!

I added a compiled version of the attached device tree and now the mmc1 shows up in my yocto image! Yes! Now I need to find out the secret magic in that tree that I need to add...If I'm not mistaken that should be done by appending
RPI_KERNEL_DEVICETREE_OVERLAYS. If you don't have your own custom
machine configuration where this could be added, try adding the
following to local.conf:

RPI_KERNEL_DEVICETREE_OVERLAYS_append = " overlays/sdio.dtbo "

Cheers,
Erik

Chuck

On 11/18/20 7:59 PM, chuck kamas via lists.yoctoproject.org wrote:

Raj,

I found out how to debug the boot process of the PI from:

https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/README.md

by turning on the boot code debug.

sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin

I found out that the sdio overlay does not exist!

MESS:00:00:07.868162:0: dtdebug: Failed to open overlay file 'overlays/sdio.dtbo'
MESS:00:00:07.874093:0: Failed to load overlay 'sdio'
MESS:00:00:07.878881:0: brfs: File read: /mfs/sd/overlays/sdio.dtbo
MESS:00:00:07.891322:0: brfs: File read: /mfs/sd/cmdline.txt

So what am I missing on how to turn on the sdio on GPIO22-27? Is it not an overlay and instead a driver/other code/linux config that needs to be set?

Chuck

On 11/17/20 4:29 PM, chuck kamas via lists.yoctoproject.org wrote:

Raj,

Thanks for taking the time to respond. I thought of that too. My custom Yocto build has the line to turn on the sdio in it:

dtoverlay=sdio,poll_once=off

I have attached the entire file: config.txt.yocto

However, the Rasbian image does not have any mention of the dtoverlay for the sdio.  Curious. See config.txt attached.

Thanks for the help!

Chuck

On 11/17/20 12:08 AM, Khem Raj wrote:

On Mon, Nov 16, 2020 at 11:43 PM chuck kamas via
lists.yoctoproject.org <chuckkamas=yahoo.com@...>
wrote:

Hi all,

I have been spinning my wheels for two days trying to discover how to
enable MMC1 on a CM3. This is the one on GPIO22-27. I can boot Rasbian
on the CM3 and it inits the MMC1 and its pins just fine. I can
read/write to my SD card from it etc. However, when I build yocto it
leaves the GPIOS22-27 in gpio mode and does not set them to MMC1 mode.
I have tried changing the device tree as described here:

https://stackoverflow.com/questions/44702426/how-to-setup-an-own-device-tree-for-a-raspberrypi-in-yocto

That compiles and add the .dtbo to my build, but still the GPIOS are not
set to MMC1 mode.

cat /sys/kernel/debug/pinctrl/*gpio*/pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
....

pin 22 (gpio22): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 23 (gpio23): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 24 (gpio24): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 25 (gpio25): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 26 (gpio26): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 27 (gpio27): (MUX UNCLAIMED) (GPIO UNCLAIMED)

.....

I have looked at:

https://ralimtek.com/raspberry%20pi/electronics/software/raspberry_pi_secondary_sd_card/

Any ideas of where to look next to turn on the sdio would be appreciated!

what does /boot/config.txt look like on raspbian and yocto built images

Chuck

Re: Best convention for FILES variable

Chuck Wolber

#51504

On Sat, Nov 21, 2020 at 12:21 AM Chuck Wolber <chuckwolber@...> wrote:

%< SNIP %<

And finally, I have adjusted to using the following pattern, and found that it has improved maintainability a great deal. It applies to DEPENDS and RDEPENDS as well. Yes, it is a bit tedious, but the benefits far outweigh the cost (IMHO).

FILES_fooz += " lib/foozlib.so"
FILES_fooz += " /usr/lib/foozlib-2.so"
FILES_fooz += " /usr/bin/fooz"
FILES_fooz += " /bin/fooz"
FILES_fooz += " /usr/share/fooz"

This pattern is invaluable when you start accumulating a lot of recipes. A recursive grep (grep -r) across a directory tree, will immediately tell you that (for example), /bin/fooz is file in the fooz package and it is referenced in the fooz_1.3.2.bb recipe.

I forgot one other benefit. When a change is made to a recipe that uses that pattern, the (Git) commit diff is a lot clearer and easier to understand.

Think of it this way... Use your pattern, but imagine there are a lot more entries in your list. A change to the middle of that list is going to result in a diff that is hard to determine if it is a FILE_fooz entry or a DEPENDS_${PN} entry. Prefixing with the directive keeps your Git history a lot clearer.

..Ch:W..

--

"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire

Re: Best convention for FILES variable

Chuck Wolber

#51503

On Fri, Nov 20, 2020 at 6:49 PM <rustyhowell@...> wrote:

Hello,
I am relatively new to yocto, and I am working on several recipes at the moment and I'm wondering about using wildcards in my FILES_{PN} list. None of the packages have more than 5 or 6 files to package. They could easily be covered with two wildcard entries, but I wonder if there is benefit to listing each file explicitly. Thanks for the help. Example below:
FILES_fooz = "\
    */fooz* \
    */*/fooz* \
"
vs
FILES_fooz = "\
   /lib/foozlib.so \
   /usr/lib/foozlib-2.so \
   /usr/bin/fooz \
   /bin/fooz \
   /usr/share/fooz \
"

Both will work, although you do run the risk of accidentally globbing files that you do not mean to include, but perhaps you know your recipes well enough that that is not a factor.

Personally, I find that being explicit makes a lot more sense for a few reasons:

Stuff changes, and I _want_ a build error or warning to let me when it changes and someone forgot to update the recipe.
The grep command is your friend. If you glob, you lose a lot of fidelity there.
If you want to refactor a recipe into separate packages later, you probably need to do a lot of head scratching to pin down all of the files generated in the build.

And finally, I have adjusted to using the following pattern, and found that it has improved maintainability a great deal. It applies to DEPENDS and RDEPENDS as well. Yes, it is a bit tedious, but the benefits far outweigh the cost (IMHO).

FILES_fooz += " lib/foozlib.so"

FILES_fooz += " /usr/lib/foozlib-2.so"

FILES_fooz += " /usr/bin/fooz"

FILES_fooz += " /bin/fooz"

FILES_fooz += " /usr/share/fooz"

This pattern is invaluable when you start accumulating a lot of recipes. A recursive grep (grep -r) across a directory tree, will immediately tell you that (for example), /bin/fooz is file in the fooz package and it is referenced in the fooz_1.3.2.bb recipe.

..Ch:W..

--

"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire