[PATCH v2] cmem: Adding New recipe for cmem

[PATCH v2] cmem: Adding New recipe for cmem

[Sam Nelson]

- Cmem module is used for user space contiguous memory alloation

Signed-off-by: Sam Nelson <sam.nelson@ti.com>
---
 recipes-bsp/cmem/cmem-mod_git.bb |   26 ++++++++++++++++++++++++++
 recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
 recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
 3 files changed, 54 insertions(+)
 create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
 create mode 100644 recipes-bsp/cmem/cmem.inc
 create mode 100644 recipes-bsp/cmem/cmem_git.bb

diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-bsp/cmem/cmem-mod_git.bb
new file mode 100644
index 0000000..c402b72
--- /dev/null
+++ b/recipes-bsp/cmem/cmem-mod_git.bb
@@ -0,0 +1,26 @@
+DESCRIPTION="Contiguous memory allocation kernel module for contiguous memory allocation from userspace "
+
+include cmem.inc
+
+NAME="cmem"
+
+# This package builds a kernel module, use kernel PR as base and append a local
+PR = "${MACHINE_KERNEL_PR}"
+PR_append = "a"
+
+PKG_${PN} = "kernel-module-${PN}"
+
+S = "${WORKDIR}/git"
+
+inherit module
+
+do_compile () {
+    cd ${S}
+    make -f lu.mak module_clean
+    make -f lu.mak module KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR} TOOLCHAIN_PREFIX=${CROSS_COMPILE} 
+}
+
+do_install () {
+    cd ${S}
+    make -f lu.mak module_install KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra" INSTALL_MOD_PATH="${D}"
+}
diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
new file mode 100644
index 0000000..5d17d8e
--- /dev/null
+++ b/recipes-bsp/cmem/cmem.inc
@@ -0,0 +1,12 @@
+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb8310b3b983024edc620"
+
+COMPATIBLE_MACHINE = "keystone-evm"
+
+BRANCH ?= "master"
+#SRCREV = "4.00.00.06"
+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
+
+SRC_URI = "git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-bsp/cmem/cmem_git.bb
new file mode 100644
index 0000000..f415630
--- /dev/null
+++ b/recipes-bsp/cmem/cmem_git.bb
@@ -0,0 +1,16 @@
+DESCRIPTION="The cmem component supports contiguous memory allocation from userspace "
+
+include cmem.inc
+
+RDEPENDS_${PN} = "cmem-mod" 
+
+S = "${WORKDIR}/git"
+
+PR = "r0"
+
+PACKAGES =+ "${PN}-test"
+
+FILES_${PN}-test = "${bindir}/*"
+
+inherit autotools
+
-- 
1.7.9.5

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Maupin, Chase]

>-----Original Message-----
>From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
>bounces@arago-project.org] On Behalf Of Nelson, Sam
>Sent: Thursday, November 07, 2013 10:34 AM
>To: meta-arago@arago-project.org; Nelson, Sam
>Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
>
>- Cmem module is used for user space contiguous memory alloation
>
>Signed-off-by: Sam Nelson <sam.nelson@ti.com>
>---
> recipes-bsp/cmem/cmem-mod_git.bb |   26
>++++++++++++++++++++++++++
> recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> 3 files changed, 54 insertions(+)
> create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> create mode 100644 recipes-bsp/cmem/cmem.inc
> create mode 100644 recipes-bsp/cmem/cmem_git.bb

This patch should be submitted to meta-ti@yoctoproject.org which is the meta-ti mailing list.

>
>diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
>bsp/cmem/cmem-mod_git.bb
>new file mode 100644
>index 0000000..c402b72
>--- /dev/null
>+++ b/recipes-bsp/cmem/cmem-mod_git.bb
>@@ -0,0 +1,26 @@
>+DESCRIPTION="Contiguous memory allocation kernel module for
>contiguous memory allocation from userspace "
>+
>+include cmem.inc
>+
>+NAME="cmem"

Not sure what the NAME variable is for

>+
>+# This package builds a kernel module, use kernel PR as base and
>append a local
>+PR = "${MACHINE_KERNEL_PR}"
>+PR_append = "a"
>+
>+PKG_${PN} = "kernel-module-${PN}"

I think what you are trying to do here is already handled by the package.bbclass.  I assume you are trying to set the package name to kernel-module-cmem-mod?

This raises the question of whether you want this to be cmem-mod for the recipe and PN or if you want cmem for the module and cmem-xyz for the libraries.

>+
>+S = "${WORKDIR}/git"
>+
>+inherit module
>+
>+do_compile () {
>+    cd ${S}
>+    make -f lu.mak module_clean
>+    make -f lu.mak module
>KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
>TOOLCHAIN_PREFIX=${CROSS_COMPILE}

You should use the default do_compile in the module.bbclass I think.  You should be able to pass this with MAKE_TARGETS variable.

>+}
>+
>+do_install () {
>+    cd ${S}
>+    make -f lu.mak module_install
>KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
>EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
>INSTALL_MOD_PATH="${D}"

Hmmm.  The default do_install for the module.bbclass uses "modules_install" instead of "module_install".  If you can get the lu.mak file updated that would be ideal.  If not then you should at least copy the base function which unsets some variables.

>+}
>diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
>new file mode 100644
>index 0000000..5d17d8e
>--- /dev/null
>+++ b/recipes-bsp/cmem/cmem.inc
>@@ -0,0 +1,12 @@
>+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
>+
>+LICENSE = "GPLv2"
>+LIC_FILES_CHKSUM =
>"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
>8310b3b983024edc620"
>+
>+COMPATIBLE_MACHINE = "keystone-evm"

As Sidd pointed out is there any reason not to add the other devices like omap-a15 as compatible machines?

>+
>+BRANCH ?= "master"
>+#SRCREV = "4.00.00.06"

Remove this comment but add one that the commit id below corresponds to release 4.00.00.06.

Is there perhaps a value to having the version in the package name instead of using _git versions?  Will all SDKs be in step with using the same version?

>+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
>+
>+SRC_URI =
>"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
>diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
>bsp/cmem/cmem_git.bb
>new file mode 100644
>index 0000000..f415630
>--- /dev/null
>+++ b/recipes-bsp/cmem/cmem_git.bb
>@@ -0,0 +1,16 @@
>+DESCRIPTION="The cmem component supports contiguous memory
>allocation from userspace "
>+
>+include cmem.inc
>+
>+RDEPENDS_${PN} = "cmem-mod"
>+
>+S = "${WORKDIR}/git"
>+
>+PR = "r0"
>+
>+PACKAGES =+ "${PN}-test"
>+
>+FILES_${PN}-test = "${bindir}/*"

As Denys pointed out last time, if everything goes into cmem-test then why not just call this whole recipe cmem-test since the base cmem package is empty.

>+
>+inherit autotools
>+
>--
>1.7.9.5
>
>_______________________________________________
>meta-arago mailing list
>meta-arago@arago-project.org
>http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Nelson, Sam]

> -----Original Message-----
> From: Maupin, Chase
> Sent: Thursday, November 07, 2013 2:35 AM
> To: Nelson, Sam; meta-arago@arago-project.org
> Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> 
> >-----Original Message-----
> >From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> >bounces@arago-project.org] On Behalf Of Nelson, Sam
> >Sent: Thursday, November 07, 2013 10:34 AM
> >To: meta-arago@arago-project.org; Nelson, Sam
> >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> >
> >- Cmem module is used for user space contiguous memory alloation
> >
> >Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> >---
> > recipes-bsp/cmem/cmem-mod_git.bb |   26
> >++++++++++++++++++++++++++
> > recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> > recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> > 3 files changed, 54 insertions(+)
> > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> > create mode 100644 recipes-bsp/cmem/cmem.inc
> > create mode 100644 recipes-bsp/cmem/cmem_git.bb
> 
> This patch should be submitted to meta-ti@yoctoproject.org which is the
> meta-ti mailing list.
[Sam] Ok. I will do that.
> 
> >
> >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
> >bsp/cmem/cmem-mod_git.bb
> >new file mode 100644
> >index 0000000..c402b72
> >--- /dev/null
> >+++ b/recipes-bsp/cmem/cmem-mod_git.bb
> >@@ -0,0 +1,26 @@
> >+DESCRIPTION="Contiguous memory allocation kernel module for
> >contiguous memory allocation from userspace "
> >+
> >+include cmem.inc
> >+
> >+NAME="cmem"
> 
> Not sure what the NAME variable is for
[Sam] I am not sure either. This is probably because of initial template used for creation of the recipe. I can remove it if this really not needed.
> 
> >+
> >+# This package builds a kernel module, use kernel PR as base and
> >append a local
> >+PR = "${MACHINE_KERNEL_PR}"
> >+PR_append = "a"
> >+
> >+PKG_${PN} = "kernel-module-${PN}"
> 
> I think what you are trying to do here is already handled by the
> package.bbclass.  I assume you are trying to set the package name to kernel-
> module-cmem-mod?
> 
> This raises the question of whether you want this to be cmem-mod for the
> recipe and PN or if you want cmem for the module and cmem-xyz for the
> libraries.
> 
[Sam] I guess the alternative you are suggesting is cmem for the module and cmem-lib for the libraries. I am not seeing a compelling reason to change.
> >+
> >+S = "${WORKDIR}/git"
> >+
> >+inherit module
> >+
> >+do_compile () {
> >+    cd ${S}
> >+    make -f lu.mak module_clean
> >+    make -f lu.mak module
> >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> 
> You should use the default do_compile in the module.bbclass I think.  You
> should be able to pass this with MAKE_TARGETS variable.
[Sam] Probably Chris and Rob on the CC list can comment on this. This will need change of the module.
> 
> >+}
> >+
> >+do_install () {
> >+    cd ${S}
> >+    make -f lu.mak module_install
> >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> >INSTALL_MOD_PATH="${D}"
> 
> Hmmm.  The default do_install for the module.bbclass uses
> "modules_install" instead of "module_install".  If you can get the lu.mak file
> updated that would be ideal.  If not then you should at least copy the base
> function which unsets some variables.
> 
[Sam] Probably Chris and Rob on the CC list can comment on this. This will need change of the module.
> >+}
> >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> >new file mode 100644
> >index 0000000..5d17d8e
> >--- /dev/null
> >+++ b/recipes-bsp/cmem/cmem.inc
> >@@ -0,0 +1,12 @@
> >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> >+
> >+LICENSE = "GPLv2"
> >+LIC_FILES_CHKSUM =
> >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> >8310b3b983024edc620"
> >+
> >+COMPATIBLE_MACHINE = "keystone-evm"
> 
> As Sidd pointed out is there any reason not to add the other devices like
> omap-a15 as compatible machines?

[Sam]  I am fine with remove the compatible machine. Although this is not tested with other machines.  
> >+
> >+BRANCH ?= "master"
> >+#SRCREV = "4.00.00.06"
> 
> Remove this comment but add one that the commit id below corresponds to
> release 4.00.00.06.
> 
[Sam] I will fix this.
> Is there perhaps a value to having the version in the package name instead of
> using _git versions?  Will all SDKs be in step with using the same version?
> 
[Sam] Chris or Rob, can you comment on this.  I am not sure of when the other verticals pick up CMEM.

> >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
> >+
> >+SRC_URI =
> >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
> >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
> >bsp/cmem/cmem_git.bb
> >new file mode 100644
> >index 0000000..f415630
> >--- /dev/null
> >+++ b/recipes-bsp/cmem/cmem_git.bb
> >@@ -0,0 +1,16 @@
> >+DESCRIPTION="The cmem component supports contiguous memory
> >allocation from userspace "
> >+
> >+include cmem.inc
> >+
> >+RDEPENDS_${PN} = "cmem-mod"
> >+
> >+S = "${WORKDIR}/git"
> >+
> >+PR = "r0"
> >+
> >+PACKAGES =+ "${PN}-test"
> >+
> >+FILES_${PN}-test = "${bindir}/*"
> 
> As Denys pointed out last time, if everything goes into cmem-test then why
> not just call this whole recipe cmem-test since the base cmem package is
> empty.
[Sam] The cmem package has the library that goes into cmem-dev. And hence the name cmem. cmem-test will have the example/unit test code binaries.  Only thing is there is no binary files associated with the cmem package itself.
> 
> >+
> >+inherit autotools
> >+
> >--
> >1.7.9.5
> >
> >_______________________________________________
> >meta-arago mailing list
> >meta-arago@arago-project.org
> >http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Tivy, Robert]

Please see my comments inline below...

Regards,

- Rob

> -----Original Message-----
> From: Nelson, Sam
> Sent: Thursday, November 07, 2013 3:50 AM
> To: Maupin, Chase; meta-arago@arago-project.org
> Cc: Ring, Chris; Tivy, Robert
> Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> 

...

> 
> > >+
> > >+S = "${WORKDIR}/git"
> > >+
> > >+inherit module
> > >+
> > >+do_compile () {
> > >+    cd ${S}
> > >+    make -f lu.mak module_clean
> > >+    make -f lu.mak module
> > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> > >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> >
> > You should use the default do_compile in the module.bbclass I think.
> You
> > should be able to pass this with MAKE_TARGETS variable.
> [Sam] Probably Chris and Rob on the CC list can comment on this. This
> will need change of the module.

Can you please explain the change needed?  I'm not familiar with do_compile().

> >
> > >+}
> > >+
> > >+do_install () {
> > >+    cd ${S}
> > >+    make -f lu.mak module_install
> > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> > >INSTALL_MOD_PATH="${D}"
> >
> > Hmmm.  The default do_install for the module.bbclass uses
> > "modules_install" instead of "module_install".  If you can get the
> lu.mak file
> > updated that would be ideal.  If not then you should at least copy
> the base
> > function which unsets some variables.
> >
> [Sam] Probably Chris and Rob on the CC list can comment on this. This
> will need change of the module.

This should be fine, I will make a change to lu.mak and commit to ludev.git.

How about module_clean?  Should that be changed to modules_clean?

> > Is there perhaps a value to having the version in the package name
> instead of
> > using _git versions?  Will all SDKs be in step with using the same
> version?
> >
> [Sam] Chris or Rob, can you comment on this.  I am not sure of when the
> other verticals pick up CMEM.

I need to let Chris comment on this.

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko]

On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote:
> 
> 
> > -----Original Message-----
> > From: Maupin, Chase
> > Sent: Thursday, November 07, 2013 2:35 AM
> > To: Nelson, Sam; meta-arago@arago-project.org
> > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > 
> > >-----Original Message-----
> > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> > >bounces@arago-project.org] On Behalf Of Nelson, Sam
> > >Sent: Thursday, November 07, 2013 10:34 AM
> > >To: meta-arago@arago-project.org; Nelson, Sam
> > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > >
> > >- Cmem module is used for user space contiguous memory alloation
> > >
> > >Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> > >---
> > > recipes-bsp/cmem/cmem-mod_git.bb |   26
> > >++++++++++++++++++++++++++
> > > recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> > > recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> > > 3 files changed, 54 insertions(+)
> > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> > > create mode 100644 recipes-bsp/cmem/cmem.inc
> > > create mode 100644 recipes-bsp/cmem/cmem_git.bb
> > 
> > This patch should be submitted to meta-ti@yoctoproject.org which is the
> > meta-ti mailing list.
> [Sam] Ok. I will do that.
> > 
> > >
> > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
> > >bsp/cmem/cmem-mod_git.bb
> > >new file mode 100644
> > >index 0000000..c402b72
> > >--- /dev/null
> > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb
> > >@@ -0,0 +1,26 @@
> > >+DESCRIPTION="Contiguous memory allocation kernel module for
> > >contiguous memory allocation from userspace "
> > >+
> > >+include cmem.inc
> > >+
> > >+NAME="cmem"
> > 
> > Not sure what the NAME variable is for
> [Sam] I am not sure either. This is probably because of initial template 
> used for creation of the recipe. I can remove it if this really not needed.

This is not a variable used by bitbake, so assigning it and not using later is 
rather redundant.


> > >+# This package builds a kernel module, use kernel PR as base and
> > >append a local
> > >+PR = "${MACHINE_KERNEL_PR}"
> > >+PR_append = "a"
> > >+
> > >+PKG_${PN} = "kernel-module-${PN}"
> > 
> > I think what you are trying to do here is already handled by the
> > package.bbclass.  I assume you are trying to set the package name to kernel-
> > module-cmem-mod?
> > 
> > This raises the question of whether you want this to be cmem-mod for the
> > recipe and PN or if you want cmem for the module and cmem-xyz for the
> > libraries.
> > 
> [Sam] I guess the alternative you are suggesting is cmem for the module and 
> cmem-lib for the libraries. I am not seeing a compelling reason to change.

You can keep cmem-mod as the name of the recipe. And even if you keep it 
as the name of the package (i.e. not set PKG_${PN} above), it will still work 
just fine.

So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module-${PN}" 
then the resulting package will be called kernel-module-cmem-mod.ipk

If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk, but 
there will be an empty package kernel-module-cmem-mod.ipk that automatically 
depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as 
long as you don't mess the FILES_${PN} variable...


> > >+S = "${WORKDIR}/git"
> > >+
> > >+inherit module
> > >+
> > >+do_compile () {
> > >+    cd ${S}
> > >+    make -f lu.mak module_clean
> > >+    make -f lu.mak module
> > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> > >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> > 
> > You should use the default do_compile in the module.bbclass I think.  You
> > should be able to pass this with MAKE_TARGETS variable.
> 
> [Sam] Probably Chris and Rob on the CC list can comment on this. This will 
> need change of the module.

Well, it is rather "nice to have" - I won't require this as a mandatory 
change. After all, components may come from different environments and it's 
unrealistic to demand them to come with a comformant Makefile...

But, in case it would be possible and easy to change the Makefile, here's how 
default do_compile and do_install functions look like for a module:

module_do_compile() {
        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
        oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
                   KERNEL_SRC=${STAGING_KERNEL_DIR}    \
                   KERNEL_VERSION=${KERNEL_VERSION}    \
                   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
                   AR="${KERNEL_AR}" \
                   ${MAKE_TARGETS}
}

module_do_install() {
        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
        oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
                   KERNEL_SRC=${STAGING_KERNEL_DIR} \
                   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
                   modules_install
}

You are only supposed to set MAKE_TARGETS variable, which in your case would 
be "module_clean module"...


> > >+}
> > >+
> > >+do_install () {
> > >+    cd ${S}
> > >+    make -f lu.mak module_install
> > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> > >INSTALL_MOD_PATH="${D}"
> > 
> > Hmmm.  The default do_install for the module.bbclass uses
> > "modules_install" instead of "module_install".  If you can get the lu.mak file
> > updated that would be ideal.  If not then you should at least copy the base
> > function which unsets some variables.
> > 
> [Sam] Probably Chris and Rob on the CC list can comment on this. This will 
> need change of the module.

Again, if changing the component is not really possible at this time, just 
unset all those *FLAGS variables above.


> > >+}
> > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> > >new file mode 100644
> > >index 0000000..5d17d8e
> > >--- /dev/null
> > >+++ b/recipes-bsp/cmem/cmem.inc
> > >@@ -0,0 +1,12 @@
> > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > >+
> > >+LICENSE = "GPLv2"
> > >+LIC_FILES_CHKSUM =
> > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > >8310b3b983024edc620"
> > >+
> > >+COMPATIBLE_MACHINE = "keystone-evm"
> > 
> > As Sidd pointed out is there any reason not to add the other devices like
> > omap-a15 as compatible machines?
> 
> [Sam] I am fine with remove the compatible machine. Although this is not 
> tested with other machines.

