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

Hello, Currently using Rocko to generate toolchains for ARM targets. Our BSP layer that is able to build a toolchain for our target architecture, ARM. I'd like to be able to add an x86 machine to this

#rocko #sdk #native

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

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

it excludes the variables from checksums see https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#checksums

#yocto #sdk

What is the difference between using “SIGGEN_UNLOCKED_RECIPES +=” and “BB_HASHBASE_WHITELIST_append =” ?

#yocto #sdk

right, the change seems to be happening in task checksums and that happens if some of bitbake variables change when SDK is built built and when it is being installed ( when it will run parse again ) p

#yocto #sdk

Nope, just validated... I build the my kernel image clean and the eSDK image right after, cache should be good, no ? Not sure how to go about resolving... it occurs on the back end of the eSDK install

#yocto #sdk

I am seeing similar issues on line for my eSDK install issue, but no resolutions… Can someone advise on best course of action to debug this ? 11:10 smonsees@yix490016 /disk0/scratch/smonsees/yocto/wor

#yocto #sdk