[meta-freescale] [base][PATCH] setup-environment: Simplify use model for pre-existing build directory

2016-11-11 Thread Tom Hochstein 
The script setup-environment requires that MACHINE and DISTRO be set.
However, these variables are only used when creating a new build directory,
and they should not be required when using a pre-existing build directory.

Signed-off-by: Tom Hochstein 
---
 setup-environment | 48 ++--
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/setup-environment b/setup-environment
index a3eae7b..a04ffae 100755
--- a/setup-environment
+++ b/setup-environment
@@ -25,12 +25,21 @@ PROGNAME="setup-environment"
 
 usage()
 {
-echo -e "\nUsage:MACHINE= DISTRO= source $PROGNAME 

-: specifies the build directory location (required)
-:   specifies the machine name (required)
-:specifies the distro name (required)
-
-You must set \$MACHINE and \$DISTRO before setting up the environment.
+echo -e "
+Usage: MACHINE= DISTRO= source $PROGNAME 
+Usage:   source $PROGNAME 
+machine name
+ distro name
+  build directory
+
+The first usage is for creating a new build directory. In this case, the
+script creates the build directory , configures it for the
+specified  and , and prepares the calling shell for running
+bitbake on the build directory.
+
+The second usage is for using an existing build directory. In this case,
+the script prepares the calling shell for running bitbake on the build
+directory . The build directory configuration is unchanged.
 "
 
 ls sources/*/conf/machine/*.conf > /dev/null 2>&1
@@ -46,9 +55,14 @@ Supported Freescale's distros: `echo; ls 
sources/meta-freescale-distro/conf/dist
 Available Poky's distros: `echo; ls sources/poky/meta-poky/conf/distro/*.conf \
 | sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`
 
-To build for a machine and distro listed above, run this script as:
-MACHINE= DISTRO= source $PROGNAME 
-Ex: MACHINE=imx6qsabresd DISTRO=fslc-framebuffer source $PROGNAME build"
+Examples:
+
+- To create a new Yocto build directory:
+  $ MACHINE=imx6qsabresd DISTRO=fslc-framebuffer source $PROGNAME build
+
+- To use an existing Yocto build directory:
+  $ source $PROGNAME build
+"
 fi
 }
 
@@ -92,9 +106,15 @@ if [ "$(whoami)" = "root" ]; then
 echo "ERROR: do not use the BSP as root. Exiting..."
 fi
 
-if [ -z "$MACHINE" ]; then
+if [ ! -e $1/conf/local.conf.sample ]; then
+build_dir_setup_enabled="true"
+else
+build_dir_setup_enabled="false"
+fi
+
+if [ "$build_dir_setup_enabled" = "true" ] && [ -z "$MACHINE" ]; then
 usage
-echo -e "\nYou must set \$MACHINE before setting up the environment."
+echo -e "ERROR: You must set MACHINE when creating a new build directory."
 clean_up
 return 1
 fi
@@ -103,9 +123,9 @@ if [ -z "$SDKMACHINE" ]; then
 SDKMACHINE='i686'
 fi
 
-if [ -z "$DISTRO" ]; then
+if [ "$build_dir_setup_enabled" = "true" ] && [ -z "$DISTRO" ]; then
 usage
-echo -e "\nYou must set \$DISTRO before setting up the environment."
+echo -e "ERROR: You must set DISTRO when creating a new build directory."
 clean_up
 return 1
 fi
@@ -146,7 +166,7 @@ fi
 export PATH="`echo $PATH | sed 's/\(:.\|:\)*:/:/g;s/^.\?://;s/:.\?$//'`"
 
 generated_config=
-if [ ! -e conf/local.conf.sample ]; then
+if [ "$build_dir_setup_enabled" = "true" ]; then
 mv conf/local.conf conf/local.conf.sample
 
 # Generate the local.conf based on the Yocto defaults
-- 
1.9.1

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

[meta-freescale] Freescale Yocto Question - Building imx6dl-riotboard

2016-11-11 Thread Eric.Zaluzec 
Greeting,
I have a quick question concerning the imx6dl-riotboard machine configuration 
file, maintained by the Yocto Freescale community.
We have an upcoming project for which we are considering a i.MX6 Dual Lite 
processor. But since there are no Dual Lite evaluation boards, at this time, we 
were provided an i.mx6 solo RIoTboard to use for initial testing, by Avnet and 
NXP distributors.

First off, thank you for providing up-to-date Yocto build repositories and 
documentation! This makes kicking-off a new Yocto BSP Project much simpler! 
Cheers.
I read the Freescale Yocto User Guide here:
http://www.bcmcom.com/CustomerDL/AR6MX/Yocto/Freescale_Yocto_Project_User's_Guide.pdf
I then read the  RIoTboard Yocto build guide here:
https://www.element14.com/community/community/designcenter/single-board-computers/riotboard/blog/2014/09/22/riotboard-yocto-part1-getting-started
Using both resources, I successfully built a Yocto image and was able to 
install onto my RIoTboard.


Now, using Yocto, I would like to build a RIoTboard image with a fido or 
krogoth branch of Yocto, to make use of the updated packages & bitbake recipes, 
like boost and java, These versions are dependencies to my metadata layer's 
packages.
I went to the fsl-arm-yocto-bsp git repository site and found the 
imx-4.1-krogoth branch:
http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/?h=imx-4.1-krogoth

I followed the User Guide steps, but this time cloned the imx-4.1-krogoth 
branch. I noticed the riotboard.conf machine configuration file no longer 
existed, but a imx6dl-riotboard machine was present in the meta-fsl-arm-extra & 
meta-freescale-3rdparty metadata layers. I successfully built an image with 
this machine conf file, but then realized that it was 'dl' (Dual Lite?) and 
would not boot with the solo RIoTboard that I was using.

Question :
Are there any branches on for the fsl-arm-yocto-bsp repository that are 
fido/jethro/krogoth compatible, that include the riotboard solo machine 
configuration file?
http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git
If not, is it possible for users, like me, to base a riotboard solo machine 
conf file off the imx6dl-riotboard machine and create a successful BSP image? 
Or are these unavoidable conflicts?

The critical piece here is not necessarily having a v4.1 kernel but just the 
use of the updated package recipes & the dependency to custom packages trying 
to be installed & tested on the riotboard!

Any help, suggestions, or feedback would greatly be appreciated! Right now I am 
just tinkering with learning about the riotboard machine conf file to see if I 
can port it to the imx-4.1-krogoth branch.

Thanks!
-Eric Zaluzec
(eric.zalu...@emerson.com)

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

[meta-freescale] [3rdparty][PATCH 2/2] linux-congatec: Bump revision to 311e836f

2016-11-11 Thread Fabio Berton 
Apply the following changes:

  - 311e836 CGT16 UMX6/QMX6: remove revision check of EXT CSD
  - 72b7310 CGT15 QMX6/UMX6: fix Q7 SUS_S3# signal handling
  - 7282208 CGT14 UMX6: add conga-UMX6 default configuration
  - 1a37041 CGT13 UMX6: add conga-UMX6 device tree configuration
  - 071278e CGT012 QMX6: improve QMX6 reset/reboot behaviour, fix

Signed-off-by: Fabio Berton 
---
 recipes-kernel/linux/linux-congatec_3.14.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-congatec_3.14.bb 
b/recipes-kernel/linux/linux-congatec_3.14.bb
index 6c05594..997b3be 100644
--- a/recipes-kernel/linux/linux-congatec_3.14.bb
+++ b/recipes-kernel/linux/linux-congatec_3.14.bb
@@ -13,7 +13,7 @@ SRC_URI = 
"git://git.congatec.com/arm/imx6_kernel_3.14.git;protocol=http;branch=
file://Fix-the-compile-issue-under-gcc6.patch \
file://defconfig"
 
-SRCREV = "f5eee0b0b67b3021676dc9fd47cf95e1dd88b749"
+SRCREV = "311e836f22da59ba682f05973f2a138cd9eececa"
 LOCALVERSION = "-1.0.x-mx6-qmx6"
 
 
-- 
2.1.4

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

[meta-freescale] [3rdparty][PATCH 1/2] linux-congatec: Add patch to fix compile issue under gcc6

2016-11-11 Thread Fabio Berton 
Signed-off-by: Fabio Berton 
---
 .../Fix-the-compile-issue-under-gcc6.patch | 92 ++
 recipes-kernel/linux/linux-congatec_3.14.bb|  1 +
 2 files changed, 93 insertions(+)
 create mode 100644 
recipes-kernel/linux/linux-congatec-3.14/Fix-the-compile-issue-under-gcc6.patch

diff --git 
a/recipes-kernel/linux/linux-congatec-3.14/Fix-the-compile-issue-under-gcc6.patch
 
b/recipes-kernel/linux/linux-congatec-3.14/Fix-the-compile-issue-under-gcc6.patch
new file mode 100644
index 000..3d080b6
--- /dev/null
+++ 
b/recipes-kernel/linux/linux-congatec-3.14/Fix-the-compile-issue-under-gcc6.patch
@@ -0,0 +1,92 @@
+From 5d39bd421fc093e2c852316080538cef85a9e1a0 Mon Sep 17 00:00:00 2001
+From: yocto 
+Date: Thu, 2 Jun 2016 00:18:33 -0500
+Subject: [PATCH] Fix the compile issue under gcc6
+
+Fix the following build error:
+| .../include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc6.h: 
No such file or directory
+| #include gcc_header(__GNUC__)
+
+Signed-off-by: Zhenhua Luo 
+
+Upstream-Status: Pending
+---
+ include/linux/compiler-gcc6.h | 66 +++
+ 1 file changed, 66 insertions(+)
+ create mode 100644 include/linux/compiler-gcc6.h
+
+diff --git a/include/linux/compiler-gcc6.h b/include/linux/compiler-gcc6.h
+new file mode 100644
+index 000..cdd1cc2
+--- /dev/null
 b/include/linux/compiler-gcc6.h
+@@ -0,0 +1,66 @@
++#ifndef __LINUX_COMPILER_H
++#error "Please don't include  directly, include 
 instead."
++#endif
++
++#define __used__attribute__((__used__))
++#define __must_check  __attribute__((warn_unused_result))
++#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
++
++/* Mark functions as cold. gcc will assume any path leading to a call
++   to them will be unlikely.  This means a lot of manual unlikely()s
++   are unnecessary now for any paths leading to the usual suspects
++   like BUG(), printk(), panic() etc. [but let's keep them for now for
++   older compilers]
++
++   Early snapshots of gcc 4.3 don't support this and we can't detect this
++   in the preprocessor, but we can live with this because they're unreleased.
++   Maketime probing would be overkill here.
++
++   gcc also has a __attribute__((__hot__)) to move hot functions into
++   a special section, but I don't see any sense in this right now in
++   the kernel context */
++#define __cold__attribute__((__cold__))
++
++#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), 
__COUNTER__)
++
++#ifndef __CHECKER__
++# define __compiletime_warning(message) __attribute__((warning(message)))
++# define __compiletime_error(message) __attribute__((error(message)))
++#endif /* __CHECKER__ */
++
++/*
++ * Mark a position in code as unreachable.  This can be used to
++ * suppress control flow warnings after asm blocks that transfer
++ * control elsewhere.
++ *
++ * Early snapshots of gcc 4.5 don't support this and we can't detect
++ * this in the preprocessor, but we can live with this because they're
++ * unreleased.  Really, we need to have autoconf for the kernel.
++ */
++#define unreachable() __builtin_unreachable()
++
++/* Mark a function definition as prohibited from being cloned. */
++#define __noclone __attribute__((__noclone__))
++
++/*
++ * Tell the optimizer that something else uses this function or variable.
++ */
++#define __visible __attribute__((externally_visible))
++
++/*
++ * GCC 'asm goto' miscompiles certain code sequences:
++ *
++ *   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
++ *
++ * Work it around via a compiler barrier quirk suggested by Jakub Jelinek.
++ * Fixed in GCC 4.8.2 and later versions.
++ *
++ * (asm goto is automatically volatile - the naming reflects this.)
++ */
++#define asm_volatile_goto(x...)   do { asm goto(x); asm (""); } while (0)
++
++#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
++#define __HAVE_BUILTIN_BSWAP32__
++#define __HAVE_BUILTIN_BSWAP64__
++#define __HAVE_BUILTIN_BSWAP16__
++#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
+-- 
+2.5.0
+
diff --git a/recipes-kernel/linux/linux-congatec_3.14.bb 
b/recipes-kernel/linux/linux-congatec_3.14.bb
index 54fe6ae..6c05594 100644
--- a/recipes-kernel/linux/linux-congatec_3.14.bb
+++ b/recipes-kernel/linux/linux-congatec_3.14.bb
@@ -10,6 +10,7 @@ DEPENDS += "lzop-native bc-native"
 SRCBRANCH = "cgt_qmx6_3.14-1.0.x-mx6_1.0.0"
 
 SRC_URI = 
"git://git.congatec.com/arm/imx6_kernel_3.14.git;protocol=http;branch=${SRCBRANCH}
 \
+   file://Fix-the-compile-issue-under-gcc6.patch \
file://defconfig"
 
 SRCREV = "f5eee0b0b67b3021676dc9fd47cf95e1dd88b749"
-- 
2.1.4

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

Re: [meta-freescale] [Documentation][PATCH 1/5] scripts: Update to version 2.2 (Morty)

2016-11-11 Thread Daiane Angolini 
On Fri, Nov 11, 2016 at 1:22 PM, Otavio Salvador
 wrote:
> On Fri, Nov 11, 2016 at 12:47 PM, Daiane Angolini  
> wrote:
>> Does anyone use or have used those documentations? What do you think
>> about eliminating all documentes but Release Notes?
>
> I am fine in reducing the documents we maintain; we can check if any
> section of user guide should be moved to the Release Notes otherwise
> we can merge this patchset and remove the docs next.

That was what I was planning. Merge the patchset and then work to
reduce the documentation.

I'm going to push this patchset merge this afternoon.

Daiane
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-freescale] [Documentation][PATCH 1/5] scripts: Update to version 2.2 (Morty)

2016-11-11 Thread Otavio Salvador 
On Fri, Nov 11, 2016 at 12:47 PM, Daiane Angolini  wrote:
> Does anyone use or have used those documentations? What do you think
> about eliminating all documentes but Release Notes?