So, Chris and Rob should comment on which platforms this version of cmem is 
supposed to be compatible with, even if it's not tested yet.


> > >+BRANCH ?= "master"
> > >+#SRCREV = "4.00.00.06"
> > 
> > Remove this comment but add one that the commit id below corresponds to
> > release 4.00.00.06.
> > 
> [Sam] I will fix this.
> > Is there perhaps a value to having the version in the package name instead of
> > using _git versions?  Will all SDKs be in step with using the same version?
> > 
> [Sam] Chris or Rob, can you comment on this.  I am not sure of when the 
> other verticals pick up CMEM.
> 
> > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
> > >+
> > >+SRC_URI =
> > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
> > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
> > >bsp/cmem/cmem_git.bb
> > >new file mode 100644
> > >index 0000000..f415630
> > >--- /dev/null
> > >+++ b/recipes-bsp/cmem/cmem_git.bb
> > >@@ -0,0 +1,16 @@
> > >+DESCRIPTION="The cmem component supports contiguous memory
> > >allocation from userspace "
> > >+
> > >+include cmem.inc
> > >+
> > >+RDEPENDS_${PN} = "cmem-mod"
> > >+
> > >+S = "${WORKDIR}/git"
> > >+
> > >+PR = "r0"
> > >+
> > >+PACKAGES =+ "${PN}-test"
> > >+
> > >+FILES_${PN}-test = "${bindir}/*"
> > 
> > As Denys pointed out last time, if everything goes into cmem-test then why
> > not just call this whole recipe cmem-test since the base cmem package is
> > empty.
> 
> [Sam] The cmem package has the library that goes into cmem-dev. And hence 
> the name cmem. cmem-test will have the example/unit test code binaries.  
> Only thing is there is no binary files associated with the cmem package 
> itself.

Right, we discussed some of this before and yesterday as well. It is not 
obvious, but a correct use case nevertheless. So, let's keep the name.

But, now I have one question - you do mention a library that goes to cmem-dev. 
Is is a dynamic library? If so, it should rather go into the main package. I 
suspect it lacks the correect extension and hence ends up in the -dev package.


> > >+inherit autotools
> > >+
> > >--
> > >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

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Tivy, Robert]

Please see one response below...

Regards,

- Rob

> -----Original Message-----
> From: Dmytriyenko, Denys
> Sent: Thursday, November 07, 2013 5:53 PM
> To: Nelson, Sam
> Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy,
> Robert
> Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> 
> 
> > > >+}
> > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> > > >new file mode 100644
> > > >index 0000000..5d17d8e
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem.inc
> > > >@@ -0,0 +1,12 @@
> > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > > >+
> > > >+LICENSE = "GPLv2"
> > > >+LIC_FILES_CHKSUM =
> > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > > >8310b3b983024edc620"
> > > >+
> > > >+COMPATIBLE_MACHINE = "keystone-evm"
> > >
> > > As Sidd pointed out is there any reason not to add the other
> devices like
> > > omap-a15 as compatible machines?
> >
> > [Sam] I am fine with remove the compatible machine. Although this is
> not
> > tested with other machines.
> 
> So, Chris and Rob should comment on which platforms this version of
> cmem is
> supposed to be compatible with, even if it's not tested yet.
> 

CMEM is completely architecture-independent.  The only HW it touches is memory, and the memory it touches is specified by the user/system integrator.

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko]

On Fri, Nov 08, 2013 at 12:33:00AM +0000, Tivy, Robert wrote:
> Please see my comments inline below...

Thanks, Rob!
inline...

> > -----Original Message-----
> > From: Nelson, Sam
> > Sent: Thursday, November 07, 2013 3:50 AM
> > To: Maupin, Chase; meta-arago@arago-project.org
> > Cc: Ring, Chris; Tivy, Robert
> > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > 
> 
> ...
> 
> > 
> > > >+
> > > >+S = "${WORKDIR}/git"
> > > >+
> > > >+inherit module
> > > >+
> > > >+do_compile () {
> > > >+    cd ${S}
> > > >+    make -f lu.mak module_clean
> > > >+    make -f lu.mak module
> > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> > >
> > > You should use the default do_compile in the module.bbclass I think.
> > You
> > > should be able to pass this with MAKE_TARGETS variable.
> > [Sam] Probably Chris and Rob on the CC list can comment on this. This
> > will need change of the module.
> 
> Can you please explain the change needed? I'm not familiar with do_compile().

Please see my other reply in this thread - I have both do_compile() and 
do_install() shown there. But the change would be more than just the make 
targets - there are slightly different variables used by default...

Anyway, I won't be insisting on this change, unless it is trivial for you to 
change.


> > > >+}
> > > >+
> > > >+do_install () {
> > > >+    cd ${S}
> > > >+    make -f lu.mak module_install
> > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> > > >INSTALL_MOD_PATH="${D}"
> > >
> > > Hmmm.  The default do_install for the module.bbclass uses
> > > "modules_install" instead of "module_install".  If you can get the
> > lu.mak file
> > > updated that would be ideal.  If not then you should at least copy
> > the base
> > > function which unsets some variables.
> > >
> > [Sam] Probably Chris and Rob on the CC list can comment on this. This
> > will need change of the module.
> 
> This should be fine, I will make a change to lu.mak and commit to ludev.git.
> 
> How about module_clean?  Should that be changed to modules_clean?

Well, modules_install comes from the kernel, as one of the standard make 
targets. There is no module(s)_clean there though, so it's up to you:

$ make help
Cleaning targets:
  clean           - Remove most generated files but keep the config and
                    enough build support to build external modules
  mrproper        - Remove all generated files + config + various backup files
  distclean       - mrproper + remove editor backup and patch files

Configuration targets:
  config          - Update current config utilising a line-oriented program
  nconfig         - Update current config utilising a ncurses menu based program
  menuconfig      - Update current config utilising a menu based program
  xconfig         - Update current config utilising a QT based front-end
  gconfig         - Update current config utilising a GTK based front-end
  oldconfig       - Update current config utilising a provided .config as base
  localmodconfig  - Update current config disabling modules not loaded
  localyesconfig  - Update current config converting local mods to core
  silentoldconfig - Same as oldconfig, but quietly, additionally update deps
  defconfig       - New config with default from ARCH supplied defconfig
  savedefconfig   - Save current config as ./defconfig (minimal config)
  allnoconfig     - New config where all options are answered with no
  allyesconfig    - New config where all options are accepted with yes
  allmodconfig    - New config selecting modules when possible
  alldefconfig    - New config with all symbols set to default
  randconfig      - New config with random answer to all options
  listnewconfig   - List new options
  olddefconfig    - Same as silentoldconfig but sets new symbols to their default value

Other generic targets:
  all             - Build all targets marked with [*]
* vmlinux         - Build the bare kernel
* modules         - Build all modules
  modules_install - Install all modules to INSTALL_MOD_PATH (default: /)
  firmware_install- Install all firmware to INSTALL_FW_PATH
                    (default: $(INSTALL_MOD_PATH)/lib/firmware)
  dir/            - Build all files in dir and below
  dir/file.[oisS] - Build specified target only
  dir/file.lst    - Build specified mixed source/assembly target only
                    (requires a recent binutils and recent build (System.map))
  dir/file.ko     - Build module including final link
  modules_prepare - Set up for building external modules
  tags/TAGS       - Generate tags file for editors
  cscope          - Generate cscope index
  gtags           - Generate GNU GLOBAL index
  kernelrelease   - Output the release version string
  kernelversion   - Output the version stored in Makefile
  image_name      - Output the image name
  headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH
                    (default: /usr/src/linux-3.11.4/usr)

Static analysers
  checkstack      - Generate a list of stack hogs
  namespacecheck  - Name space analysis on compiled kernel
  versioncheck    - Sanity check on version.h usage
  includecheck    - Check for duplicate included header files
  export_report   - List the usages of all exported symbols
  headers_check   - Sanity check on exported headers
  headerdep       - Detect inclusion cycles in headers
  coccicheck      - Check with Coccinelle.

Kernel packaging:
  rpm-pkg             - Build both source and binary RPM kernel packages
  binrpm-pkg          - Build only the binary kernel package
  deb-pkg             - Build the kernel as a deb package
  tar-pkg             - Build the kernel as an uncompressed tarball
  targz-pkg           - Build the kernel as a gzip compressed tarball
  tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball
  tarxz-pkg           - Build the kernel as a xz compressed tarball
  perf-tar-src-pkg    - Build perf-3.11.4.tar source tarball
  perf-targz-src-pkg  - Build perf-3.11.4.tar.gz source tarball
  perf-tarbz2-src-pkg - Build perf-3.11.4.tar.bz2 source tarball
  perf-tarxz-src-pkg  - Build perf-3.11.4.tar.xz source tarball

Documentation targets:
 Linux kernel internal documentation in different formats:
  htmldocs        - HTML
  pdfdocs         - PDF
  psdocs          - Postscript
  xmldocs         - XML DocBook
  mandocs         - man pages
  installmandocs  - install man pages generated by mandocs
  cleandocs       - clean all generated DocBook files

Architecture specific targets (x86):
* bzImage      - Compressed kernel image (arch/x86/boot/bzImage)
  install      - Install kernel using
                  (your) ~/bin/installkernel or
                  (distribution) /sbin/installkernel or
                  install to $(INSTALL_PATH) and run lilo
  fdimage      - Create 1.4MB boot floppy image (arch/x86/boot/fdimage)
  fdimage144   - Create 1.4MB boot floppy image (arch/x86/boot/fdimage)
  fdimage288   - Create 2.8MB boot floppy image (arch/x86/boot/fdimage)
  isoimage     - Create a boot CD-ROM image (arch/x86/boot/image.iso)
                  bzdisk/fdimage*/isoimage also accept:
                  FDARGS="..."  arguments for the booted kernel
                  FDINITRD=file initrd for the booted kernel
  kvmconfig     - Enable additional options for guest kernel support

  x86_64_defconfig         - Build for x86_64
  i386_defconfig           - Build for i386

  make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build
  make V=2   [targets] 2 => give reason for rebuild of target
  make O=dir [targets] Locate all output files in "dir", including .config
  make C=1   [targets] Check all c source with $CHECK (sparse by default)
  make C=2   [targets] Force check of all c source with $CHECK
  make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections
  make W=n   [targets] Enable extra gcc checks, n=1,2,3 where
                1: warnings which may be relevant and do not occur too often
                2: warnings which occur quite often but may still be relevant
                3: more obscure warnings, can most likely be ignored
                Multiple levels can be combined with W=12 or W=123

Execute "make" or "make all" to build all targets marked with [*] 
For further info see the ./README file


> > > Is there perhaps a value to having the version in the package name
> > instead of
> > > using _git versions?  Will all SDKs be in step with using the same
> > version?
> > >
> > [Sam] Chris or Rob, can you comment on this.  I am not sure of when the
> > other verticals pick up CMEM.
> 
> I need to let Chris comment on this.
> 
> 
> _______________________________________________
> meta-arago mailing list
> meta-arago@arago-project.org
> http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko]

