[PATCH v3 1/7] fsl-tlu: add recipe

[PATCH v3 1/7] fsl-tlu: add recipe

[Zhenhua Luo]

The fsl-tlu package includes the TLU(Table Lookup Unit) test scripts and
and configuration files.

Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
 recipes-bsp/fsl-tlu/fsl-tlu_1.0.0.bb | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 recipes-bsp/fsl-tlu/fsl-tlu_1.0.0.bb

diff --git a/recipes-bsp/fsl-tlu/fsl-tlu_1.0.0.bb b/recipes-bsp/fsl-tlu/fsl-tlu_1.0.0.bb
new file mode 100644
index 0000000..213e74a
--- /dev/null
+++ b/recipes-bsp/fsl-tlu/fsl-tlu_1.0.0.bb
@@ -0,0 +1,18 @@
+SUMMARY = "Freescale TLU(Table Lookup Unit) test package"
+DESCRIPTION = "This package includes the TLU(Table Lookup Unit) test scripts \
+and configuration files."
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=8a71d0475d08eee76d8b6d0c6dbec543"
+
+SRC_URI = "git://git.freescale.com/ppc/sdk/fsl-tlu.git;branch=master"
+SRCREV = "8837cce3c86b30c0931c319e9e1a8ca622ae5354"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+    install -d ${D}${sbindir}/fsl_tlu
+    find . -type f -exec cp {} ${D}${sbindir}/fsl_tlu/ \;
+}
+
+COMPATIBLE_MACHINE = "(e500mc)"
-- 
2.4.3

[PATCH v3 2/7] kernel-module-perf-qoriq: Add recipe

[Zhenhua Luo]

The kernel-module-perf-qoriq package is QorIQ extension to perf for
supporting non core counters.

Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
 .../kernel-module-perf-qoriq_0.8.2.bb                  | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 recipes-kernel/kernel-module-perf-qoriq/kernel-module-perf-qoriq_0.8.2.bb

diff --git a/recipes-kernel/kernel-module-perf-qoriq/kernel-module-perf-qoriq_0.8.2.bb b/recipes-kernel/kernel-module-perf-qoriq/kernel-module-perf-qoriq_0.8.2.bb
new file mode 100644
index 0000000..1536708
--- /dev/null
+++ b/recipes-kernel/kernel-module-perf-qoriq/kernel-module-perf-qoriq_0.8.2.bb
@@ -0,0 +1,18 @@
+DESCRIPTION = "QorIQ extension to Perf for supporting non core counters"
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=e29234dd5d40dc352cc60cc0c93437ba"
+
+SRC_URI = "git://git.freescale.com/ppc/sdk/qoriq-perf.git;branch=master"
+SRCREV = "7beb3783edac66bab00c85d99a7b073f569af7fd"
+
+S = "${WORKDIR}/git"
+
+inherit module autotools-brokensep qoriq_build_64bit_kernel
+
+PROCESSOR_REV ?= "B4860_R1"
+EXTRA_OECONF += "--with-linux=${STAGING_KERNEL_DIR} \
+    --with-processor=${PROCESSOR_REV}"
+
+EXTRA_OEMAKE += 'SYSROOT="${D}"'
+
+COMPATIBLE_MACHINE = "(b4860qds)"
-- 
2.4.3

[PATCH v3 3/7] qoriq-base.inc: disable virtual terminal support for QorIQ

[Zhenhua Luo]

Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
 conf/machine/include/qoriq-base.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/machine/include/qoriq-base.inc b/conf/machine/include/qoriq-base.inc
index 5744db6..d1fda5e 100644
--- a/conf/machine/include/qoriq-base.inc
+++ b/conf/machine/include/qoriq-base.inc
@@ -20,4 +20,6 @@ MACHINE_EXTRA_RRECOMMENDS ?= "udev-rules-qoriq"
 
 EXTRA_IMAGEDEPENDS += "u-boot cst-native"
 
+USE_VT ?= "0"
+
 MACHINEOVERRIDES .= ":qoriq"
-- 
2.4.3

[PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Zhenhua Luo]

* Add bbappend for qoriq(except e500v2) to create a symbolic link as the
  user expects to see a /usr/bin/valgrind on 64-bit MACHINE's, ensure that
  the link created, points to the *64-bit* valgrind. Assume that the presence
  of the patterns: "\-64b" in ${MACHINE} and "64" in ${TARGET_ARCH}, indicate
  the 64-bit flavour and that their absence indicates 32-bit flavour respectively.
  Now, when both 32-bit and 64-bit flavours are available to choose from; it
  does happen that even though ${MACHINE} is chosen to indicate the choice of
  the 32-bit case, the 64-bit tools are built too. So, ensure that on 32-bit,
  the link points to the 32-bit valgrind, and of-course, that on 64-bit, the
  link points to the 64-bit valgrind.
* Override the 32-bit implementations of memcpy(), memset() from glibc.
  On 64-bit platforms, for 32-bit mode, the Freescale optimized implementations
  of the glibc functions memcpy(), memset() use POWER ISA Category:64-bit
  instructions. By design, these are not implementatble in Valgrind in 32-bit
  mode. Therefore, we override the library versions with plain classic POWER
  32-bit alternate versions (emitted at -O0 by GCC).
* Add COMPATIBLE_MACHINE

Signed-off-by: Ting Liu <b28495@freescale.com>
Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
 .../override-32-bit-glibc-memcpy-memset.patch      | 159 +++++++++++++++++++++
 recipes-devtools/valgrind/valgrind_3.10.1.bbappend |  28 ++++
 2 files changed, 187 insertions(+)
 create mode 100644 recipes-devtools/valgrind/valgrind/override-32-bit-glibc-memcpy-memset.patch
 create mode 100644 recipes-devtools/valgrind/valgrind_3.10.1.bbappend

diff --git a/recipes-devtools/valgrind/valgrind/override-32-bit-glibc-memcpy-memset.patch b/recipes-devtools/valgrind/valgrind/override-32-bit-glibc-memcpy-memset.patch
new file mode 100644
index 0000000..56da7d2
--- /dev/null
+++ b/recipes-devtools/valgrind/valgrind/override-32-bit-glibc-memcpy-memset.patch
@@ -0,0 +1,159 @@
+Upstream-Status: Pending
+
+ Override the 32-bit implementations of memcpy(), memset() from glibc.
+
+ On 64-bit platforms, for 32-bit mode, the Freescale optimized implementations
+ of the glibc functions memcpy(), memset() use POWER ISA Category:64-bit
+ instructions. By design, these are not implementatble in Valgrind in 32-bit
+ mode. Therefore, we override the library versions with plain classic POWER
+ 32-bit alternate versions (emitted at -O0 by GCC).
+
+ Note that this does not affect in any way, the user's ability to debug their
+ code with Valgrind.
+
+Signed-off-by: Anmol Paralkar <Anmol@freescale.com>
+
+Index: coregrind/pub_core_trampoline.h
+===================================================================
+--- a/coregrind/pub_core_trampoline.h	(revision 14779)
++++ b/coregrind/pub_core_trampoline.h	(working copy)
+@@ -79,6 +79,8 @@
+ extern UInt  VG_(ppc32_linux_REDIR_FOR_strlen)( void* );
+ extern UInt  VG_(ppc32_linux_REDIR_FOR_strcmp)( void*, void* );
+ extern void* VG_(ppc32_linux_REDIR_FOR_strchr)( void*, Int );
++extern void *VG_(ppc32_linux_fsl_REDIR_FOR_memcpy)(void *dest, const void *src, Int n);
++extern void *VG_(ppc32_linux_fsl_REDIR_FOR_memset)(void *s, Int c, Int n);
+ #endif
+ 
+ #if defined(VGP_ppc64be_linux) || defined(VGP_ppc64le_linux)
+Index: coregrind/m_trampoline.S
+===================================================================
+--- a/coregrind/m_trampoline.S	(revision 14779)
++++ b/coregrind/m_trampoline.S	(working copy)
+@@ -307,6 +307,105 @@
+ .global VG_(trampoline_stuff_start)
+ VG_(trampoline_stuff_start):
+ 
++/* To obtain the assembly below, do: gcc -S -m32 on:
++#define VG_(x) x
++
++void *VG_(ppc32_linux_fsl_REDIR_FOR_memcpy)(char *dst, const char *src, int n)
++{
++  const char *p;
++  char *q = dst;
++  p = src;
++  while ((p - src) < n)
++    *q++ = *p++;
++  return dst;
++}
++*/
++.align 2
++.globl VG_(ppc32_linux_fsl_REDIR_FOR_memcpy)
++.type   VG_(ppc32_linux_fsl_REDIR_FOR_memcpy), @function
++VG_(ppc32_linux_fsl_REDIR_FOR_memcpy):
++        stwu 1,-48(1)
++        stw 31,44(1)
++        mr 31,1
++        stw 3,24(31)
++        stw 4,28(31)
++        stw 5,32(31)
++        lwz 9,24(31)
++        stw 9,12(31)
++        lwz 9,28(31)
++        stw 9,8(31)
++        b .L2
++.L3:   
++        lwz 9,12(31)
++        addi 10,9,1
++        stw 10,12(31)
++        lwz 10,8(31)
++        addi 8,10,1
++        stw 8,8(31)
++        lbz 10,0(10)
++        rlwinm 10,10,0,0xff
++        stb 10,0(9)
++.L2:   
++        lwz 10,8(31)
++        lwz 9,28(31)
++        subf 10,9,10
++        lwz 9,32(31)
++        cmpw 7,10,9
++        blt 7,.L3
++        lwz 9,24(31)
++        mr 3,9
++        addi 11,31,48
++        lwz 31,-4(11)
++        mr 1,11
++        blr
++.size   VG_(ppc32_linux_fsl_REDIR_FOR_memcpy),.-VG_(ppc32_linux_fsl_REDIR_FOR_memcpy)
++
++/* To obtain the assembly below, do: gcc -S -m32 on:
++#define VG_(x) x
++void *VG_(ppc32_linux_fsl_REDIR_FOR_memset)(char *s, int c, int n)
++{
++  char *p;
++  p = s;
++  while ((p - s) < n)
++    *p++ = c;
++  return s;
++}
++ */
++.align 2
++.globl VG_(ppc32_linux_fsl_REDIR_FOR_memset)
++.type   VG_(ppc32_linux_fsl_REDIR_FOR_memset), @function
++VG_(ppc32_linux_fsl_REDIR_FOR_memset):
++        stwu 1,-48(1)
++        stw 31,44(1)
++        mr 31,1
++        stw 3,24(31)
++        stw 4,28(31)
++        stw 5,32(31)
++        lwz 9,24(31)
++        stw 9,8(31)
++        b .L6
++.L7:
++        lwz 9,8(31)
++        addi 10,9,1
++        stw 10,8(31)
++        lwz 10,28(31)
++        rlwinm 10,10,0,0xff
++        stb 10,0(9)
++.L6:   
++        lwz 10,8(31)
++        lwz 9,24(31)
++        subf 10,9,10
++        lwz 9,32(31)
++        cmpw 7,10,9
++        blt 7,.L7
++        lwz 9,24(31)
++        mr 3,9
++        addi 11,31,48
++        lwz 31,-4(11)
++        mr 1,11
++        blr
++.size   VG_(ppc32_linux_fsl_REDIR_FOR_memset),.-VG_(ppc32_linux_fsl_REDIR_FOR_memset)
++
+ .global VG_(ppc32_linux_SUBST_FOR_sigreturn)
+ VG_(ppc32_linux_SUBST_FOR_sigreturn):
+ 	li 0,__NR_sigreturn
+Index: coregrind/m_redir.c
+===================================================================
+--- a/coregrind/m_redir.c	(revision 14779)
++++ b/coregrind/m_redir.c	(working copy)
+@@ -1284,6 +1284,16 @@
+    }
+ 
+ #  elif defined(VGP_ppc32_linux)
++   add_hardwired_spec(
++      "ld.so.1", "memcpy",
++      (Addr)VG_(fnptr_to_fnentry)( &VG_(ppc32_linux_fsl_REDIR_FOR_memcpy) ),
++         complain_about_stripped_glibc_ldso
++   );
++   add_hardwired_spec(
++      "ld.so.1", "memset",
++      (Addr)VG_(fnptr_to_fnentry)( &VG_(ppc32_linux_fsl_REDIR_FOR_memset) ),
++         complain_about_stripped_glibc_ldso
++   );
+    /* If we're using memcheck, use these intercepts right from
+       the start, otherwise ld.so makes a lot of noise. */
+    if (0==VG_(strcmp)("Memcheck", VG_(details).name)) {
diff --git a/recipes-devtools/valgrind/valgrind_3.10.1.bbappend b/recipes-devtools/valgrind/valgrind_3.10.1.bbappend
new file mode 100644
index 0000000..bd164ce
--- /dev/null
+++ b/recipes-devtools/valgrind/valgrind_3.10.1.bbappend
@@ -0,0 +1,28 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
+
+SRC_URI_append_qoriq-ppc = " \
+    file://override-32-bit-glibc-memcpy-memset.patch \
+"
+EXTRA_OECONF_append_qoriq-ppc = " --program-prefix=${TARGET_ARCH}-"
+
+do_install_append_qoriq-ppc() {
+    # Create a symbolic link as the user expects to see a /usr/bin/valgrind
+    # On 64-bit MACHINE's, ensure that the link created, points to the *64-bit*
+    # valgrind. Assume that the presence of the patterns: "\-64b" in ${MACHINE}
+    # and "64" in ${TARGET_ARCH}, indicate the 64-bit flavour and that their
+    # absence indicates 32-bit flavour respectively. Now, when both 32-bit and
+    # 64-bit flavours are available to choose from; it does happen that even
+    # though ${MACHINE} is chosen to indicate the choice of the 32-bit case, the
+    # 64-bit tools are built too. So, ensure that on 32-bit, the link points
+    # to the 32-bit valgrind, and of-course, that on 64-bit, the link points
+    # to the 64-bit valgrind.
+    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
+        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
+         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
+          echo "${TARGET_ARCH}" | grep --quiet "64"); then
+        cd ${D}/${bindir}
+        ln -sf ${TARGET_ARCH}-valgrind valgrind
+    fi
+}
+
+COMPATIBLE_MACHINE = "(e500mc|e5500|e5500-64b|e6500|e6500-64b)"
-- 
2.4.3

[PATCH v3 6/7] rename scatter-gather to kernel-module-scatter-gather

[Zhenhua Luo]

Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
 .../kernel-module-scatter-gather_git.bb}                                  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename recipes-kernel/{scatter-gather/scatter-gather_git.bb => kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb} (100%)

diff --git a/recipes-kernel/scatter-gather/scatter-gather_git.bb b/recipes-kernel/kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb
similarity index 100%
rename from recipes-kernel/scatter-gather/scatter-gather_git.bb
rename to recipes-kernel/kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb
-- 
2.4.3

[PATCH v3 7/7] kernel-module-scatter-gather: update COMPATIBLE_MACHINE from ls1021atwr to ls1021a

[Zhenhua Luo]

Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
---
 .../kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb b/recipes-kernel/kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb
index 0fb6c65..1caec3e 100644
--- a/recipes-kernel/kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb
+++ b/recipes-kernel/kernel-module-scatter-gather/kernel-module-scatter-gather_git.bb
@@ -9,4 +9,4 @@ SRCREV = "97db173d08a70abe2b9a6fa928299a117f3febc2"
 
 S = "${WORKDIR}/git"
 
-COMPATIBLE_MACHINE = "(ls1021atwr)"
+COMPATIBLE_MACHINE = "(ls1021a)"
-- 
2.4.3

Re: [PATCH v3 3/7] qoriq-base.inc: disable virtual terminal support for QorIQ

[Otavio Salvador]

On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com> wrote:
> Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>

To be honest I dislike disabling VT in the BSP but if we do it, it
needs to be done in the machine files as a new machine should not do
that by default.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Otavio Salvador]

On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com> wrote:
> * Add bbappend for qoriq(except e500v2) to create a symbolic link as the
>   user expects to see a /usr/bin/valgrind on 64-bit MACHINE's, ensure that
>   the link created, points to the *64-bit* valgrind. Assume that the presence
>   of the patterns: "\-64b" in ${MACHINE} and "64" in ${TARGET_ARCH}, indicate
>   the 64-bit flavour and that their absence indicates 32-bit flavour respectively.
>   Now, when both 32-bit and 64-bit flavours are available to choose from; it
>   does happen that even though ${MACHINE} is chosen to indicate the choice of
>   the 32-bit case, the 64-bit tools are built too. So, ensure that on 32-bit,
>   the link points to the 32-bit valgrind, and of-course, that on 64-bit, the
>   link points to the 64-bit valgrind.
> * Override the 32-bit implementations of memcpy(), memset() from glibc.
>   On 64-bit platforms, for 32-bit mode, the Freescale optimized implementations
>   of the glibc functions memcpy(), memset() use POWER ISA Category:64-bit
>   instructions. By design, these are not implementatble in Valgrind in 32-bit
>   mode. Therefore, we override the library versions with plain classic POWER
>   32-bit alternate versions (emitted at -O0 by GCC).
> * Add COMPATIBLE_MACHINE
>
> Signed-off-by: Ting Liu <b28495@freescale.com>
> Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>


If user is debugging memory in over 32bit space it will work?

...
> +++ b/recipes-devtools/valgrind/valgrind_3.10.1.bbappend
> @@ -0,0 +1,28 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
> +
> +SRC_URI_append_qoriq-ppc = " \
> +    file://override-32-bit-glibc-memcpy-memset.patch \
> +"
> +EXTRA_OECONF_append_qoriq-ppc = " --program-prefix=${TARGET_ARCH}-"
> +
> +do_install_append_qoriq-ppc() {
> +    # Create a symbolic link as the user expects to see a /usr/bin/valgrind
> +    # On 64-bit MACHINE's, ensure that the link created, points to the *64-bit*
> +    # valgrind. Assume that the presence of the patterns: "\-64b" in ${MACHINE}
> +    # and "64" in ${TARGET_ARCH}, indicate the 64-bit flavour and that their
> +    # absence indicates 32-bit flavour respectively. Now, when both 32-bit and
> +    # 64-bit flavours are available to choose from; it does happen that even
> +    # though ${MACHINE} is chosen to indicate the choice of the 32-bit case, the
> +    # 64-bit tools are built too. So, ensure that on 32-bit, the link points
> +    # to the 32-bit valgrind, and of-course, that on 64-bit, the link points
> +    # to the 64-bit valgrind.
> +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
> +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
> +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
> +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
> +        cd ${D}/${bindir}
> +        ln -sf ${TARGET_ARCH}-valgrind valgrind
> +    fi
> +}

I understand the need for this but I think a better way to do is:

 - use program-prefix always
 - use update-alternatives to maintain the link

This can be done upstream.

> +COMPATIBLE_MACHINE = "(e500mc|e5500|e5500-64b|e6500|e6500-64b)"

This breaks build of valgrind for all other machines.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 3/7] qoriq-base.inc: disable virtual terminal support for QorIQ

[Luo Zhenhua]

> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> Sent: Thursday, August 27, 2015 9:37 PM
> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [PATCH v3 3/7] qoriq-base.inc: disable virtual
> terminal support for QorIQ
> 
> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com>
> wrote:
> > Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
> 
> To be honest I dislike disabling VT in the BSP but if we do it, it needs to be done
> in the machine files as a new machine should not do that by default.
[Luo Zhenhua-B19537] Since all QorIQ targets don't need VT, I consider it as a common setting for QorIQ targets, instead of adding it in each QorIQ machine conf. 
	In future if there is QorIQ machine which should enable VT, it can be overridden in corresponding machine conf, does it make sense? 


Best Regards,

Zhenhua

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 3/7] qoriq-base.inc: disable virtual terminal support for QorIQ

[Otavio Salvador]

On Thu, Aug 27, 2015 at 10:56 AM, Luo Zhenhua <zhenhua.luo@freescale.com> wrote:
>> -----Original Message-----
>> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
>> Sent: Thursday, August 27, 2015 9:37 PM
>> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
>> Cc: meta-freescale@yoctoproject.org
>> Subject: Re: [meta-freescale] [PATCH v3 3/7] qoriq-base.inc: disable virtual
>> terminal support for QorIQ
>>
>> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com>
>> wrote:
>> > Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
>>
>> To be honest I dislike disabling VT in the BSP but if we do it, it needs to be done
>> in the machine files as a new machine should not do that by default.
> [Luo Zhenhua-B19537] Since all QorIQ targets don't need VT, I consider it as a common setting for QorIQ targets, instead of adding it in each QorIQ machine conf.
>         In future if there is QorIQ machine which should enable VT, it can be overridden in corresponding machine conf, does it make sense?

ls1021atwr has HDMI and Usb, why I cannot use VT?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 2/7] kernel-module-perf-qoriq: Add recipe

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com>
wrote:

> The kernel-module-perf-qoriq package is QorIQ extension to perf for
> supporting non core counters.
>
> Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
>

I applied this however moved this for kernel-modules subdir so we put it in
a common place. Take a look at meta-freescale and please rebase your
patches.

While doing this, please rework the commit log of the modules more in line
of
https://github.com/Freescale/meta-freescale/commit/8a86093beaca3b6720b3516a823be72157dece3b

This makes more clear the move.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 1685 bytes --]

Re: [PATCH v3 3/7] qoriq-base.inc: disable virtual terminal support for QorIQ

[Luo Zhenhua]

> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> Sent: Thursday, August 27, 2015 10:07 PM
> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [PATCH v3 3/7] qoriq-base.inc: disable virtual
> terminal support for QorIQ
> 
> On Thu, Aug 27, 2015 at 10:56 AM, Luo Zhenhua <zhenhua.luo@freescale.com>
> wrote:
> >> -----Original Message-----
> >> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> >> Sent: Thursday, August 27, 2015 9:37 PM
> >> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
> >> Cc: meta-freescale@yoctoproject.org
> >> Subject: Re: [meta-freescale] [PATCH v3 3/7] qoriq-base.inc: disable
> >> virtual terminal support for QorIQ
> >>
> >> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo
> >> <zhenhua.luo@freescale.com>
> >> wrote:
> >> > Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
> >>
> >> To be honest I dislike disabling VT in the BSP but if we do it, it
> >> needs to be done in the machine files as a new machine should not do that
> by default.
> > [Luo Zhenhua-B19537] Since all QorIQ targets don't need VT, I consider it as a
> common setting for QorIQ targets, instead of adding it in each QorIQ machine
> conf.
> >         In future if there is QorIQ machine which should enable VT, it can be
> overridden in corresponding machine conf, does it make sense?
> 
> ls1021atwr has HDMI and Usb, why I cannot use VT?
[Luo Zhenhua-B19537] "disable by default" doesn't mean "not support". Since QorIQ SDK is tested with USE_VT disabled, I added USE_VT ?="0" for all QorIQ targets. 
	Is the following solution OK?
	Moving USE_VT ?= "0" to qoriq-ppc.inc, accordingly USE_VT is enabled for ls1021a targets. 


Best Regards,

Zhenhua

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Luo Zhenhua]

> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> Sent: Thursday, August 27, 2015 9:46 PM
> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [PATCH v3 5/7] valgrind: add bbappend for
> multilib support and override memcpy/memset
> 
> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com>
> wrote:
> > * Add bbappend for qoriq(except e500v2) to create a symbolic link as the
> >   user expects to see a /usr/bin/valgrind on 64-bit MACHINE's, ensure that
> >   the link created, points to the *64-bit* valgrind. Assume that the presence
> >   of the patterns: "\-64b" in ${MACHINE} and "64" in ${TARGET_ARCH},
> indicate
> >   the 64-bit flavour and that their absence indicates 32-bit flavour respectively.
> >   Now, when both 32-bit and 64-bit flavours are available to choose from; it
> >   does happen that even though ${MACHINE} is chosen to indicate the choice
> of
> >   the 32-bit case, the 64-bit tools are built too. So, ensure that on 32-bit,
> >   the link points to the 32-bit valgrind, and of-course, that on 64-bit, the
> >   link points to the 64-bit valgrind.
> > * Override the 32-bit implementations of memcpy(), memset() from glibc.
> >   On 64-bit platforms, for 32-bit mode, the Freescale optimized
> implementations
> >   of the glibc functions memcpy(), memset() use POWER ISA Category:64-bit
> >   instructions. By design, these are not implementatble in Valgrind in 32-bit	
> >   mode. Therefore, we override the library versions with plain classic POWER
> >   32-bit alternate versions (emitted at -O0 by GCC).
> > * Add COMPATIBLE_MACHINE
> >
> > Signed-off-by: Ting Liu <b28495@freescale.com>
> > Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
> 
> 
> If user is debugging memory in over 32bit space it will work?
[Luo Zhenhua-B19537] currently no issue is reported for the implementation, 

