[meta-freescale] Updates to meta-freescale (master) in 2017-07-13

2017-07-13 Thread otavio . salvador 
Hello,

I pushed following updates:

commit b5c351ee708053fbc3f29d3b54c011f63d6a5319 (HEAD -> pending, 
yocto/master-next, yocto/master)
Author: Otavio Salvador 
Date:   Mon Jul 10 12:04:58 2017 -0300

u-boot-fslc: Upgrade to 2017.07-based release

This release provides a huge improvement regarding the support for SPL
to more boards.

We now uses this and migrated following boards:

 - imx6qpsabresd -> imx6qdlsabresd
 - imx6qsabresd -> imx6qdlsabresd
 - imx6dlsabresd -> imx6qdlsabresd
 - imx6solosabresd -> imx6qdlsabresd
 - imx6qpsabreauto -> imx6qdlsabreauto
 - imx6qsabreauto -> imx6qdlsabreauto
 - imx6dlsabreauto -> imx6qdlsabreauto
 - imx6solosabreauto -> imx6qdlsabreauto

So now, the 8 boards are covered by 2 machine files. This drastically
reduces the build time and allow for a better user experience as we
can use the same image to test different boards.

In summary an image built for imx6qdlsabresd or imx6qdlsabreauto is
capable of run on a its respective board which contains a i.MX6
QuadPlus, Quad, Dual, DualLite or Solo SoC removing the need of a
specific image for each SoC type.

On top of the official 2017.07 release, following patches are
included:

801fd44563 mx6sabreauto: Make Ethernet functional again
8ccb1970b8 wandboard: Set fdt based on board_rev and board_name
e6605743e5 mx6sabresd: Enable video interfaces in bootargs
e50a2475d4 mx6sabresd: Use LDO dtb file until LDO bypass support is added
b1a4715311 mx6slevk: Use LDO dtb file until LDO bypass support is added
957409876b imx: cx9020: try pxe boot, if no vmlinuz on mmc
3608315bf1 imx: cx9020: use fdt_addr_r and ramdisk_addr_r
9a1c960516 mx6sabreauto: Add Falcon mode support
3a279e5fe8 warp: Use PARTUUID to specify the rootfs location
0f9a6703e7 embestmx6boards: Use PARTUUID to specify the rootfs location
c877510614 mx6cuboxi: Use PARTUUID to specify the rootfs location
0ada2d6caf wandboard: Use PARTUUID to specify the rootfs location
eee442362c mx6sabre: Use PARTUUID to specify the rootfs location
80a56615fa mx6sabreauto: Do not enable WEIM by default
321339efd7 imx: reorganize IMX code as other SOCs
1567ce3edc mmc: fsl_esdhc: drop CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
40294f880d dm: mmc: fsl_esdhc: handle vqmmc supply
0378edcd02 mmc: fsl_esdhc: introduce vs18_enable for 1.8V fix I/O
3657cae890 mmc: fsl_esdhc: correct type of wp_enable
45103e1030 imx6_spl: Add u-boot-dtb.img for SPL payload
61131fa4b5 mx6sabreauto: Update to SPL only mode
07a667be9b mx6qsabreauto: Add SPL support
4506c859ee mx6cuboxi: Add support for sata
a5c5962327 mx7dsabresd: Set VLD04 output to 2.8V in PMIC initialization.
4590f11b61 mx6: soc: Move mxs_dma_init() into the mxs nand driver
10d185960e net: fec_mxc: fix PHY initialization bug with CONFIG_DM_ETH
b2d4bf303e icorem6_rqs: Rename icorem6_rqs config file
af34708e1e dt-bindings: Document the Broadcom STB wake-up timer node
3e92667cfe serial: mxc: Add debug uart support
4e2b31a5c5 serial: mxc: Code cleanup
27835dae1a serial: mxc: Move common baud gen into _mxc_serial_setbrg
1ca9fe11fd serial: mxc: Move common init into _mxc_serial_init
14ac9d06be serial: mxc: Move cr1 and cr2 write to mxc_serial_setbrg
fdd1f0debc serial: mxc: Use RFDIV in dm-code
fd008b0569 serial: mxc: Add common mxc_uart reg space
2fd7878124 imx: mx6ull: fix USB bmode for i.MX 6UL and 6ULL
5c72de6152 ot1200: enable CONFIG_IMX_THERMAL for detailed thermal 
information
8e38f54c56 mx6sabresd: Fix guard file symbol
3320a872b0 wandboard: Remove unnecessary delay
d5ae3ce6dd cm_fx6: Remove SPL entry from CONFIG_SYS_EXTRA_OPTIONS
1325b822da cgtqmx6eval: Remove SPL entry from CONFIG_SYS_EXTRA_OPTIONS
844365a5a0 mx6slevk_spl: Remove SPL entry from CONFIG_SYS_EXTRA_OPTIONS
ff9e6d62ed mx6sabresd: Remove SPL entry from CONFIG_SYS_EXTRA_OPTIONS