On Thu, Nov 07, 2013 at 09:00:08PM -0500, Tivy, Robert wrote:
> Please see one response below...
> 
> Regards,
> 
> - Rob
> 
> > -----Original Message-----
> > From: Dmytriyenko, Denys
> > Sent: Thursday, November 07, 2013 5:53 PM
> > To: Nelson, Sam
> > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy,
> > Robert
> > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > 
> > 
> > > > >+}
> > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> > > > >new file mode 100644
> > > > >index 0000000..5d17d8e
> > > > >--- /dev/null
> > > > >+++ b/recipes-bsp/cmem/cmem.inc
> > > > >@@ -0,0 +1,12 @@
> > > > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > > > >+
> > > > >+LICENSE = "GPLv2"
> > > > >+LIC_FILES_CHKSUM =
> > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > > > >8310b3b983024edc620"
> > > > >+
> > > > >+COMPATIBLE_MACHINE = "keystone-evm"
> > > >
> > > > As Sidd pointed out is there any reason not to add the other
> > devices like
> > > > omap-a15 as compatible machines?
> > >
> > > [Sam] I am fine with remove the compatible machine. Although this is
> > not
> > > tested with other machines.
> > 
> > So, Chris and Rob should comment on which platforms this version of
> > cmem is
> > supposed to be compatible with, even if it's not tested yet.
> > 
> 
> CMEM is completely architecture-independent.  The only HW it touches is 
> memory, and the memory it touches is specified by the user/system 
> integrator.

Thanks. Then it doesn't make sense to artificially limit it to Keystone only.

-- 
Denys

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Nelson, Sam]

> -----Original Message-----
> From: Dmytriyenko, Denys
> Sent: Thursday, November 07, 2013 9:04 PM
> To: Tivy, Robert
> Cc: Nelson, Sam; Maupin, Chase; meta-arago@arago-project.org; Ring, Chris
> Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> 
> On Thu, Nov 07, 2013 at 09:00:08PM -0500, Tivy, Robert wrote:
> > Please see one response below...
> >
> > Regards,
> >
> > - Rob
> >
> > > -----Original Message-----
> > > From: Dmytriyenko, Denys
> > > Sent: Thursday, November 07, 2013 5:53 PM
> > > To: Nelson, Sam
> > > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy,
> > > Robert
> > > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > >
> > >
> > > > > >+}
> > > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-
> bsp/cmem/cmem.inc
> > > > > >new file mode 100644
> > > > > >index 0000000..5d17d8e
> > > > > >--- /dev/null
> > > > > >+++ b/recipes-bsp/cmem/cmem.inc
> > > > > >@@ -0,0 +1,12 @@
> > > > >
> >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > > > > >+
> > > > > >+LICENSE = "GPLv2"
> > > > > >+LIC_FILES_CHKSUM =
> > > > >
> >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > > > > >8310b3b983024edc620"
> > > > > >+
> > > > > >+COMPATIBLE_MACHINE = "keystone-evm"
> > > > >
> > > > > As Sidd pointed out is there any reason not to add the other
> > > devices like
> > > > > omap-a15 as compatible machines?
> > > >
> > > > [Sam] I am fine with remove the compatible machine. Although this is
> > > not
> > > > tested with other machines.
> > >
> > > So, Chris and Rob should comment on which platforms this version of
> > > cmem is
> > > supposed to be compatible with, even if it's not tested yet.
> > >
> >
> > CMEM is completely architecture-independent.  The only HW it touches is
> > memory, and the memory it touches is specified by the user/system
> > integrator.
> 
> Thanks. Then it doesn't make sense to artificially limit it to Keystone only.
[Sam] Agreed. I will remove COMPATIBLE_MACHINE = "keystone-evm"
> 
> --
> Denys

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Nelson, Sam]

> -----Original Message-----
> From: Dmytriyenko, Denys
> Sent: Thursday, November 07, 2013 8:53 PM
> To: Nelson, Sam
> Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, Robert
> Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> 
> On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote:
> >
> >
> > > -----Original Message-----
> > > From: Maupin, Chase
> > > Sent: Thursday, November 07, 2013 2:35 AM
> > > To: Nelson, Sam; meta-arago@arago-project.org
> > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > >
> > > >-----Original Message-----
> > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> > > >bounces@arago-project.org] On Behalf Of Nelson, Sam
> > > >Sent: Thursday, November 07, 2013 10:34 AM
> > > >To: meta-arago@arago-project.org; Nelson, Sam
> > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > > >
> > > >- Cmem module is used for user space contiguous memory alloation
> > > >
> > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> > > >---
> > > > recipes-bsp/cmem/cmem-mod_git.bb |   26
> > > >++++++++++++++++++++++++++
> > > > recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> > > > recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> > > > 3 files changed, 54 insertions(+)
> > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> > > > create mode 100644 recipes-bsp/cmem/cmem.inc
> > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb
> > >
> > > This patch should be submitted to meta-ti@yoctoproject.org which is the
> > > meta-ti mailing list.
> > [Sam] Ok. I will do that.
> > >
> > > >
> > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
> > > >bsp/cmem/cmem-mod_git.bb
> > > >new file mode 100644
> > > >index 0000000..c402b72
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb
> > > >@@ -0,0 +1,26 @@
> > > >+DESCRIPTION="Contiguous memory allocation kernel module for
> > > >contiguous memory allocation from userspace "
> > > >+
> > > >+include cmem.inc
> > > >+
> > > >+NAME="cmem"
> > >
> > > Not sure what the NAME variable is for
> > [Sam] I am not sure either. This is probably because of initial template
> > used for creation of the recipe. I can remove it if this really not needed.
> 
> This is not a variable used by bitbake, so assigning it and not using later is
> rather redundant.
> 
> 
> > > >+# This package builds a kernel module, use kernel PR as base and
> > > >append a local
> > > >+PR = "${MACHINE_KERNEL_PR}"
> > > >+PR_append = "a"
> > > >+
> > > >+PKG_${PN} = "kernel-module-${PN}"
> > >
> > > I think what you are trying to do here is already handled by the
> > > package.bbclass.  I assume you are trying to set the package name to
> kernel-
> > > module-cmem-mod?
> > >
> > > This raises the question of whether you want this to be cmem-mod for
> the
> > > recipe and PN or if you want cmem for the module and cmem-xyz for the
> > > libraries.
> > >
> > [Sam] I guess the alternative you are suggesting is cmem for the module
> and
> > cmem-lib for the libraries. I am not seeing a compelling reason to change.
> 
> You can keep cmem-mod as the name of the recipe. And even if you keep it
> as the name of the package (i.e. not set PKG_${PN} above), it will still work
> just fine.
> 
> So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module-
> ${PN}"
> then the resulting package will be called kernel-module-cmem-mod.ipk
> 
> If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk,
> but
> there will be an empty package kernel-module-cmem-mod.ipk that
> automatically
> depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as
> long as you don't mess the FILES_${PN} variable...
> 
[Sam] I will remove the line PKG_${PN} = "kernel-module-${PN}"
> 
> > > >+S = "${WORKDIR}/git"
> > > >+
> > > >+inherit module
> > > >+
> > > >+do_compile () {
> > > >+    cd ${S}
> > > >+    make -f lu.mak module_clean
> > > >+    make -f lu.mak module
> > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> > >
> > > You should use the default do_compile in the module.bbclass I think.
> You
> > > should be able to pass this with MAKE_TARGETS variable.
> >
> > [Sam] Probably Chris and Rob on the CC list can comment on this. This will
> > need change of the module.
> 
> Well, it is rather "nice to have" - I won't require this as a mandatory
> change. After all, components may come from different environments and
> it's
> unrealistic to demand them to come with a comformant Makefile...
> 
> But, in case it would be possible and easy to change the Makefile, here's how
> default do_compile and do_install functions look like for a module:
> 
> module_do_compile() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
>                    KERNEL_SRC=${STAGING_KERNEL_DIR}    \
>                    KERNEL_VERSION=${KERNEL_VERSION}    \
>                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>                    AR="${KERNEL_AR}" \
>                    ${MAKE_TARGETS}
> }
> 
> module_do_install() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
>                    KERNEL_SRC=${STAGING_KERNEL_DIR} \
>                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>                    modules_install
> }
> 
> You are only supposed to set MAKE_TARGETS variable, which in your case
> would
> be "module_clean module"...
> 
> 
> > > >+}
> > > >+
> > > >+do_install () {
> > > >+    cd ${S}
> > > >+    make -f lu.mak module_install
> > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> > > >INSTALL_MOD_PATH="${D}"
> > >
> > > Hmmm.  The default do_install for the module.bbclass uses
> > > "modules_install" instead of "module_install".  If you can get the lu.mak
> file
> > > updated that would be ideal.  If not then you should at least copy the
> base
> > > function which unsets some variables.
> > >
> > [Sam] Probably Chris and Rob on the CC list can comment on this. This will
> > need change of the module.
> 
> Again, if changing the component is not really possible at this time, just
> unset all those *FLAGS variables above.
> 
> 
> > > >+}
> > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> > > >new file mode 100644
> > > >index 0000000..5d17d8e
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem.inc
> > > >@@ -0,0 +1,12 @@
> > >
> >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > > >+
> > > >+LICENSE = "GPLv2"
> > > >+LIC_FILES_CHKSUM =
> > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > > >8310b3b983024edc620"
> > > >+
> > > >+COMPATIBLE_MACHINE = "keystone-evm"
> > >
> > > As Sidd pointed out is there any reason not to add the other devices like
> > > omap-a15 as compatible machines?
> >
> > [Sam] I am fine with remove the compatible machine. Although this is not
> > tested with other machines.
> 
> So, Chris and Rob should comment on which platforms this version of cmem
> is
> supposed to be compatible with, even if it's not tested yet.
> 
> 
> > > >+BRANCH ?= "master"
> > > >+#SRCREV = "4.00.00.06"
> > >
> > > Remove this comment but add one that the commit id below corresponds
> to
> > > release 4.00.00.06.
> > >
> > [Sam] I will fix this.
> > > Is there perhaps a value to having the version in the package name
> instead of
> > > using _git versions?  Will all SDKs be in step with using the same version?
> > >
> > [Sam] Chris or Rob, can you comment on this.  I am not sure of when the
> > other verticals pick up CMEM.
> >
> > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
> > > >+
> > > >+SRC_URI =
> > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
> > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
> > > >bsp/cmem/cmem_git.bb
> > > >new file mode 100644
> > > >index 0000000..f415630
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem_git.bb
> > > >@@ -0,0 +1,16 @@
> > > >+DESCRIPTION="The cmem component supports contiguous memory
> > > >allocation from userspace "
> > > >+
> > > >+include cmem.inc
> > > >+
> > > >+RDEPENDS_${PN} = "cmem-mod"
> > > >+
> > > >+S = "${WORKDIR}/git"
> > > >+
> > > >+PR = "r0"
> > > >+
> > > >+PACKAGES =+ "${PN}-test"
> > > >+
> > > >+FILES_${PN}-test = "${bindir}/*"
> > >
> > > As Denys pointed out last time, if everything goes into cmem-test then
> why
> > > not just call this whole recipe cmem-test since the base cmem package is
> > > empty.
> >
> > [Sam] The cmem package has the library that goes into cmem-dev. And
> hence
> > the name cmem. cmem-test will have the example/unit test code binaries.
> > Only thing is there is no binary files associated with the cmem package
> > itself.
> 
> Right, we discussed some of this before and yesterday as well. It is not
> obvious, but a correct use case nevertheless. So, let's keep the name.
> 
> But, now I have one question - you do mention a library that goes to cmem-
> dev.
> Is is a dynamic library? If so, it should rather go into the main package. I
> suspect it lacks the correect extension and hence ends up in the -dev
> package.
> 
[Sam] There is both static and dynamic library here. Actually the shared library will be part of cmem package. ( The static library will be part of cmem-dev)
> 
> > > >+inherit autotools
> > > >+
> > > >--
> > > >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

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Nelson, Sam]

> -----Original Message-----
> From: Dmytriyenko, Denys
> Sent: Thursday, November 07, 2013 8:53 PM
> To: Nelson, Sam
> Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, Robert
> Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> 
> On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote:
> >
> >
> > > -----Original Message-----
> > > From: Maupin, Chase
> > > Sent: Thursday, November 07, 2013 2:35 AM
> > > To: Nelson, Sam; meta-arago@arago-project.org
> > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > >
> > > >-----Original Message-----
> > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> > > >bounces@arago-project.org] On Behalf Of Nelson, Sam
> > > >Sent: Thursday, November 07, 2013 10:34 AM
> > > >To: meta-arago@arago-project.org; Nelson, Sam
> > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > > >
> > > >- Cmem module is used for user space contiguous memory alloation
> > > >
> > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> > > >---
> > > > recipes-bsp/cmem/cmem-mod_git.bb |   26
> > > >++++++++++++++++++++++++++
> > > > recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> > > > recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> > > > 3 files changed, 54 insertions(+)
> > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> > > > create mode 100644 recipes-bsp/cmem/cmem.inc
> > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb
> > >
> > > This patch should be submitted to meta-ti@yoctoproject.org which is the
> > > meta-ti mailing list.
> > [Sam] Ok. I will do that.
> > >
> > > >
> > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
> > > >bsp/cmem/cmem-mod_git.bb
> > > >new file mode 100644
> > > >index 0000000..c402b72
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb
> > > >@@ -0,0 +1,26 @@
> > > >+DESCRIPTION="Contiguous memory allocation kernel module for
> > > >contiguous memory allocation from userspace "
> > > >+
> > > >+include cmem.inc
> > > >+
> > > >+NAME="cmem"
> > >
> > > Not sure what the NAME variable is for
> > [Sam] I am not sure either. This is probably because of initial template
> > used for creation of the recipe. I can remove it if this really not needed.
> 
> This is not a variable used by bitbake, so assigning it and not using later is
> rather redundant.
> 
> 
> > > >+# This package builds a kernel module, use kernel PR as base and
> > > >append a local
> > > >+PR = "${MACHINE_KERNEL_PR}"
> > > >+PR_append = "a"
> > > >+
> > > >+PKG_${PN} = "kernel-module-${PN}"
> > >
> > > I think what you are trying to do here is already handled by the
> > > package.bbclass.  I assume you are trying to set the package name to
> kernel-
> > > module-cmem-mod?
> > >
> > > This raises the question of whether you want this to be cmem-mod for
> the
> > > recipe and PN or if you want cmem for the module and cmem-xyz for the
> > > libraries.
> > >
> > [Sam] I guess the alternative you are suggesting is cmem for the module
> and
> > cmem-lib for the libraries. I am not seeing a compelling reason to change.
> 
> You can keep cmem-mod as the name of the recipe. And even if you keep it
> as the name of the package (i.e. not set PKG_${PN} above), it will still work
> just fine.
> 
> So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module-
> ${PN}"
> then the resulting package will be called kernel-module-cmem-mod.ipk
> 
> If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk,
> but
> there will be an empty package kernel-module-cmem-mod.ipk that
> automatically
> depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as
> long as you don't mess the FILES_${PN} variable...
> 
> 
> > > >+S = "${WORKDIR}/git"
> > > >+
> > > >+inherit module
> > > >+
> > > >+do_compile () {
> > > >+    cd ${S}
> > > >+    make -f lu.mak module_clean
> > > >+    make -f lu.mak module
> > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> > >
> > > You should use the default do_compile in the module.bbclass I think.
> You
> > > should be able to pass this with MAKE_TARGETS variable.
> >
> > [Sam] Probably Chris and Rob on the CC list can comment on this. This will
> > need change of the module.
> 
> Well, it is rather "nice to have" - I won't require this as a mandatory
> change. After all, components may come from different environments and
> it's
> unrealistic to demand them to come with a comformant Makefile...
> 
> But, in case it would be possible and easy to change the Makefile, here's how
> default do_compile and do_install functions look like for a module:
> 
> module_do_compile() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
>                    KERNEL_SRC=${STAGING_KERNEL_DIR}    \
>                    KERNEL_VERSION=${KERNEL_VERSION}    \
>                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>                    AR="${KERNEL_AR}" \
>                    ${MAKE_TARGETS}
> }
> 
> module_do_install() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
>                    KERNEL_SRC=${STAGING_KERNEL_DIR} \
>                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>                    modules_install
> }
> 
> You are only supposed to set MAKE_TARGETS variable, which in your case
> would
> be "module_clean module"...
[Sam] we will add the unset FLAGS. Am I supposed to also rename do_install to module_do_install, do_compile --> module_do_install. And also will add module_do_clean? Please confirm.
Currently we have to still use non-standard makefile.
> 
> 
> > > >+}
> > > >+
> > > >+do_install () {
> > > >+    cd ${S}
> > > >+    make -f lu.mak module_install
> > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> > > >INSTALL_MOD_PATH="${D}"
> > >
> > > Hmmm.  The default do_install for the module.bbclass uses
> > > "modules_install" instead of "module_install".  If you can get the lu.mak
> file
> > > updated that would be ideal.  If not then you should at least copy the
> base
> > > function which unsets some variables.
> > >
> > [Sam] Probably Chris and Rob on the CC list can comment on this. This will
> > need change of the module.
> 
> Again, if changing the component is not really possible at this time, just
> unset all those *FLAGS variables above.
> 
> 
> > > >+}
> > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> > > >new file mode 100644
> > > >index 0000000..5d17d8e
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem.inc
> > > >@@ -0,0 +1,12 @@
> > >
> >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > > >+
> > > >+LICENSE = "GPLv2"
> > > >+LIC_FILES_CHKSUM =
> > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > > >8310b3b983024edc620"
> > > >+
> > > >+COMPATIBLE_MACHINE = "keystone-evm"
> > >
> > > As Sidd pointed out is there any reason not to add the other devices like
> > > omap-a15 as compatible machines?
> >
> > [Sam] I am fine with remove the compatible machine. Although this is not
> > tested with other machines.
> 
> So, Chris and Rob should comment on which platforms this version of cmem
> is
> supposed to be compatible with, even if it's not tested yet.
> 
> 
> > > >+BRANCH ?= "master"
> > > >+#SRCREV = "4.00.00.06"
> > >
> > > Remove this comment but add one that the commit id below corresponds
> to
> > > release 4.00.00.06.
> > >
> > [Sam] I will fix this.
> > > Is there perhaps a value to having the version in the package name
> instead of
> > > using _git versions?  Will all SDKs be in step with using the same version?
> > >
> > [Sam] Chris or Rob, can you comment on this.  I am not sure of when the
> > other verticals pick up CMEM.
> >
> > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
> > > >+
> > > >+SRC_URI =
> > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
> > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
> > > >bsp/cmem/cmem_git.bb
> > > >new file mode 100644
> > > >index 0000000..f415630
> > > >--- /dev/null
> > > >+++ b/recipes-bsp/cmem/cmem_git.bb
> > > >@@ -0,0 +1,16 @@
> > > >+DESCRIPTION="The cmem component supports contiguous memory
> > > >allocation from userspace "
> > > >+
> > > >+include cmem.inc
> > > >+
> > > >+RDEPENDS_${PN} = "cmem-mod"
> > > >+
> > > >+S = "${WORKDIR}/git"
> > > >+
> > > >+PR = "r0"
> > > >+
> > > >+PACKAGES =+ "${PN}-test"
> > > >+
> > > >+FILES_${PN}-test = "${bindir}/*"
> > >
> > > As Denys pointed out last time, if everything goes into cmem-test then
> why
> > > not just call this whole recipe cmem-test since the base cmem package is
> > > empty.
> >
> > [Sam] The cmem package has the library that goes into cmem-dev. And
> hence
> > the name cmem. cmem-test will have the example/unit test code binaries.
> > Only thing is there is no binary files associated with the cmem package
> > itself.
> 
> Right, we discussed some of this before and yesterday as well. It is not
> obvious, but a correct use case nevertheless. So, let's keep the name.
> 
> But, now I have one question - you do mention a library that goes to cmem-
> dev.
> Is is a dynamic library? If so, it should rather go into the main package. I
> suspect it lacks the correect extension and hence ends up in the -dev
> package.
> 
> 
> > > >+inherit autotools
> > > >+
> > > >--
> > > >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

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko]

On Tue, Nov 12, 2013 at 04:01:14PM -0500, Nelson, Sam wrote:
> 
> 
> > -----Original Message-----
> > From: Dmytriyenko, Denys
> > Sent: Thursday, November 07, 2013 8:53 PM
> > To: Nelson, Sam
> > Cc: Maupin, Chase; meta-arago@arago-project.org; Ring, Chris; Tivy, Robert
> > Subject: Re: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > 
> > On Thu, Nov 07, 2013 at 11:49:42AM +0000, Nelson, Sam wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Maupin, Chase
> > > > Sent: Thursday, November 07, 2013 2:35 AM
> > > > To: Nelson, Sam; meta-arago@arago-project.org
> > > > Subject: RE: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > > >
> > > > >-----Original Message-----
> > > > >From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> > > > >bounces@arago-project.org] On Behalf Of Nelson, Sam
> > > > >Sent: Thursday, November 07, 2013 10:34 AM
> > > > >To: meta-arago@arago-project.org; Nelson, Sam
> > > > >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> > > > >
> > > > >- Cmem module is used for user space contiguous memory alloation
> > > > >
> > > > >Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> > > > >---
> > > > > recipes-bsp/cmem/cmem-mod_git.bb |   26
> > > > >++++++++++++++++++++++++++
> > > > > recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> > > > > recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> > > > > 3 files changed, 54 insertions(+)
> > > > > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> > > > > create mode 100644 recipes-bsp/cmem/cmem.inc
> > > > > create mode 100644 recipes-bsp/cmem/cmem_git.bb
> > > >
> > > > This patch should be submitted to meta-ti@yoctoproject.org which is the
> > > > meta-ti mailing list.
> > > [Sam] Ok. I will do that.
> > > >
> > > > >
> > > > >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
> > > > >bsp/cmem/cmem-mod_git.bb
> > > > >new file mode 100644
> > > > >index 0000000..c402b72
> > > > >--- /dev/null
> > > > >+++ b/recipes-bsp/cmem/cmem-mod_git.bb
> > > > >@@ -0,0 +1,26 @@
> > > > >+DESCRIPTION="Contiguous memory allocation kernel module for
> > > > >contiguous memory allocation from userspace "
> > > > >+
> > > > >+include cmem.inc
> > > > >+
> > > > >+NAME="cmem"
> > > >
> > > > Not sure what the NAME variable is for
> > > [Sam] I am not sure either. This is probably because of initial template
> > > used for creation of the recipe. I can remove it if this really not needed.
> > 
> > This is not a variable used by bitbake, so assigning it and not using later is
> > rather redundant.
> > 
> > 
> > > > >+# This package builds a kernel module, use kernel PR as base and
> > > > >append a local
> > > > >+PR = "${MACHINE_KERNEL_PR}"
> > > > >+PR_append = "a"
> > > > >+
> > > > >+PKG_${PN} = "kernel-module-${PN}"
> > > >
> > > > I think what you are trying to do here is already handled by the
> > > > package.bbclass.  I assume you are trying to set the package name to
> > kernel-
> > > > module-cmem-mod?
> > > >
> > > > This raises the question of whether you want this to be cmem-mod for
> > the
> > > > recipe and PN or if you want cmem for the module and cmem-xyz for the
> > > > libraries.
> > > >
> > > [Sam] I guess the alternative you are suggesting is cmem for the module
> > and
> > > cmem-lib for the libraries. I am not seeing a compelling reason to change.
> > 
> > You can keep cmem-mod as the name of the recipe. And even if you keep it
> > as the name of the package (i.e. not set PKG_${PN} above), it will still work
> > just fine.
> > 
> > So, if your recipe is called cmem-mod, but PKG_${PN} = "kernel-module-
> > ${PN}"
> > then the resulting package will be called kernel-module-cmem-mod.ipk
> > 
> > If you don't set PKG_${PN}, then the package will be called cmem-mod.ipk,
> > but
> > there will be an empty package kernel-module-cmem-mod.ipk that
> > automatically
> > depend on cmem-mod.ipk :) At the end of the day, it will work just fine, as
> > long as you don't mess the FILES_${PN} variable...
> > 
> > 
> > > > >+S = "${WORKDIR}/git"
> > > > >+
> > > > >+inherit module
> > > > >+
> > > > >+do_compile () {
> > > > >+    cd ${S}
> > > > >+    make -f lu.mak module_clean
> > > > >+    make -f lu.mak module
> > > > >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> > > > >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> > > >
> > > > You should use the default do_compile in the module.bbclass I think.
> > You
> > > > should be able to pass this with MAKE_TARGETS variable.
> > >
> > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will
> > > need change of the module.
> > 
> > Well, it is rather "nice to have" - I won't require this as a mandatory
> > change. After all, components may come from different environments and
> > it's
> > unrealistic to demand them to come with a comformant Makefile...
> > 
> > But, in case it would be possible and easy to change the Makefile, here's how
> > default do_compile and do_install functions look like for a module:
> > 
> > module_do_compile() {
> >         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> >         oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
> >                    KERNEL_SRC=${STAGING_KERNEL_DIR}    \
> >                    KERNEL_VERSION=${KERNEL_VERSION}    \
> >                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> >                    AR="${KERNEL_AR}" \
> >                    ${MAKE_TARGETS}
> > }
> > 
> > module_do_install() {
> >         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> >         oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
> >                    KERNEL_SRC=${STAGING_KERNEL_DIR} \
> >                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> >                    modules_install
> > }
> > 
> > You are only supposed to set MAKE_TARGETS variable, which in your case
> > would
> > be "module_clean module"...

> [Sam] we will add the unset FLAGS. Am I supposed to also rename do_install 
> to module_do_install, do_compile --> module_do_install. And also will add 
> module_do_clean? Please confirm. Currently we have to still use non-standard 
> makefile.

No, providing own do_install and do_compile should be fine for now, if you 
can't change module's Makefile.


> > > > >+}
> > > > >+
> > > > >+do_install () {
> > > > >+    cd ${S}
> > > > >+    make -f lu.mak module_install
> > > > >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> > > > >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> > > > >INSTALL_MOD_PATH="${D}"
> > > >
> > > > Hmmm.  The default do_install for the module.bbclass uses
> > > > "modules_install" instead of "module_install".  If you can get the lu.mak
> > file
> > > > updated that would be ideal.  If not then you should at least copy the
> > base
> > > > function which unsets some variables.
> > > >
> > > [Sam] Probably Chris and Rob on the CC list can comment on this. This will
> > > need change of the module.
> > 
> > Again, if changing the component is not really possible at this time, just
> > unset all those *FLAGS variables above.
> > 
> > 
> > > > >+}
> > > > >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> > > > >new file mode 100644
> > > > >index 0000000..5d17d8e
> > > > >--- /dev/null
> > > > >+++ b/recipes-bsp/cmem/cmem.inc
> > > > >@@ -0,0 +1,12 @@
> > > >
> > >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> > > > >+
> > > > >+LICENSE = "GPLv2"
> > > > >+LIC_FILES_CHKSUM =
> > > > >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> > > > >8310b3b983024edc620"
> > > > >+
> > > > >+COMPATIBLE_MACHINE = "keystone-evm"
> > > >
> > > > As Sidd pointed out is there any reason not to add the other devices like
> > > > omap-a15 as compatible machines?
> > >
> > > [Sam] I am fine with remove the compatible machine. Although this is not
> > > tested with other machines.
> > 
> > So, Chris and Rob should comment on which platforms this version of cmem
> > is
> > supposed to be compatible with, even if it's not tested yet.
> > 
> > 
> > > > >+BRANCH ?= "master"
> > > > >+#SRCREV = "4.00.00.06"
> > > >
> > > > Remove this comment but add one that the commit id below corresponds
> > to
> > > > release 4.00.00.06.
> > > >
> > > [Sam] I will fix this.
> > > > Is there perhaps a value to having the version in the package name
> > instead of
> > > > using _git versions?  Will all SDKs be in step with using the same version?
> > > >
> > > [Sam] Chris or Rob, can you comment on this.  I am not sure of when the
> > > other verticals pick up CMEM.
> > >
> > > > >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
> > > > >+
> > > > >+SRC_URI =
> > > > >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
> > > > >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
> > > > >bsp/cmem/cmem_git.bb
> > > > >new file mode 100644
> > > > >index 0000000..f415630
> > > > >--- /dev/null
> > > > >+++ b/recipes-bsp/cmem/cmem_git.bb
> > > > >@@ -0,0 +1,16 @@
> > > > >+DESCRIPTION="The cmem component supports contiguous memory
> > > > >allocation from userspace "
> > > > >+
> > > > >+include cmem.inc
> > > > >+
> > > > >+RDEPENDS_${PN} = "cmem-mod"
> > > > >+
> > > > >+S = "${WORKDIR}/git"
> > > > >+
> > > > >+PR = "r0"
> > > > >+
> > > > >+PACKAGES =+ "${PN}-test"
> > > > >+
> > > > >+FILES_${PN}-test = "${bindir}/*"
> > > >
> > > > As Denys pointed out last time, if everything goes into cmem-test then
> > why
> > > > not just call this whole recipe cmem-test since the base cmem package is
> > > > empty.
> > >
> > > [Sam] The cmem package has the library that goes into cmem-dev. And
> > hence
> > > the name cmem. cmem-test will have the example/unit test code binaries.
> > > Only thing is there is no binary files associated with the cmem package
> > > itself.
> > 
> > Right, we discussed some of this before and yesterday as well. It is not
> > obvious, but a correct use case nevertheless. So, let's keep the name.
> > 
> > But, now I have one question - you do mention a library that goes to cmem-
> > dev.
> > Is is a dynamic library? If so, it should rather go into the main package. I
> > suspect it lacks the correect extension and hence ends up in the -dev
> > package.
> > 
> > 
> > > > >+inherit autotools
> > > > >+
> > > > >--
> > > > >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

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Maupin, Chase]

