Hi, I am trying to include qca9377 module in my image (yocto-gatesgarth). I am using command bitbake imx-image-full, and i added two lines in my local.conf file: MACHINE_FEATURES += " qca9377" IMAGE_I

#qca9377 #yocto #bitbake #gatesgarth

Working with zeus 3.0.4, extended SDK… Could someone explain what I overlooked, or why this issue pops up with python-native support inclusion ? Thanks… When I add in native-python3 support # # Additi

#yocto #sdk

No the vivado module sets up key variables, the lib path, and the include paths for building Xilinx low level drivers built into bootapp/kernel... I need to be able to include these components in actu

#yocto #sdk

there is KERNEL_MODULE_AUTOLOAD which could be used to load modules on boot, don't know if that suffices to what you need but worth looking into. On Tue, Apr 6, 2021 at 12:47 PM Monsees, Steven C (US)

#yocto #sdk

Working with zeus, aarch64, with Xilinx vivado dependencies… Kerenl image and bootapp build and run correctly, need to be able to build EXT SDK,,, How do I incorporate the dependencies of the low leve

#yocto #sdk

EXT SDK, aarch64, zeus… How do I best modify the EXT SDK build env so as to reference the “vivado” env dependencies ? Is there a way to build in support so that the “module load” command would be usab

#yocto #sdk

Hi Can you try this patch ( if you are using master ) and see if that helps diff --git a/recipes-devtools/clang/clang_git.bb b/recipes-devtools/clang/clang_git.bb index b8986be..b0c81f1 100644 --- a/r

#sdk #dunfell #yocto #kernel #linux

Hello, I need Clang compiler apart from currently available default gcc compiler as I am trying to compile eBPF which will run on my custom yocto which is based on core-image-minimal. Therefore I adde

#sdk #dunfell #yocto #kernel #linux

For Arm EXT SDK support: Can I modify the EXT SDK build env paths from “sdk-extra.conf” so as to reference the “vivado” env? Is there a way to build in support so the “module load” command would be us

#yocto #sdk

Thanks for your patience… I was able to followed your advice and I am now able to build and install the Extended SDK for our Intel platform… Can you tell me when building for Arm/Xilinx based platform

#yocto #sdk

Perhaps get into install env and do signatures check for this task

#yocto #sdk

I've been looking at this but still find it odd that they are all " virtual:native"/ "poky/meta"/“do_populate_sysroot” related... It is a "minimum" plus "toolset" build... and it builds clean, yet fai

#yocto #sdk

The output you see is from setting: SDK_EXT_TYPE = "minimal" SDK_INCLUDE_TOOLCHAIN = "1" When building minimal only, there are no errors/warnings (and no tools...)

#yocto #sdk

I think there still are signature differences. perhaps try to add incremntally on top of minimal sdk and see where it breaks.

#yocto #sdk

you are better off by having two different DISTROs like poky and poky-altcfg is.

#yocto #bitbake #systemd #sysvinit

I corrected for the sig warnings, but still have an issue with the extended SDK installing correctly (though I think I am close…) Note: The only issue now appears to be around the “…/poky/meta” layer…

#yocto #sdk

Hi all, I would like to change the init system (systemd / SysVinit) on a per-image basis. Therefore I added both "systemd" and "sysvinit" to my DISTRO_FEATURES. I set this inside my image-systemd.bb t

#yocto #bitbake #systemd #sysvinit

Hi everyone, I'm using Poky with a master branch, I'm enabling the fitImage. Unfortunately, the fitImage is not packaged and not installed into the root file system. Here is my updates in the conf/loc

#yocto #linux #uboot

Hello Guys i have installed avahi-0.8 version using gatesgarth version, its compiled successfully but i am facing an issue with TriggeredBy: [[0;1;32m●[[0m avahi-daemon.socket, when i restart my servi

#yocto

Hello, It's a bit hard to know where to start without more information. Can you tell us what release, layers and hardware you are using? Are you able to reproduce the problem using runqemu ? Are you a

#yocto