I am fine in reducing the documents we maintain; we can check if any
section of user guide should be moved to the Release Notes otherwise
we can merge this patchset and remove the docs next.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-freescale] [Documentation][PATCH 1/5] scripts: Update to version 2.2 (Morty)

2016-11-11 Thread Daiane Angolini 
The patchset looks good to me. However it made me think about the
reason why we are maintaining documentation we don't use such as FAQ
and User Guide.

Maybe it's better just remove it.


Does anyone use or have used those documentations? What do you think
about eliminating all documentes but Release Notes?


Daiane

On Wed, Nov 9, 2016 at 3:30 PM, Fabio Berton
 wrote:
>   - Update FSL layers names
>   - Add DISTRO and MACHINE to run setup-environment
>   - Update Yocto Project Bugzilla url address
>
> Signed-off-by: Fabio Berton 
> ---
>  scripts/bitbake-metadata2doc.py | 18 +-
>  scripts/bitbake-metadata2doc.sh |  6 +++---
>  scripts/generate-bugs-table.py  |  6 +++---
>  scripts/output-machine-list |  2 +-
>  scripts/test-sheet-parser.py|  2 +-
>  5 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/scripts/bitbake-metadata2doc.py b/scripts/bitbake-metadata2doc.py
> index 98af3f8..001d59d 100644
> --- a/scripts/bitbake-metadata2doc.py
> +++ b/scripts/bitbake-metadata2doc.py
> @@ -112,8 +112,8 @@ def write_fsl_community_bsp_supported_kernels(data, 
> out_dir):
>  kernel = board_data['recipes']['virtual/kernel']
>  recipe = kernel['recipe']
>  recipe_file = kernel['file']
> -if (('/sources/meta-fsl-arm/' in recipe_file) or \
> -('/sources/meta-fsl-arm-extra/' in recipe_file)) and \
> +if (('/sources/meta-freescale/' in recipe_file) or \
> +('/sources/meta-freescale-3rdparty/' in recipe_file)) and \
>  recipe not in kernel_recipes:
>  kernels += [[recipe, kernel['description']]]
>  kernel_recipes.append(recipe)
> @@ -128,8 +128,8 @@ def 
> write_fsl_community_bsp_supported_bootloaders_descr(data, out_dir):
>  bootloader = board_data['recipes'][bootloader_software]
>  recipe = bootloader['recipe']
>  recipe_file = bootloader['file']
> -if (('/sources/meta-fsl-arm/' in recipe_file) or \
> -('/sources/meta-fsl-arm-extra/' in recipe_file)) and 
> \
> +if (('/sources/meta-freescale/' in recipe_file) or \
> +('/sources/meta-freescale-3rdparty/' in 
> recipe_file)) and \
>  recipe not in bootloader_recipes:
>  bootloaders += [[recipe, bootloader['description']]]
>  bootloader_recipes.append(recipe)
> @@ -305,14 +305,14 @@ def write_soc_pkg(data, out_dir):
>
>
>  def write_maintainers_tables(data, out_dir, bsp_dir):
> -meta_fsl_arm_machines_dir = os.path.join(bsp_dir, 'sources', 
> 'meta-fsl-arm', 'conf', 'machine')
> -meta_fsl_arm_extra_machines_dir = os.path.join(bsp_dir, 'sources', 
> 'meta-fsl-arm-extra', 'conf', 'machine')
> -get_maintainer_script = os.path.join(bsp_dir, 'sources', 'meta-fsl-arm', 
> 'scripts', 'get-maintainer')
> +meta_freescale_machines_dir = os.path.join(bsp_dir, 'sources', 
> 'meta-freescale', 'conf', 'machine')
> +meta_freescale_3rdparty_machines_dir = os.path.join(bsp_dir, 'sources', 
> 'meta-freescale-3rdparty', 'conf', 'machine')
> +get_maintainer_script = os.path.join(bsp_dir, 'sources', 
> 'meta-freescale', 'scripts', 'get-maintainer')
>  try:
>  get_maintainer_pipe = subprocess.Popen([get_maintainer_script,
>  '--dump',
> -meta_fsl_arm_machines_dir,
> -
> meta_fsl_arm_extra_machines_dir],
> +meta_freescale_machines_dir,
> +
> meta_freescale_3rdparty_machines_dir],
> stdout=subprocess.PIPE)
>  except OSError:
>  error('Could not run the get-maintainer script (attempted %s)' % 
> (get_maintainer_script,))
> diff --git a/scripts/bitbake-metadata2doc.sh b/scripts/bitbake-metadata2doc.sh
> index 3616fe1..775e26d 100755
> --- a/scripts/bitbake-metadata2doc.sh
> +++ b/scripts/bitbake-metadata2doc.sh
> @@ -46,7 +46,7 @@ gitdm_dir="$2"
>  start_commit="$3"
>  end_commit="$4"
>  anchor="`pwd`"
> -fsl_layers="meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos"
> +fsl_layers="meta-freescale meta-freescale-3rdparty meta-freescale-distro"
>
>  machines=
>  if [ -n "$MACHINES" ]; then
> @@ -80,9 +80,9 @@ build_dir=`mktemp -d --tmpdir=$yocto_dir`
>  for machine in $machines; do
>  cd $yocto_dir
>  echo "Using $build_dir as build directory"
> -MACHINE=$machine . ./setup-environment `basename $build_dir`
> +MACHINE=$machine DISTRO=fslc-framebuffer . ./setup-environment `basename 
> $build_dir`
>
> -MACHINE=$machine python3 $anchor/extract-bitbake-metadata.py \
> +MACHINE=$machine DISTRO=fslc-framebuffer python3 
> $anchor/extract-bitbake-metadata.py \
>  $anchor/$marshalled_data_file \
>  apptrk \

Re: [meta-freescale] [3rdparty][PATCH 1/2] linux-wandboard: Add patch to fix build error with gcc6

2016-11-11 Thread Otavio Salvador 
On Fri, Nov 11, 2016 at 11:06 AM, Dominic Sacré  wrote:
> On 2016-11-11 11:24, Otavio Salvador wrote:
>> On Thu, Nov 10, 2016 at 12:23 PM, Dominic Sacré  wrote:
>>> Without this patch, gcc6 fails to build the Vivante driver with
>>> -Werror=misleading-indentation.
>>>
>>> Signed-off-by: Dominic Sacré 
>>
>> There is any reason why you are not using the external kernel module?
>
> I was working on linux-wandboard-rt when I noticed this build failure.
> Am I right in assuming that the external module still doesn't support RT
> kernels?
>
> As for linux-wandboard itself, I see no particular reason not to use the
> external kernel module.

Yes; however if there is a way to detect the presence of RT patch and
act accordingly. We can patch the source of the external module to
cope with this...

Is it possible for you to try to do that? If so, please see:
https://github.com/Freescale/kernel-module-imx-gpu-viv

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-freescale] [3rdparty][PATCH 1/2] linux-wandboard: Add patch to fix build error with gcc6

2016-11-11 Thread Dominic Sacré 
On 2016-11-11 11:24, Otavio Salvador wrote:
> On Thu, Nov 10, 2016 at 12:23 PM, Dominic Sacré  wrote:
>> Without this patch, gcc6 fails to build the Vivante driver with
>> -Werror=misleading-indentation.
>>
>> Signed-off-by: Dominic Sacré 
> 
> There is any reason why you are not using the external kernel module?

I was working on linux-wandboard-rt when I noticed this build failure.
Am I right in assuming that the external module still doesn't support RT
kernels?

As for linux-wandboard itself, I see no particular reason not to use the
external kernel module.


Dominic
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-freescale] is git.freescale.com down?

2016-11-11 Thread Lauren Post 
Should be working - it was not down just slow which caused the fetch to timeout.

-Original Message-
From: meta-freescale-boun...@yoctoproject.org 
[mailto:meta-freescale-boun...@yoctoproject.org] On Behalf Of Otavio Salvador
Sent: Thursday, November 10, 2016 6:24 AM
To: Christian Ege 
Cc: meta-freescale 
Subject: Re: [meta-freescale] is git.freescale.com down?

On Thu, Nov 10, 2016 at 10:01 AM, Christian Ege  wrote:
> it looks like the Freescale (NXP) public git is down. This is for 
> example used in
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2FFreescale%2Fmeta-freescale%2Fblob%2Fc663fed590b3dd5c0f43e0bb
> d1a457a61a488a0e%2Frecipes-bsp%2Ffirmware-imx%2Ffirmware-imx.inc&data=
> 01%7C01%7Clauren.post%40nxp.com%7Ce91446f9c6a24afa736a08d409649ddf%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=r3GV%2FxYZ1d%2FfmoEYaApLF0%2
> FB2hsERVZri8o5r%2B%2Ft2%2Bo%3D&reserved=0
>
> Will it recover or will they move?

This is likely due the NXP merge ongoing; I notified some people about it and 
asked for it to be fixed.

Thanks for letting us know.

-- 
Otavio Salvador O.S. Systems
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ossystems.com.br&data=01%7C01%7Clauren.post%40nxp.com%7Ce91446f9c6a24afa736a08d409649ddf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=206WLMpJXPrSHGLKcg6%2BkJ9GaDExrD667entviIMLz8%3D&reserved=0

https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.ossystems.com.br&data=01%7C01%7Clauren.post%40nxp.com%7Ce91446f9c6a24afa736a08d409649ddf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=5GzWTU9NGdwz28nk7nxSShqpyZ1HAHwytjKLnjZVS68%3D&reserved=0
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fmeta-freescale&data=01%7C01%7Clauren.post%40nxp.com%7Ce91446f9c6a24afa736a08d409649ddf%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=y38qtt1WodH7T6iCncWUkCp1FV%2FasCC%2FN9DTIWOL19U%3D&reserved=0
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-freescale] [3rdparty][PATCH 1/2] linux-wandboard: Add patch to fix build error with gcc6

2016-11-11 Thread Otavio Salvador 
On Thu, Nov 10, 2016 at 12:23 PM, Dominic Sacré  wrote:
> Without this patch, gcc6 fails to build the Vivante driver with
> -Werror=misleading-indentation.
>
> Signed-off-by: Dominic Sacré 

There is any reason why you are not using the external kernel module?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale