Re: [yocto] profiling tools on a T4240RDB board

2016-08-24 Thread Zhenhua Luo 
The fsl-image-minimal rootfs doesn't include those graphic packages by default, 
I think those packages are included by the dependency of new added packages.

You can run "bitbake -g fsl-image-minimal" to generate the dependence file and 
analysis how the unneeded packages are brought in.


Best Regards,

Zhenhua

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Leonardo Sandoval
Sent: Wednesday, August 24, 2016 10:19 PM
To: Tanasa Bogdan ; 'yocto@yoctoproject.org' 

Subject: Re: [yocto] profiling tools on a T4240RDB board




El 08/24/2016 a las 04:01 AM, Tanasa Bogdan escribió:
Hi,

We are using the (freescale) linux yocto 1.6 on a T4240RDB board where we want 
to have "tools-profile" set in our local.conf file. When building the 
fsl-image-minimal we see that there are some packages that are graphics-related 
(like gtk+, pixbuf, etc..). The card does not have any graphics capabilities. 
Why does these packets install at all? Is it possible to have the profiling 
tools without any gtk dependencies? How the local.conf should look like?
I believe the image you are using include those graphic-related pkgs so that is 
why you are seeing them. You may redefine your image, at the end 
fsl-image-minimal is just an example that you can modify. Also you may have 
more answers  on a FSL (NXP?) channel/mailing-list



PS: These dependencies are there even when we choose tools-sdk in order to have 
gcc in the final image.

Thanks,
Bogdan.



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [eclipse-poky][PATCH] scripts/setup.sh: check java version

2016-08-24 Thread Randle, William C 
On Wed, 2016-08-24 at 22:59 +, Randle, William C wrote:
On Wed, 2016-08-24 at 15:22 -0700, Tim Orling wrote:

> > Make it obvious when run on autobuilder if java version is too low.
While we are at it, check that java is present.

[YOCTO #10156]

Borrowing heavily from:
http://stackoverflow.com/questions/7334754/correct-way-to-check-java-version
> > -from-bash-script

Signed-off-by: Tim Orling 
>
---
 scripts/setup.sh | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/scripts/setup.sh b/scripts/setup.sh
index 75310ab..c2b32a4 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -67,6 +67,29 @@ if [ "x$url" != "x" ]; then
 [ "x$port" != "x" ] && PROXY_PARAM="${PROXY_PARAM}
> > -Dhttp.proxyPort=$port"
 fi

+echo " Checking that Java is available "
+if type -p java; then
+echo java found in PATH
+_java=java
+elif [[ -n "$JAVA_HOME" ]] && [[ -x "$JAVA_HOME/bin/java" ]]; thennightly-
> > multilib.conf
+echo java found in JAVA_HOME
+_java="$JAVA_HOME/bin/java"
+else
+err_exit 2 "no java"
+fi
+echo " Checking that the appropriate Java version is available "
+JAVA_VER_STRING=1.8
+JAVA_VER_INT=001008
+if [[ "$_java" ]]; then
+version=$("$_java" -version 2>&1 | awk -F '"' '/version/ {print $2}')
+echo java version as string = $version
+version_int=$(echo "$version" | awk -F. '{printf("%03d%03d",$1,$2);}')
+echo java version as integer = $version_int
+if [ $version_int -lt $JAVA_VER_INT ]; then
+err_exit 1 "Java version must be $JAVA_VER_STRING+"
+fi
+fi
+
 # prepare the base Eclipse installation in folder "eclipse"
 ep_rel="R-"
 ep_ver="4.6"
--
2.7.4


Tim,

FYI, the dash shell used on Ubuntu does not recognize the "[[" construct, 
because it's a bash extension and not POSIX. I suggest you replace it with 
something POSIX compliant.

-Bill

--



Never mind. I checked the full setup.sh script and it explicitly invokes 
/bin/bash, so you're ok as is.

-Bill
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [eclipse-poky][PATCH] scripts/setup.sh: check java version

2016-08-24 Thread Randle, William C 
On Wed, 2016-08-24 at 15:22 -0700, Tim Orling wrote:

Make it obvious when run on autobuilder if java version is too low.
While we are at it, check that java is present.

[YOCTO #10156]

Borrowing heavily from:
http://stackoverflow.com/questions/7334754/correct-way-to-check-java-version-from-bash-script

Signed-off-by: Tim Orling 
>
---
 scripts/setup.sh | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/scripts/setup.sh b/scripts/setup.sh
index 75310ab..c2b32a4 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -67,6 +67,29 @@ if [ "x$url" != "x" ]; then
 [ "x$port" != "x" ] && PROXY_PARAM="${PROXY_PARAM} -Dhttp.proxyPort=$port"
 fi

+echo " Checking that Java is available "
+if type -p java; then
+echo java found in PATH
+_java=java
+elif [[ -n "$JAVA_HOME" ]] && [[ -x "$JAVA_HOME/bin/java" ]]; then
+echo java found in JAVA_HOME
+_java="$JAVA_HOME/bin/java"
+else
+err_exit 2 "no java"
+fi
+echo " Checking that the appropriate Java version is available "
+JAVA_VER_STRING=1.8
+JAVA_VER_INT=001008
+if [[ "$_java" ]]; then
+version=$("$_java" -version 2>&1 | awk -F '"' '/version/ {print $2}')
+echo java version as string = $version
+version_int=$(echo "$version" | awk -F. '{printf("%03d%03d",$1,$2);}')
+echo java version as integer = $version_int
+if [ $version_int -lt $JAVA_VER_INT ]; then
+err_exit 1 "Java version must be $JAVA_VER_STRING+"
+fi
+fi
+
 # prepare the base Eclipse installation in folder "eclipse"
 ep_rel="R-"
 ep_ver="4.6"
--
2.7.4



Tim,

FYI, the dash shell used on Ubuntu does not recognize the "[[" construct, 
because it's a bash extension and not POSIX. I suggest you replace it with 
something POSIX compliant.

-Bill
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 1/3] drivers/misc: Axxia MTC Driver Memory Initialization Check

2016-08-24 Thread John Jacques 
Bruce,

I agree with you on both.  I spoke to Sreedevi and there's isn't a reason
she didn't use readl().  As for the delay, we expect about 2 us.  So, I
assume udelay(1) would be appropriate?  If both are okay (readl() instead
of direct access and udelay(1)), I'll update the commit.

Thanks for looking at this!

On Tue, Aug 23, 2016 at 10:08 AM, Dragomir, Daniel <
daniel.drago...@windriver.com> wrote:

> Adding John Jacques, the proper person to respond on this.
>
> Regards,
> Daniel
> 
> From: Winkler, Tomas [tomas.wink...@intel.com]
> Sent: Monday, August 22, 2016 12:52 PM
> To: Dragomir, Daniel; linux-yocto@yoctoproject.org
> Subject: RE: [linux-yocto] [PATCH 1/3] drivers/misc: Axxia MTC Driver
> MemoryInitialization Check
>
> >
> > Axxia MTC driver changes:
> >  - Memory initialization completion check added
> >  - ECC error status clearing added
> >
> > Signed-off-by: Sreedevi Joshi 
> > ---
> >  drivers/misc/lsi-mtc.c | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/misc/lsi-mtc.c b/drivers/misc/lsi-mtc.c index
> > 55c3403..f4fbe6f 100644
> > --- a/drivers/misc/lsi-mtc.c
> > +++ b/drivers/misc/lsi-mtc.c
> > @@ -31,6 +31,7 @@
> >  #include 
> >  #include "linux/lsi_mtc_ioctl.h"
> >
> > +#define MTC_POLL_TIMEOUT (msecs_to_jiffies(1000))
> >
> >  /*
> > device tree node:
> > @@ -4114,6 +4115,8 @@ static long _mtc_config(struct mtc_device *dev,
> > struct lsi_mtc_cfg_t *pMTCCfg)
> >   struct ncp_axis_mtc_MTC_CONFIG0_REG_ADDR_r_t cfg0 = { 0 };
> >   struct ncp_axis_mtc_MTC_CONFIG1_REG_ADDR_r_t cfg1 = { 0 };
> >   struct ncp_axis_mtc_MTC_EXECUTE1_REG_ADDR_r_t exec1 = { 0 };
> > + u32 init_reg = { 0 };
> > + unsigned long tmo = 0;
> >
> >   if ((!pMTCCfg) || (!dev))
> >   return -EINVAL;
> > @@ -4129,6 +4132,21 @@ static long _mtc_config(struct mtc_device *dev,
> > struct lsi_mtc_cfg_t *pMTCCfg)
> >   exec1.sw_reset = 1;
> >   dev->regs->execute = *((u32 *) );
> >   dev->regs->mem_init = 0x202;
> > + /* wait for the init to complete */
> > + tmo = jiffies + MTC_POLL_TIMEOUT;
> > + do {
> > + init_reg = *(&(dev->regs->mem_init));+
>
> I'm not familiar with this code but I don't think this is the way to read
> a register , why not using readl(), you are at least missing memory barrier
> here.
>
> > + if ((init_reg & 0x101) == 0x101)
> > + break;
> > + } while (time_before(jiffies, tmo));
>
> This is busy loop, how fast is that going to settle ?
>
> > +
> > + if ((init_reg & 0x101) != 0x101) {
> > + pr_debug("warning: mem_init failed value=0x%x
> > (expected:0x101)\n",
> > +init_reg);
> > + }
> > +
> > + /* clear ECC interrupt status */
> > + dev->regs->ecc_int_status = 0xF;
> >
> >   /* 3. config MTC */
> >   cfg0 =
> > --
> > 2.7.4
> >
> > --
> > ___
> > linux-yocto mailing list
> > linux-yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/linux-yocto
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] [eclipse-poky][PATCH] scripts/setup.sh: check java version

2016-08-24 Thread Tim Orling 
Make it obvious when run on autobuilder if java version is too low.
While we are at it, check that java is present.

[YOCTO #10156]

Borrowing heavily from:
http://stackoverflow.com/questions/7334754/correct-way-to-check-java-version-from-bash-script

Signed-off-by: Tim Orling 
---
 scripts/setup.sh | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/scripts/setup.sh b/scripts/setup.sh
index 75310ab..c2b32a4 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -67,6 +67,29 @@ if [ "x$url" != "x" ]; then
 [ "x$port" != "x" ] && PROXY_PARAM="${PROXY_PARAM} -Dhttp.proxyPort=$port"
 fi
 
+echo " Checking that Java is available "
+if type -p java; then
+echo java found in PATH
+_java=java
+elif [[ -n "$JAVA_HOME" ]] && [[ -x "$JAVA_HOME/bin/java" ]]; then
+echo java found in JAVA_HOME
+_java="$JAVA_HOME/bin/java"
+else
+err_exit 2 "no java"
+fi
+echo " Checking that the appropriate Java version is available "
+JAVA_VER_STRING=1.8
+JAVA_VER_INT=001008
+if [[ "$_java" ]]; then
+version=$("$_java" -version 2>&1 | awk -F '"' '/version/ {print $2}')
+echo java version as string = $version 
+version_int=$(echo "$version" | awk -F. '{printf("%03d%03d",$1,$2);}')
+echo java version as integer = $version_int
+if [ $version_int -lt $JAVA_VER_INT ]; then
+err_exit 1 "Java version must be $JAVA_VER_STRING+"
+fi
+fi
+
 # prepare the base Eclipse installation in folder "eclipse"
 ep_rel="R-"
 ep_ver="4.6"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Tuning for a machine based on Cortex-A9

2016-08-24 Thread Khem Raj 

> On Aug 24, 2016, at 12:51 AM, Ottavio Campana  wrote:
> 
> Hello,
> 
> I am trying to port a third-party BSP based on buildroot to yocto, but I am 
> not able to tune the compiler to extactly match the original one.
> 
> Particularly, if I run readelf on a binary compiled with the gcc that is used 
> by buildroot I get this output
> 
> ottavio@ottavio:~$ readelf -A hello_world
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_Advanced_SIMD_arch: NEONv1
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio@ottavio:~$
> 
> I tried to replicate this by configuring a new machine, and my machine 
> configuration looks like this
> 
> require ../../../meta/conf/machine/include/tune-cortexa9.inc
> 
> AVAILTUNES += "cortexa9t-vfpv3-neon"
> ARMPKGARCH_tune-cortexa9t-vfpv3-neon  = "cortexa9"
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon   = 
> "${TUNE_FEATURES_tune-armv7at-vfpv3} neon cortexa9"
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv7at-vfpv3} cortexa9-vfp cortexa9-vfpv3 
> cortexa9t2-vfp cortexa9t2-vfpv3 cortexa9-neon"
> 
> DEFAULTTUNE = "cortexa9t-vfpv3-neon”

Use

 DEFAULTTUNE = "cortexa9t-neon"

if you want to use hard-float ABI then

DEFAULTTUNE = “cortexa9thf-neon"

> 
> If I run readelf on any compiled binary obtained with yocto, I get this 
> result:
> 
> ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
>  readelf -A .libs/bzip2
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
> 
> I am quite close to get a similar binary, the missing part is the 
> Tag_Advanced_SIMD_arch: NEONv1 .  I get exactly the same result if I use 
> DEFAULTTUNE = "cortexa9t-vfpv3", thus it seems that the neon and 
> cortexa9-neon options I tried to add are ignored.
> 
> At this point I have two questions
> 
> Question #1
> 
> How should I change ARMPKGARCH_tune-cortexa9t-vfpv3-neon , 
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon and 
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon to have exactly the same kind 
> of elf?
> 
> Question # 2
> 
> Why the only options for neon in meta/conf/machine/include/tune-cortexa9.inc 
> are offered for HF tunes?
> 
> 
> Thank you for your help
> 
> Ottavio
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building applications and distributions separately, but integrate into final image

2016-08-24 Thread Khem Raj 

> On Aug 24, 2016, at 11:54 AM, Michael Habibi  wrote:
> 
> All,
> 
> I am looking at Yocto as a replacement for our embedded distribution.
> Currently we build everything as a distribution. This includes
> building the Linux kernel, open source packages, as well as our own IP
> and applications.
> 
> As you can imagine, a vast majority of our build is taken up by
> repeatedly building distribution components and not our actual IP,
> which is a majority of what changes day to day.
> 
> In moving to Yocto, my first plan was to create all the necessary
> layers and separate out what changes from what doesn't (in fact much
> of what doesn't change is already included in Yocto or the many
> freely-available layers online).
> 
> However, this would still require application developers to have to
> learn and use Yocto to build the entire distribution. Ideally, I'd
> like to separate the applications from the main build, so that
> application developers have to learn less about Yocto, and more
> importantly, save on build time when they make their changes.
> 
> I am exploring exactly how I can use the available SDK options as a
> solution. If I create an image with the base distribution and required
> applications, I'm wondering if I can create a separate tree for the
> application developers. They would then build that entire tree with
> the yocto SDK. I haven't quite figured out yet how I can then
> integrate their applications into the Yocto image, and prepare it for
> deployment. I'm also unclear how we can define new dependencies if the
> base distribution is pre-built. For example, if we introduce a new
> dependency (our custom application now requires zlib, for example), it
> doesn't seem for there to be a way to then ensure zlib is built into
> the final image with the SDK option.
> 
> Unfortunately, we can't build the distribution and then install the
> applications directly onto the target. Based on how our codebase is
> currently designed, it requires a fully-complete image to be installed
> on the target as a whole, and not piecemeal. This is why I need to
> integrate on the host/build environment first before we create the
> deployable image.
> 
> Can anyone share any workflows that they use that may fit with what we
> need? In the mean time I am continuing to play with Yocto and the SDK
> to see what else I can come up with.


You can separate out the application development workflow from system
builder workflow. You can generate SDKs from build system e.g.

bitbake -cpopulate_sdk 

which should generate an SDK which is suitable for developing the
applications which are part of your image. However, when you add new
packages which has dependencies not as part of your images then you
have to regenerate the SDK and provide it.

In some large app teams, I have seen that they deploy the SDK on a
shared NFS or something drive and then platform/SDK teams can provide
newer versions of SDK and let app developers switch their applications
to new SDK in a staggered approach.


You have two ways to integrate the applications

1. Let application teams generate binary artifacts and then you
write recipes, to package them into final image.

2. second option is to build these applications from source as part
of image builds in your CI or production.

if you follow the API discipline. You might not need to update the SDK
so often. What this means is that the applications need to have there
own component build system. Yocto can deal with a lot of them e.g.
cmake, autotools, qmake, or even simple make.

with this you do not have to immediately expose the app devs to OE
internals.

Key piece is how you unit-test or do CI in such an environment especially
for applications. I have solutions for those too but it really depends
upon what kind of tooling is in place and how devs are used to do
the work.

> 
> Thanks all for your time.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Tuning for a machine based on Cortex-A9

2016-08-24 Thread Lennart Sorensen 
On Wed, Aug 24, 2016 at 07:51:40AM +, Ottavio Campana wrote:
> Hello,
> 
> I am trying to port a third-party BSP based on buildroot to yocto, but I am 
> not able to tune the compiler to extactly match the original one.
> 
> Particularly, if I run readelf on a binary compiled with the gcc that is used 
> by buildroot I get this output
> 
> ottavio@ottavio:~$ readelf -A hello_world
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_Advanced_SIMD_arch: NEONv1
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio@ottavio:~$
> 
> I tried to replicate this by configuring a new machine, and my machine 
> configuration looks like this
> 
> require ../../../meta/conf/machine/include/tune-cortexa9.inc
> 
> AVAILTUNES += "cortexa9t-vfpv3-neon"
> ARMPKGARCH_tune-cortexa9t-vfpv3-neon  = "cortexa9"
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon   = 
> "${TUNE_FEATURES_tune-armv7at-vfpv3} neon cortexa9"
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv7at-vfpv3} cortexa9-vfp cortexa9-vfpv3 
> cortexa9t2-vfp cortexa9t2-vfpv3 cortexa9-neon"
> 
> DEFAULTTUNE = "cortexa9t-vfpv3-neon"
> 
> If I run readelf on any compiled binary obtained with yocto, I get this 
> result:
> 
> ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
>  readelf -A .libs/bzip2
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
> 
> I am quite close to get a similar binary, the missing part is the 
> Tag_Advanced_SIMD_arch: NEONv1 .  I get exactly the same result if I use 
> DEFAULTTUNE = "cortexa9t-vfpv3", thus it seems that the neon and 
> cortexa9-neon options I tried to add are ignored.
> 
> At this point I have two questions
> 
> Question #1
> 
> How should I change ARMPKGARCH_tune-cortexa9t-vfpv3-neon , 
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon and 
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon to have exactly the same kind 
> of elf?
> 
> Question # 2
> 
> Why the only options for neon in meta/conf/machine/include/tune-cortexa9.inc 
> are offered for HF tunes?

Well it looks to me like the HF neon options imply vfp, while the vfp3
tunes imply not neon.  Since they share registers the performance may
in fact be better if they are not mixed.

Of course there exists A9's without neon, so one might want to build
for that.

The git commit that added the vfpv3 tunes says they are for 32 register
VFP on A9s.  Neon already implies 32 registers for the vfp.

As far as I can tell, you can set DEFAULTTUNE to cortexa9t-neon to get
softfp with neon support, or you can set it to cortexa9thf-neon to get
hardfp with neon support.

Certainly cortexa9t-vfpv3 should NOT do neon as far as I can tell.

Getting the output you had above with neon support in it, I believe
means doing DEFAULTTUNE=cortexa9thf-neon

There is no such option as cortexa9t-vfpv3-neon that I can find in the
files anywhere, so that wouldn't work.  No point trying to invent one
since neon implies vfpv3 already.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Building applications and distributions separately, but integrate into final image

2016-08-24 Thread Michael Habibi 
All,

I am looking at Yocto as a replacement for our embedded distribution.
Currently we build everything as a distribution. This includes
building the Linux kernel, open source packages, as well as our own IP
and applications.

As you can imagine, a vast majority of our build is taken up by
repeatedly building distribution components and not our actual IP,
which is a majority of what changes day to day.

In moving to Yocto, my first plan was to create all the necessary
layers and separate out what changes from what doesn't (in fact much
of what doesn't change is already included in Yocto or the many
freely-available layers online).

However, this would still require application developers to have to
learn and use Yocto to build the entire distribution. Ideally, I'd
like to separate the applications from the main build, so that
application developers have to learn less about Yocto, and more
importantly, save on build time when they make their changes.

I am exploring exactly how I can use the available SDK options as a
solution. If I create an image with the base distribution and required
applications, I'm wondering if I can create a separate tree for the
application developers. They would then build that entire tree with
the yocto SDK. I haven't quite figured out yet how I can then
integrate their applications into the Yocto image, and prepare it for
deployment. I'm also unclear how we can define new dependencies if the
base distribution is pre-built. For example, if we introduce a new
dependency (our custom application now requires zlib, for example), it
doesn't seem for there to be a way to then ensure zlib is built into
the final image with the SDK option.

Unfortunately, we can't build the distribution and then install the
applications directly onto the target. Based on how our codebase is
currently designed, it requires a fully-complete image to be installed
on the target as a whole, and not piecemeal. This is why I need to
integrate on the host/build environment first before we create the
deployable image.

Can anyone share any workflows that they use that may fit with what we
need? In the mean time I am continuing to play with Yocto and the SDK
to see what else I can come up with.

Thanks all for your time.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH] nightly-wic.conf: add additional config settings for efi images

2016-08-24 Thread Bill Randle 
Building efi disk images now requires extra config settings, so add
IMAGE_FSTYPES and MACHINE_FEATURES appends to the auto.conf file.

Signed-off-by: Bill Randle 
---
 buildset-config.controller/nightly-wic.conf | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/buildset-config.controller/nightly-wic.conf 
b/buildset-config.controller/nightly-wic.conf
index 1b91852..14e2411 100644
--- a/buildset-config.controller/nightly-wic.conf
+++ b/buildset-config.controller/nightly-wic.conf
@@ -9,24 +9,24 @@ steps: [{'SetDest':{}},
 {'RunPreamble':{}},
 {'GetDistroVersion':{'distro': 'poky'}},
 {'CreateBBLayersConf':{'buildprovider':'yocto'}},
-{'CreateAutoConf':{'machine':'qemux86'}},
+{'CreateAutoConf':{'machine':'qemux86', 'atextappend':'\nIMAGE_FSTYPES 
+= " hddimg"\nMACHINE_FEATURES_append = " efi"\n'}},
 {'BuildImages':{'images':'syslinux syslinux-native parted-native 
gptfdisk-native dosfstools-native mtools-native'}},
 {'BuildImages':{'images':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk-gpt', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'mkefidisk', 
'target_img':'core-image-sato'}},
-{'CreateAutoConf':{'machine':'genericx86'}},
+{'CreateAutoConf':{'machine':'genericx86', 
'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append = " 
efi"\n'}},
 {'BuildImages':{'images':'syslinux syslinux-native parted-native 
gptfdisk-native dosfstools-native mtools-native'}},
 {'BuildImages':{'images':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk-gpt', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'mkefidisk', 
'target_img':'core-image-sato'}},
-{'CreateAutoConf':{'machine':'qemux86-64'}},
+{'CreateAutoConf':{'machine':'qemux86-64', 
'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append = " 
efi"\n'}},
 {'BuildImages':{'images':'syslinux syslinux-native parted-native 
gptfdisk-native dosfstools-native mtools-native'}},
 {'BuildImages':{'images':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk-gpt', 
'target_img':'core-image-sato'}},
-{'CreateAutoConf':{'machine':'genericx86-64'}},
+{'CreateAutoConf':{'machine':'genericx86-64', 
'atextappend':'\nIMAGE_FSTYPES += " hddimg"\nMACHINE_FEATURES_append = " 
efi"\n'}},
 {'BuildImages':{'images':'syslinux syslinux-native parted-native 
gptfdisk-native dosfstools-native mtools-native'}},
 {'BuildImages':{'images':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
-- 
2.5.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 1/3] features: Fix dependencies and =m vs =y discrepancies for corei7

2016-08-24 Thread Saul Wold 
On Fri, 2016-08-19 at 20:40 -0700, California Sullivan wrote:
> I missed these in my first pass. This should fix the remaining
> warnings
> that occur with the intel-corei7-64 configurations. The ISDN
> configurations might need to be broken out into their own feature but
> for now just enable them as dependencies for BT_CMTP.
> 
> Signed-off-by: California Sullivan 
> ---
>  features/bluetooth/bluetooth.cfg   | 7 ++-
>  features/ieee802154/ieee802154.cfg | 2 +-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/features/bluetooth/bluetooth.cfg
> b/features/bluetooth/bluetooth.cfg
> index fefb357..67d3f52 100644
> --- a/features/bluetooth/bluetooth.cfg
> +++ b/features/bluetooth/bluetooth.cfg
> @@ -1,5 +1,10 @@
> +# Dependencies
> +CONFIG_ISDN=y
> +CONFIG_ISDN_CAPI=m
> +
> +# Features
>  CONFIG_BT=y
> -CONFIG_BT_6LOWPAN=y
> +CONFIG_BT_6LOWPAN=m
>  CONFIG_BT_RFCOMM=m
>  CONFIG_BT_RFCOMM_TTY=y
>  CONFIG_BT_BNEP=m
> diff --git a/features/ieee802154/ieee802154.cfg
> b/features/ieee802154/ieee802154.cfg
> index bd6c214..518adf0 100644
> --- a/features/ieee802154/ieee802154.cfg
> +++ b/features/ieee802154/ieee802154.cfg
> @@ -1,2 +1,2 @@
>  CONFIG_IEEE802154=y
> -CONFIG_IEEE802154_6LOWPAN=y
> +CONFIG_IEEE802154_6LOWPAN=m
> -- 

Do we also need a 6lowpan feature scc file?

Sau!

> 2.5.5
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] profiling tools on a T4240RDB board

2016-08-24 Thread Leonardo Sandoval 



El 08/24/2016 a las 04:01 AM, Tanasa Bogdan escribió:


Hi,

We are using the (freescale) linux yocto 1.6 on a T4240RDB board where 
we want to have "tools-profile" set in our local.conf file. When 
building the fsl-image-minimal we see that there are some packages 
that are graphics-related (like gtk+, pixbuf, etc..). The card does 
not have any graphics capabilities. Why does these packets install at 
all? Is it possible to have the profiling tools without any gtk 
dependencies? How the local.conf should look like?


I believe the image you are using include those graphic-related pkgs so 
that is why you are seeing them. You may redefine your image, at the end 
fsl-image-minimal is just an example that you can modify. Also you may 
have more answers  on a FSL (NXP?) channel/mailing-list


PS: These dependencies are there even when we choose tools-sdk in 
order to have gcc in the final image.


Thanks,

Bogdan.





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trying to run toaster off master, running into issues w/ django

2016-08-24 Thread Michael Habibi 
Excellent. Thanks! I knew using latest was going to burn me eventually :)

On Wed, Aug 24, 2016 at 5:51 AM, Ed Bartosh  wrote:
> On Tue, Aug 23, 2016 at 04:49:42PM -0500, Michael Habibi wrote:
>> I am running the master branch and trying to run toaster to play
>> around with the web interface (already successfully completed a build
>> w/o toaster setup).
>>
>> I followed the instructions in the documentation. I created a
>> virtualenv, sourced/activated my virtualenv, and while under venv I
>> did a pip install. It believes Django is installed, but I cannot run
>> toaster. See below:
>>
>> (venv)habibim@bvm-poc8:/projects/yocto-git/build$ pip install -r
>> /projects/yocto-git/bitbake/toaster-requirements.txt
>> Requirement already satisfied (use --upgrade to upgrade):
>> Django>1.8,<1.9 in /home/habibim/venv/lib/python2.7/site-packages
>> (from -r /projects/yocto-git/bitbake/toaster-requirements.txt (line
>> 1))
>> Requirement already satisfied (use --upgrade to upgrade):
>> beautifulsoup4>=4.4.0 in
>> /home/habibim/venv/lib/python2.7/site-packages (from -r
>> /projects/yocto-git/bitbake/toaster-requirements.txt (line 2))
>> Requirement already satisfied (use --upgrade to upgrade): pytz in
>> /home/habibim/venv/lib/python2.7/site-packages (from -r
>> /projects/yocto-git/bitbake/toaster-requirements.txt (line 3))
>> Cleaning up...
>> (venv)habibim@bvm-poc8:/projects/yocto-git/build$ python --version
>> Python 2.7.6
>>
>> ...
>>
>>
>> (venv)habibim@bvm-poc8:/projects/yocto-git$ source oe-init-build-env
>>
>> ### Shell environment set up for builds. ###
>>
>> You can now run 'bitbake '
>>
>> Common targets are:
>> core-image-minimal
>> core-image-sato
>> meta-toolchain
>> meta-ide-support
>>
>> You can also run generated qemu images with a command like 'runqemu qemux86'
>> (venv)habibim@bvm-poc8:/projects/yocto-git/build$ source 
>> ../bitbake/bin/toaster
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> ImportError: No module named 'django'
>> This program needs Django>1.8,<1.9
>> Please install with pip install -r
>> /projects/yocto-git/bitbake/toaster-requirements.txt
>>
>> Am I going insane? I did some google-fu and people recommended
>> cleaning up manage.py, but those changes did not seem to affect this
>> outcome.
>
> Looks like python3 issue to me. You should install requirements with
> pip3 for python3 to be able to import them.
>
> You probably used old setup instructions. Please, read the latest manual here:
> http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-manual-setup-and-use
>
> Regards,
> Ed
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-oracle-java][BUG-REPORT

2016-08-24 Thread Maxin B. John 
Hi,

>On Wed, Aug 17, 2016 at 09:19:49AM -0400, Mark Schnell wrote:
>
>Good day;
>
> Short version:
>
>The ARM architecture for the meta-oracle-java layer still points to Java v7u60.
>
>  Long version:


 
Good catch. I missed that part while upgrading it. Will update it this week :)

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trying to run toaster off master, running into issues w/ django

2016-08-24 Thread Ed Bartosh 
On Tue, Aug 23, 2016 at 04:49:42PM -0500, Michael Habibi wrote:
> I am running the master branch and trying to run toaster to play
> around with the web interface (already successfully completed a build
> w/o toaster setup).
> 
> I followed the instructions in the documentation. I created a
> virtualenv, sourced/activated my virtualenv, and while under venv I
> did a pip install. It believes Django is installed, but I cannot run
> toaster. See below:
> 
> (venv)habibim@bvm-poc8:/projects/yocto-git/build$ pip install -r
> /projects/yocto-git/bitbake/toaster-requirements.txt
> Requirement already satisfied (use --upgrade to upgrade):
> Django>1.8,<1.9 in /home/habibim/venv/lib/python2.7/site-packages
> (from -r /projects/yocto-git/bitbake/toaster-requirements.txt (line
> 1))
> Requirement already satisfied (use --upgrade to upgrade):
> beautifulsoup4>=4.4.0 in
> /home/habibim/venv/lib/python2.7/site-packages (from -r
> /projects/yocto-git/bitbake/toaster-requirements.txt (line 2))
> Requirement already satisfied (use --upgrade to upgrade): pytz in
> /home/habibim/venv/lib/python2.7/site-packages (from -r
> /projects/yocto-git/bitbake/toaster-requirements.txt (line 3))
> Cleaning up...
> (venv)habibim@bvm-poc8:/projects/yocto-git/build$ python --version
> Python 2.7.6
> 
> ...
> 
> 
> (venv)habibim@bvm-poc8:/projects/yocto-git$ source oe-init-build-env
> 
> ### Shell environment set up for builds. ###
> 
> You can now run 'bitbake '
> 
> Common targets are:
> core-image-minimal
> core-image-sato
> meta-toolchain
> meta-ide-support
> 
> You can also run generated qemu images with a command like 'runqemu qemux86'
> (venv)habibim@bvm-poc8:/projects/yocto-git/build$ source 
> ../bitbake/bin/toaster
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named 'django'
> This program needs Django>1.8,<1.9
> Please install with pip install -r
> /projects/yocto-git/bitbake/toaster-requirements.txt
> 
> Am I going insane? I did some google-fu and people recommended
> cleaning up manage.py, but those changes did not seem to affect this
> outcome.

Looks like python3 issue to me. You should install requirements with
pip3 for python3 to be able to import them.

You probably used old setup instructions. Please, read the latest manual here:
http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-manual-setup-and-use

Regards,
Ed

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] packagegroup-core-selinux: add auditd support for audit log

2016-08-24 Thread Shrikant Bobade 
From: Shrikant Bobade 

this change provide dependency required by audit log file, to prepare it at
/var/log/audit/audit.log and get cleaner boot log.
without this change all avc denial messages mix with the boot log & it is
difficult for avc denial analysis.

Signed-off-by: Shrikant Bobade 
---
 recipes-security/packagegroups/packagegroup-core-selinux.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 9c74458..a0152a9 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -27,4 +27,5 @@ RDEPENDS_${PN} = " \
selinux-labeldev \
refpolicy \
coreutils \
+   auditd \
"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] profiling tools on a T4240RDB board

2016-08-24 Thread Tanasa Bogdan 
Hi,

We are using the (freescale) linux yocto 1.6 on a T4240RDB board where we want 
to have "tools-profile" set in our local.conf file. When building the 
fsl-image-minimal we see that there are some packages that are graphics-related 
(like gtk+, pixbuf, etc..). The card does not have any graphics capabilities. 
Why does these packets install at all? Is it possible to have the profiling 
tools without any gtk dependencies? How the local.conf should look like?

PS: These dependencies are there even when we choose tools-sdk in order to have 
gcc in the final image.

Thanks,
Bogdan.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Tuning for a machine based on Cortex-A9

2016-08-24 Thread Ottavio Campana 
Hello,

I am trying to port a third-party BSP based on buildroot to yocto, but I am not 
able to tune the compiler to extactly match the original one.

Particularly, if I run readelf on a binary compiled with the gcc that is used 
by buildroot I get this output

ottavio@ottavio:~$ readelf -A hello_world
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "Cortex-A9"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_CPU_unaligned_access: v6
  Tag_MPextension_use: Allowed
  Tag_Virtualization_use: TrustZone
ottavio@ottavio:~$

I tried to replicate this by configuring a new machine, and my machine 
configuration looks like this

require ../../../meta/conf/machine/include/tune-cortexa9.inc

AVAILTUNES += "cortexa9t-vfpv3-neon"
ARMPKGARCH_tune-cortexa9t-vfpv3-neon  = "cortexa9"
TUNE_FEATURES_tune-cortexa9t-vfpv3-neon   = 
"${TUNE_FEATURES_tune-armv7at-vfpv3} neon cortexa9"
PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at-vfpv3} cortexa9-vfp cortexa9-vfpv3 
cortexa9t2-vfp cortexa9t2-vfpv3 cortexa9-neon"

DEFAULTTUNE = "cortexa9t-vfpv3-neon"

If I run readelf on any compiled binary obtained with yocto, I get this result:

ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
 readelf -A .libs/bzip2
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "Cortex-A9"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_CPU_unaligned_access: v6
  Tag_MPextension_use: Allowed
  Tag_Virtualization_use: TrustZone
ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$

I am quite close to get a similar binary, the missing part is the 
Tag_Advanced_SIMD_arch: NEONv1 .  I get exactly the same result if I use 
DEFAULTTUNE = "cortexa9t-vfpv3", thus it seems that the neon and cortexa9-neon 
options I tried to add are ignored.

At this point I have two questions

Question #1

How should I change ARMPKGARCH_tune-cortexa9t-vfpv3-neon , 
TUNE_FEATURES_tune-cortexa9t-vfpv3-neon and 
PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon to have exactly the same kind of 
elf?

Question # 2

Why the only options for neon in meta/conf/machine/include/tune-cortexa9.inc 
are offered for HF tunes?


Thank you for your help

Ottavio
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto