>-----Original Message-----
>From: Aravind Batni
>Sent: Wednesday, February 19, 2014 9:07 AM
>To: Maupin, Chase; Dmytriyenko, Denys
>Cc: [email protected]
>Subject: RE: [meta-arago] [PATCH] ti-rm: provides ti resouce
>manager recipe for KeyStone devices
>
>> -----Original Message-----
>> From: Maupin, Chase
>> Sent: Wednesday, February 19, 2014 9:18 AM
>> To: Aravind Batni; Dmytriyenko, Denys
>> Cc: [email protected]
>> Subject: RE: [meta-arago] [PATCH] ti-rm: provides ti resouce
>manager recipe
>> for KeyStone devices
>>
>> >-----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?
>>
>[Aravind Batni] Yes, if we had an option to clone the repo under
>${WORKDIR}/git/ti/drv/rm everything would work and we don't need
>to do symbolic links for the builds.
Aravind, my question is whether inside the git repository you can store the
sources in a ti/drv/rm directory.
>>
>> >> >
>> >> > >+}
>> >> > >+
>> >> > >+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
