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

[Denys Dmytriyenko]

On Fri, Mar 10, 2017 at 06:45:00PM -0800, Khem Raj wrote:
> 
> 
> 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.

Unfortunately, OE doesn't easily support separate sysroots for "secondary" 
processors, besides host and target, like DSP. We had looked into that long 
time ago w/o much success. If you have any suggestions or recommendations, I'm 
all ears!

-- 
Denys