> -----Original Message-----
> From: Dmytriyenko, Denys
> Sent: Wednesday, February 19, 2014 5:04 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 Wed, Feb 19, 2014 at 09:17:48AM -0500, Maupin, Chase wrote:
> > >-----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?
>
> Yes, adding ;destsuffix=ti/drv/rm to SRC_URI will check out into that
> directory relative to ${WORKDIR}. If you want the default "git" part
> preserved, you can do ;destsuffix=git/ti/drv/rm - either way is fine.
>
[Aravind Batni] Denys, Thanks - this would help me not to have any symbolic
links in the recipe.
>
> > 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