Signed-off-by: Otavio Salvador 
Acked-by: Daiane Angolini 
Signed-off-by: Otavio Salvador 

commit c3a6be93645711d4a60267c7911b8676ecbef6e3
Author: Otavio Salvador 
Date:   Tue Jul 11 14:59:53 2017 -0300

linux-fslc-imx: Bump to 300a765 revision

This merges the 4.1.15 2.1.0 GA release as well as the 4.1.42 stable
release.

Signed-off-by: Otavio Salvador 

commit 63985dc4a6fdbbc2fe53b289a5484110ee6f1d81
Author: Otavio Salvador 
Date:   Mon Jul 10 12:01:12 2017 -0300

alsa-lib: Ensure MACHINE_SOCARCH is used consistently

The alsa-lib needs to apply the patches for all i.MX SoCs so using the
'imx' override seems to be the best choice for this specific
use-case.

A missing aspect though was that this

Re: [meta-freescale] building core-image-minimalfort1042d4rdb*failsbuilding hypervisor

2017-07-13 Thread Robert P. J. Day 
On Thu, 13 Jul 2017, Zhenhua Luo wrote:

> Hi Robert,
>
> The patch is submitted to fix the hypervisor build issue.
> https://patchwork.openembedded.org/patch/141881/.
>
> The hypervisor is a layer of software that enables the efficient and
> secure partitioning of a multicore system. A system's CPUs, memory,
> and I/O devices can be divided into groupings or partitions, as
> shown in the figure below. Each partition is capable of executing a
> guest operating system. For more details, you can refer to the QorIQ
> SDK document which is available in http://tinyurl.com/ya57eeol.

  oh, i know what a hypervisor *is*, i'm just asking whether it's
*necessary* to simply get a bootable system for a t1042d4rdb target.
since it's selected via EXTRA_IMAGEDEPENDS, the impression i get is
that it's optional. or am i misunderstanding something?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [meta-freescale] building core-image-minimalfort1042d4rdb*failsbuilding hypervisor

2017-07-13 Thread Zhenhua Luo 
Hypervisor is not necessary to boot the t1042d4rdb board. 


Best Regards, 

Zhenhua

> -Original Message-
> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> Sent: Friday, July 14, 2017 2:41 AM
> To: Zhenhua Luo 
> Cc: Kursad Oney CW ; meta-freescale@yoctoproject.org;
> C.r. Guo 
> Subject: RE: [meta-freescale] building core-image-
> minimalfort1042d4rdb*failsbuilding hypervisor
> 
> On Thu, 13 Jul 2017, Zhenhua Luo wrote:
> 
> > Hi Robert,
> >
> > The patch is submitted to fix the hypervisor build issue.
> > https://patchwork.openembedded.org/patch/141881/.
> >
> > The hypervisor is a layer of software that enables the efficient and
> > secure partitioning of a multicore system. A system's CPUs, memory,
> > and I/O devices can be divided into groupings or partitions, as shown
> > in the figure below. Each partition is capable of executing a guest
> > operating system. For more details, you can refer to the QorIQ SDK
> > document which is available in http://tinyurl.com/ya57eeol.
> 
>   oh, i know what a hypervisor *is*, i'm just asking whether it's
> *necessary* to simply get a bootable system for a t1042d4rdb target.
> since it's selected via EXTRA_IMAGEDEPENDS, the impression i get is that it's
> optional. or am i misunderstanding something?
> 
> rday
> 
> --
> 
> =
> ===
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> =
> ===
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [meta-freescale] building core-image-minimalfort1042d4rdb*failsbuilding hypervisor

2017-07-13 Thread Zhenhua Luo 
Hi Robert, 

The patch is submitted to fix the hypervisor build issue. 
https://patchwork.openembedded.org/patch/141881/. 

The hypervisor is a layer of software that enables the efficient and secure 
partitioning of a multicore system. A system's CPUs, memory, and I/O devices 
can be divided into groupings or partitions, as shown in the figure below. Each 
partition is capable of executing a guest operating system. For more details, 
you can refer to the QorIQ SDK document which is available in 
http://tinyurl.com/ya57eeol. 


Best Regards, 

Zhenhua

