[meta-ti] Getting TI tools into [host] SDK

[Khem Raj]

On 3/10/17 6:27 PM, Denys Dmytriyenko wrote:
> On Fri, Mar 10, 2017 at 06:00:20PM -0800, Khem Raj wrote:
>>
>>
>> On 3/10/17 5:47 PM, Denys Dmytriyenko wrote:
>>> On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
>>>> On 17-03-08 09:10:18, Gary Thomas wrote:
>>>>> I'm trying to build a [host] SDK for my target which uses some
>>>>> TI tools, via -c populate_sdk_ext
>>>
>>> Gary,
>>>
>>> We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the 
>>> old meta-toolchain mechanism. First, because it can be incorporated into other 
>>> recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball. 
>>> Second, it provides more control to what get's packaged into SDK. Third, it 
>>> doesn't have this undefined magic to packaging stuff - i.e. this post is an 
>>> example of it failing. And only one slight drawback - requires keeping rootfs 
>>> image recipe in sync with meta-toolchain SDK recipe...
>>>
>>>
>>>>> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
>>>>> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
>>>>> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
>>>>>
>>>>> The problem is that in my SDK, none of the binaries are included, including clpru:
>>>>>
>>>>> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
>>>>> total 16
>>>>> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
>>>>> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
>>>>>
>>>>> I added this to try and include the files:
>>>>>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
>>>>> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
>>>>> executables included, they just aren't being packaged.
>>>>>
>>>>> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
>>>>
>>>> perhaps you need to correct the install location for nativesdk may be
>>>> via overriding do_install
>>>
>>> Why?
>>
>> because  /usr/share doesnt look normal place for putting executables.
> 
> True in general, but that shouldn't matter. FILES_${PN} lists those and that 
> should be enough. It appears you are just guessing...
> 
> Sidenote:
> This PRU CodeGen toolchain is kind of weird - it targets PRUs (Programmable 
> Real-time Units http://elinux.org/Ti_AM33XX_PRUSSv2) and provides binaries in 
> bin/, headers in include/ and libraries in lib/ directories. Some of the names 
> collide with system (e.g. libc.a) and hence cannot be installed in standard 
> locations, thus /usr/share. In fact, many of non-Linux specific components 
> that deal with specialized cores (i.e. non-general-purpose ARM, such as DSP, 
> PRU, IPU, numerous Cortex-M accelerators, etc.) are in fact as weird and are 
> also getting installed in /usr/share to not confuse people and not conflict 
> with the rest of the system...
> 

it would be better to have multiple sysroots for all these variants
would be way simpler and understandable, but why do I care.