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

[Denys Dmytriyenko]

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

-- 
Denys