> -Original Message-
> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> Sent: Thursday, July 13, 2017 5:48 AM
> To: Zhenhua Luo 
> Cc: Kursad Oney CW ; meta-freescale@yoctoproject.org;
> C.r. Guo 
> Subject: RE: [meta-freescale] building core-image-
> minimalfort1042d4rdb*failsbuilding hypervisor
> 
> On Tue, 11 Jul 2017, Zhenhua Luo wrote:
> 
> > Hi all,
> >
> > We will take a look the issue and fix it ASAP.
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> > > -Original Message-
> > > From: meta-freescale-boun...@yoctoproject.org
> > > [mailto:meta-freescale- boun...@yoctoproject.org] On Behalf Of
> > > Kursad Oney CW
> > > Sent: Sunday, July 09, 2017 11:24 PM
> > > To: Robert P. J. Day 
> > > Cc: meta-freescale@yoctoproject.org
> > > Subject: Re: [meta-freescale] building core-image-
> > > minimalfort1042d4rdb*failsbuilding hypervisor
> > >
> > > Robert,
> > >
> > > >
> > > > > Robert,
> > > > >
> > > > > >   to make a long story (hopefully) short, i was trying to
> > > > > > build both the 32- and 64-bit versions of t1042d4rdb, and both
> > > > > > failed in exactly the same place, trying to build the
> > > > > > hypervisor recipe, so i'm open to suggestions (this is on a 
> > > > > > fully-updated
> fedora system):
> > > > > >
> > > > > > [...truncated...]
> > > > > > | /home/rpjday/oe/builds/t1042d4rdb-64b/tmp/work/ppc64e5500-po
> > > > > > | ky-
> > > linux/hypervisor/git-r3/git/libos/lib/sprintf.c: In function 'sprintf':
> > > > > > | /home/rpjday/oe/builds/t1042d4rdb-64b/tmp/work/ppc64e5500-po
> > > > > > | ky-
> > > linux/hypervisor/git-r3/git/libos/lib/sprintf.c:459:6: error:
> > > specified bound
> > > 18446744073709551615 exceeds maximum object size
> 9223372036854775807
> > > [-Werror=format-truncation=]
> > > > > > |   int ret = vsnprintf(buf, ULONG_MAX, str, args);
> > > > > > |   ^~~
> > > > > > | cc1: all warnings being treated as errors
> > > > >
> > > > > I think gcc is complaining about ULONG_MAX being the size argument.
> > > > > Since vsnprintf() returns int, it can print at most LONG_MAX
> > > > > characters to the buffer. I'd probably just change that argument
> > > > > to
> > > LONG_MAX.
> > > > >
> > > > > I believe the format-truncation flag is a gcc 7 thing.
> > > >
> > > >   i suspected as much, but i'm curious as to why this error still
> > > > exists, and wasn't flagged by regular build testing. i don't just
> > > > want to hack the code without hearing from others as to why this
> > > > issue exists.
> > >
> > > To take a wild guess, I would say the yocto version you are using
> > > probably upgraded to gcc 7 where this new flag became a default for
> > > -Werror. If you try an older branch or just use the recipe for gcc 6, the
> warning might go away.
> > >
> > > That said the DNG team at NXP would be the definite authority on this.
> 
>   while fixing that hypervisor compile error, here's probably a dumb question 
> ...
> what do i need the hypervisor for, anyway? since it's listed in
> EXTRA_IMAGEDEPENDS, i can clearly temporarily remove it to get a build. as i'm
> new to this target and processor, what's it for?
> 
> rday
> 
> --
> 
> =
> ===
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> =
> ===
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

[meta-freescale] [PATCH] hypervisor:fix build error with gcc7

2017-07-13 Thread Chunrong Guo 
From: Chunrong Guo 

Signed-off-by: Chunrong Guo 
---
 .../files/0001-fix-build-error-gcc7.patch  | 40 ++
 .../hypervisor/hypervisor_git.bb   |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 
recipes-virtualization/hypervisor/files/0001-fix-build-error-gcc7.patch

diff --git 
a/recipes-virtualization/hypervisor/files/0001-fix-build-error-gcc7.patch 
b/recipes-virtualization/hypervisor/files/0001-fix-build-error-gcc7.patch
new file mode 100644
index 000..1100ab6
--- /dev/null
+++ b/recipes-virtualization/hypervisor/files/0001-fix-build-error-gcc7.patch
@@ -0,0 +1,40 @@
+From 51f545b9c16f6a371c129bd0fbb9c7f7ae339df3 Mon Sep 17 00:00:00 2001
+From: Chunrong Guo 
+Date: Thu, 13 Jul 2017 13:59:28 +0800
+Subject: [PATCH] fix build  error gcc7
+
+
+Upstream-Status: Pending
+
+---
+ Makefile.build | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile.build b/Makefile.build
+index e93cc9a..f6028fe 100644
+--- a/Makefile.build
 b/Makefile.build
