* [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices @ 2014-02-12 22:14 Aravind Batni 2014-02-13 14:14 ` Maupin, Chase 0 siblings, 1 reply; 9+ messages in thread From: Aravind Batni @ 2014-02-12 22:14 UTC (permalink / raw) To: meta-arago; +Cc: Aravind Batni - TI Resource Manager Low Level Driver Signed-off-by: Aravind Batni <aravindbr@ti.com> --- 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" diff --git a/meta-arago-extras/recipes-bsp/ti-rm/ti-rm_git.bb 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" +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} +} + +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 +} + +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 +} -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-12 22:14 [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices Aravind Batni @ 2014-02-13 14:14 ` Maupin, Chase 2014-02-14 21:11 ` Denys Dmytriyenko 0 siblings, 1 reply; 9+ messages in thread From: Maupin, Chase @ 2014-02-13 14:14 UTC (permalink / raw) To: Aravind Batni, meta-arago@arago-project.org >-----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 <aravindbr@ti.com> >--- > 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. >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? >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. >+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} 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. >+} >+ >+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? 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. >+} >+ >+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 >+} >-- >1.7.9.5 > >_______________________________________________ >meta-arago mailing list >meta-arago@arago-project.org >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-13 14:14 ` Maupin, Chase @ 2014-02-14 21:11 ` Denys Dmytriyenko 2014-02-19 1:40 ` Aravind Batni 0 siblings, 1 reply; 9+ messages in thread From: Denys Dmytriyenko @ 2014-02-14 21:11 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-arago@arago-project.org, Aravind Batni 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 <aravindbr@ti.com> > >--- > > 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. > > >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? > > >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. > > >+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 > 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. > > >+} > >+ > >+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? > 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. > > >+} > >+ > >+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 > >+} > >-- > >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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-14 21:11 ` Denys Dmytriyenko @ 2014-02-19 1:40 ` Aravind Batni 2014-02-19 14:17 ` Maupin, Chase 0 siblings, 1 reply; 9+ messages in thread From: Aravind Batni @ 2014-02-19 1:40 UTC (permalink / raw) To: Dmytriyenko, Denys, Maupin, Chase; +Cc: meta-arago@arago-project.org 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 <aravindbr@ti.com> > > >--- > > > 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 > > >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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-19 1:40 ` Aravind Batni @ 2014-02-19 14:17 ` Maupin, Chase 2014-02-19 15:07 ` Aravind Batni 2014-02-19 22:03 ` Denys Dmytriyenko 0 siblings, 2 replies; 9+ messages in thread From: Maupin, Chase @ 2014-02-19 14:17 UTC (permalink / raw) To: Aravind Batni, Dmytriyenko, Denys; +Cc: meta-arago@arago-project.org >-----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 <aravindbr@ti.com> >> > >--- >> > > 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 >> > >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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-19 14:17 ` Maupin, Chase @ 2014-02-19 15:07 ` Aravind Batni 2014-02-19 16:11 ` Maupin, Chase 2014-02-19 22:03 ` Denys Dmytriyenko 1 sibling, 1 reply; 9+ messages in thread From: Aravind Batni @ 2014-02-19 15:07 UTC (permalink / raw) To: Maupin, Chase, Dmytriyenko, Denys; +Cc: meta-arago@arago-project.org > -----Original Message----- > From: Maupin, Chase > Sent: Wednesday, February 19, 2014 9:18 AM > To: Aravind Batni; Dmytriyenko, Denys > Cc: meta-arago@arago-project.org > 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: 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 <aravindbr@ti.com> > >> > >--- > >> > > 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. > > >> > > >> > >+} > >> > >+ > >> > >+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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-19 15:07 ` Aravind Batni @ 2014-02-19 16:11 ` Maupin, Chase 0 siblings, 0 replies; 9+ messages in thread From: Maupin, Chase @ 2014-02-19 16:11 UTC (permalink / raw) To: Aravind Batni, Dmytriyenko, Denys; +Cc: meta-arago@arago-project.org >-----Original Message----- >From: Aravind Batni >Sent: Wednesday, February 19, 2014 9:07 AM >To: Maupin, Chase; Dmytriyenko, Denys >Cc: meta-arago@arago-project.org >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: meta-arago@arago-project.org >> 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: 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 <aravindbr@ti.com> >> >> > >--- >> >> > > 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 >> >> > >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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-19 14:17 ` Maupin, Chase 2014-02-19 15:07 ` Aravind Batni @ 2014-02-19 22:03 ` Denys Dmytriyenko 2014-02-19 22:09 ` Aravind Batni 1 sibling, 1 reply; 9+ messages in thread From: Denys Dmytriyenko @ 2014-02-19 22:03 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-arago@arago-project.org, Aravind Batni 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 <aravindbr@ti.com> > >> > >--- > >> > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices 2014-02-19 22:03 ` Denys Dmytriyenko @ 2014-02-19 22:09 ` Aravind Batni 0 siblings, 0 replies; 9+ messages in thread From: Aravind Batni @ 2014-02-19 22:09 UTC (permalink / raw) To: Dmytriyenko, Denys, Maupin, Chase; +Cc: meta-arago@arago-project.org > -----Original Message----- > From: Dmytriyenko, Denys > Sent: Wednesday, February 19, 2014 5:04 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 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 <aravindbr@ti.com> > > >> > >--- > > >> > > 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 > > >> > >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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-02-19 22:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-12 22:14 [PATCH] ti-rm: provides ti resouce manager recipe for KeyStone devices Aravind Batni 2014-02-13 14:14 ` Maupin, Chase 2014-02-14 21:11 ` Denys Dmytriyenko 2014-02-19 1:40 ` Aravind Batni 2014-02-19 14:17 ` Maupin, Chase 2014-02-19 15:07 ` Aravind Batni 2014-02-19 16:11 ` Maupin, Chase 2014-02-19 22:03 ` Denys Dmytriyenko 2014-02-19 22:09 ` Aravind Batni
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.