• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 279 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM62X: yocto "bitbake meta-toolchain-arago-tisdk" doesnt allow for custom targets. causing SDK to be missing components

Jesse Kolstad
Prodigy 60 points
Part Number: PROCESSOR-SDK-AM62X

Tool/software:

im used to yocto sdk being part of the target build.

example:
bitbake <my_custom_content_image> -c populate_sdk

but what TI is doing:
bitbake meta-toolchain-arago-tisdk
No image defined?

since there is no reference to the target I'm building for my sdk i keep having missing components. ie sdk is not including needed content.


we need to build multiple outputs for various reasons which is why all our included components for various image builds are in a custom target layer bb file and not just hardcoded in local.conf.

how do you get this original yocto behavior back when its this one off sdk command (bitbake meta-toolchain-arago-tisdk)?
its not following specified target which always had automatically include packages by its nature?

can we get standard  bitbake <my_custom_content_image> -c populate_sdk to work like it should?

or a workaround to make it always include the target image we need to generate the sdk for? again this cant just be a flat local.conf that kills custom target outputs.

we have a lot of automation and source control wrapped around yocto to make it scriptable to pull and generate. so changes needs to all exist within our custom meta-layer and not mess with other meta layers folders we dont own and control.

it was always strait forward when its original yocto behavior to generate sdk via -c populate_sdk.
Now im a little confused how this is supposed to work thus my forum hail marry.

  • 0
    Prodigy 60 points

    an example is boost and opencv are not included in sdk. but its on the board from our target image build.

  • 0
    Prodigy 60 points

    i believe I'm starting to find a way.
    the sdk target <meta-toolchain-arago-tisdk.bb> needs 
    require recipes-ocr/ocr-image-dev.bb
    added to it which is the recipe that it wants to make the sdk against.

    i think i can bbappend meta-toolchain-arago-tisdk to include it.
    the downside is  there is only one bbappend. so it might still be dirty to swap out various bbappend content but it can still be done all within our own meta layer.

    stand by for further info as i work though this

  • 0
    TI__Guru 69707 points

    Hi Jesse,

    Jesse Kolstad said:
    can we get standard  bitbake <my_custom_content_image> -c populate_sdk to work like it should?

    This is not something we support for our SDK v11.x stream. Building the cross toolchain/devkit using `meta-toolchain-arago-tisdk` is the recommended and officially supported method.

    If you want additional headers/libraries etc. included into your cross toolchain you need to specifically add those to the toolchain like this (assumes conf/local.conf change) like this...

    # Make sure package-related libraries etc. for a specific package are made part
# of the toolchain installer build with `bitbake meta-toolchain-arago-tisdk`.
# Note that for header files (.h) to get populated into the devkit installer
# one need to add the respective '-dev' package variants.
TOOLCHAIN_TARGET_TASK:append = " package_1 package_2 ..."

    But just for completeness sake let me check in with our dev team for the latest reasoning as to why `-c populate_sdk` is not supported in the context of SDK v11.x. I know I was able to make this work with some earlier SDK versions like v9.x but I haven't attempted this for a while.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 60 points

    OK now i feel dumb.
    Originally TI was very adamant to not use and cannot use "-c populate_sdk" and i had tried it back in 9x and a sea of red text flowed out from trying it.

    well i tried it now it it appears to have generated an SDK without error. so i take back what i said. 
    BTW im on 10.01 and i now see 11x was just released.

  • 0 in reply to Jesse Kolstad
    Prodigy 60 points

    one note post build of using SDK for our application.

    there were 3 opencv 3rd party libs (we don't use) that were blowing up the cmake build. i had to manually pull them from the opencv SDK cmake files to not reference then, (the only 3rd party components there were ).

    correspondence
    Multiview
    numeric

    /opt/arago-2023.10/sysroots/aarch64-oe-linux/usr/lib/cmake/opencv4/
    OpenCVModules-release.cmake
    OpenCVModules.cmake

    then our applications all built against the SDK. no missing components like boost and opencv etc...

  • 0 in reply to Jesse Kolstad
    TI__Guru 69707 points

    Hi Jesse,

    Jesse Kolstad said:
    Originally TI was very adamant to not use and cannot use "-c populate_sdk" and i had tried it back in 9x and a sea of red text flowed out from trying it.

    One reason is we can only support what we officially document/test, otherwise there are too many permutations and it becomes unmanageable. But it doesn't mean if sufficiently motivated one can't go down a different path. Especially for large open-source projects, like Yocto.

    Jesse Kolstad said:
    well i tried it now it it appears to have generated an SDK without error. so i take back what i said. 
    BTW im on 10.01 and i now see 11x was just released.
    Jesse Kolstad said:
    there were 3 opencv 3rd party libs (we don't use) that were blowing up the cmake build. i had to manually pull them from the opencv SDK cmake files to not reference then, (the only 3rd party components there were ).

    Thanks for giving this a shot and reporting back here. I know we have made improvements to generally make SDK v10.x and v11.x more Yocto-ish, and better contain/compartmentalize the TI contributions with less interdependencies, so this helped I'm sure. Good to hear the created devkit seems to be without any missing components.

    I'm still waiting to hear back from the development team as to why the `-c populate_sdk` isn't our official route and report back here.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 60 points

    not sure why it worked when it didn't in 9x but its possible because i built the ti sdk target first then did the std yocto that it had some things it needed. just guessing that order of operation might contributed to 99.9% success.
    hoping when i move to 11x that that stays true Slight smile

  • 0 in reply to Jesse Kolstad
    TI__Guru 69707 points

    Hi Jesse,

    Andreas Dannenberg said:
    But just for completeness sake let me check in with our dev team for the latest reasoning as to why `-c populate_sdk` is not supported in the context of SDK v11.x

    they pointed me to this Yocto community thread here; it explains some of the rationale behind keeping the `meta-toolchain-arago-tisdk` approach around, please have a look:

    https://lists.yoctoproject.org/g/meta-arago/topic/99071307#msg14450

    Regards, Andreas