+@@ -35,7 +35,8 @@ GENASSYM=$(libos)lib/genassym.sh
+ 
+ export libos := $(src)libos/
+ 
+-export CC=$(CROSS_COMPILE)gcc
++
++
+ 
+ export GCCINCDIR := $(shell $(CC) -print-file-name=include)
+ CC_OPTS=-Wa,-m$(CONFIG_GCC_CPU_FLAG) -nostdinc -I $(GCCINCDIR) -I 
$(GCCINCDIR)-fixed \
+@@ -46,8 +47,8 @@ CC_OPTS=-Wa,-m$(CONFIG_GCC_CPU_FLAG) -nostdinc -I 
$(GCCINCDIR) -I $(GCCINCDIR)-f
+ export CC_OPTS_NODEP := -include include/config/autoconf.h
+ 
+ export WARNINGS := -Wwrite-strings -Wmissing-prototypes \
+-   -Wstrict-prototypes -Wold-style-definition \
+-   -Wmissing-declarations
++   -Wstrict-prototypes -Wold-style-definition 
-Wno-format-truncation \
++   -Wmissing-declarations 
+ 
+ # Our code should build without any of these warnings, but some
+ # external code may be excluded.
+-- 
+2.7.4
+
diff --git a/recipes-virtualization/hypervisor/hypervisor_git.bb 
b/recipes-virtualization/hypervisor/hypervisor_git.bb
index 90cdf2b..bf904e0 100644
--- a/recipes-virtualization/hypervisor/hypervisor_git.bb
+++ b/recipes-virtualization/hypervisor/hypervisor_git.bb
@@ -17,6 +17,7 @@ SRC_URI = " \
git://git.kernel.org/pub/scm/utils/dtc/dtc.git;name=dtc;destsuffix=dtc \

git://git.freescale.com/ppc/sdk/hypertrk.git;name=hypertrk;destsuffix=git/hypertrk;branch=sdk-v2.0.x
 \
file://81-fsl-embedded-hv.rules \
+file://0001-fix-build-error-gcc7.patch \
  "
 
 SRCREV_FORMAT="hypervisor"
-- 
1.9.0

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

Re: [meta-freescale] is meta-fsl-ppc layer even used anymore?

2017-07-13 Thread Zhenhua Luo 
I have added a note for meta-fsl-ppc layer to indicate the migration from 
meta-fsl-ppc to meta-freescale, meanwhile, meta-fsl-ppc is marked to inactive. 


Best Regards, 

Zhenhua

> -Original Message-
> From: meta-freescale-boun...@yoctoproject.org [mailto:meta-freescale-
> boun...@yoctoproject.org] On Behalf Of Otavio Salvador
> Sent: Tuesday, July 11, 2017 2:25 AM
> To: Robert P. J. Day 
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] is meta-fsl-ppc layer even used anymore?
> 
> On Mon, Jul 10, 2017 at 3:18 PM, Robert P. J. Day 
> wrote:
> > On Mon, 10 Jul 2017, Otavio Salvador wrote:
> >
> >> On Mon, Jul 10, 2017 at 2:06 PM, Robert P. J. Day 
> wrote:
> >> > On Mon, 10 Jul 2017, Otavio Salvador wrote:
> >> >
> >> >> On Fri, Jul 7, 2017 at 5:50 PM, Robert P. J. Day 
> wrote:
> >> >> >
> >> >> >   i was having trouble building for t1042d4rdb with the
> >> >> > meta-fsl-ppc layer until i noticed that the meta-freescale layer
> >> >> > had a machine definition for the same target. does the
> >> >> > meta-freescale layer obsolete meta-fsl-ppc?
> >> >>
> >> >> Yes. meta-freescale provides it all.
> >> >
> >> >   then it might be useful to remove links to superseded meta-fsl-*
> >> > layers from
> >> > https://layers.openembedded.org/layerindex/branch/master/layers/
> >>
> >> For meta-fsl-arm I added, long time ago, a note:
> >>
> >> For morty and newer releases, use the meta-freescale layer instead.
> >>
> >> Now to be even more clear, I setted it to inactive.
> >
> >   excellent.
> >
> >> The meta-fsl-ppc, I don't have control on the metadata to update it.
> >> I am adding Luo to look at it.
> >
> >   so does that mean meta-fsl-ppc has also been folded into
> > meta-freescale? or is it still meant to be used independently?
> 
> folded.
> 
> 
> --
> 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
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale