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