>-----Original Message-----
>From: Aravind Batni
>Sent: Tuesday, February 18, 2014 7:41 PM
>To: Dmytriyenko, Denys; Maupin, Chase
>Cc: [email protected]
>Subject: RE: [meta-arago] [PATCH] ti-rm: provides ti resouce
>manager recipe for KeyStone devices
>
>Denys/Chase,
>Thanks for the inputs - Please find the response in-lined.
>
>-Best Regards,
>Aravind
>
>
>> -----Original Message-----
>> From: Dmytriyenko, Denys
>> Sent: Friday, February 14, 2014 4:12 PM
>> To: Maupin, Chase
>> Cc: Aravind Batni; [email protected]
>> Subject: Re: [meta-arago] [PATCH] ti-rm: provides ti resouce
>manager recipe
>> for KeyStone devices
>>
>> On Thu, Feb 13, 2014 at 02:14:56PM +0000, Maupin, Chase wrote:
>> > >-----Original Message-----
>> > >From: [email protected] [mailto:meta-
>arago-
>> > >[email protected]] On Behalf Of Aravind Batni
>> > >Sent: Wednesday, February 12, 2014 4:15 PM
>> > >To: [email protected]
>> > >Cc: Aravind Batni
>> > >Subject: [meta-arago] [PATCH] ti-rm: provides ti resouce
>manager
>> > >recipe for KeyStone devices
>> > >
>> > >- TI Resource Manager Low Level Driver
>> > >
>> > >Signed-off-by: Aravind Batni <[email protected]>
>> > >---
>> > > meta-arago-extras/recipes-bsp/ti-rm/ti-rm.inc | 7 ++++
>> > > meta-arago-extras/recipes-bsp/ti-rm/ti-rm_git.bb | 45
>> > >++++++++++++++++++++++
>> > > 2 files changed, 52 insertions(+)
>> > > create mode 100644 meta-arago-extras/recipes-bsp/ti-rm/ti-
>rm.inc
>> > > create mode 100644 meta-arago-extras/recipes-bsp/ti-rm/ti-
>> > >rm_git.bb
>> > >
>> > >diff --git a/meta-arago-extras/recipes-bsp/ti-rm/ti-rm.inc
>b/meta-
>> > >arago-extras/recipes-bsp/ti-rm/ti-rm.inc
>> > >new file mode 100644
>> > >index 0000000..96da467
>> > >--- /dev/null
>> > >+++ b/meta-arago-extras/recipes-bsp/ti-rm/ti-rm.inc
>> > >@@ -0,0 +1,7 @@
>> > >+LICENSE = "TI BSD"
>> > >+LIC_FILES_CHKSUM =
>> > >"file://COPYING.txt;md5=dc61631b65360e6beb73b6c337800afc"
>> > >+
>> > >+BRANCH="master"
>> > >+SRC_URI = "git://git.ti.com/keystone-rtos/rm-
>> > >lld.git;protocol=git;branch=${BRANCH}"
>> > >+# Below commit ID corresponds to DEV.RM_LLD.02.00.00.08
>SRCREV =
>> > >+"3a73cfe015214ff0401639f85fa5e52ea610e59d"
>> >
>> > If you aren't going to have multiple versions of a recipe the
>.inc is
>> > not required. If you do plan for multiple versions then the
>SRCREV at
>> > least is probably best left in the version specific recipe and
>not in the .inc.
>> > Looking at this I would think it likely that you could/should
>just
>> > roll this .inc into the regular .bb recipe.
>> >
>
> [Aravind Batni] Yes, we can roll this to the regular .bb recipe
>
>> > >diff --git a/meta-arago-extras/recipes-bsp/ti-rm/ti-rm_git.bb
>> >
>> > Looking at the SRCREV below do you want to call this
>02.00.00.08
>> > version of the recipe instead of just _git?
>> >
>[Aravind Batni] We would like to call this as _git recipe since
>we don't plan to provide multiple recipes per RM release.
>
>> > >b/meta-arago-extras/recipes-bsp/ti-rm/ti-rm_git.bb
>> > >new file mode 100644
>> > >index 0000000..7c8dad0
>> > >--- /dev/null
>> > >+++ b/meta-arago-extras/recipes-bsp/ti-rm/ti-rm_git.bb
>> > >@@ -0,0 +1,45 @@
>> > >+DESCRIPTION = "TI Resource Manager Low Level Driver"
>> > >+
>> > >+COMPATIBLE_MACHINE = "keystone"
>> > >+
>> > >+PR = "r0"
>> >
>> > You should probably set PV here if you are not going to change
>this
>> > recipe to a specific version.
>
>[Aravind Batni] Yes, I would add PV variable in the recipe
>> >
>> > >+DEPENDS="ti-ipc"
>> > >+LLD-NAME="rm"
>> > >+
>> > >+include ti-rm.inc
>> > >+
>> > >+S = "${WORKDIR}/git"
>> > >+LLD-BLD-DIR="${S}/ti/drv"
>> > >+
>> > >+PACKAGES =+ "${PN}-test"
>> > >+
>> > >+FILES_${PN}-test = "${bindir}/rmDspClientTest_*.out \
>> > >+ ${bindir}/rmLinuxClientTest_*.out \
>> > >+
>${bindir}/ti/drv/rm/test/dts_files/*.dtb"
>> > >+
>> > >+do_configure () {
>> > >+# tweak the directory structure to LLD way
>> > >+ cd ${S}
>> > >+ mkdir -p ${LLD-BLD-DIR}
>> > >+ cd ${LLD-BLD-DIR}
>> > >+ ln -s ${S} ${LLD-NAME}
>>
>> Also, please don't use dashes in variable names! Underscores,
>while not
>> recommended, are still acceptable:
>>
>> LLDBLDDIR - best from Bitbake perspective, not very human-
>readable
>> LLD_BLD_DIR - not perfect from Bitbake perspective, but
>parseable and
>> readable LLD-BLD-DIR - may cause all kinds of issues
>>
> [Aravind Batni] Yes, I would correct the recipe not to use any
>dashes
>>
>> > I'm not sure I understand what you are trying to do here. It
>seems
>> > like you want ${WORKDIR}/git/ti/drv/rm to be pointed to ${S}?
>Looking
>> > below it seems like you then want to pass ${S}/ti/drm/rm,
>which points
>> > to ${S} to the make commands. So can't you just point things
>to ${S}?
>> >
>> > Are you trying to work around the Makefile maybe looking for
>other
>> > files in the ti/drv directory? Since you created that
>directory that
>> > doesn't seem likely though. This seems like an issue best
>handled by
>> > updating the Makefiles to allow you to set paths and have a
>set of
>> > defaults. i.e. PATHX ?= "default path". That way you can
>update PATHX as
>> a parameter you pass.
>> > But this seems strange to make new direcory structures that
>then link
>> > back to the base directory you were already in.
>[Aravind Batni] The RM source does not permit to build from ${S}
>directly. If we had a way to create ${S} (git clone) under
>ti/drv/rm, then we don’t need to create the symbolic links to
>build RM lld. This is done originally to support DSP builds that
>are delivered from PDK, which demand this depth in the directory.
OK, help me understand here. You are cloning to ${WORKDIR}/git, but you need
the clone to really be in ${WORKDIR}/git/ti/drv/rm directory because the
makefiles/sources demand this directory structure?
Denys, are you aware of any option to control where the clone checks out to?
If the sources were stored in the repo under ti/drm/rm would this work?
>> >
>> > >+}
>> > >+
>> > >+do_compile () {
>> > >+# Now build the lld in the updated directory
>> > >+ cd ${LLD-BLD-DIR}/${LLD-NAME}
>> > >+ make -f makefile_armv7 clean
>> > >PDK_INSTALL_PATH=${STAGING_INCDIR} DEVICE=k2h
>> RM_SRC_DIR=${LLD-
>> > >BLD-DIR}/${LLD-NAME}
>> > >+ make -f makefile_armv7 lib tests
>> > >PDK_INSTALL_PATH=${STAGING_INCDIR} DEVICE=k2h
>> RM_SRC_DIR=${LLD-
>> > >BLD-DIR}/${LLD-NAME}
>> > >+ make -f makefile_armv7 lib tests
>> > >PDK_INSTALL_PATH=${STAGING_INCDIR} DEVICE=k2h
>> RM_SRC_DIR=${LLD-
>> > >BLD-DIR}/${LLD-NAME} USEDYNAMIC_LIB=yes
>> > >+ make -f makefile_armv7 clean
>> > >PDK_INSTALL_PATH=${STAGING_INCDIR} DEVICE=k2k
>> RM_SRC_DIR=${LLD-
>> > >BLD-DIR}/${LLD-NAME}
>> > >+ make -f makefile_armv7 lib tests
>> > >PDK_INSTALL_PATH=${STAGING_INCDIR} DEVICE=k2k
>> RM_SRC_DIR=${LLD-
>> > >BLD-DIR}/${LLD-NAME}
>> > >+ make -f makefile_armv7 lib tests
>> > >PDK_INSTALL_PATH=${STAGING_INCDIR} DEVICE=k2k
>> RM_SRC_DIR=${LLD-
>> > >BLD-DIR}/${LLD-NAME} USEDYNAMIC_LIB=yes
>> >
>> > Some thoughts:
>> >
>> > 1. Would this be better done as a for loop iterated of the
>different
>> > DEVICE settings?
>[Aravind Batni] Yes, thanks for the inputs. I will modify the
>recipe to have for loops .
>> > 2. Since you don't seem to be breaking these libraries out per
>DEVICE
>> > and I think you are packaging both static and dynamic
>libraries would an
>> "all"
>> > make target be better than calling each individually?
>> > - I actually wonder if you would prefer to split dynamic vs.
>static
>> > libraries. Why are both packaged? Or maybe I don't
>understand
>> what
>> > you are doing here?
>> > 3. Should the libraries be packaged per DEVICE? The root of
>this
>> > question is whether this recipe should be machine specific and
>you
>> > build the package for k2k and k2h devices. It seems like you
>are
>> > making one package that has support for multiple devices.
>
>[Aravind Batni] There is a single library for both K2H and K2K
>devices, the options are for test applications. I now modified the
>recipe
>to build the library only once for both K2H and K2K and build all
>other variations on the test applications in the next updated
>patch submit.
>> >
>> > >+}
>> > >+
>> > >+do_install () {
>> > >+ install -d ${D}/${includedir}/ti/drv/${LLD-NAME}
>> > >+ install -d ${D}/${libdir}
>> > >+ install -d ${D}/${bindir}
>> > >+ make -f makefile_armv7 install installbin
>installbin_test
>> > >INSTALL_INC_BASE_DIR=${D}/${includedir}
>> > >INSTALL_LIB_BASE_DIR=${D}/${libdir}
>> > >INSTALL_BIN_BASE_DIR=${D}/${bindir} DEVICE=k2h
>> > >+ make -f makefile_armv7 install installbin
>installbin_test
>> > >INSTALL_INC_BASE_DIR=${D}/${includedir}
>> > >INSTALL_LIB_BASE_DIR=${D}/${libdir}
>> > >INSTALL_BIN_BASE_DIR=${D}/${bindir} DEVICE=k2k
>> > >+}
>> > >--
>[Aravind Batni] I would have a for loop based installs for every
>device.
>> > >1.7.9.5
>> > >
>> > >_______________________________________________
>> > >meta-arago mailing list
>> > >[email protected]
>> > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
>> > _______________________________________________
>> > meta-arago mailing list
>> > [email protected]
>> > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
_______________________________________________
meta-arago mailing list
[email protected]
http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
