From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by arago-project.org (Postfix) with ESMTPS id E3A0252986 for ; Wed, 19 Feb 2014 22:03:56 +0000 (UTC) Received: from dflxv15.itg.ti.com ([128.247.5.124]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id s1JM3uJH000889 for ; Wed, 19 Feb 2014 16:03:56 -0600 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id s1JM3txb012246 for ; Wed, 19 Feb 2014 16:03:55 -0600 Received: from dflp33.itg.ti.com (10.64.6.16) by DFLE72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.3.174.1; Wed, 19 Feb 2014 16:03:55 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id s1JM3t5f001040; Wed, 19 Feb 2014 16:03:55 -0600 Date: Wed, 19 Feb 2014 17:03:55 -0500 From: Denys Dmytriyenko To: "Maupin, Chase" Message-ID: <20140219220355.GF7138@edge> References: <1392243289-10398-1-git-send-email-aravindbr@ti.com> <7D46E86EC0A8354091174257B2FED1015996BEC8@DLEE11.ent.ti.com> <20140214211136.GM7138@edge> <941289A393E94C478C153EF5E432FDBB3EA797F4@DBDE04.ent.ti.com> <7D46E86EC0A8354091174257B2FED1015CEBED5F@DLEE11.ent.ti.com> MIME-Version: 1.0 In-Reply-To: <7D46E86EC0A8354091174257B2FED1015CEBED5F@DLEE11.ent.ti.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "meta-arago@arago-project.org" , Aravind Batni Subject: Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices X-BeenThere: meta-arago@arago-project.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Arago metadata layer for TI SDKs - OE-Core/Yocto compatible List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:03:57 -0000 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: meta-arago@arago-project.org > >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; meta-arago@arago-project.org > >> 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: meta-arago-bounces@arago-project.org [mailto:meta- > >arago- > >> > >bounces@arago-project.org] On Behalf Of Aravind Batni > >> > >Sent: Wednesday, February 12, 2014 4:15 PM > >> > >To: meta-arago@arago-project.org > >> > >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 > >> > >--- > >> > > 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. > 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 > >> > >meta-arago@arago-project.org > >> > >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago > >> > _______________________________________________ > >> > meta-arago mailing list > >> > meta-arago@arago-project.org > >> > http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago