I am unable to build an extensible SDK for my RISC-V machine. Required Details: Also, I am able to build the normal SDK successfully. I ran this for my custom machine "cdac-ooo". MACHINE=cdac-ooo bitb

#dunfell #sdk #yocto

Native recipes are meant for the build machine itself to aid your build. If you are packaging something to run on a destination machine, you should be producing non-native recipe images. ..Ch:W..

#toolchain #sdk #bitbake #native

Hello Enrico, an eSDK would be enough to do everything, however I would demand the entire development system if I were to start a project, but that is my opinion. I don't know well Node-RED but using

#sdk #zeus #toolchain

Hello, I permit myself to contact you because I got a weird issue in my sdk toolchain. So, as I need "qtremoteobjects" in my embedded linux image, I add it like this: ---------------------------------

#toolchain #sdk #qtremoteobjects #repc

this is fine, if you are interested submit it as a patch to include in metadata in meta-python

#sdk

Hello, I wrote a kernel driver which exposes some header to userspace application. Application engineers use generated SDK, so I'd like to export that header file as part of SDK. I added my header to

#kernel #sdk

Thanks you...

#yocto #sdk #cmake

Any one seen this before… ? SDK appears to be working okay without the inclusion of native python3 components, not sure how the inclusion breaks devtool…

#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

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

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

#yocto #sdk

Hi, We have a functioning image built for our device/platform based on Ti Processor SDK 04.03.00.05; at this point I'm trying to build an SDK for the image that I can distribute to other members of ou

#toolchain #sdk #qt5

That means it’s having issues with checksums is there any AUTOREV being used ? I would suggest to build without your changes and see if you can get an eSDK

#yocto #zeus #sdk

Hello Alexander, I have two ideas that might get you closer. 1) First, I noticed that using TOOLCHAIN_HOST_TASK += "xxx" is broken on Yocto dunfell for me (non-extensible SDK). The issue is that even

#sdk

Hi Team, I've built OS for rpi3 using dunfell yocto. I've also generated SDK for the same, for that I've added these info in my local.conf file- TOOLCHAIN_TARGET_TASK_append = " python3-dev kernel-dev

#dunfell #raspberrypi #sdk

Hi All, I'm in serious task here and I need to cross compile a Cmake project. I need to send an SDK to a client with steps to cross compile the project. This project is compiling successfully via a Yo

#sdk #yocto #toolchain

Hello Henrik, As far as I known: - The -dev packages do not end up in target rootfs, unless you specify them in your target image. - The -dev packages end up in the standard SDK target sysroot if you

#yocto #sdk

On Thu, Oct 1, 2020 at 7:42 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote: drm_intel is in upstream kernel isn't it ? So just check

#yocto #sdk