> > +++ b/recipes-devtools/valgrind/valgrind_3.10.1.bbappend
> > @@ -0,0 +1,28 @@
> > +FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
> > +
> > +SRC_URI_append_qoriq-ppc = " \
> > +    file://override-32-bit-glibc-memcpy-memset.patch \ "
> > +EXTRA_OECONF_append_qoriq-ppc = " --program-
> prefix=${TARGET_ARCH}-"
> > +
> > +do_install_append_qoriq-ppc() {
> > +    # Create a symbolic link as the user expects to see a /usr/bin/valgrind
> > +    # On 64-bit MACHINE's, ensure that the link created, points to the *64-
> bit*
> > +    # valgrind. Assume that the presence of the patterns: "\-64b" in
> ${MACHINE}
> > +    # and "64" in ${TARGET_ARCH}, indicate the 64-bit flavour and that their
> > +    # absence indicates 32-bit flavour respectively. Now, when both 32-bit
> and
> > +    # 64-bit flavours are available to choose from; it does happen that even
> > +    # though ${MACHINE} is chosen to indicate the choice of the 32-bit case,
> the
> > +    # 64-bit tools are built too. So, ensure that on 32-bit, the link points
> > +    # to the 32-bit valgrind, and of-course, that on 64-bit, the link points
> > +    # to the 64-bit valgrind.
> > +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
> > +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
> > +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
> > +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
> > +        cd ${D}/${bindir}
> > +        ln -sf ${TARGET_ARCH}-valgrind valgrind
> > +    fi
> > +}
> 
> I understand the need for this but I think a better way to do is:
> 
>  - use program-prefix always
>  - use update-alternatives to maintain the link
> This can be done upstream.
[Luo Zhenhua-B19537] I tried to utilize update-alternatives bbclass, the following syntax is not supported by update-alternatives. 
	ALTERNATIVE_${PN} = "valgrind-${TARGET_ARCH}"
	ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"

	ERROR: ParseError at ./poky/meta/recipes-devtools/valgrind/valgrind_3.10.0.bb:102: unparsed line: 'ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"'

> > +COMPATIBLE_MACHINE = "(e500mc|e5500|e5500-64b|e6500|e6500-64b)"
> 
> This breaks build of valgrind for all other machines.
[Luo Zhenhua-B19537] You are right,  I will drop this line in new version. 


Best Regards,

Zhenhua

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 3/7] qoriq-base.inc: disable virtual terminal support for QorIQ

[Otavio Salvador]

On Thu, Aug 27, 2015 at 11:02 PM, Luo Zhenhua <zhenhua.luo@freescale.com> wrote:
>> -----Original Message-----
>> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
>> Sent: Thursday, August 27, 2015 10:07 PM
>> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
>> Cc: meta-freescale@yoctoproject.org
>> Subject: Re: [meta-freescale] [PATCH v3 3/7] qoriq-base.inc: disable virtual
>> terminal support for QorIQ
>>
>> On Thu, Aug 27, 2015 at 10:56 AM, Luo Zhenhua <zhenhua.luo@freescale.com>
>> wrote:
>> >> -----Original Message-----
>> >> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
>> >> Sent: Thursday, August 27, 2015 9:37 PM
>> >> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
>> >> Cc: meta-freescale@yoctoproject.org
>> >> Subject: Re: [meta-freescale] [PATCH v3 3/7] qoriq-base.inc: disable
>> >> virtual terminal support for QorIQ
>> >>
>> >> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo
>> >> <zhenhua.luo@freescale.com>
>> >> wrote:
>> >> > Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
>> >>
>> >> To be honest I dislike disabling VT in the BSP but if we do it, it
>> >> needs to be done in the machine files as a new machine should not do that
>> by default.
>> > [Luo Zhenhua-B19537] Since all QorIQ targets don't need VT, I consider it as a
>> common setting for QorIQ targets, instead of adding it in each QorIQ machine
>> conf.
>> >         In future if there is QorIQ machine which should enable VT, it can be
>> overridden in corresponding machine conf, does it make sense?
>>
>> ls1021atwr has HDMI and Usb, why I cannot use VT?
> [Luo Zhenhua-B19537] "disable by default" doesn't mean "not support". Since QorIQ SDK is tested with USE_VT disabled, I added USE_VT ?="0" for all QorIQ targets.
>         Is the following solution OK?
>         Moving USE_VT ?= "0" to qoriq-ppc.inc, accordingly USE_VT is enabled for ls1021a targets.

The point here is that the qoriq include files should describe the
qoriq specifics, not board settings.

So I am not concerning if you will enable or not VT but this should be
in the board file, not the .inc.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Otavio Salvador]

On Fri, Aug 28, 2015 at 5:18 AM, Luo Zhenhua <zhenhua.luo@freescale.com> wrote:
>> -----Original Message-----
>> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
>> Sent: Thursday, August 27, 2015 9:46 PM
>> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
>> Cc: meta-freescale@yoctoproject.org
>> Subject: Re: [meta-freescale] [PATCH v3 5/7] valgrind: add bbappend for
>> multilib support and override memcpy/memset
>>
>> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo@freescale.com>
>> wrote:
>> > * Add bbappend for qoriq(except e500v2) to create a symbolic link as the
>> >   user expects to see a /usr/bin/valgrind on 64-bit MACHINE's, ensure that
>> >   the link created, points to the *64-bit* valgrind. Assume that the presence
>> >   of the patterns: "\-64b" in ${MACHINE} and "64" in ${TARGET_ARCH},
>> indicate
>> >   the 64-bit flavour and that their absence indicates 32-bit flavour respectively.
>> >   Now, when both 32-bit and 64-bit flavours are available to choose from; it
>> >   does happen that even though ${MACHINE} is chosen to indicate the choice
>> of
>> >   the 32-bit case, the 64-bit tools are built too. So, ensure that on 32-bit,
>> >   the link points to the 32-bit valgrind, and of-course, that on 64-bit, the
>> >   link points to the 64-bit valgrind.
>> > * Override the 32-bit implementations of memcpy(), memset() from glibc.
>> >   On 64-bit platforms, for 32-bit mode, the Freescale optimized
>> implementations
>> >   of the glibc functions memcpy(), memset() use POWER ISA Category:64-bit
>> >   instructions. By design, these are not implementatble in Valgrind in 32-bit
>> >   mode. Therefore, we override the library versions with plain classic POWER
>> >   32-bit alternate versions (emitted at -O0 by GCC).
>> > * Add COMPATIBLE_MACHINE
>> >
>> > Signed-off-by: Ting Liu <b28495@freescale.com>
>> > Signed-off-by: Zhenhua Luo <zhenhua.luo@freescale.com>
>>
>>
>> If user is debugging memory in over 32bit space it will work?
> [Luo Zhenhua-B19537] currently no issue is reported for the implementation,
>
>> > +++ b/recipes-devtools/valgrind/valgrind_3.10.1.bbappend
>> > @@ -0,0 +1,28 @@
>> > +FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
>> > +
>> > +SRC_URI_append_qoriq-ppc = " \
>> > +    file://override-32-bit-glibc-memcpy-memset.patch \ "
>> > +EXTRA_OECONF_append_qoriq-ppc = " --program-
>> prefix=${TARGET_ARCH}-"
>> > +
>> > +do_install_append_qoriq-ppc() {
>> > +    # Create a symbolic link as the user expects to see a /usr/bin/valgrind
>> > +    # On 64-bit MACHINE's, ensure that the link created, points to the *64-
>> bit*
>> > +    # valgrind. Assume that the presence of the patterns: "\-64b" in
>> ${MACHINE}
>> > +    # and "64" in ${TARGET_ARCH}, indicate the 64-bit flavour and that their
>> > +    # absence indicates 32-bit flavour respectively. Now, when both 32-bit
>> and
>> > +    # 64-bit flavours are available to choose from; it does happen that even
>> > +    # though ${MACHINE} is chosen to indicate the choice of the 32-bit case,
>> the
>> > +    # 64-bit tools are built too. So, ensure that on 32-bit, the link points
>> > +    # to the 32-bit valgrind, and of-course, that on 64-bit, the link points
>> > +    # to the 64-bit valgrind.
>> > +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
>> > +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
>> > +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
>> > +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
>> > +        cd ${D}/${bindir}
>> > +        ln -sf ${TARGET_ARCH}-valgrind valgrind
>> > +    fi
>> > +}
>>
>> I understand the need for this but I think a better way to do is:
>>
>>  - use program-prefix always
>>  - use update-alternatives to maintain the link
>> This can be done upstream.
> [Luo Zhenhua-B19537] I tried to utilize update-alternatives bbclass, the following syntax is not supported by update-alternatives.
>         ALTERNATIVE_${PN} = "valgrind-${TARGET_ARCH}"
>         ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"
>
>         ERROR: ParseError at ./poky/meta/recipes-devtools/valgrind/valgrind_3.10.0.bb:102: unparsed line: 'ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"'

So please add the patch, set package-arch accordingly and let's work
on this at upstream. This is a valid use case for multilib and we
ought to discuss this at oe-core to see how to address the issue in a
clean way.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Luo Zhenhua]

> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> Sent: Tuesday, September 01, 2015 12:23 AM
> 
> On Fri, Aug 28, 2015 at 5:18 AM, Luo Zhenhua <zhenhua.luo@freescale.com>
> wrote:
> >> -----Original Message-----
> >> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> >> Sent: Thursday, August 27, 2015 9:46 PM
> >>
> >> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo
> >> <zhenhua.luo@freescale.com>
> >> wrote:
> >> > +
> >> > +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
> >> > +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
> >> > +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
> >> > +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
> >> > +        cd ${D}/${bindir}
> >> > +        ln -sf ${TARGET_ARCH}-valgrind valgrind
> >> > +    fi
> >> > +}
> >>
> >> I understand the need for this but I think a better way to do is:
> >>
> >>  - use program-prefix always
> >>  - use update-alternatives to maintain the link This can be done
> >> upstream.
> > [Luo Zhenhua-B19537] I tried to utilize update-alternatives bbclass, the
> following syntax is not supported by update-alternatives.
> >         ALTERNATIVE_${PN} = "valgrind-${TARGET_ARCH}"
> >         ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"
> >
> >         ERROR: ParseError at ./poky/meta/recipes-
> devtools/valgrind/valgrind_3.10.0.bb:102: unparsed line:
> 'ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"'
> 
> So please add the patch, set package-arch accordingly and let's work on this at
> upstream. 
[Luo Zhenhua-B19537] I think you mean submit patch to use current way and add PACKAGE_ARCH = "'${MACHIINE_ARCH}", is this right? 

> This is a valid use case for multilib and we ought to discuss this at oe-
> core to see how to address the issue in a clean way.
[Luo Zhenhua-B19537] I can initial an email to oe-core mailist to discuss the topic, 


Best Regards,

Zhenhua

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Otavio Salvador]

On Tue, Sep 1, 2015 at 4:45 AM, Luo Zhenhua <zhenhua.luo@freescale.com> wrote:
>> -----Original Message-----
>> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
>> Sent: Tuesday, September 01, 2015 12:23 AM
>>
>> On Fri, Aug 28, 2015 at 5:18 AM, Luo Zhenhua <zhenhua.luo@freescale.com>
>> wrote:
>> >> -----Original Message-----
>> >> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
>> >> Sent: Thursday, August 27, 2015 9:46 PM
>> >>
>> >> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo
>> >> <zhenhua.luo@freescale.com>
>> >> wrote:
>> >> > +
>> >> > +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
>> >> > +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
>> >> > +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
>> >> > +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
>> >> > +        cd ${D}/${bindir}
>> >> > +        ln -sf ${TARGET_ARCH}-valgrind valgrind
>> >> > +    fi
>> >> > +}
>> >>
>> >> I understand the need for this but I think a better way to do is:
>> >>
>> >>  - use program-prefix always
>> >>  - use update-alternatives to maintain the link This can be done
>> >> upstream.
>> > [Luo Zhenhua-B19537] I tried to utilize update-alternatives bbclass, the
>> following syntax is not supported by update-alternatives.
>> >         ALTERNATIVE_${PN} = "valgrind-${TARGET_ARCH}"
>> >         ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"
>> >
>> >         ERROR: ParseError at ./poky/meta/recipes-
>> devtools/valgrind/valgrind_3.10.0.bb:102: unparsed line:
>> 'ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"'
>>
>> So please add the patch, set package-arch accordingly and let's work on this at
>> upstream.
> [Luo Zhenhua-B19537] I think you mean submit patch to use current way and add PACKAGE_ARCH = "'${MACHIINE_ARCH}", is this right?

For the SoC families which apply the patch.

>> This is a valid use case for multilib and we ought to discuss this at oe-
>> core to see how to address the issue in a clean way.
> [Luo Zhenhua-B19537] I can initial an email to oe-core mailist to discuss the topic,

Good.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Luo Zhenhua]

> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> Sent: Tuesday, September 01, 2015 8:04 PM
> To: Luo Zhenhua-B19537 <zhenhua.luo@freescale.com>
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [PATCH v3 5/7] valgrind: add bbappend for
> multilib support and override memcpy/memset
> 
> On Tue, Sep 1, 2015 at 4:45 AM, Luo Zhenhua <zhenhua.luo@freescale.com>
> wrote:
> >> -----Original Message-----
> >> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> >> Sent: Tuesday, September 01, 2015 12:23 AM
> >>
> >> On Fri, Aug 28, 2015 at 5:18 AM, Luo Zhenhua
> >> <zhenhua.luo@freescale.com>
> >> wrote:
> >> >> -----Original Message-----
> >> >> From: Otavio Salvador [mailto:otavio.salvador@ossystems.com.br]
> >> >> Sent: Thursday, August 27, 2015 9:46 PM
> >> >>
> >> >> On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo
> >> >> <zhenhua.luo@freescale.com>
> >> >> wrote:
> >> >> > +
> >> >> > +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
> >> >> > +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
> >> >> > +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
> >> >> > +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
> >> >> > +        cd ${D}/${bindir}
> >> >> > +        ln -sf ${TARGET_ARCH}-valgrind valgrind
> >> >> > +    fi
> >> >> > +}
> >> >>
> >> >> I understand the need for this but I think a better way to do is:
> >> >>
> >> >>  - use program-prefix always
> >> >>  - use update-alternatives to maintain the link This can be done
> >> >> upstream.
> >> > [Luo Zhenhua-B19537] I tried to utilize update-alternatives
> >> > bbclass, the
> >> following syntax is not supported by update-alternatives.
> >> >         ALTERNATIVE_${PN} = "valgrind-${TARGET_ARCH}"
> >> >         ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"
> >> >
> >> >         ERROR: ParseError at ./poky/meta/recipes-
> >> devtools/valgrind/valgrind_3.10.0.bb:102: unparsed line:
> >> 'ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"'
> >>
> >> So please add the patch, set package-arch accordingly and let's work
> >> on this at upstream.
> > [Luo Zhenhua-B19537] I think you mean submit patch to use current way and
> add PACKAGE_ARCH = "'${MACHIINE_ARCH}", is this right?
> 
> For the SoC families which apply the patch.
[Luo Zhenhua-B19537] I am sorry, I don't understand this comment, can you please elaborate? An example will be helpful.  


Best Regards,

Zhenhua

> >> This is a valid use case for multilib and we ought to discuss this at
> >> oe- core to see how to address the issue in a clean way.
> > [Luo Zhenhua-B19537] I can initial an email to oe-core mailist to
> > discuss the topic,
> 
> Good.
> 
> 
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Otavio Salvador]

On Tue, Sep 1, 2015 at 11:10 PM, Luo Zhenhua <zhenhua.luo@freescale.com> wrote:
>> For the SoC families which apply the patch.
> [Luo Zhenhua-B19537] I am sorry, I don't understand this comment, can you please elaborate? An example will be helpful.

SRC_URI_append_qoriq = " file://..."
PACKAGE_ARCH_qoriq = "${MACHINE_ARCH}"

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750