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

yocto provides a layer to abstract native binaries on top of build host and thats what you are seeing. Its as designed. > > >

#toolchain #sdk #bitbake #native

I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the pr

#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 Marco, In your opinion isn't enough to ask for eSDK? for instance if i want to add Node-RED, it would be difficult to build with devtool? because i've seen that it doesn't resolve dependencies a

#sdk #zeus #toolchain

With the eSDK i've to use devtool right?

#sdk #zeus #toolchain

Hello Enrico, usually nowadays every honest hardware manufacturer provides all the sources of the BSP and the development system to their customers. Try asking your supplier for them. -- Marco Cavalli

#sdk #zeus #toolchain

if its eSDK then you can, with standard application SDK not so much.

#sdk #zeus #toolchain

Hello, It has been 2 years that i'm using the yocto project to build the image for an embedded system on IMX8M. Now the system basic image is done outside and i receive the SDK. All the additional pac

#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

I was able to make it work correctly enabling CMAKE_SKIP_RPATH. Here the working full recipe: LICENSE = "NCSA" LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=59d01ad98720f3c50d6a8a0ef3108c88 \ file://iwyu

#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

Good morning everybody, I would like to include IWYU in my SDK, but I couldn't find a recipe, so I'm trying to write my own. With the help of devtool, I came to something like this: LICENSE = "NCSA" L

#sdk

Thanks you...

#yocto #sdk #cmake

take a look at https://github.com/kraj/meta-clang/blob/master/recipes-core/meta/clang-environment.inc#L11-L19 perhaps that can be something you might find useful On Thu, Apr 22, 2021 at 11:51 AM Monse

#yocto #sdk #cmake

When setting up an SDK, (standard or extensible), build which will be using cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for ones env/applications ? Currently I build the SDK,

#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

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