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

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

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

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 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

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

#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

Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ? Thanks, Steve

#yocto #sdk

I still appear to be having an issue with the SXT SDK install… Building for zeus/x86_64 Intel based platform… I build my kernel image clean, fully functional… Standard SDK builds clean and appears fun

#yocto #sdk

Thanks, will try it out...

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST “ ? I tried to do : BB_HASHBASE_WHITELIST += “BB_TRACE” in my local.conf but it ended up replacing existing list with just “BB_T

Thanks again, these utilities make it much easier to understand and correct the issues...

#yocto #sdk

Thanks, will go through it...

#yocto #sdk

I am trying to understand the warnings/error as seen below… Building for zeus… Built kernel image clean updated my SSTATE_MIRRORS directory with the state_cache generated. Rebuilt my image clean again

#yocto #sdk

I have gotten much closer with Yocto-check-layer, down to the same error for both layers, all other tests passing… Can someone explain what the error means, and what might be causing it ? Meta-intel-b

#yocto #kernel

Is there documentation on the yocto-check-layer script thtat goes over proper use of command line options ?

#yocto #kernel