Sam,

Were you going to post an updated set of these patches to meta-ti so you can align with Mrinmayee? I think your approach of splitting out the packages in linux-utils is a good one and will be cleaner going forward.  Since both of your groups share these packages aligning between the two would be helpful.

As a side note I assume you have other recipes that depend on the cmem libraries that your cmem recipe provides.  Can you post one of those or share it with Mrinmayee as an example of how you are able to point to the right staging location for the libraries and headers for cmem in other recipes.  I'm hoping we can start getting rid of ti-paths.inc but I'd like to see how you were working around this.

Denys, 

Since ti-linuxutils has other modules in it for edma, sdma, and irq but those are only for legacy devices can we just replace the whole ti-linuxutils with the cmem package which seems to be the main package needed?  Or do you want to see additional recipes for the sdma, edma, and irq moduled?

>-----Original Message-----
>From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
>bounces@arago-project.org] On Behalf Of Nelson, Sam
>Sent: Wednesday, November 06, 2013 11:04 PM
>To: meta-arago@arago-project.org; Nelson, Sam
>Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
>
>- Cmem module is used for user space contiguous memory alloation
>
>Signed-off-by: Sam Nelson <sam.nelson@ti.com>
>---
> recipes-bsp/cmem/cmem-mod_git.bb |   26
>++++++++++++++++++++++++++
> recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> 3 files changed, 54 insertions(+)
> create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> create mode 100644 recipes-bsp/cmem/cmem.inc
> create mode 100644 recipes-bsp/cmem/cmem_git.bb
>
>diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
>bsp/cmem/cmem-mod_git.bb
>new file mode 100644
>index 0000000..c402b72
>--- /dev/null
>+++ b/recipes-bsp/cmem/cmem-mod_git.bb
>@@ -0,0 +1,26 @@
>+DESCRIPTION="Contiguous memory allocation kernel module for
>contiguous memory allocation from userspace "
>+
>+include cmem.inc
>+
>+NAME="cmem"
>+
>+# This package builds a kernel module, use kernel PR as base and
>append a local
>+PR = "${MACHINE_KERNEL_PR}"
>+PR_append = "a"
>+
>+PKG_${PN} = "kernel-module-${PN}"
>+
>+S = "${WORKDIR}/git"
>+
>+inherit module
>+
>+do_compile () {
>+    cd ${S}
>+    make -f lu.mak module_clean
>+    make -f lu.mak module
>KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
>TOOLCHAIN_PREFIX=${CROSS_COMPILE}
>+}
>+
>+do_install () {
>+    cd ${S}
>+    make -f lu.mak module_install
>KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
>EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
>INSTALL_MOD_PATH="${D}"
>+}
>diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
>new file mode 100644
>index 0000000..5d17d8e
>--- /dev/null
>+++ b/recipes-bsp/cmem/cmem.inc
>@@ -0,0 +1,12 @@
>+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
>+
>+LICENSE = "GPLv2"
>+LIC_FILES_CHKSUM =
>"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
>8310b3b983024edc620"
>+
>+COMPATIBLE_MACHINE = "keystone-evm"
>+
>+BRANCH ?= "master"
>+#SRCREV = "4.00.00.06"
>+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
>+
>+SRC_URI =
>"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
>diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
>bsp/cmem/cmem_git.bb
>new file mode 100644
>index 0000000..f415630
>--- /dev/null
>+++ b/recipes-bsp/cmem/cmem_git.bb
>@@ -0,0 +1,16 @@
>+DESCRIPTION="The cmem component supports contiguous memory
>allocation from userspace "
>+
>+include cmem.inc
>+
>+RDEPENDS_${PN} = "cmem-mod"
>+
>+S = "${WORKDIR}/git"
>+
>+PR = "r0"
>+
>+PACKAGES =+ "${PN}-test"
>+
>+FILES_${PN}-test = "${bindir}/*"
>+
>+inherit autotools
>+
>--
>1.7.9.5
>
>_______________________________________________
>meta-arago mailing list
>meta-arago@arago-project.org
>http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko]

On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote:
> Sam,
> 
> Were you going to post an updated set of these patches to meta-ti so you can 
> align with Mrinmayee? I think your approach of splitting out the packages in 
> linux-utils is a good one and will be cleaner going forward.  Since both of 
> your groups share these packages aligning between the two would be helpful.
> 
> As a side note I assume you have other recipes that depend on the cmem 
> libraries that your cmem recipe provides.  Can you post one of those or 
> share it with Mrinmayee as an example of how you are able to point to the 
> right staging location for the libraries and headers for cmem in other 
> recipes.  I'm hoping we can start getting rid of ti-paths.inc but I'd like 
> to see how you were working around this.
> 
> Denys,
> 
> Since ti-linuxutils has other modules in it for edma, sdma, and irq but 
> those are only for legacy devices can we just replace the whole 
> ti-linuxutils with the cmem package which seems to be the main package 
> needed?  Or do you want to see additional recipes for the sdma, edma, and 
> irq moduled?

I'd like to see other parts of linuxutils modularized, but that can be done on 
as needed basis for any of the new platforms when they require those. We can 
keep the old linuxutils around for a little longer, but it can only be used on 
the old 35x and 37x plaftorms only and there are many other components (like 
SGX) removing support for those old platforms already...

-- 
Denys


> >-----Original Message-----
> >From: meta-arago-bounces@arago-project.org [mailto:meta-arago-
> >bounces@arago-project.org] On Behalf Of Nelson, Sam
> >Sent: Wednesday, November 06, 2013 11:04 PM
> >To: meta-arago@arago-project.org; Nelson, Sam
> >Subject: [meta-arago] [PATCH v2] cmem: Adding New recipe for cmem
> >
> >- Cmem module is used for user space contiguous memory alloation
> >
> >Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> >---
> > recipes-bsp/cmem/cmem-mod_git.bb |   26
> >++++++++++++++++++++++++++
> > recipes-bsp/cmem/cmem.inc        |   12 ++++++++++++
> > recipes-bsp/cmem/cmem_git.bb     |   16 ++++++++++++++++
> > 3 files changed, 54 insertions(+)
> > create mode 100644 recipes-bsp/cmem/cmem-mod_git.bb
> > create mode 100644 recipes-bsp/cmem/cmem.inc
> > create mode 100644 recipes-bsp/cmem/cmem_git.bb
> >
> >diff --git a/recipes-bsp/cmem/cmem-mod_git.bb b/recipes-
> >bsp/cmem/cmem-mod_git.bb
> >new file mode 100644
> >index 0000000..c402b72
> >--- /dev/null
> >+++ b/recipes-bsp/cmem/cmem-mod_git.bb
> >@@ -0,0 +1,26 @@
> >+DESCRIPTION="Contiguous memory allocation kernel module for
> >contiguous memory allocation from userspace "
> >+
> >+include cmem.inc
> >+
> >+NAME="cmem"
> >+
> >+# This package builds a kernel module, use kernel PR as base and
> >append a local
> >+PR = "${MACHINE_KERNEL_PR}"
> >+PR_append = "a"
> >+
> >+PKG_${PN} = "kernel-module-${PN}"
> >+
> >+S = "${WORKDIR}/git"
> >+
> >+inherit module
> >+
> >+do_compile () {
> >+    cd ${S}
> >+    make -f lu.mak module_clean
> >+    make -f lu.mak module
> >KERNEL_INSTALL_DIR=${STAGING_KERNEL_DIR}
> >TOOLCHAIN_PREFIX=${CROSS_COMPILE}
> >+}
> >+
> >+do_install () {
> >+    cd ${S}
> >+    make -f lu.mak module_install
> >KERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}"
> >EXEC_DIR="${D}/lib/modules/${KERNEL_VERSION}/extra"
> >INSTALL_MOD_PATH="${D}"
> >+}
> >diff --git a/recipes-bsp/cmem/cmem.inc b/recipes-bsp/cmem/cmem.inc
> >new file mode 100644
> >index 0000000..5d17d8e
> >--- /dev/null
> >+++ b/recipes-bsp/cmem/cmem.inc
> >@@ -0,0 +1,12 @@
> >+HOMEPAGE="http://processors.wiki.ti.com/index.php/Category:CMEM"
> >+
> >+LICENSE = "GPLv2"
> >+LIC_FILES_CHKSUM =
> >"file://include/ti/cmem.h;beginline=1;endline=30;md5=b86138d4028fb
> >8310b3b983024edc620"
> >+
> >+COMPATIBLE_MACHINE = "keystone-evm"
> >+
> >+BRANCH ?= "master"
> >+#SRCREV = "4.00.00.06"
> >+SRCREV = "c2cf2406702bcb889c10d0e6e7d298ba7b84ae7d"
> >+
> >+SRC_URI =
> >"git://git.ti.com/ipc/ludev.git;protocol=git;branch=${BRANCH}"
> >diff --git a/recipes-bsp/cmem/cmem_git.bb b/recipes-
> >bsp/cmem/cmem_git.bb
> >new file mode 100644
> >index 0000000..f415630
> >--- /dev/null
> >+++ b/recipes-bsp/cmem/cmem_git.bb
> >@@ -0,0 +1,16 @@
> >+DESCRIPTION="The cmem component supports contiguous memory
> >allocation from userspace "
> >+
> >+include cmem.inc
> >+
> >+RDEPENDS_${PN} = "cmem-mod"
> >+
> >+S = "${WORKDIR}/git"
> >+
> >+PR = "r0"
> >+
> >+PACKAGES =+ "${PN}-test"
> >+
> >+FILES_${PN}-test = "${bindir}/*"
> >+
> >+inherit autotools
> >+
> >--
> >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

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Enrico]

On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote:
>> Sam,
>>
>> Were you going to post an updated set of these patches to meta-ti so you can
>> align with Mrinmayee? I think your approach of splitting out the packages in
>> linux-utils is a good one and will be cleaner going forward.  Since both of
>> your groups share these packages aligning between the two would be helpful.
>>
>> As a side note I assume you have other recipes that depend on the cmem
>> libraries that your cmem recipe provides.  Can you post one of those or
>> share it with Mrinmayee as an example of how you are able to point to the
>> right staging location for the libraries and headers for cmem in other
>> recipes.  I'm hoping we can start getting rid of ti-paths.inc but I'd like
>> to see how you were working around this.
>>
>> Denys,
>>
>> Since ti-linuxutils has other modules in it for edma, sdma, and irq but
>> those are only for legacy devices can we just replace the whole
>> ti-linuxutils with the cmem package which seems to be the main package
>> needed?  Or do you want to see additional recipes for the sdma, edma, and
>> irq moduled?
>
> I'd like to see other parts of linuxutils modularized, but that can be done on
> as needed basis for any of the new platforms when they require those. We can
> keep the old linuxutils around for a little longer, but it can only be used on
> the old 35x and 37x plaftorms only and there are many other components (like
> SGX) removing support for those old platforms already...

Please keep the linuxutils recipe until it can be replaced with the
modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti).

Enrico

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko]

On Tue, Nov 26, 2013 at 01:56:56PM +0100, Enrico wrote:
> On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> > On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote:
> >> Sam,
> >>
> >> Were you going to post an updated set of these patches to meta-ti so you can
> >> align with Mrinmayee? I think your approach of splitting out the packages in
> >> linux-utils is a good one and will be cleaner going forward.  Since both of
> >> your groups share these packages aligning between the two would be helpful.
> >>
> >> As a side note I assume you have other recipes that depend on the cmem
> >> libraries that your cmem recipe provides.  Can you post one of those or
> >> share it with Mrinmayee as an example of how you are able to point to the
> >> right staging location for the libraries and headers for cmem in other
> >> recipes.  I'm hoping we can start getting rid of ti-paths.inc but I'd like
> >> to see how you were working around this.
> >>
> >> Denys,
> >>
> >> Since ti-linuxutils has other modules in it for edma, sdma, and irq but
> >> those are only for legacy devices can we just replace the whole
> >> ti-linuxutils with the cmem package which seems to be the main package
> >> needed?  Or do you want to see additional recipes for the sdma, edma, and
> >> irq moduled?
> >
> > I'd like to see other parts of linuxutils modularized, but that can be done on
> > as needed basis for any of the new platforms when they require those. We can
> > keep the old linuxutils around for a little longer, but it can only be used on
> > the old 35x and 37x plaftorms only and there are many other components (like
> > SGX) removing support for those old platforms already...
> 
> Please keep the linuxutils recipe until it can be replaced with the
> modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti).

Enrico,

Thanks, I'll keep it around for now.

Can you please clarify which kernel you use for 35x and 37x platforms? And 
whether you use the latest versions of other components?

The problem with keeping old components around is that they quickly lose 
compatibility with kernel, toolchain, udev etc. that we use these days and it 
doesn't make much sense to carry them indefinitely w/o updating or replacing.

-- 
Denys

Re: [PATCH v2] cmem: Adding New recipe for cmem

[Enrico]

On Wed, Nov 27, 2013 at 5:55 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> On Tue, Nov 26, 2013 at 01:56:56PM +0100, Enrico wrote:
>> On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote:
>> > I'd like to see other parts of linuxutils modularized, but that can be done on
>> > as needed basis for any of the new platforms when they require those. We can
>> > keep the old linuxutils around for a little longer, but it can only be used on
>> > the old 35x and 37x plaftorms only and there are many other components (like
>> > SGX) removing support for those old platforms already...
>>
>> Please keep the linuxutils recipe until it can be replaced with the
>> modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti).
>
> Enrico,
>
> Thanks, I'll keep it around for now.
>
> Can you please clarify which kernel you use for 35x and 37x platforms? And
> whether you use the latest versions of other components?

In production i'm using mainline kernel 3.2 with some custom patches
(not related to dsp components, see my github at [1]), with unmodified
components from meta-ti (i'm not using meta-arago).

I'm testing now with kernel 3.12, unmodified components from meta-ti,
gcc 4.8.something (angstrom 2013.12), the components need some
patching but it was really easy to fix them. I don't remember right
now what were the components i needed to fix but i'm sure about cmem
and dsplink.

Right now the most important feature i'm missing is devicetree
bindings for omap3isp.

> The problem with keeping old components around is that they quickly lose
> compatibility with kernel, toolchain, udev etc. that we use these days and it
> doesn't make much sense to carry them indefinitely w/o updating or replacing.

I think there are still many users of the omap dsp stuff. I understand
that TI doesn't want to put resources on "old" platforms (even if they
are still in production and not declared obsolete) but do you think it
could be possible to have some help when those kind of problems
happen?
For example if i have a problem with dsplink and i'm not able to fix
it, asking for help in meta-ti will be useful? (i'm speaking about
someone in a TI dev team that already knows the code).

Enrico

[1]: https://github.com/ebutera/meta-igep/blob/master/recipes-kernel/linux/linux_3.2.bb