[yocto] Files missing from SDK

Gary Thomas gary at mlbassoc.com
Tue Mar 7 23:51:09 PST 2017


On 2017-03-07 23:26, Paul Eggleton wrote:
> On Tuesday, 7 March 2017 5:44:05 PM NZDT Gary Thomas wrote:
>> On 2017-03-06 21:56, Paul Eggleton wrote:
>>> On Tuesday, 7 March 2017 2:28:22 AM NZDT Gary Thomas wrote:
>>>> On 2017-03-06 13:22, Burton, Ross wrote:
>>>>> On 3 March 2017 at 06:39, Gary Thomas <gary at mlbassoc.com
>>> <mailto:gary at mlbassoc.com>> wrote:
>>>>>     I'm trying to build SDKs for my board, both the native style
>>>>>     using populate_sdk_ext as well as including the SDK packages
>>>>>     in my image.  My image includes some extended libraries of
>>>>>     my own packaging (am335x-pru-support) that I need to get into
>>>>>     these SDKs.  This package (via debian renaming) turns into
>>>>>
>>>>>       libprussdrv-dbg - 2016-08-30-r0.23 - am335x-pru-support version
>>>>>       2016-08-30-r0 - Debugging files libprussdrv-dev - 2016-08-30-r0.23
>>>>>       - am335x-pru-support version 2016-08-30-r0 - Development files
>>>>>       libprussdrv-staticdev - 2016-08-30-r0.23 - am335x-pru-support
>>>>>       version 2016-08-30-r0 - Development files (St) libprussdrv1 -
>>>>>       2016-08-30-r0.23 - am335x-pru-support version 2016-08-30-r0>
>>>>>
>>>>>     On my board/image, I can get the files I need but only if I manually
>>>>>     include libprussdrv-dev>
>>>>>
>>>>>       # opkg files libprussdrv-dev | sort
>>>>>       /usr/bin/pasm
>>>>>       /usr/include/pruss/
>>>>>       /usr/include/pruss/pruss_intc_mapping.h
>>>>>       /usr/include/pruss/prussdrv.h
>>>>>       /usr/lib/libprussdrv.so
>>>>>
>>>>>     How can I get these automatically added to my SDK images?  To build
>>>>>     the
>>>>>
>>>>>     board SDK, I'm adding these packages to my image:
>>>>>       CORE_IMAGE_EXTRA_INSTALL = "packagegroup-core-sdk
>>>>>       packagegroup-core-standalone-sdk-target">
>>>>>
>>>>>     I suppose I could add libprussdrv-dev to that list, but I'd like it
>>>>>     a
>>>>>     bit more automated.>
>>>>>
>>>>>     For the native SDK, I tried adding this to local.conf:
>>>>>       TOOLCHAIN_HOST_TASK_append = " nativesdk-am335x-pru-support"
>>>>>
>>>>>     which only got me the 'pasm' tool in my sysroot, but nothing else.
>>>>>
>>>>> If libprussdrv1 is in your image then the -dev package should be pulled
>>>>> into your SDK images, assuming that you have IMAGE_FEATURES+=dev-pkgs
>>>>> already.
>>>>
>>>> Thanks, that did it for the embedded SDK
>>>
>>> That shouldn't actually be necessary. IMAGE_FEATURES controls what goes
>>> into the image, adding dev-pkgs to that is going to include those in the
>>> image, not just the SDK. We have a SDKIMAGE_FEATURES and the default
>>> value of that includes dev-pkgs. If libprussdrv1 is in the image and
>>> SDKIMAGE_FEATURES is at the default (or otherwise includes dev-pkgs) I
>>> have to say I'm not sure what would be preventing this from working.
>>>
>>>>> The same should mean that standalone SDKs (populate_sdk-style) contain
>>>>> the
>>>>> headers too.  Worse case, TOOLCHAIN_TARGET_TASK_append = "
>>>>> libprussdrvi-dev".
>>>>
>>>> Sadly, this still doesn't work.  With the TOOLCHAIN* line above, I get:
>>>>    ERROR: Nothing RPROVIDES 'libprussdrv1-dev'
>>>>
>>>> Without it, no changes - the bits are still missing.
>>>
>>> As with almost all variables, in TOOLCHAIN_TARGET_TASK you want the
>>> recipe-
>>> space name of the package, not the final (post debian-renamed) name.
>>
>> I tried that as well, and it got a lot farther along, but failed in
>> the final steps:
>>
>> ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Unable to install packages.
>> Command
>> '/build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative
>> -tarball/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
>> /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-
>> tarball/1.0-r0/opkg.conf -t
>> /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-
>> tarball/1.0-r0/temp/ipktemp/ -o
>> /build/p8701_2016-10-22/tmp/work/x86_64-nativesdk-amltdsdk-linux/uninative-
>> tarball/1.0-r0/sdk/image/opt/amltd/2.2+snapshot/sysroots/none
>> --force_postinstall --prefer-arch-to-version   install libprussdrv-dev'
>> returned 255: Collected errors:
>>   * opkg_prepare_url_for_install: Couldn't find anything to satisfy
>> 'libprussdrv-dev'.
>>
>> ERROR: uninative-tarball-1.0-r0 do_populate_sdk: Function failed:
>> do_populate_sdk
>
> It sounds like you're setting TOOLCHAIN_TARGET_TASK at the configuration
> level, thus affecting uninative-tarball as well. Set it in your image recipe
> (or a class / inc file used from there) and that should work.

Thanks, that solved that problem.  I'm now getting the missing files in my
[host] SDK, getting much closer.

I'm still missing some others though - files from [meta-ti]recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
I am getting the appropriate files when I build using bitbake, as well as
on my target when I include the sdk components, just not when I build a
host SDK using -c populate_sdk_ext

That's a very differently packaged recipe (lots of magic), so I'll take it up with the meta-ti list

Thanks for your help

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



More information about the yocto mailing list