[meta-freescale] Update patch
Your patch
recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0008-Specific-patches-for-gstplayer-API.patch
no longer applies to Yocto master (9ea5a31776440abd6468f003c5e1905f079446d3)
Here is a refresh (without your comments or Signed-off-by)
which lets the package build again
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
>From f8538e6a020ad862bc715f778bfedd538eef536c Mon Sep 17 00:00:00 2001
From: Gary Thomas
Date: Tue, 20 Jun 2017 09:54:43 +0200
Subject: [PATCH] gstreamer1.0-plugins-bad: Update patch for latest OE-core
---
.../0008-Specific-patches-for-gstplayer-API.patch | 66 +++---
1 file changed, 19 insertions(+), 47 deletions(-)
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0008-Specific-patches-for-gstplayer-API.patch b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0008-Specific-patches-for-gstplayer-API.patch
index 0679e4b..0925be3 100755
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0008-Specific-patches-for-gstplayer-API.patch
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0008-Specific-patches-for-gstplayer-API.patch
@@ -1,59 +1,34 @@
-From 3d789943c1f0568014ff2399a097b5dfa5d7a92e Mon Sep 17 00:00:00 2001
-From: Lyon Wang
-Date: Fri, 30 Dec 2016 15:53:21 +0800
-Subject: [PATCH 3/5] Specific patches for gstplayer API
-
-player: Add get_rotate, set_rotate API
-
-- Add gstplayer get_rotate() and set_rotate() API
-
-player: Add force-aspect-ratio config
-
-- Add get/set force-aspect-ratio config API
-
-player: Add set audio / text sink API
-
-- Add set audio / text sink API
-
-Upstream-Status: Inappropriate [i.MX specific]
-
-Signed-off-by: Lyon Wang
- gst-libs/gst/player/gstplayer.c | 214
- gst-libs/gst/player/gstplayer.h | 10 ++
- 2 files changed, 224 insertions(+)
-
-diff --git a/gst-libs/gst/player/gstplayer.c b/gst-libs/gst/player/gstplayer.c
-index d9ff524..960e7a2 100644
a/gst-libs/gst/player/gstplayer.c
-+++ b/gst-libs/gst/player/gstplayer.c
-@@ -86,6 +86,7 @@ typedef enum
+Index: gst-plugins-bad-1.10.4/gst-libs/gst/player/gstplayer.c
+===
+--- gst-plugins-bad-1.10.4.orig/gst-libs/gst/player/gstplayer.c
gst-plugins-bad-1.10.4/gst-libs/gst/player/gstplayer.c
+@@ -85,6 +85,7 @@ typedef enum
+ {
CONFIG_QUARK_USER_AGENT = 0,
CONFIG_QUARK_POSITION_INTERVAL_UPDATE,
- CONFIG_QUARK_ACCURATE_SEEK,
+ CONFIG_QUARK_FORCE_ASPECT_RATIO,
CONFIG_QUARK_MAX
} ConfigQuarkId;
-@@ -94,6 +95,7 @@ static const gchar *_config_quark_strings[] = {
+@@ -92,6 +93,7 @@ typedef enum
+ static const gchar *_config_quark_strings[] = {
"user-agent",
"position-interval-update",
- "accurate-seek",
+ "force-aspect-ratio",
};
GQuark _config_quark_table[CONFIG_QUARK_MAX];
-@@ -269,6 +271,7 @@ gst_player_init (GstPlayer * self)
+@@ -266,6 +268,7 @@ gst_player_init (GstPlayer * self)
+ /* *INDENT-OFF* */
self->config = gst_structure_new_id (QUARK_CONFIG,
CONFIG_QUARK (POSITION_INTERVAL_UPDATE), G_TYPE_UINT, DEFAULT_POSITION_UPDATE_INTERVAL_MS,
- CONFIG_QUARK (ACCURATE_SEEK), G_TYPE_BOOLEAN, FALSE,
+ CONFIG_QUARK (FORCE_ASPECT_RATIO), G_TYPE_BOOLEAN, TRUE,
NULL);
/* *INDENT-ON* */
-@@ -4259,3 +4262,214 @@ gst_player_config_get_seek_accurate (const GstStructure * config)
+@@ -4199,3 +4202,214 @@ gst_player_config_get_position_update_in
- return accurate;
+ return interval;
}
+
+/**
@@ -266,13 +241,13 @@ index d9ff524..960e7a2 100644
+ GST_DEBUG_OBJECT (self, "set text sink '%s'", sink_name);
+ return TRUE;
+}
-diff --git a/gst-libs/gst/player/gstplayer.h b/gst-libs/gst/player/gstplayer.h
-index 8426be5..bfc12b2 100644
a/gst-libs/gst/player/gstplayer.h
-+++ b/gst-libs/gst/player/gstplayer.h
-@@ -205,6 +205,16 @@ guint gst_player_config_get_position_update_interval (const GstStructu
- void gst_player_config_set_seek_accurate (GstPlayer * player, gboolean accurate);
- gboolean gst_player_config_get_seek_accurate (const GstStructure * config);
+Index: gst-plugins-bad-1.10.4/gst-libs/gst/player/gstplayer.h
+===
+--- gst-plugins-bad-1.10.4.orig/gst-libs/gst/player/gstplayer.h
gst-plugins-bad-1.10.4/gst-libs/gst/player/gstplayer.h
+@@ -202,6 +202,16 @@ void gst_player_config_set_pos
+ guint interval);
+ guint gst_player_config_get_position_update_interval (const GstStructure * config);
+/* Custom gstplayer API */
+gbooleangst_player_set_rotate (GstPlayer * player, gint rotation);
@@ -287,6
[meta-freescale] Broken/missing bbappend?
I'm working with the [tip]master branches of meta-freescale & meta-browser: meta-freescale= "master:196bee744726d4bbeb52883bf06145e96e0843ce" meta-browser = "master:898af3679e5db0ca1747ee9ce4e1c6c2424fbc75" Still with the latest master I get ERROR: No recipes available for: /local/poky-cutting-edge/meta-freescale/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend meta-browser only has chromium-wayland_53.0.2785.143.bb I work around this (I'm interested in X11, not wayland) by ignoring the error via BB_DANGLINGAPPENDS_WARNONLY = "1" That said, it looks like this should be addressed. n.b. please don't ask me for a patch as I don't use wayland and am really not qualified to propose any such changes. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
On 2017-01-31 21:14, Tom Hochstein wrote:
-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: Tuesday, January 24, 2017 9:37 AM
To: Tom Hochstein ; meta-freescale@yoctoproject.org
Cc: Lauren Post
Subject: Re: [meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
On 2017-01-24 16:32, Tom Hochstein wrote:
Hi Gary,
I am seeing a failure too. We're looking into it.
Thanks for the feedback. Looking forward to a resolution. Let me know if
I can provide any more data to help diagnose the issue.
I posted a patch from Prabhu to OE-core.
I tested this and it does seem to work again, thanks (I'm not sure what change
made it work, but I'm happy one was found).
Sorry for the delayed follow-up - I was away on holiday.
-Original Message-----
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: Tuesday, January 24, 2017 8:41 AM
To: meta-freescale@yoctoproject.org
Cc: Tom Hochstein ; Lauren Post
Subject: Re: [meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
On 2017-01-17 06:32, Gary Thomas wrote:
When I build for my i.MX6Q target, X crashes immediately. This is a
direct result of OE-core updating the X server from 1.18.4 to 1.19
What I've been able to discover is that the video driver
(xf86-video-imxfb-vivante)
is being called early on from 'AddScreen' in the main X server. The
driver sets up a shared data structure DRIInfoRec like this:
VivDRIScreenInit: pDRIInfo: 0xb76e80, busIdString = 0xb76f38 ('platform:Vivante
GCCore:00')
00B76E80: ||
00B76E90: ||
00B76EA0: 9401 1500 3C03 1500 |<...|
00B76EB0: 9CCF 1400 B0D1 1400 1404 1500 38D3 1400 |8...|
00B76EC0: B0D6 59B6 B8D6 59B6 386F B700 |..Y...Y.8o..|
00B76ED0: ||
00B76EE0: ||
00B76EF0: ||
00B76F00: ||
00B76F10: ||
00B76F20: ||
but by the time the server gets to ProcXF86DRIOpenConnection, this structure
has been trashed:
DRIOpenConnection: pDRIPriv: 0xb76fc0, pDriverInfo: 0xb76e80, busIdString:
0x454d
00B76E80: E889 B700 C06E B700 0400 |.n..|
00B76E90: FF7F 0080 ||
00B76EA0: 0200 9018 0D00 DC18 0D00 ||
00B76EB0: 2075 1D00 B88B B700 1100 | u..|
00B76EC0: 5345 5256 4552 5449 4D45 2900 |SERVERTIME..)...|
00B76ED0: 4C00 00EC B000 |L...|
00B76EE0: A95D 1A00 888B B700 |.]..|
00B76EF0: 0100 1900 4C00 |L...|
00B76F00: 1600 D06E B700 1800 3900 |.n..9...|
00B76F10: 0100 486F B700 8100 |Ho..|
00B76F20: 4000 4100 |@...A...|
ProcXF86DRIOpenConnection: busIdString = 0x454d
I'm pretty sure that what's happening is near the end of AddScreen,
there is a call to dixRegisterScreenPrivateKey() which in turn
calls dixReallocPrivates() which seems to be relocating the DRIInfoRec
but the pointers used by DRIOpenConnection() are not updated. The old
(non-relocated) structure gets reused and trashed and when DRIOpenConnection()
it picks up garbage.
I'm not sure what needs to change to fix this though. Looking at the X server
code, I didn't find a lot of differences in/around this code path. What I do
know is that reverting to xserver-xorg 1.18.4 absolutely works.
I'm using Poky/Yocto + meta-freescale layers (both on master)
poky: 840e221ea7c35177fda37af618c4727fa7754789
meta-freescale: a99b95c899e6c20b9f46fa04766c155e3a32949a
Has anyone else built X (not Wayland) recently using this codebase? Anyone
else having the same issues?
Is no-one else but me seeing this issue? If not, what could I be doing wrong?
I'm building the same images (same config, etc) that I've been using for
[literally]
years and now it breaks with this version of the X server.
At least an 'ack - I've read this and it's your problem' would be better
than total silence...
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] Out of sync recipes
ERROR: No recipes available for: /local/poky-cutting-edge/meta-freescale/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend poky/yocto: d45d4a5a21ab4209b87331dddf515ecdb62367fa meta-freescale: 816646509484561360350f83744e867dccfb7e5e meta-browser: d875f40c3a120118ddf998545dd7efba09d01cc1 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-freescale-3rdparty][PATCH] linux-boundary: Use compatible version names
On 2017-01-31 12:23, Gary Thomas wrote:
Kernel modules now contain ${LOCAL_VERSION} as part of the
final package name. IPK/OPKG packages cannot contain '_',
so 2.0.0_ga+yocto... is invalid. This patch uses a version
scheme which is compatible with those packaging schemes.
Signed-off-by: Gary Thomas
---
recipes-kernel/linux/linux-boundary_4.1.15.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-boundary_4.1.15.bb
b/recipes-kernel/linux/linux-boundary_4.1.15.bb
index 69fe61c..d62d4e8 100644
--- a/recipes-kernel/linux/linux-boundary_4.1.15.bb
+++ b/recipes-kernel/linux/linux-boundary_4.1.15.bb
@@ -10,7 +10,7 @@ SRC_URI =
"git://github.com/boundarydevices/linux-imx6.git;branch=${SRCBRANCH} \
file://defconfig \
"
-LOCALVERSION = "-2.0.0_ga+yocto"
+LOCALVERSION = "-2.0.0-ga+yocto"
SRCBRANCH = "boundary-imx_4.1.15_2.0.0_ga"
SRCREV = "ff4e28b95115d7021c3ea6209b7c2b0b849874e1"
DEPENDS += "lzop-native bc-native"
BTW, without this patch, building a system which uses linux-boundary
dies a horrible death :-(
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
ERROR: kernel-module-imx-gpu-viv-5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0
do_package_write_ipk: Error executing a python function in exec_python_func()
autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:do_package_ipk(d)
0003:
File: '/local/poky-cutting-edge/meta/classes/package_ipk.bbclass', lineno: 229,
function: do_package_ipk
0225:conffiles.close()
0226:
0227:os.chdir(basedir)
0228:subprocess.check_output("PATH=\"%s\" %s %s %s" %
(localdata.getVar("PATH"),
*** 0229:
d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir), shell=True)
0230:
0231:if d.getVar('IPK_SIGN_PACKAGES') == '1':
0232:ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))
0233:ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir, pkgname,
ipkver, d.getVar('PACKAGE_ARCH'))
File: '/usr/lib/python3.5/subprocess.py', lineno: 626, function: check_output
0622:# empty string. That is maintained here for backwards
compatibility.
0623:kwargs['input'] = '' if kwargs.get('universal_newlines',
False) else b''
0624:
0625:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
*** 0626: **kwargs).stdout
0627:
0628:
0629:class CompletedProcess(object):
0630:"""A process that has finished running.
File: '/usr/lib/python3.5/subprocess.py', lineno: 708, function: run
0704:raise
0705:retcode = process.poll()
0706:if check and retcode:
0707:raise CalledProcessError(retcode, process.args,
*** 0708: output=stdout, stderr=stderr)
0709:return CompletedProcess(process.args, retcode, stdout, stderr)
0710:
0711:
0712:def list2cmdline(seq):
Exception: subprocess.CalledProcessError: Command
'PATH="/build/p0382_2016-01-13/tmp/sysroots-uninative/x86_64-linux/usr/bin:/local/poky-cutting-edge/scripts:/build/p0382_2016-01-13/tmp/work/teton_p0382-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi:/build/p0382_2016-01-13/tmp/work/teton_p0382-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0/recipe-sysroot/usr/bin/crossscripts:/build/p0382_2016-01-13/tmp/work/teton_p0382-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0/recipe-sysroot-native/usr/sbin:/build/p0382_2016-01-13/tmp/work/teton_p0382-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0/recipe-sysroot-native/usr/bin:/build/p0382_2016-01-13/tmp/work/teton_p0382-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0/recipe-sysroot-native/sbin:/build/p0382_2016-01-13/tmp/work/teton_p0382-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p8.6+fslc+gitAUTOINC+1be63fb14e-r0/recipe-sysroot-native/bin:/local/poky-cutting-edge/scripts:/local/poky-cutting-edge/bitbake/bin:/home/gthomas/bin:/opt/amltd/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
opkg-build kernel-module-galc
[meta-freescale] [meta-freescale-3rdparty][PATCH] linux-boundary: Use compatible version names
Kernel modules now contain ${LOCAL_VERSION} as part of the
final package name. IPK/OPKG packages cannot contain '_',
so 2.0.0_ga+yocto... is invalid. This patch uses a version
scheme which is compatible with those packaging schemes.
Signed-off-by: Gary Thomas
---
recipes-kernel/linux/linux-boundary_4.1.15.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-boundary_4.1.15.bb
b/recipes-kernel/linux/linux-boundary_4.1.15.bb
index 69fe61c..d62d4e8 100644
--- a/recipes-kernel/linux/linux-boundary_4.1.15.bb
+++ b/recipes-kernel/linux/linux-boundary_4.1.15.bb
@@ -10,7 +10,7 @@ SRC_URI =
"git://github.com/boundarydevices/linux-imx6.git;branch=${SRCBRANCH} \
file://defconfig \
"
-LOCALVERSION = "-2.0.0_ga+yocto"
+LOCALVERSION = "-2.0.0-ga+yocto"
SRCBRANCH = "boundary-imx_4.1.15_2.0.0_ga"
SRCREV = "ff4e28b95115d7021c3ea6209b7c2b0b849874e1"
DEPENDS += "lzop-native bc-native"
--
2.7.4
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Stale .bbappend?
On 2017-01-25 12:37, Otavio Salvador wrote: On Wed, Jan 25, 2017 at 4:20 AM, Gary Thomas wrote: I got this error with today's build: ERROR: No recipes available for: /local/poky-cutting-edge/meta-freescale/recipes-graphics/xserver-common/xserver-common_%.bbappend Using Poky/Yocto 62d7d4130202d8ede16abf9e7d779361ca70847e meta-freescale 67b09d4b6bec8efae566d04b24f67af439349452 It appears that this recipe is only in meta-oe. Does this mean that building using meta-freescale now requires meta-oe? No; we need to move this to the dynamic-layers so it is enabled only if avail. Do you mind to prepare a patch for it? Done -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [PATCH] xserver-common: Move to dynamic layers
The xserver-common recipe can only be built if the openbedded (meta-oe)
layer is present, so move it to the dynamic layers to prevent breakage
if that layer is not in the build.
Signed-off-by: Gary Thomas
---
.../0016-xserver-common-enable-iglx-module.patch | 30 ++
.../xserver-common/xserver-common_%.bbappend | 10
.../0016-xserver-common-enable-iglx-module.patch | 30 --
.../xserver-common/xserver-common_%.bbappend | 10
4 files changed, 40 insertions(+), 40 deletions(-)
create mode 100644
dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
create mode 100644
dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common_%.bbappend
delete mode 100644
recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
delete mode 100644 recipes-graphics/xserver-common/xserver-common_%.bbappend
diff --git
a/dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
b/dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
new file mode 100644
index 000..283a081
--- /dev/null
+++
b/dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
@@ -0,0 +1,30 @@
+From 8ad045e5e664fe2d1bd9f88616d5bf83437aab4e Mon Sep 17 00:00:00 2001
+From: Yang Dong
+Date: Wed, 9 Sep 2015 13:08:57 +0800
+Subject: [PATCH] xserver-common: enable iglx module
+
+Enable iglx module to pass indirect glx rendering test case.
+
+Upstream-Status: Inappropriate [imx specific]
+
+Date: Sep 9, 2015
+Signed-off-by Yang Dong
+---
+ X11/xserver-common | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/X11/xserver-common b/X11/xserver-common
+index 4dc48c4..d19b858 100644
+--- a/X11/xserver-common
b/X11/xserver-common
+@@ -44,6 +44,7 @@ SCREEN_SIZE=`fallback_screen_arg`
+ export USER=root
+ export XSERVER_DEFAULT_ORIENTATION=normal
+
++INPUT_EXTRA_ARGS="+iglx"
+ ARGS="-br -pn -nolisten tcp $INPUT_EXTRA_ARGS"
+ DPI="100"
+ MOUSE=""
+--
+1.9.1
+
diff --git
a/dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common_%.bbappend
b/dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common_%.bbappend
new file mode 100644
index 000..28d1f7b
--- /dev/null
+++
b/dynamic-layers/openembedded-layer/recipes-graphics/xserver-common/xserver-common_%.bbappend
@@ -0,0 +1,10 @@
+# i.MX extra configuration
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+PATCHES_IMX_SPECIFIC = " file://0016-xserver-common-enable-iglx-module.patch \
+"
+SRC_URI_append = " \
+${PATCHES_IMX_SPECIFIC} \
+"
+PACKAGE_ARCH_mx6 = "${MACHINE_SOCARCH}"
+PACKAGE_ARCH_mx7 = "${MACHINE_SOCARCH}"
diff --git
a/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
b/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
deleted file mode 100644
index 283a081..000
---
a/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From 8ad045e5e664fe2d1bd9f88616d5bf83437aab4e Mon Sep 17 00:00:00 2001
-From: Yang Dong
-Date: Wed, 9 Sep 2015 13:08:57 +0800
-Subject: [PATCH] xserver-common: enable iglx module
-
-Enable iglx module to pass indirect glx rendering test case.
-
-Upstream-Status: Inappropriate [imx specific]
-
-Date: Sep 9, 2015
-Signed-off-by Yang Dong
- X11/xserver-common | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/X11/xserver-common b/X11/xserver-common
-index 4dc48c4..d19b858 100644
a/X11/xserver-common
-+++ b/X11/xserver-common
-@@ -44,6 +44,7 @@ SCREEN_SIZE=`fallback_screen_arg`
- export USER=root
- export XSERVER_DEFAULT_ORIENTATION=normal
-
-+INPUT_EXTRA_ARGS="+iglx"
- ARGS="-br -pn -nolisten tcp $INPUT_EXTRA_ARGS"
- DPI="100"
- MOUSE=""
---
-1.9.1
-
diff --git a/recipes-graphics/xserver-common/xserver-common_%.bbappend
b/recipes-graphics/xserver-common/xserver-common_%.bbappend
deleted file mode 100644
index 28d1f7b..000
--- a/recipes-graphics/xserver-common/xserver-common_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-# i.MX extra configuration
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-PATCHES_IMX_SPECIFIC = " file://0016-xserver-common-enable-iglx-module.patch \
-"
-SRC_URI_append = " \
-${PATCHES_IMX_SPECIFIC} \
-"
-PACKAGE_ARCH_mx6 = "${MACHINE_SOCARCH}"
-PACKAGE_ARCH_mx7 = "${MACHINE_SOCARCH}"
--
2.7.4
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] Stale .bbappend?
I got this error with today's build: ERROR: No recipes available for: /local/poky-cutting-edge/meta-freescale/recipes-graphics/xserver-common/xserver-common_%.bbappend Using Poky/Yocto 62d7d4130202d8ede16abf9e7d779361ca70847e meta-freescale 67b09d4b6bec8efae566d04b24f67af439349452 It appears that this recipe is only in meta-oe. Does this mean that building using meta-freescale now requires meta-oe? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
On 2017-01-24 16:32, Tom Hochstein wrote:
Hi Gary,
I am seeing a failure too. We're looking into it.
Thanks for the feedback. Looking forward to a resolution. Let me know if
I can provide any more data to help diagnose the issue.
-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: Tuesday, January 24, 2017 8:41 AM
To: meta-freescale@yoctoproject.org
Cc: Tom Hochstein ; Lauren Post
Subject: Re: [meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
On 2017-01-17 06:32, Gary Thomas wrote:
When I build for my i.MX6Q target, X crashes immediately. This is a
direct result of OE-core updating the X server from 1.18.4 to 1.19
What I've been able to discover is that the video driver
(xf86-video-imxfb-vivante)
is being called early on from 'AddScreen' in the main X server. The
driver sets up a shared data structure DRIInfoRec like this:
VivDRIScreenInit: pDRIInfo: 0xb76e80, busIdString = 0xb76f38 ('platform:Vivante
GCCore:00')
00B76E80: ||
00B76E90: ||
00B76EA0: 9401 1500 3C03 1500 |<...|
00B76EB0: 9CCF 1400 B0D1 1400 1404 1500 38D3 1400 |8...|
00B76EC0: B0D6 59B6 B8D6 59B6 386F B700 |..Y...Y.8o..|
00B76ED0: ||
00B76EE0: ||
00B76EF0: ||
00B76F00: ||
00B76F10: ||
00B76F20: ||
but by the time the server gets to ProcXF86DRIOpenConnection, this structure
has been trashed:
DRIOpenConnection: pDRIPriv: 0xb76fc0, pDriverInfo: 0xb76e80, busIdString:
0x454d
00B76E80: E889 B700 C06E B700 0400 |.n..|
00B76E90: FF7F 0080 ||
00B76EA0: 0200 9018 0D00 DC18 0D00 ||
00B76EB0: 2075 1D00 B88B B700 1100 | u..|
00B76EC0: 5345 5256 4552 5449 4D45 2900 |SERVERTIME..)...|
00B76ED0: 4C00 00EC B000 |L...|
00B76EE0: A95D 1A00 888B B700 |.]..|
00B76EF0: 0100 1900 4C00 |L...|
00B76F00: 1600 D06E B700 1800 3900 |.n..9...|
00B76F10: 0100 486F B700 8100 |Ho..|
00B76F20: 4000 4100 |@...A...|
ProcXF86DRIOpenConnection: busIdString = 0x454d
I'm pretty sure that what's happening is near the end of AddScreen,
there is a call to dixRegisterScreenPrivateKey() which in turn
calls dixReallocPrivates() which seems to be relocating the DRIInfoRec
but the pointers used by DRIOpenConnection() are not updated. The old
(non-relocated) structure gets reused and trashed and when DRIOpenConnection()
it picks up garbage.
I'm not sure what needs to change to fix this though. Looking at the X server
code, I didn't find a lot of differences in/around this code path. What I do
know is that reverting to xserver-xorg 1.18.4 absolutely works.
I'm using Poky/Yocto + meta-freescale layers (both on master)
poky: 840e221ea7c35177fda37af618c4727fa7754789
meta-freescale: a99b95c899e6c20b9f46fa04766c155e3a32949a
Has anyone else built X (not Wayland) recently using this codebase? Anyone
else having the same issues?
Is no-one else but me seeing this issue? If not, what could I be doing wrong?
I'm building the same images (same config, etc) that I've been using for
[literally]
years and now it breaks with this version of the X server.
At least an 'ack - I've read this and it's your problem' would be better
than total silence...
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
On 2017-01-17 06:32, Gary Thomas wrote:
When I build for my i.MX6Q target, X crashes immediately. This is a
direct result of OE-core updating the X server from 1.18.4 to 1.19
What I've been able to discover is that the video driver
(xf86-video-imxfb-vivante)
is being called early on from 'AddScreen' in the main X server. The
driver sets up a shared data structure DRIInfoRec like this:
VivDRIScreenInit: pDRIInfo: 0xb76e80, busIdString = 0xb76f38 ('platform:Vivante
GCCore:00')
00B76E80: ||
00B76E90: ||
00B76EA0: 9401 1500 3C03 1500 |<...|
00B76EB0: 9CCF 1400 B0D1 1400 1404 1500 38D3 1400 |8...|
00B76EC0: B0D6 59B6 B8D6 59B6 386F B700 |..Y...Y.8o..|
00B76ED0: ||
00B76EE0: ||
00B76EF0: ||
00B76F00: ||
00B76F10: ||
00B76F20: ||
but by the time the server gets to ProcXF86DRIOpenConnection, this structure
has been trashed:
DRIOpenConnection: pDRIPriv: 0xb76fc0, pDriverInfo: 0xb76e80, busIdString:
0x454d
00B76E80: E889 B700 C06E B700 0400 |.n..|
00B76E90: FF7F 0080 ||
00B76EA0: 0200 9018 0D00 DC18 0D00 ||
00B76EB0: 2075 1D00 B88B B700 1100 | u..|
00B76EC0: 5345 5256 4552 5449 4D45 2900 |SERVERTIME..)...|
00B76ED0: 4C00 00EC B000 |L...|
00B76EE0: A95D 1A00 888B B700 |.]..|
00B76EF0: 0100 1900 4C00 |L...|
00B76F00: 1600 D06E B700 1800 3900 |.n..9...|
00B76F10: 0100 486F B700 8100 |Ho..|
00B76F20: 4000 4100 |@...A...|
ProcXF86DRIOpenConnection: busIdString = 0x454d
I'm pretty sure that what's happening is near the end of AddScreen,
there is a call to dixRegisterScreenPrivateKey() which in turn
calls dixReallocPrivates() which seems to be relocating the DRIInfoRec
but the pointers used by DRIOpenConnection() are not updated. The old
(non-relocated) structure gets reused and trashed and when DRIOpenConnection()
it picks up garbage.
I'm not sure what needs to change to fix this though. Looking at the X server
code, I didn't find a lot of differences in/around this code path. What I do
know is that reverting to xserver-xorg 1.18.4 absolutely works.
I'm using Poky/Yocto + meta-freescale layers (both on master)
poky: 840e221ea7c35177fda37af618c4727fa7754789
meta-freescale: a99b95c899e6c20b9f46fa04766c155e3a32949a
Has anyone else built X (not Wayland) recently using this codebase? Anyone
else having the same issues?
Is no-one else but me seeing this issue? If not, what could I be doing wrong?
I'm building the same images (same config, etc) that I've been using for
[literally]
years and now it breaks with this version of the X server.
At least an 'ack - I've read this and it's your problem' would be better
than total silence...
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] xf86-video-imxfb-vivante crashing with Xorg 1.19
When I build for my i.MX6Q target, X crashes immediately. This is a
direct result of OE-core updating the X server from 1.18.4 to 1.19
What I've been able to discover is that the video driver
(xf86-video-imxfb-vivante)
is being called early on from 'AddScreen' in the main X server. The
driver sets up a shared data structure DRIInfoRec like this:
VivDRIScreenInit: pDRIInfo: 0xb76e80, busIdString = 0xb76f38 ('platform:Vivante
GCCore:00')
00B76E80: ||
00B76E90: ||
00B76EA0: 9401 1500 3C03 1500 |<...|
00B76EB0: 9CCF 1400 B0D1 1400 1404 1500 38D3 1400 |8...|
00B76EC0: B0D6 59B6 B8D6 59B6 386F B700 |..Y...Y.8o..|
00B76ED0: ||
00B76EE0: ||
00B76EF0: ||
00B76F00: ||
00B76F10: ||
00B76F20: ||
but by the time the server gets to ProcXF86DRIOpenConnection, this structure
has been trashed:
DRIOpenConnection: pDRIPriv: 0xb76fc0, pDriverInfo: 0xb76e80, busIdString:
0x454d
00B76E80: E889 B700 C06E B700 0400 |.n..|
00B76E90: FF7F 0080 ||
00B76EA0: 0200 9018 0D00 DC18 0D00 ||
00B76EB0: 2075 1D00 B88B B700 1100 | u..|
00B76EC0: 5345 5256 4552 5449 4D45 2900 |SERVERTIME..)...|
00B76ED0: 4C00 00EC B000 |L...|
00B76EE0: A95D 1A00 888B B700 |.]..|
00B76EF0: 0100 1900 4C00 |L...|
00B76F00: 1600 D06E B700 1800 3900 |.n..9...|
00B76F10: 0100 486F B700 8100 |Ho..|
00B76F20: 4000 4100 |@...A...|
ProcXF86DRIOpenConnection: busIdString = 0x454d
I'm pretty sure that what's happening is near the end of AddScreen,
there is a call to dixRegisterScreenPrivateKey() which in turn
calls dixReallocPrivates() which seems to be relocating the DRIInfoRec
but the pointers used by DRIOpenConnection() are not updated. The old
(non-relocated) structure gets reused and trashed and when DRIOpenConnection()
it picks up garbage.
I'm not sure what needs to change to fix this though. Looking at the X server
code, I didn't find a lot of differences in/around this code path. What I do
know is that reverting to xserver-xorg 1.18.4 absolutely works.
I'm using Poky/Yocto + meta-freescale layers (both on master)
poky: 840e221ea7c35177fda37af618c4727fa7754789
meta-freescale: a99b95c899e6c20b9f46fa04766c155e3a32949a
Has anyone else built X (not Wayland) recently using this codebase? Anyone
else having the same issues?
Thanks
--
----
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [boundary-imx] Enquiry boundary-imx_4.1.15_1.0.0_ga kernel with egalax touch support on sabrelite
On 2017-01-12 14:09, Otavio Salvador wrote: Hello, On Thu, Dec 29, 2016 at 5:42 AM, Shrikant Bobade wrote: I used boundary-eval-image-nitrogen6x-krogoth-next.sdcard.gz https://boundarydevices.com/krogoth-next-yocto-release/ on imx6q-sabrelite target along with 10Inch Hannstar LVDS Display connected. Observed the egalax touch is not working out of box. Does anyone else faced similar issue? Is Hannstar LVDS display supported by default? Do you mind to test with other test images? http://blink.ossystems.com.br/manufacturer/boundary Those uses new kernel and provides new boot scripts. It may provide a better result. Make sure to also use the latest production release for U-Boot provided by them. Note that Ian (Boundary Devices) just sent some patches for what seems to be this problem. It may be easier to just check against those. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] gstreamer1.0-plugins-bad build failure
On 2017-01-11 07:56, Gary Thomas wrote: With the OE-core update to 1.10.2, the meta-freescale specific patches no longer apply. ERROR: gstreamer1.0-plugins-bad-1.10.2-r0 do_patch: Command Error: 'quilt --quiltrc /build/p0382_2016-01-13/tmp/sysroots/x86_64-linux/etc/quiltrc push' exited with 0 Output: Applying patch 0008-glplugin-glcolorconvert-fix-MRT-cannot-work-in-GLES3.patch patching file gst-libs/gst/gl/glprototypes/fbo.h patching file gst-libs/gst/gl/glprototypes/gstgl_gles2compat.h Hunk #1 FAILED at 34. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/gl/glprototypes/gstgl_gles2compat.h patching file gst-libs/gst/gl/gstglcolorconvert.c Hunk #1 FAILED at 2075. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/gl/gstglcolorconvert.c patching file gst-libs/gst/gl/gstglmemory.c Hunk #2 succeeded at 633 (offset 19 lines). Hunk #3 succeeded at 666 (offset 28 lines). Patch 0008-glplugin-glcolorconvert-fix-MRT-cannot-work-in-GLES3.patch does not apply (enforce with -f) ERROR: gstreamer1.0-plugins-bad-1.10.2-r0 do_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /build/p0382_2016-01-13/tmp/work/cortexa9hf-neon-mx6qdl-amltd-linux-gnueabi/gstreamer1.0-plugins-bad/1.10.2-r0/temp/log.do_patch.23224 ERROR: Task (/local/poky-cutting-edge/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.2.bb:do_patch) failed with exit code '1' I see that this recipe has just been updated and this patch failure no longer happens. Thanks (some feedback on my issue would have been nice though...) -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] gstreamer1.0-plugins-bad build failure
With the OE-core update to 1.10.2, the meta-freescale specific patches no longer apply. ERROR: gstreamer1.0-plugins-bad-1.10.2-r0 do_patch: Command Error: 'quilt --quiltrc /build/p0382_2016-01-13/tmp/sysroots/x86_64-linux/etc/quiltrc push' exited with 0 Output: Applying patch 0008-glplugin-glcolorconvert-fix-MRT-cannot-work-in-GLES3.patch patching file gst-libs/gst/gl/glprototypes/fbo.h patching file gst-libs/gst/gl/glprototypes/gstgl_gles2compat.h Hunk #1 FAILED at 34. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/gl/glprototypes/gstgl_gles2compat.h patching file gst-libs/gst/gl/gstglcolorconvert.c Hunk #1 FAILED at 2075. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/gl/gstglcolorconvert.c patching file gst-libs/gst/gl/gstglmemory.c Hunk #2 succeeded at 633 (offset 19 lines). Hunk #3 succeeded at 666 (offset 28 lines). Patch 0008-glplugin-glcolorconvert-fix-MRT-cannot-work-in-GLES3.patch does not apply (enforce with -f) ERROR: gstreamer1.0-plugins-bad-1.10.2-r0 do_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /build/p0382_2016-01-13/tmp/work/cortexa9hf-neon-mx6qdl-amltd-linux-gnueabi/gstreamer1.0-plugins-bad/1.10.2-r0/temp/log.do_patch.23224 ERROR: Task (/local/poky-cutting-edge/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.2.bb:do_patch) failed with exit code '1' -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Errors building the Chromium browser
On 2017-01-09 11:06, Shree wrote: Hello All, I am trying to build the yocto images with the Chromium browser integrated into it. For that I followed the info. given in i.MX yocto Project's user guide and I added below lines in my local.conf file CORE_IMAGE_EXTRA_INSTALL += "chromium libexif" LICENSE_FLAGS_WHITELIST="commercial" and Started the build but I am getting below errors: ERROR: Nothing RPROVIDES 'chromium' (but /home/hrushi/fsl-release-bsp/sources/meta-fsl-bsp-release/imx/meta-sdk/recipes-fsl/images/fsl-image-qt5.bb RDEPENDS on or otherwise requires it) ERROR: chromium was skipped: Recipe is blacklisted: BROKEN: fails to build with gcc-6 NOTE: Runtime target 'chromium' is unbuildable, removing... Missing or unbuildable dependency chain was: ['chromium'] ERROR: Required build target 'fsl-image-qt5' has no buildable providers. Missing or unbuildable dependency chain was: ['fsl-image-qt5', 'chromium'] What version/branch of the metadata (OE-core/Yocto layers, meta-browser, etc) are you using? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] Master build error
Using (updated today 2017-01-03) Poky/Yocto: dbb247cac5fbf7b037e4955f9793828451723924 meta-freescale: 3335d0902ee31411e09e795583569b2f611adb0d I get this error when building ERROR: gstreamer1.0-plugins-bad-1.10.1-r0 do_patch: Command Error: 'quilt --quiltrc /build/p0382_2016-01-13/tmp/sysroots/x86_64-linux/etc/quiltrc push' exited with 0 Output: Applying patch 0008-glplugin-glcolorconvert-fix-MRT-cannot-work-in-GLES3.patch patching file gst-libs/gst/gl/glprototypes/fbo.h patching file gst-libs/gst/gl/glprototypes/gstgl_gles2compat.h Hunk #1 FAILED at 34. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/gl/glprototypes/gstgl_gles2compat.h patching file gst-libs/gst/gl/gstglcolorconvert.c Hunk #1 FAILED at 2075. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/gl/gstglcolorconvert.c patching file gst-libs/gst/gl/gstglmemory.c Hunk #2 succeeded at 633 (offset 19 lines). Hunk #3 succeeded at 666 (offset 28 lines). Patch 0008-glplugin-glcolorconvert-fix-MRT-cannot-work-in-GLES3.patch does not apply (enforce with -f) ERROR: gstreamer1.0-plugins-bad-1.10.1-r0 do_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /build/p0382_2016-01-13/tmp/work/cortexa9hf-neon-mx6qdl-amltd-linux-gnueabi/gstreamer1.0-plugins-bad/1.10.1-r0/temp/log.do_patch.24719 ERROR: Task (/local/poky-cutting-edge/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb:do_patch) failed with exit code '1' This failed patch was brought in by meta-freescale/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.%.bbappend Ideas? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] i.MX6 DL, Yocto Krogoth and Chromium 48.0.2548 problems ...
On 2016-11-04 02:43, Gary Thomas wrote: On 2016-11-03 22:10, Ian Coolidge wrote: Try: google-chrome --ignore-gpu-blacklist www.google.com <http://www.google.com> I got the same results on my i.MX6Q (basically a SabreLite) Which is to say that I get the same crash/backtrace as before, even with this switch You'll need to ignore the gpu blacklist AND go to some specific website. Also, sometimes opening new tabs crashes the browser. Chromium is a mess on imx right now, at least from my experience. The older versions were more stable, but they aren't patched for GCC5 Check out my bbappend I apply, it adds that flag to the compile and changes the desktop launcher to go to www.google.com <http://www.google.com> to bypass problems. https://github.com/boundarydevices/meta-boundary/tree/krogoth/recipes-browser/chromium I'll give this a go tomorrow If anyone finds better solutions, let me know! -Ian On Thu, Nov 3, 2016 at 8:34 AM, Gary Thomas mailto:g...@mlbassoc.com>> wrote: On 2016-11-03 13:45, Flavio Suligoi wrote: Hi all, I compiled a standard Yocto "Krogoth" distro for a sabresd Dual Lite board (meta-fsl-arm, last commit of today), with Chromium 48.0.2548 (meta-browser, last commit of today). In meta-fsl-arm there is the software to enable the GPU graphic acceleration in Chromium 48.0.2548. The distro building works fine. But, when I try to execute Chromium, the application doesn't run with the following error: [1148:1148:1102/214428:ERROR:sandbox_linux.cc(338)] InitializeSandbox() called with multiple threads in process gpu-process Segmentation fault Chromium runs only if I disable the graphic acceleration using the switch: --disable-gpu I can't get it to run even with this switch: ~# google-chrome --disable-gpu Received signal 4 b2a34770 #0 0xb6e0ce4a base::debug::StackTrace::StackTrace() #1 0xb6e0d130 #2 0xb2b414c0 #3 0xb2a34770 WTF::decommitSystemPages() #4 0xb6bb9afa #5 0xb6bba3e4 #6 0xb6bb69d2 blink::NormalPageArena::allocatePage() #7 0xb6bb6f6e blink::NormalPageArena::outOfLineAllocate() #8 0xb68ba942 blink::ChromeClientImpl::create() #9 0xb6936d0e blink::WebViewImpl::WebViewImpl() #10 0xb69374f0 blink::WebViewImpl::create() #11 0xb5e83266 content::RenderViewImpl::Initialize() #12 0xb5e84fba content::RenderViewImpl::Create() #13 0xb5e79aa0 content::RenderThreadImpl::OnControlMessageReceived() #14 0xb5d2e56c #15 0xb4e3898c IPC::ChannelProxy::Context::OnDispatchMessage() #16 0xb6e0de88 base::debug::TaskAnnotator::RunTask() #17 0xb0ff7ca8 scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #18 0xb0ff808c scheduler::TaskQueueManager::DoWork() #19 0xb0ff67d2 #20 0xb6e0de88 base::debug::TaskAnnotator::RunTask() #21 0xb6e244da base::MessageLoop::RunTask() #22 0xb6e24b54 base::MessageLoop::DeferOrRunPendingTask() #23 0xb6e24d0c base::MessageLoop::DoWork() #24 0xb6e25ba4 base::MessagePumpDefault::Run() #25 0xb6e38320 base::RunLoop::Run() #26 0xb6e23b08 base::MessageLoop::Run() #27 0xb5e91c24 #28 0xb5aad63e #29 0xb5aada24 #30 0xb5aac692 content::ContentMain() #31 0x7f840100 ChromeMain #32 0xb2b2b67c __libc_start_main [end of stack trace] # opkg list chromium chromium - 52.0.2743.76-r0.0 - chromium version 52.0.2743.76-r0 Chromium browser Note: built from the latest master source(s): meta = "master:c3d2df883a9d6d5036277114339673656d89a728" meta-freescale= "master:7717fe4a8ffd57c85e6c43e8de1fab8993b2bf08" meta-browser = "master:1edcce7791b4cee9a515c1f11b351753a4f8b12e" -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] i.MX6 DL, Yocto Krogoth and Chromium 48.0.2548 problems ...
On 2016-11-03 22:10, Ian Coolidge wrote: Try: google-chrome --ignore-gpu-blacklist www.google.com <http://www.google.com> I got the same results on my i.MX6Q (basically a SabreLite) You'll need to ignore the gpu blacklist AND go to some specific website. Also, sometimes opening new tabs crashes the browser. Chromium is a mess on imx right now, at least from my experience. The older versions were more stable, but they aren't patched for GCC5 Check out my bbappend I apply, it adds that flag to the compile and changes the desktop launcher to go to www.google.com <http://www.google.com> to bypass problems. https://github.com/boundarydevices/meta-boundary/tree/krogoth/recipes-browser/chromium I'll give this a go tomorrow If anyone finds better solutions, let me know! -Ian On Thu, Nov 3, 2016 at 8:34 AM, Gary Thomas mailto:g...@mlbassoc.com>> wrote: On 2016-11-03 13:45, Flavio Suligoi wrote: Hi all, I compiled a standard Yocto "Krogoth" distro for a sabresd Dual Lite board (meta-fsl-arm, last commit of today), with Chromium 48.0.2548 (meta-browser, last commit of today). In meta-fsl-arm there is the software to enable the GPU graphic acceleration in Chromium 48.0.2548. The distro building works fine. But, when I try to execute Chromium, the application doesn't run with the following error: [1148:1148:1102/214428:ERROR:sandbox_linux.cc(338)] InitializeSandbox() called with multiple threads in process gpu-process Segmentation fault Chromium runs only if I disable the graphic acceleration using the switch: --disable-gpu I can't get it to run even with this switch: ~# google-chrome --disable-gpu Received signal 4 b2a34770 #0 0xb6e0ce4a base::debug::StackTrace::StackTrace() #1 0xb6e0d130 #2 0xb2b414c0 #3 0xb2a34770 WTF::decommitSystemPages() #4 0xb6bb9afa #5 0xb6bba3e4 #6 0xb6bb69d2 blink::NormalPageArena::allocatePage() #7 0xb6bb6f6e blink::NormalPageArena::outOfLineAllocate() #8 0xb68ba942 blink::ChromeClientImpl::create() #9 0xb6936d0e blink::WebViewImpl::WebViewImpl() #10 0xb69374f0 blink::WebViewImpl::create() #11 0xb5e83266 content::RenderViewImpl::Initialize() #12 0xb5e84fba content::RenderViewImpl::Create() #13 0xb5e79aa0 content::RenderThreadImpl::OnControlMessageReceived() #14 0xb5d2e56c #15 0xb4e3898c IPC::ChannelProxy::Context::OnDispatchMessage() #16 0xb6e0de88 base::debug::TaskAnnotator::RunTask() #17 0xb0ff7ca8 scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #18 0xb0ff808c scheduler::TaskQueueManager::DoWork() #19 0xb0ff67d2 #20 0xb6e0de88 base::debug::TaskAnnotator::RunTask() #21 0xb6e244da base::MessageLoop::RunTask() #22 0xb6e24b54 base::MessageLoop::DeferOrRunPendingTask() #23 0xb6e24d0c base::MessageLoop::DoWork() #24 0xb6e25ba4 base::MessagePumpDefault::Run() #25 0xb6e38320 base::RunLoop::Run() #26 0xb6e23b08 base::MessageLoop::Run() #27 0xb5e91c24 #28 0xb5aad63e #29 0xb5aada24 #30 0xb5aac692 content::ContentMain() #31 0x7f840100 ChromeMain #32 0xb2b2b67c __libc_start_main [end of stack trace] # opkg list chromium chromium - 52.0.2743.76-r0.0 - chromium version 52.0.2743.76-r0 Chromium browser Note: built from the latest master source(s): meta = "master:c3d2df883a9d6d5036277114339673656d89a728" meta-freescale= "master:7717fe4a8ffd57c85e6c43e8de1fab8993b2bf08" meta-browser = "master:1edcce7791b4cee9a515c1f11b351753a4f8b12e" -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org <mailto:meta-freescale@yoctoproject.org> https://lists.yoctoproject.org/listinfo/meta-freescale <https://lists.yoctoproject.org/listinfo/meta-freescale> -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] i.MX6 DL, Yocto Krogoth and Chromium 48.0.2548 problems ...
On 2016-11-03 13:45, Flavio Suligoi wrote: Hi all, I compiled a standard Yocto "Krogoth" distro for a sabresd Dual Lite board (meta-fsl-arm, last commit of today), with Chromium 48.0.2548 (meta-browser, last commit of today). In meta-fsl-arm there is the software to enable the GPU graphic acceleration in Chromium 48.0.2548. The distro building works fine. But, when I try to execute Chromium, the application doesn't run with the following error: [1148:1148:1102/214428:ERROR:sandbox_linux.cc(338)] InitializeSandbox() called with multiple threads in process gpu-process Segmentation fault Chromium runs only if I disable the graphic acceleration using the switch: --disable-gpu I can't get it to run even with this switch: ~# google-chrome --disable-gpu Received signal 4 b2a34770 #0 0xb6e0ce4a base::debug::StackTrace::StackTrace() #1 0xb6e0d130 #2 0xb2b414c0 #3 0xb2a34770 WTF::decommitSystemPages() #4 0xb6bb9afa #5 0xb6bba3e4 #6 0xb6bb69d2 blink::NormalPageArena::allocatePage() #7 0xb6bb6f6e blink::NormalPageArena::outOfLineAllocate() #8 0xb68ba942 blink::ChromeClientImpl::create() #9 0xb6936d0e blink::WebViewImpl::WebViewImpl() #10 0xb69374f0 blink::WebViewImpl::create() #11 0xb5e83266 content::RenderViewImpl::Initialize() #12 0xb5e84fba content::RenderViewImpl::Create() #13 0xb5e79aa0 content::RenderThreadImpl::OnControlMessageReceived() #14 0xb5d2e56c #15 0xb4e3898c IPC::ChannelProxy::Context::OnDispatchMessage() #16 0xb6e0de88 base::debug::TaskAnnotator::RunTask() #17 0xb0ff7ca8 scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #18 0xb0ff808c scheduler::TaskQueueManager::DoWork() #19 0xb0ff67d2 #20 0xb6e0de88 base::debug::TaskAnnotator::RunTask() #21 0xb6e244da base::MessageLoop::RunTask() #22 0xb6e24b54 base::MessageLoop::DeferOrRunPendingTask() #23 0xb6e24d0c base::MessageLoop::DoWork() #24 0xb6e25ba4 base::MessagePumpDefault::Run() #25 0xb6e38320 base::RunLoop::Run() #26 0xb6e23b08 base::MessageLoop::Run() #27 0xb5e91c24 #28 0xb5aad63e #29 0xb5aada24 #30 0xb5aac692 content::ContentMain() #31 0x7f840100 ChromeMain #32 0xb2b2b67c __libc_start_main [end of stack trace] # opkg list chromium chromium - 52.0.2743.76-r0.0 - chromium version 52.0.2743.76-r0 Chromium browser Note: built from the latest master source(s): meta = "master:c3d2df883a9d6d5036277114339673656d89a728" meta-freescale= "master:7717fe4a8ffd57c85e6c43e8de1fab8993b2bf08" meta-browser = "master:1edcce7791b4cee9a515c1f11b351753a4f8b12e" -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] ANN: New layout for FSL Community BSP and BSP layers
On 2016-10-25 16:52, Otavio Salvador wrote: Hello everyone, In 2015 an effort to unify the i.MX and QorIQ BSP layers has been started and today we are finally moving the FSL Community BSP to use the result of this work. The development of this new layer has been possible due a collaborative work from O.S. Systems and NXP. It has been a long commitment from all the involved people as we tried hard to make the transition as seamless as possible. The new layer, called meta-freescale, has been available for quite some time at Github[1] but now it is also available under the Yocto Project Git[2] server. 1. https://github.com/Freescale/meta-freescale 2. http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/ This layer supports Yocto Project 2.2 (morty) and upcoming releases (master). Users of older releases should keep using the meta-fsl-arm and meta-fsl-ppc layers. As a consequence of the new unified layer, the meta-fsl-arm-extra and meta-fsl-demos layers were also renamed so they use a more meaningful name. Basically: - meta-fsl-arm-extra has been renamed to meta-freescale-3rdparty. It makes clear that 3rdparty boards are supported on this layer and also removes the ARM from name as PowerPC and other NXP SoC’s based board are welcome to be included there as well. - meta-fsl-demos has been renamed to meta-freescale-distro. This communicates better the layer goal as it has been always a design decision to keep as isolated as possible the BSP and distribution bits. All previous releases are still working as Github provides a very nice rename handling so all users and forks are still valid. Please don’t think the work is complete as there are a number of recipes inside meta-freescale that need clean up or to be moved to other layers, however the base for the work is ready, and we need to look forward in order to develop the layer for the best of the community. So, in practice, should we start using these new layers immediately? Also, will new work/changes only be done in these new/renamed layers? We are now focusing in verifying as much the build results as possible from the new FSL Community BSP and to update the documentation to reflect those changes. All possible help is welcome. -- Gary Thomas -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] i.MX6Q vs i.MX6UL tuning
On 2016-10-12 03:24, Gary Thomas wrote: On 2016-10-11 15:54, Otavio Salvador wrote: On Tue, Oct 11, 2016 at 10:36 AM, Lauren Post wrote: We test with hard in our release for i.MX 6UL DEFAULTTUNE_mx6ul ?= "cortexa7hf-neon" Good catch Lauren. Gary, your machine must be missing a proper machine overrides setting. Please take a look. I started with a clone of imx6ulevk.conf which does not contain this Thanks for the pointers. Somehow I ended up with an incorrect override in my i.MX6UL machine config files which I've now corrected. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] i.MX6Q vs i.MX6UL tuning
On 2016-10-11 15:54, Otavio Salvador wrote: On Tue, Oct 11, 2016 at 10:36 AM, Lauren Post wrote: We test with hard in our release for i.MX 6UL DEFAULTTUNE_mx6ul ?= "cortexa7hf-neon" Good catch Lauren. Gary, your machine must be missing a proper machine overrides setting. Please take a look. I started with a clone of imx6ulevk.conf which does not contain this -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] i.MX6Q vs i.MX6UL tuning
I'm working with machines that have i.MX6Q/DL and i.MX6UL and noticed that they have quite different tuning. i.MX6Q: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU= "hard" i.MX6UL: TUNE_FEATURES = "arm armv7ve vfp thumb neon cortexa7" TARGET_FPU= "softfp" I've not adjusted any GCC tuning for these targets. Just wondering why the i.MX6Q is hardfp and the i.MX6UL is soft? Anyone know why this choice was made? -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Please do something about broken chromium .bbappend
On 2016-09-22 11:51, Otavio Salvador wrote: On Thu, Sep 22, 2016 at 4:41 AM, Gary Thomas wrote: It's been broken for weeks :-( ERROR: No recipes available for: /local/poky-cutting-edge/meta-fsl-arm/browser-layer/recipes-browser/chromium/chromium_48.0.2548.0.bbappend If you can't update the .bbappend, at least delete it until you can. What about instead of complain send the patch to fix? Lauren sent a tentative patch which got comments from Carlos. If you are in a hurry use her patch as base and fix the concerns Carlos expressed and send the new patch. Removing it won't fix the problem but hide it so please step up and send a patch ;-) I've already answered this - I don't have the expertise to make such a patch. That said, leaving the repository broken for so long is really poor form. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Please do something about broken chromium .bbappend
It's been broken for weeks :-( ERROR: No recipes available for: /local/poky-cutting-edge/meta-fsl-arm/browser-layer/recipes-browser/chromium/chromium_48.0.2548.0.bbappend If you can't update the .bbappend, at least delete it until you can. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm][PATCH] u-boot: Fix out-of-tree builds
Recent changes to the main u-boot recipe builds in a separate tree
which broke the segment of this code that attempts to find the GIT
revision (not in correct directory). This patch adjusts that by
forcing the git command to run in the correct location.
Signed-off-by: Gary Thomas
---
classes/fsl-u-boot-localversion.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/classes/fsl-u-boot-localversion.bbclass
b/classes/fsl-u-boot-localversion.bbclass
index f7e0971..69a0fd4 100644
--- a/classes/fsl-u-boot-localversion.bbclass
+++ b/classes/fsl-u-boot-localversion.bbclass
@@ -17,7 +17,7 @@ UBOOT_LOCALVERSION = "${LOCALVERSION}"
do_compile_prepend() {
if [ "${SCMVERSION}" = "y" ]; then
# Add GIT revision to the local version
- head=`git rev-parse --verify --short HEAD 2> /dev/null`
+ head=`cd ${S};git rev-parse --verify --short HEAD 2> /dev/null`
printf "%s%s%s" "${UBOOT_LOCALVERSION}" +g $head >
${S}/.scmversion
printf "%s%s%s" "${UBOOT_LOCALVERSION}" +g $head >
${B}/.scmversion
else
--
2.7.4
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Out of sync with meta-browser
On 2016-08-19 16:43, Otavio Salvador wrote: Hello Gary, On Fri, Aug 19, 2016 at 7:43 AM, Gary Thomas wrote: After updating to meta-fsl-arm: 53cfeee85f712937cd33c63b18a4be49e0b08e19 meta-browser: d4deef18f8662bdd918a2d0456078dd4976d9ce9 ERROR: No recipes available for: /local/poky-cutting-edge/meta-fsl-arm/browser-layer/recipes-browser/chromium/chromium_48.0.2548.0.bbappend Indeed; for Krogoth I created a branch for meta-browser before the upgrade so it is possible to keep using it. For master, someone who is actively using Chromium should provide a patch :-) (Yes Gary I am looking at you... :-)) I might, Except I don't know the implications of the patches/changes w.r.t. the new version :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Out of sync with meta-browser
After updating to meta-fsl-arm: 53cfeee85f712937cd33c63b18a4be49e0b08e19 meta-browser: d4deef18f8662bdd918a2d0456078dd4976d9ce9 ERROR: No recipes available for: /local/poky-cutting-edge/meta-fsl-arm/browser-layer/recipes-browser/chromium/chromium_48.0.2548.0.bbappend -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] How to build yocto as a root user?
On 2016-08-09 15:32, jags gediya wrote: I am facing issues while build yocto as root user on ubuntu 14.04. How can i build as a root user? Why do you want to? Yocto is perfectly complete building as any [normal] user. Are you having issues with that? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Struck while booting up.
On 2016-08-05 08:20, berlinjoevi...@yahoo.com wrote: Hi , I am using kontron smarc-samx6i one of the third party board processor used on this board is imx6q. Currently i am using a new kernel from kontron. A new layer for smarc-samx6i. But after compiling the kernel it struck on some point while booting. please help me to solve this. Please find the attachment the message that showed when bootup. Your bootargs are wrong - it's looking for the root file system on /dev/mmcblk0p1 but you only have /dev/mmcblk3 (with no partitions) Your best bet will be to contact the folks that provide that layer (and BSP) and work with them (i.e. this is not a Yocto problem) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Myriad of kernel recipes
Can someone explain all of the different kernel choices found in meta-fsl-arm? $ ls meta-fsl-arm/recipes-kernel/linux/*.bb meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.6.bb meta-fsl-arm/recipes-kernel/linux/linux-fslc-imx_4.1-1.0.x.bb meta-fsl-arm/recipes-kernel/linux/linux-fslc-imx-rt_4.1-1.0.x.bb meta-fsl-arm/recipes-kernel/linux/linux-imx_4.1.15.bb meta-fsl-arm/recipes-kernel/linux/linux-imx-mfgtool_4.1.15.bb meta-fsl-arm/recipes-kernel/linux/linux-ls1_3.12.bb I build for [my own] i.MX6Q/i.MX6DL/i.MX6Solo/i.MX6UL boards. Which of the meta-fsl-arm recipes might be the best to follow/use? n.b. I've been using the Boundary Devices versions from meta-fsl-arm-extra because I also have a SabreLite (now replaced by Nitrogen6x), but I'm happy to switch if it makes sense. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] One rpm for all kernel modules
On 2016-07-14 16:25, Otavio Salvador wrote: On Thu, Jul 14, 2016 at 10:56 AM, Prasant J wrote: I'm building my custom layer for imx6 boards. When the kernel is built, a lot of rpms are generated: kernel image rpm + kernel module rpms. Is it possible to have only 1 rpm for kernel modules (instead of having an rpm for each module)? Check the kernel-modules-split class :-) What about just kernel-modules? That will include all kernel modules that are built with the kernel recipe, but not any modules that are added on later. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Out of date patch
On 2016-06-28 17:24, Otavio Salvador wrote: On Tue, Jun 28, 2016 at 4:52 AM, Gary Thomas wrote: This recipe/patch is out of date with current OE-core master: meta-fsl-arm/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend It does not apply because these changes have moved upstream. Can someone please remove it? Could you prepare a patch? :-) I really don't feel comfortable with that as I don't know that much about the recipe/tool. To me it does look like the previous patch is just out of date, but I'm not 100% certain, I just see that as is, meta-fsl-arm (master) is broken. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Out of date patch
This recipe/patch is out of date with current OE-core master: meta-fsl-arm/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend It does not apply because these changes have moved upstream. Can someone please remove it? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] imx-kobs 5.4 recipe update for jethro
On 2016-06-14 11:51, Palacios, Hector wrote: Hello, Current version 5.3 of imx-kobs in Jethro does not write correctly FCB blocks for the i.MX6UL, preventing it from booting from the NAND. Version 5.4 in 'meta-fsl-bsp-release' on the other hand works fine. Could we have this recipe updated to 5.4 for Jethro, as it has been updated in the past? This would just be a request to merge the current recipe from master to jethro. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Out of date .bbappend
ERROR: No recipes available for: /local/poky-cutting-edge/meta-fsl-arm/browser-layer/recipes-browser/chromium/chromium_40.0.2214.91.bbappend chromium recipe has upgraded to chromium_48.0.2548.0.bb making this file out of date (and breaking builds) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] ERROR during do_rootfs (no package provides libX11.so.6)
On 2016-05-04 15:08, Daniel Oliveira wrote: Sorry for the lack of information, but I am a newb on yocto. This what I get when I run bitbake Build Configuration: BB_VERSION= "1.28.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-15.10" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "imx6qsabresd" DISTRO= "poky" DISTRO_VERSION= "2.0.1" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU= "vfp-neon" meta meta-yocto= "HEAD:6dba9abd43f7584178de52b623c603a5d4fcec5c" meta-oe meta-multimedia = "HEAD:c305ac5d2f5285d5eec8952a4ca7f3b4f89aed96" meta-fsl-arm = "HEAD:19fa4c0ae14f38cfba52c9b65494b8f066c36a66" meta-fsl-arm-extra = "HEAD:dd074c47af53948041f6c5671e519fbf815b0980" meta-fsl-demos= "HEAD:8bffde8d803dd2362fbded79781ce084d723b048" meta-qt5 = "jethro:ea37a0bc987aa9484937ad68f762b4657c198617" meta-ruby meta-multimedia = "HEAD:c305ac5d2f5285d5eec8952a4ca7f3b4f89aed96" So this is jethro release. Looking at 'local.conf' - why do you have this line? DISTRO_FEATURES_remove = "wayland nfc 3g ppp bluetooth x11" This says that you don't want X11 support in your system. You can't have it both ways :-( Either keep X11 so you can build the multi-media image or pick a different image. Note: you should send your replies to the mailing list so that everyone benefits. 2016-05-04 13:38 GMT+01:00 Gary Thomas mailto:g...@mlbassoc.com>>: On 2016-05-04 14:32, Daniel Oliveira wrote: I am building /fsl-image-multimedia-full/ on /jethro /branch for iMX SABRE SD and I am getting an error during the last task (do_rootfs). This is the error that I get: "Computing transaction...error: Can't install fsl-gpu-sdk-2.2.1-r0@cortexa9hf_vfp_neon_mx6qdl: no package provides libX11.so.6" Attached you can see my local.conf and bblayers.conf. I would mention that I am trying to build a stable image for using QT/QML with QtMultimedia. More data is needed - what version (GIT rev or download version/tag) do you have of all the layers (hint: it's printed when you run bitbake) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] ERROR during do_rootfs (no package provides libX11.so.6)
On 2016-05-04 14:32, Daniel Oliveira wrote: I am building /fsl-image-multimedia-full/ on /jethro /branch for iMX SABRE SD and I am getting an error during the last task (do_rootfs). This is the error that I get: "Computing transaction...error: Can't install fsl-gpu-sdk-2.2.1-r0@cortexa9hf_vfp_neon_mx6qdl: no package provides libX11.so.6" Attached you can see my local.conf and bblayers.conf. I would mention that I am trying to build a stable image for using QT/QML with QtMultimedia. More data is needed - what version (GIT rev or download version/tag) do you have of all the layers (hint: it's printed when you run bitbake) -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Alsamixer output is broken
On 2016-05-01 22:13, Fabio Estevam wrote: Hi, Does anyone know how to fix alsamixer output in Yocto? It has been broken for a long time. Please see the attached picture. Any ideas? How are you connecting to your board? I've seen this when using minicom directly to the serial port but the output is much better (correct) if I connect to the board using ssh (and hence the rendering is happening on the connecting host and not the board). I'd like to see it fixed as well, but for now I just use ssh. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Integrating arm-xilinx-linux-gnueabi- external prebuilt toolchain in meta-fsl-arm
e_sysroot', 'libiconv, do_patch', 'gettext, do_populate_sysroot']) Task 1315 (/home/krishna/fsl-release-bsp/sources/poky/meta/recipes-support/libiconv/libiconv_1.14.bb, do_compile) (dependent Tasks ['libiconv, do_configure']) Task 1311 (/home/krishna/fsl-release-bsp/sources/poky/meta/recipes-support/libiconv/libiconv_1.14.bb, do_install) (dependent Tasks ['libiconv, do_compile', 'pseudo, do_populate_sysroot']) Task 1312 (/home/krishna/fsl-release-bsp/sources/poky/meta/recipes-support/libiconv/libiconv_1.14.bb, do_populate_sysroot) (dependent Tasks ['libiconv, do_install']) Task 929 (/home/krishna/fsl-release-bsp/sources/poky/meta/recipes-core/gettext/gettext_0.18.3.2.bb, do_configure) (dependent Tasks ['libiconv, do_populate_sysroot', 'eglibc, do_populate_sysroot', 'gettext, do_populate_sysroot', 'gnu-config, do_populate_sysroot', 'gcc-runtime, do_populate_sysroot', 'autoconf, do_populate_sysroot', 'expat, do_populate_sysroot', 'libtool-native, do_populate_sysroot', 'libtool-cross, do_populate_sysroot', 'automake, do_populate_sysroot', 'gcc-cross, do_populate_sysroot', 'gettext, do_patch']) Task 930 (/home/krishna/fsl-release-bsp/sources/poky/meta/recipes-core/gettext/gettext_0.18.3.2.bb, do_compile) (dependent Tasks ['gettext, do_configure']) Thanks & Regards, Krishna Dwivedi -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra] SabreLite: Can't run epiphany
On 2016-04-15 18:16, Gary Bisson wrote: Hi Gary, On Fri, Apr 15, 2016 at 6:12 PM, Gary Thomas wrote: epiphany on my SabreLite does not run. When I try to start it, I see fleeting messages about some error trying to display the page. These repeat every few seconds, ad nauseum... Using Poky/Yocto: Build Configuration: BB_VERSION= "1.30.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-15.10" TARGET_SYS= "arm-amltd-linux-gnueabi" MACHINE = "nitrogen6x" DISTRO= "amltd" DISTRO_VERSION= "2.1+snapshot-20160415" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU= "hard" meta = "master:20a0121b558b32179220e394a66cb90dc6ff3879" meta-fsl-arm = "master:682b957545172a79cfb19108a9d0b61209f8671e" meta-fsl-arm-extra = "master:39eb21c4c24a0be6d8277b566ebd52b657fbc2bb" Check out http://www.mlbassoc.com/misc/VIDEO0036.mp4 to see this in action. CC Ian, he is the one who can help you with that. On further investigation, I don't think this is a Boundary Devices (kernel or otherwise) issue. I get the same behavior on i.MX6UL EVK -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Strange FireFox error
I just got this error running FireFox on my i.MX6Q system: [3657:3687:0416/034122:ERROR:gpu_watchdog_thread.cc(253)] The GPU process hung. Terminating after 10. [3631:3631:0416/034122:ERROR:gpu_process_transport_factory.cc(514)] Lost UI shared context. [3734:3735:0416/034134:ERROR:gpu_watchdog_thread.cc(253)] The GPU process hung. Terminating after 1 ms. At this point, FireFox was unable to continue (update the display, etc). I've only seen it once, but it's bothersome. What can I do about it? Note: this was on the SabreLite, running the latest linux-boundary_3.14.52 -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm-extra] SabreLite: Can't run epiphany
epiphany on my SabreLite does not run. When I try to start it, I see fleeting messages about some error trying to display the page. These repeat every few seconds, ad nauseum... Using Poky/Yocto: Build Configuration: BB_VERSION= "1.30.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-15.10" TARGET_SYS= "arm-amltd-linux-gnueabi" MACHINE = "nitrogen6x" DISTRO= "amltd" DISTRO_VERSION= "2.1+snapshot-20160415" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU= "hard" meta = "master:20a0121b558b32179220e394a66cb90dc6ff3879" meta-fsl-arm = "master:682b957545172a79cfb19108a9d0b61209f8671e" meta-fsl-arm-extra = "master:39eb21c4c24a0be6d8277b566ebd52b657fbc2bb" Check out http://www.mlbassoc.com/misc/VIDEO0036.mp4 to see this in action. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm][PATCH] imx-kobs: Fix compile error
On 2016-04-15 12:37, Otavio Salvador wrote: On Fri, Apr 15, 2016 at 5:43 AM, Gary Bisson wrote: Gary, All, On Fri, Apr 15, 2016 at 4:43 AM, Gary Thomas wrote: Recent compiler updates now require to use 'uintX_t' types. As a FYI, I've made a patch for that in Buildroot: https://github.com/buildroot/buildroot/blob/master/package/freescale-imx/imx-kobs/0002-Fix-build-for-recent-toolchains.patch This issue only appears with kernel headers >= 4.4 since mtd-user.h isn't including stdint.h any more. Also, for those using musl, another patch is needed: https://github.com/buildroot/buildroot/blob/master/package/freescale-imx/imx-kobs/0001-Fix-musl-build.patch Great so please rework the commit log to inform about the Kernel headers >= 4.4, GCC and please prepare another patch to support musl. New patch sent. Note that the recipe & version have been updated [today?] Also, someone else need to respond to the musl change - I'm not qualified nor do I have time to work on that. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm][PATCH v2] imx-kobs: Fix compiler error when build with recent OE-core (kernel includes from linux version >=4.4)
Signed-off-by: Gary Thomas
---
recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch | 15 +++
recipes-bsp/imx-kobs/imx-kobs_5.4.bb| 4 +++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
diff --git a/recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
b/recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
new file mode 100644
index 000..09f476b
--- /dev/null
+++ b/recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
@@ -0,0 +1,15 @@
+This patch fixes a build error with kernel includes (>= 4.4) must
+be explicitly included to get uintX_t types.
+
+Index: imx-kobs-5.4/src/BootControlBlocks.h
+===
+--- imx-kobs-5.4.orig/src/BootControlBlocks.h
imx-kobs-5.4/src/BootControlBlocks.h
+@@ -54,6 +54,7 @@
+ //! This structure holds the timing for the NAND. This data is used by
+ //! rom_nand_hal_GpmiSetNandTiming to setup the GPMI hardware registers.
+
++#include
+ typedef struct _NAND_Timing {
+ uint8_t m_u8DataSetup;
+ uint8_t m_u8DataHold;
diff --git a/recipes-bsp/imx-kobs/imx-kobs_5.4.bb
b/recipes-bsp/imx-kobs/imx-kobs_5.4.bb
index 5487160..1d33d40 100644
--- a/recipes-bsp/imx-kobs/imx-kobs_5.4.bb
+++ b/recipes-bsp/imx-kobs/imx-kobs_5.4.bb
@@ -5,7 +5,9 @@ SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-SRC_URI = "${FSL_MIRROR}/imx-kobs-${PV}.tar.gz"
+SRC_URI = "${FSL_MIRROR}/imx-kobs-${PV}.tar.gz \
+ file://fix-compile.patch \
+"
SRC_URI[md5sum] = "77467d834f858c2ec216841583e5f437"
SRC_URI[sha256sum] =
"85171b46068ac47c42fedb8104167bf9afd33dd9527ed127e1ca2eb29d7a86bf"
--
2.5.0
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] i.MX6 memory needs
I realize this is a bit off-topic but I'm hoping someone might have an idea for me. I want to run my i.MX6 targets with a fairly small amount of DDR RAM. I have a i.MX6UL which runs happily in 512MB. When I boot and check things (/proc/meminfo) I can see that very little of this memory is actually used. Sadly, if I tell the kernel to use only 256MB, it crashes with illegal address exceptions (different platforms get different errors, but they all die horribly). I've tried the same thing using qemuarm and it is quite happy with only 256MB. Any ideas about this? Will I be able to run i.MX6 with only 256MB? n.b. to test this I just added 'mem=256m' to "bootargs". -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm][PATCH] imx-kobs: Fix compile error
Recent compiler updates now require to use 'uintX_t' types.
Signed-off-by: Gary Thomas
---
recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch | 15 +++
recipes-bsp/imx-kobs/imx-kobs_5.3.bb| 4 +++-
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
diff --git a/recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
b/recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
new file mode 100644
index 000..ca2d675
--- /dev/null
+++ b/recipes-bsp/imx-kobs/imx-kobs/fix-compile.patch
@@ -0,0 +1,15 @@
+This patch fixes a build error with recent compilers ( must
+be explicitly included to get uintX_t types)
+
+Index: imx-kobs-5.3/src/BootControlBlocks.h
+===
+--- imx-kobs-5.3.orig/src/BootControlBlocks.h
imx-kobs-5.3/src/BootControlBlocks.h
+@@ -54,6 +54,7 @@
+ //! This structure holds the timing for the NAND. This data is used by
+ //! rom_nand_hal_GpmiSetNandTiming to setup the GPMI hardware registers.
+
++#include
+ typedef struct _NAND_Timing {
+ uint8_t m_u8DataSetup;
+ uint8_t m_u8DataHold;
diff --git a/recipes-bsp/imx-kobs/imx-kobs_5.3.bb
b/recipes-bsp/imx-kobs/imx-kobs_5.3.bb
index ccc4a24..d641cbf 100644
--- a/recipes-bsp/imx-kobs/imx-kobs_5.3.bb
+++ b/recipes-bsp/imx-kobs/imx-kobs_5.3.bb
@@ -5,7 +5,9 @@ SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-SRC_URI = "${FSL_MIRROR}/imx-kobs-${PV}.tar.gz"
+SRC_URI = "${FSL_MIRROR}/imx-kobs-${PV}.tar.gz \
+ file://fix-compile.patch \
+"
SRC_URI[md5sum] = "a2a9e1c3445d14c961577492313a41fb"
SRC_URI[sha256sum] =
"45f729fc2b49556f1ca9df778f52bf5cc749cfe53664c8206daab29991c5f6c1"
--
2.5.0
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Can't build manufacturing tool for imx6ulevk
On 2016-04-14 14:41, Otavio Salvador wrote: On Thu, Apr 14, 2016 at 6:25 AM, Gary Thomas wrote: Seems to be some confusion over the U-Boot style - the manufacturing tool recipe is expecting a split SPL+.img but the target builds a .imx | cp: cannot stat '/local/imx6ul_2016-02-22/tmp/work/imx6ulevk-amltd-linux-gnueabi/u-boot-imx-mfgtool/2015.04-r0/git/mx6ul_14x14_evk_config/u-boot.img': No such file or directory | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /local/imx6ul_2016-02-22/tmp/work/imx6ulevk-amltd-linux-gnueabi/u-boot-imx-mfgtool/2015.04-r0/temp/log.do_compile.1707) ERROR: Task 133 (/local/poky-cutting-edge/meta-fsl-arm/recipes-bsp/u-boot/u-boot-imx-mfgtool_2015.04.bb, do_compile) failed with exit code '1' Built with a recent master meta = "master:778121ab844af623a215430ba579a5fb3947928b" meta-fsl-arm = "master:cec4c47e33979631e85e2c933cea5182da61ad82" Any ideas how I can get the manufacturing tool built for this target? Ideally you could send the mfgtool support for the U-Boot mainline; the NXP fork is not used by the board by default, even though it is available, so you need to adapt the board file to not use SPL. I'm just trying to use the "off the shelf" [i.e. meta-fsl-arm] stuff. I didn't expect to have to work so hard to get something in master to be able to build :-( -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] kobs-ng tool?
On 2016-04-14 14:39, Otavio Salvador wrote: On Thu, Apr 14, 2016 at 3:30 AM, Gary Thomas wrote: On 2016-04-13 16:13, Otavio Salvador wrote: On Wed, Apr 13, 2016 at 11:04 AM, Gary Thomas wrote: On 2016-04-13 15:38, Otavio Salvador wrote: On Wed, Apr 13, 2016 at 8:48 AM, Gary Thomas wrote: I have a recipe (don't recall where I found it, it was a while ago) for kobs-ng_3.0.35-4.1.0.bb The tool created by this recipe doesn't seem to work with my i.MX6UL target and indeed the NAND image created does not come close to matching what the FreeScale manufacturing tool creates using the same U-Boot image. Does anyone know where I can find a more recent tool (I tried the cited website and ended up in Russia!)? I really need to get this working with my i.MX6UL target. imx-kobs ;-) Sadly, that's not building for my target. MACHINE = "imx6ulevk" meta = "master:778121ab844af623a215430ba579a5fb3947928b" meta-fsl-arm = "master:cec4c47e33979631e85e2c933cea5182da61ad82" Error log attached. Any ideas? Not on top of my head. Maybe someone inside NXP might help? I generated a patch for this problem but the recipe (and sources) are scant on details. Anyone know where I should send the patch upstream, and/or discuss issues with this tool? Update the recipe and add the patch; it is likely to be taken for next BSP release. Sure, I'll do that. Is there no way to contact upstream? There are no pointers in the recipe nor the sources. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Can't build manufacturing tool for imx6ulevk
Seems to be some confusion over the U-Boot style - the manufacturing tool recipe is expecting a split SPL+.img but the target builds a .imx | cp: cannot stat '/local/imx6ul_2016-02-22/tmp/work/imx6ulevk-amltd-linux-gnueabi/u-boot-imx-mfgtool/2015.04-r0/git/mx6ul_14x14_evk_config/u-boot.img': No such file or directory | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /local/imx6ul_2016-02-22/tmp/work/imx6ulevk-amltd-linux-gnueabi/u-boot-imx-mfgtool/2015.04-r0/temp/log.do_compile.1707) ERROR: Task 133 (/local/poky-cutting-edge/meta-fsl-arm/recipes-bsp/u-boot/u-boot-imx-mfgtool_2015.04.bb, do_compile) failed with exit code '1' Built with a recent master meta = "master:778121ab844af623a215430ba579a5fb3947928b" meta-fsl-arm = "master:cec4c47e33979631e85e2c933cea5182da61ad82" Any ideas how I can get the manufacturing tool built for this target? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] kobs-ng tool?
On 2016-04-13 16:13, Otavio Salvador wrote: On Wed, Apr 13, 2016 at 11:04 AM, Gary Thomas wrote: On 2016-04-13 15:38, Otavio Salvador wrote: On Wed, Apr 13, 2016 at 8:48 AM, Gary Thomas wrote: I have a recipe (don't recall where I found it, it was a while ago) for kobs-ng_3.0.35-4.1.0.bb The tool created by this recipe doesn't seem to work with my i.MX6UL target and indeed the NAND image created does not come close to matching what the FreeScale manufacturing tool creates using the same U-Boot image. Does anyone know where I can find a more recent tool (I tried the cited website and ended up in Russia!)? I really need to get this working with my i.MX6UL target. imx-kobs ;-) Sadly, that's not building for my target. MACHINE = "imx6ulevk" meta = "master:778121ab844af623a215430ba579a5fb3947928b" meta-fsl-arm = "master:cec4c47e33979631e85e2c933cea5182da61ad82" Error log attached. Any ideas? Not on top of my head. Maybe someone inside NXP might help? I generated a patch for this problem but the recipe (and sources) are scant on details. Anyone know where I should send the patch upstream, and/or discuss issues with this tool? Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] kobs-ng tool?
On 2016-04-13 16:04, Gary Thomas wrote: On 2016-04-13 15:38, Otavio Salvador wrote: On Wed, Apr 13, 2016 at 8:48 AM, Gary Thomas wrote: I have a recipe (don't recall where I found it, it was a while ago) for kobs-ng_3.0.35-4.1.0.bb The tool created by this recipe doesn't seem to work with my i.MX6UL target and indeed the NAND image created does not come close to matching what the FreeScale manufacturing tool creates using the same U-Boot image. Does anyone know where I can find a more recent tool (I tried the cited website and ended up in Russia!)? I really need to get this working with my i.MX6UL target. imx-kobs ;-) Sadly, that's not building for my target. MACHINE = "imx6ulevk" meta = "master:778121ab844af623a215430ba579a5fb3947928b" meta-fsl-arm = "master:cec4c47e33979631e85e2c933cea5182da61ad82" Error log attached. Any ideas? BTW, I'm still using GCC-4.9.3 -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] kobs-ng tool?
On 2016-04-13 15:38, Otavio Salvador wrote: On Wed, Apr 13, 2016 at 8:48 AM, Gary Thomas wrote: I have a recipe (don't recall where I found it, it was a while ago) for kobs-ng_3.0.35-4.1.0.bb The tool created by this recipe doesn't seem to work with my i.MX6UL target and indeed the NAND image created does not come close to matching what the FreeScale manufacturing tool creates using the same U-Boot image. Does anyone know where I can find a more recent tool (I tried the cited website and ended up in Russia!)? I really need to get this working with my i.MX6UL target. imx-kobs ;-) Sadly, that's not building for my target. MACHINE = "imx6ulevk" meta = "master:778121ab844af623a215430ba579a5fb3947928b" meta-fsl-arm = "master:cec4c47e33979631e85e2c933cea5182da61ad82" Error log attached. Any ideas? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common'] DEBUG: Executing shell function do_compile NOTE: make -j 4 Making all in include make[1]: Entering directory '/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0/build/include' make all-am make[2]: Entering directory '/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0/build/include' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0/build/include' make[1]: Leaving directory '/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0/build/include' Making all in src make[1]: Entering directory '/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0/build/src' arm-amltd-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk -DHAVE_CONFIG_H -I. -I../../imx-kobs-5.3/src -I../include -I../../imx-kobs-5.3/include-O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0=/usr/src/debug/imx-kobs/5.3-r0 -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/x86_64-linux= -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk= -Wall -c -o main.o ../../imx-kobs-5.3/src/main.c arm-amltd-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk -DHAVE_CONFIG_H -I. -I../../imx-kobs-5.3/src -I../include -I../../imx-kobs-5.3/include-O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0=/usr/src/debug/imx-kobs/5.3-r0 -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/x86_64-linux= -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk= -Wall -c -o mtd.o ../../imx-kobs-5.3/src/mtd.c arm-amltd-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk -DHAVE_CONFIG_H -I. -I../../imx-kobs-5.3/src -I../include -I../../imx-kobs-5.3/include-O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0=/usr/src/debug/imx-kobs/5.3-r0 -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/x86_64-linux= -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk= -Wall -c -o rom_nand_hamming_code_ecc.o ../../imx-kobs-5.3/src/rom_nand_hamming_code_ecc.c arm-amltd-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk -DHAVE_CONFIG_H -I. -I../../imx-kobs-5.3/src -I../include -I../../imx-kobs-5.3/include-O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/imx-kobs/5.3-r0=/usr/src/debug/imx-kobs/5.3-r0 -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/x86_64-linux= -fdebug-prefix-map=/local/imx6ul_2016-02-22/tmp/sysroots/imx6ulevk= -Wall -c -o ncb.o ../../imx-kobs-5.3/src/ncb.c In file included from ../../imx-kobs-5.3/src/mtd.h:31:0, from ../../imx-kobs-5.3/src/ncb.c:30: ../../imx-kobs-5.3/src/BootControlBlocks.h:58:2: error: unknown type name 'uint8_t' uint8_t m_u8DataSetup; ^ ../../imx-kobs-5.3/
[meta-freescale] [meta-fsl-arm] kobs-ng tool?
I have a recipe (don't recall where I found it, it was a while ago) for kobs-ng_3.0.35-4.1.0.bb The tool created by this recipe doesn't seem to work with my i.MX6UL target and indeed the NAND image created does not come close to matching what the FreeScale manufacturing tool creates using the same U-Boot image. Does anyone know where I can find a more recent tool (I tried the cited website and ended up in Russia!)? I really need to get this working with my i.MX6UL target. Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra][PATCH] linux-boundary: Bump kernel version to 3.14.52
On 2016-03-30 08:22, Gary Thomas wrote: On 2016-03-28 16:59, Otavio Salvador wrote: On Fri, Mar 25, 2016 at 8:16 PM, Ian Coolidge wrote: Kernel based on 3.14.52-1.1.0 GA release Main new changes are added support for Nitrogen7 and Nitrogen6QP_MAX Removal of linux-boundary_3.14.28 kernel recipe Removal of linux-boundary_3.14.38-6qp kernel recipe Signed-off-by: Ian Coolidge I applied this to master and master-next; if all goes well, please remind me in few days to backport this for Jethro. I just tried to build this recipe and got a fetcher error: WARNING: linux-boundary-3.14.52-r0 do_fetch: Failed to fetch URL git://github.com/boundarydevices/linux-imx6.git;branch=boundary-imx_3.14.52_1.1.0_ga, attempting MIRRORS if available ERROR: linux-boundary-3.14.52-r0 do_fetch: Fetcher failure: Unable to find revision 6ec10717cc47612c67b99011eb43829fb8bb8576 in branch boundary-imx_3.14.52_1.1.0_ga even from upstream ERROR: linux-boundary-3.14.52-r0 do_fetch: Function failed: Fetcher failure for URL: 'git://github.com/boundarydevices/linux-imx6.git;branch=boundary-imx_3.14.52_1.1.0_ga'. Unable to fetch URL from any source. I then cloned this repo manually and saw the same thing (that rev isn't anywhere to be found). Interestingly, I pulled from this same repo yesterday and that revision was there. Any ideas what's going on? BTW, here are the top commits from today's clone/fetch for branch boundary-imx_3.14.52_1.1.0_ga: commit 9af660ea819fa2911b66ef71f964e98fcb718453 Author: Fabio Estevam Date: Sat Feb 7 15:46:41 2015 -0200 serial: imx: Do not store/restore the UBRC register commit 148c4ffe325204cd6556f726cdc06e26ee504446 Author: Troy Kisky Date: Thu Mar 24 17:33:36 2016 -0700 serial: imx: fix ^c hang cause by imx_flush_buffer Yesterday's: commit b9db4fe48ce1a902cf144962368e92a17987e708 Author: Troy Kisky Date: Mon Mar 28 19:28:04 2016 -0700 usbmisc_imx: fix hsic hang commit 6ec10717cc47612c67b99011eb43829fb8bb8576 Author: Gary Bisson Date: Fri Mar 25 15:39:26 2016 +0100 ARM: dts: imx7d-nitrogen7: fix uart6 clock assignment commit bfd170a8ba6c31d639a1d1b22331061739d12194 Author: Lucas Stach Date: Fri Sep 4 17:52:41 2015 +0200 serial: imx: don't use idle condition detect for DMA transfers Note that the desired branch/revision was there yesterday, but not today :-( -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra][PATCH] linux-boundary: Bump kernel version to 3.14.52
On 2016-03-28 16:59, Otavio Salvador wrote: On Fri, Mar 25, 2016 at 8:16 PM, Ian Coolidge wrote: Kernel based on 3.14.52-1.1.0 GA release Main new changes are added support for Nitrogen7 and Nitrogen6QP_MAX Removal of linux-boundary_3.14.28 kernel recipe Removal of linux-boundary_3.14.38-6qp kernel recipe Signed-off-by: Ian Coolidge I applied this to master and master-next; if all goes well, please remind me in few days to backport this for Jethro. I just tried to build this recipe and got a fetcher error: WARNING: linux-boundary-3.14.52-r0 do_fetch: Failed to fetch URL git://github.com/boundarydevices/linux-imx6.git;branch=boundary-imx_3.14.52_1.1.0_ga, attempting MIRRORS if available ERROR: linux-boundary-3.14.52-r0 do_fetch: Fetcher failure: Unable to find revision 6ec10717cc47612c67b99011eb43829fb8bb8576 in branch boundary-imx_3.14.52_1.1.0_ga even from upstream ERROR: linux-boundary-3.14.52-r0 do_fetch: Function failed: Fetcher failure for URL: 'git://github.com/boundarydevices/linux-imx6.git;branch=boundary-imx_3.14.52_1.1.0_ga'. Unable to fetch URL from any source. I then cloned this repo manually and saw the same thing (that rev isn't anywhere to be found). Interestingly, I pulled from this same repo yesterday and that revision was there. Any ideas what's going on? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] yocto and linux Mint 17.3
On 2016-02-05 12:00, idealsim wrote: I think i move my host machine to another distro, what do you think about kubuntu 14.04 lts or ubuntu 14.10 lts is better for yocto ? Kubuntu 15.10 works perfectly with Yocto. Le Fri, 05 Feb 2016 09:17:23 +0100, idealsim a écrit: thank's for you help but i already install it (sorry it's in french, but already install) : /mls@be-linuxHpZ400 ~ $ sudo apt-get install python-pysqlite2 [sudo] password for mls: Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait python-pysqlite2 est déjà la plus récente version disponible. 0 mis à jour, 0 nouvellement installés, 0 à enlever et 104 non mis à jour/ same with synaptic (see picture join) Otherwise, i reset all my yocto directory (repo with) to restart from scratch, but now i can't init my repo ?! /mls@be-linuxHpZ400 ~/fsl-release-bsp $ repo init fatal: Cannot get https://gerrit.googlesource.com/git-repo/clone.bundle fatal: error unknown url type: http/ and if i test the git port i obtain this : /mls@be-linuxHpZ400 ~/fsl-release-bsp $ nmap github.com -p https,git Starting Nmap 6.40 ( http://nmap.org ) at 2016-02-04 18:31 CET Nmap scan report for github.com (192.30.252.128) Host is up (0.0049s latency). PORT STATE SERVICE 443/tcp filtered https 9418/tcp filtered git Nmap done: 1 IP address (1 host up) scanned in 2.55 seconds mls@be-linuxHpZ400 ~/fsl-release-bsp $ nmap github.com -p http,git Starting Nmap 6.40 ( http://nmap.org ) at 2016-02-04 18:31 CET Nmap scan report for github.com (192.30.252.128) Host is up (0.013s latency). PORT STATE SERVICE 80/tcp open http 8008/tcp open http 9418/tcp filtered git/ Apparently the git port is filtered (normaly open !) and if i try a repo init on my virtual machine (under ubuntu 12.04) it works !!! Le Thu, 04 Feb 2016 18:01:20 +0100, Esponde, Joel a écrit: Hi, You should try to install pysqlite2 like this: sudo apt-get install |python-pysqlite2| || It works well in a pure Ubuntu 14.04 installation. Joël *De :*meta-freescale-boun...@yoctoproject.org [mailto:meta-freescale-boun...@yoctoproject.org] *De la part de* idealsim *Envoyé :* jeudi 4 février 2016 13:13 *À :* meta-freescale@yoctoproject.org *Objet :* [meta-freescale] yocto and linux Mint 17.3 Hi all, i have a problem to start a buil with a host pc. My pc is under linux mint 17.3 (cinnamon) 64 bits, Linux Mint 17.3 is based on Ubuntu 14.04. When i launch a bitbake, i have this error : /ImportError: No module named pysqlite2// //home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/event.py:107: RuntimeWarning: Parent module 'bb' not found while handling absolute import/ /from bb.msg import BBLogFormatter/ /Error in atexit._run_exitfuncs:/ /Traceback (most recent call last):/ /File "/usr/local/lib/python2.7/atexit.py", line 24, in _run_exitfuncs/ /func(*targs, **kargs)/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/event.py", line 107, in print_ui_queue/ /from bb.msg import BBLogFormatter/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/__init__.py", line 77, in / /from bb import fetch2 as fetch/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/fetch2/__init__.py", line 37, in / /import bb.persist_data, bb.utils/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/persist_data.py", line 35, in / /from pysqlite2 import dbapi2 as sqlite3/ /ImportError: No module named pysqlite2/ /Error in sys.exitfunc:/ /Traceback (most recent call last):/ /File "/usr/local/lib/python2.7/atexit.py", line 24, in _run_exitfuncs/ /func(*targs, **kargs)/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/event.py", line 107, in print_ui_queue/ /from bb.msg import BBLogFormatter/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/__init__.py", line 77, in / /from bb import fetch2 as fetch/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/fetch2/__init__.py", line 37, in / /import bb.persist_data, bb.utils/ /File "/home/mls/bin/fsl-release-bsp/sources/poky/bitbake/lib/bb/persist_data.py", line 35, in / /from pysqlite2 import dbapi2 as sqlite3/ /ImportError: No module named pysqlite2// apparently bb can't import pysqlite2 ? I already install pip install pysqlite libsqlite3-dev but nothing to
Re: [meta-freescale] [meta-fsl-arm] Multiple U-Boot configurations
On 01/25/2016 05:05 PM, Gary Thomas wrote: On 01/25/2016 04:48 PM, Max Krummenacher wrote: 2016-01-25 16:18 GMT+01:00 Gary Thomas : On 01/25/2016 03:42 PM, Max Krummenacher wrote: Hi Gary 2016-01-25 15:10 GMT+01:00 Gary Thomas : I have a board which can be deployed with either i.MX6Q or i.MX6solo I have U-Boot configurations for both. I'm trying to use a single build (bitbake u-boot-fslc) to create both U-Boot images, using UBOOT_MACHINE ?= "teton_p8303_config teton_p8303s_config" Sadly, it's failing: | Configuring for teton_p8303 - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303q.cfg,MX6Q,DDR_MB=2048 | Configuring for teton_p8303s - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303.cfg,MX6S,DDR_MB=1024 | ln: failed to create symbolic link 'asm/arch': File exists | Makefile:468: recipe for target 'teton_p8303_config' failed Obviously, I don't understand the mechanism and I don't see a working example in either meta-fsl-arm or meta-fsl-arm-extra Any pointers would be great Have you tried something like this: https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/apalis-imx6.conf#L24 So in your .conf: UBOOT_CONFIG ??= "s" UBOOT_CONFIG[q] = "teton_p8303_config" UBOOT_CONFIG[s] = "teton_p8303s_config" Which I expect to build a u-boot.imx, u-boot.imx-s What if I want to build u-boot.imx-q and u-boot.imx-s? I want to build all possible versions and decide only when I install which to use. I expect that you get a binary for each of your UBOOT_CONFIG[]. And what is set by UBOOT_CONFIG = "s" is the default one. Thanks, I'll give it a go. That works, thanks. However, to get the i.MX6Q version to be the default and get both versions created, I had to write this: UBOOT_CONFIG ??= "s q" UBOOT_CONFIG[q] = "teton_p8303_config" UBOOT_CONFIG[s] = "teton_p8303s_config" -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Multiple U-Boot configurations
On 01/25/2016 04:48 PM, Max Krummenacher wrote: 2016-01-25 16:18 GMT+01:00 Gary Thomas : On 01/25/2016 03:42 PM, Max Krummenacher wrote: Hi Gary 2016-01-25 15:10 GMT+01:00 Gary Thomas : I have a board which can be deployed with either i.MX6Q or i.MX6solo I have U-Boot configurations for both. I'm trying to use a single build (bitbake u-boot-fslc) to create both U-Boot images, using UBOOT_MACHINE ?= "teton_p8303_config teton_p8303s_config" Sadly, it's failing: | Configuring for teton_p8303 - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303q.cfg,MX6Q,DDR_MB=2048 | Configuring for teton_p8303s - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303.cfg,MX6S,DDR_MB=1024 | ln: failed to create symbolic link 'asm/arch': File exists | Makefile:468: recipe for target 'teton_p8303_config' failed Obviously, I don't understand the mechanism and I don't see a working example in either meta-fsl-arm or meta-fsl-arm-extra Any pointers would be great Have you tried something like this: https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/apalis-imx6.conf#L24 So in your .conf: UBOOT_CONFIG ??= "s" UBOOT_CONFIG[q] = "teton_p8303_config" UBOOT_CONFIG[s] = "teton_p8303s_config" Which I expect to build a u-boot.imx, u-boot.imx-s What if I want to build u-boot.imx-q and u-boot.imx-s? I want to build all possible versions and decide only when I install which to use. I expect that you get a binary for each of your UBOOT_CONFIG[]. And what is set by UBOOT_CONFIG = "s" is the default one. Thanks, I'll give it a go. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Multiple U-Boot configurations
On 01/25/2016 03:42 PM, Max Krummenacher wrote: Hi Gary 2016-01-25 15:10 GMT+01:00 Gary Thomas : I have a board which can be deployed with either i.MX6Q or i.MX6solo I have U-Boot configurations for both. I'm trying to use a single build (bitbake u-boot-fslc) to create both U-Boot images, using UBOOT_MACHINE ?= "teton_p8303_config teton_p8303s_config" Sadly, it's failing: | Configuring for teton_p8303 - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303q.cfg,MX6Q,DDR_MB=2048 | Configuring for teton_p8303s - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303.cfg,MX6S,DDR_MB=1024 | ln: failed to create symbolic link 'asm/arch': File exists | Makefile:468: recipe for target 'teton_p8303_config' failed Obviously, I don't understand the mechanism and I don't see a working example in either meta-fsl-arm or meta-fsl-arm-extra Any pointers would be great Have you tried something like this: https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/apalis-imx6.conf#L24 So in your .conf: UBOOT_CONFIG ??= "s" UBOOT_CONFIG[q] = "teton_p8303_config" UBOOT_CONFIG[s] = "teton_p8303s_config" Which I expect to build a u-boot.imx, u-boot.imx-s What if I want to build u-boot.imx-q and u-boot.imx-s? I want to build all possible versions and decide only when I install which to use. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Multiple U-Boot configurations
I have a board which can be deployed with either i.MX6Q or i.MX6solo I have U-Boot configurations for both. I'm trying to use a single build (bitbake u-boot-fslc) to create both U-Boot images, using UBOOT_MACHINE ?= "teton_p8303_config teton_p8303s_config" Sadly, it's failing: | Configuring for teton_p8303 - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303q.cfg,MX6Q,DDR_MB=2048 | Configuring for teton_p8303s - Board: teton_p8303, Options: IMX_CONFIG=board/amltd/teton_p8303/teton_p8303.cfg,MX6S,DDR_MB=1024 | ln: failed to create symbolic link 'asm/arch': File exists | Makefile:468: recipe for target 'teton_p8303_config' failed Obviously, I don't understand the mechanism and I don't see a working example in either meta-fsl-arm or meta-fsl-arm-extra Any pointers would be great Thanks -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] All thumb i.MX6?
Is it possible to build Poky/Yocto for the i.MX6 using only thumb binaries? Could this be done by adjusting the machine tune (cortexa9hf-vfp-neon)? If so, how? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Using older kernels
On 2015-11-30 08:38, Otavio Salvador wrote: On Mon, Nov 30, 2015 at 1:32 PM, Gary Thomas wrote: On 2015-11-30 05:48, Otavio Salvador wrote: On Fri, Nov 27, 2015 at 9:09 PM, Gary Thomas wrote: I have a customer that wants to stay with the old LTS (3.10.53) kernel. Is there any way to use this kernel with the remainder of meta-fsl-arm*, in particular with respect to the Vivante graphics engine? Using Jethro, the kernel module system should just work. Indeed, it is working, although I'm not sure why it was not when I sent this original message (nothing has really changed...) I sent a fix for galcore loading; it might have helped? Maybe that's it. In the end, I'm just happy it's working :-) -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Using older kernels
On 2015-11-30 05:48, Otavio Salvador wrote: On Fri, Nov 27, 2015 at 9:09 PM, Gary Thomas wrote: I have a customer that wants to stay with the old LTS (3.10.53) kernel. Is there any way to use this kernel with the remainder of meta-fsl-arm*, in particular with respect to the Vivante graphics engine? Using Jethro, the kernel module system should just work. Indeed, it is working, although I'm not sure why it was not when I sent this original message (nothing has really changed...) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] Using older kernels
I have a customer that wants to stay with the old LTS (3.10.53) kernel. Is there any way to use this kernel with the remainder of meta-fsl-arm*, in particular with respect to the Vivante graphics engine? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] gstreamer1.0-plugins-bad failure
The platform specific patch for gstreamer1.0-plugins-bad no longer applies with the current OE-core master (after update to gstreamer-1.6.1). ERROR: Command Error: exit status: 1 Output: Applying patch 0001-PATCH-install-gstaggregator-and-gstvideoaggregator-h.patch patching file gst-libs/gst/base/Makefile.am patching file gst-libs/gst/video/Makefile.am Hunk #1 FAILED at 19. 1 out of 1 hunk FAILED -- rejects in file gst-libs/gst/video/Makefile.am Patch 0001-PATCH-install-gstaggregator-and-gstvideoaggregator-h.patch does not apply (enforce with -f) ERROR: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /local/p0382-cutting-edge_2014-11-21/tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/gstreamer1.0-plugins-bad/1.6.1-r0/temp/log.do_patch.24379 ERROR: Task 1 (/local/poky-cutting-edge/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.6.1.bb, do_patch) failed with exit code '1' I adjusted the patch but I'm not comfortable replacing the boilerplate as it's attributed to Mingke Wang Perhaps someone at Freescale can fix this properly? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world Index: gst-plugins-bad-1.6.1/gst-libs/gst/base/Makefile.am === --- gst-plugins-bad-1.6.1.orig/gst-libs/gst/base/Makefile.am +++ gst-plugins-bad-1.6.1/gst-libs/gst/base/Makefile.am @@ -6,11 +6,12 @@ libgstbadbase_@GST_API_VERSION@_la_SOURC libgstbadbase_@GST_API_VERSION@_la_CFLAGS = $(GST_CFLAGS) \ -DGST_USE_UNSTABLE_API +libgstbadbase_@GST_API_VERSION@includedir = $(includedir)/gstreamer-@GST_API_VERSION@/gst/base +libgstbadbase_@GST_API_VERSION@include_HEADERS = \ +gstaggregator.h + libgstbadbase_@GST_API_VERSION@_la_LIBADD = $(GST_LIBS) libgstbadbase_@GST_API_VERSION@_la_LDFLAGS = $(GST_LIB_LDFLAGS) $(GST_ALL_LDFLAGS) $(GST_LT_LDFLAGS) -noinst_HEADERS = \ - gstaggregator.h - EXTRA_DIST = Index: gst-plugins-bad-1.6.1/gst-libs/gst/video/Makefile.am === --- gst-plugins-bad-1.6.1.orig/gst-libs/gst/video/Makefile.am +++ gst-plugins-bad-1.6.1/gst-libs/gst/video/Makefile.am @@ -16,6 +16,11 @@ libgstbadvideo_@GST_API_VERSION@_la_CFLA $(GST_PLUGINS_BASE_CFLAGS) \ $(GST_BASE_CFLAGS) +libgstbadvideo_@GST_API_VERSION@includedir = $(includedir)/gstreamer-@GST_API_VERSION@/gst/video +libgstbadvideo_@GST_API_VERSION@include_HEADERS = \ +gstvideoaggregatorpad.h \ +gstvideoaggregator.h + libgstbadvideo_@GST_API_VERSION@_la_LIBADD = \ $(top_builddir)/gst-libs/gst/base/libgstbadbase-$(GST_API_VERSION).la \ $(GST_PLUGINS_BASE_LIBS) -lgstvideo-$(GST_API_VERSION) \ -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra] nitrogen6x: ov5642 support in master/jethro broken
On 2015-11-16 14:27, Ian Coolidge wrote:
Gary/Carlos,
What U-Boot version are you running? You need the new 2015-07 boundary u-boot
to work with the new 3.14.28 kernel.
U-Boot 2015.07 (Sep 23 2015 - 09:05:20 -0600)
Is there anything newer?
Thanks,
-Ian Coolidge
On Wed, Nov 11, 2015 at 7:50 AM, Gary Thomas mailto:g...@mlbassoc.com>> wrote:
On 2015-11-11 08:42, Carlos Rafael Giani wrote:
Yes, same here. The thing is, my camera is an ov5642 module.
What's really interesting is that the ov5642 doesn't seem to even
show up on the I2C bus with the newer kernel:
3.10.53:
root@nitrogen6x:~# i2cdetect -r -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- UU UU --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
3.14.28:
root@nitrogen6x:~# i2cdetect -r -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
0x3d is the ov5642 and 0x3e is ov5640_mipi
On 2015-11-11 16:37, Gary Thomas wrote:
On 2015-11-10 18:56, Ian Coolidge wrote:
Carlos,
To follow up, I tested both the 3.14.28 image on jethro and the
old 3.10.53 fido image in the blogpost I mentioned and both worked. Granted it
took me two tries to
get the ribbon
cable seated properly, maybe you're having the same issues?
You should see "camera ov5640 is found" in dmesg if it properly
detects the hardware. Then you can run this gst command to show it on the screen
"gst-launch-1.0
imxv4l2videosrc
device=/dev/video0 ! autovideosink".
I just verified this on my SabreLite which has OV5642 & OV5640_MIPI
installed.
With the 3.10.53 kernel built in July, both sensors are found and
function.
With the 3.14.28 kernel built today, only the OV5640_MIPI is found.
Thanks!
-Ian Coolidge
On Tue, Nov 10, 2015 at 3:25 PM, Ian Coolidge mailto:i...@boundarydevices.com> <mailto:i...@boundarydevices.com
<mailto:i...@boundarydevices.com>>> wrote:
Hello Carlos,
What kernel are you running? If it's the new 3.14.28
kernel you'll need to upgrade your u-boot version to our 2015.07 u-boot. I've
written a blogpost about it
here:
https://boundarydevices.com/compiling-latest-u-boot-for-i-mx6-2015-edition/.
If you want to keep your old u-boot version, or want an
image that works for the old u-boot, we have images on this blogpost that will
work and have been
tested against that
hardware:
https://boundarydevices.com/fido-release-of-yocto/
Thanks,
-Ian Coolidge
On Mon, Nov 9, 2015 at 2:29 PM, Otavio Salvador
mailto:otavio.salva...@ossystems.com.br>
<mailto:otavio.salva...@ossystems.com.br
<mailto:otavio.salva...@ossystems.com.br>>> wrote:
Hello Carlos,
On Mon, Nov 9, 2015 at 7:25 PM, Carlos Rafael Giani
mailto:d...@pseudoterminal.org>
<mailto:d...@pseudoterminal.org <mailto:d...@pseudoterminal.org>>> wrote:
> I tried to use the nitrogen6x' camera, and saw that
no ov5642 hardware was
> detected. The kernel module was loaded.
> With the fido kernel and the exact same hardware, it
works just fine.
> Is this a known issue?
Added Boundary's fellows on Cc.
--
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: [meta-freescale] [meta-fsl-arm-extra] nitrogen6x: ov5642 support in master/jethro broken
On 2015-11-11 08:42, Carlos Rafael Giani wrote: Yes, same here. The thing is, my camera is an ov5642 module. What's really interesting is that the ov5642 doesn't seem to even show up on the I2C bus with the newer kernel: 3.10.53: root@nitrogen6x:~# i2cdetect -r -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- UU UU -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 3.14.28: root@nitrogen6x:~# i2cdetect -r -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 0x3d is the ov5642 and 0x3e is ov5640_mipi On 2015-11-11 16:37, Gary Thomas wrote: On 2015-11-10 18:56, Ian Coolidge wrote: Carlos, To follow up, I tested both the 3.14.28 image on jethro and the old 3.10.53 fido image in the blogpost I mentioned and both worked. Granted it took me two tries to get the ribbon cable seated properly, maybe you're having the same issues? You should see "camera ov5640 is found" in dmesg if it properly detects the hardware. Then you can run this gst command to show it on the screen "gst-launch-1.0 imxv4l2videosrc device=/dev/video0 ! autovideosink". I just verified this on my SabreLite which has OV5642 & OV5640_MIPI installed. With the 3.10.53 kernel built in July, both sensors are found and function. With the 3.14.28 kernel built today, only the OV5640_MIPI is found. Thanks! -Ian Coolidge On Tue, Nov 10, 2015 at 3:25 PM, Ian Coolidge mailto:i...@boundarydevices.com>> wrote: Hello Carlos, What kernel are you running? If it's the new 3.14.28 kernel you'll need to upgrade your u-boot version to our 2015.07 u-boot. I've written a blogpost about it here: https://boundarydevices.com/compiling-latest-u-boot-for-i-mx6-2015-edition/. If you want to keep your old u-boot version, or want an image that works for the old u-boot, we have images on this blogpost that will work and have been tested against that hardware: https://boundarydevices.com/fido-release-of-yocto/ Thanks, -Ian Coolidge On Mon, Nov 9, 2015 at 2:29 PM, Otavio Salvador mailto:otavio.salva...@ossystems.com.br>> wrote: Hello Carlos, On Mon, Nov 9, 2015 at 7:25 PM, Carlos Rafael Giani mailto:d...@pseudoterminal.org>> wrote: > I tried to use the nitrogen6x' camera, and saw that no ov5642 hardware was > detected. The kernel module was loaded. > With the fido kernel and the exact same hardware, it works just fine. > Is this a known issue? Added Boundary's fellows on Cc. -- 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 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra] nitrogen6x: ov5642 support in master/jethro broken
On 2015-11-10 18:56, Ian Coolidge wrote: Carlos, To follow up, I tested both the 3.14.28 image on jethro and the old 3.10.53 fido image in the blogpost I mentioned and both worked. Granted it took me two tries to get the ribbon cable seated properly, maybe you're having the same issues? You should see "camera ov5640 is found" in dmesg if it properly detects the hardware. Then you can run this gst command to show it on the screen "gst-launch-1.0 imxv4l2videosrc device=/dev/video0 ! autovideosink". I just verified this on my SabreLite which has OV5642 & OV5640_MIPI installed. With the 3.10.53 kernel built in July, both sensors are found and function. With the 3.14.28 kernel built today, only the OV5640_MIPI is found. Thanks! -Ian Coolidge On Tue, Nov 10, 2015 at 3:25 PM, Ian Coolidge mailto:i...@boundarydevices.com>> wrote: Hello Carlos, What kernel are you running? If it's the new 3.14.28 kernel you'll need to upgrade your u-boot version to our 2015.07 u-boot. I've written a blogpost about it here: https://boundarydevices.com/compiling-latest-u-boot-for-i-mx6-2015-edition/. If you want to keep your old u-boot version, or want an image that works for the old u-boot, we have images on this blogpost that will work and have been tested against that hardware: https://boundarydevices.com/fido-release-of-yocto/ Thanks, -Ian Coolidge On Mon, Nov 9, 2015 at 2:29 PM, Otavio Salvador mailto:otavio.salva...@ossystems.com.br>> wrote: Hello Carlos, On Mon, Nov 9, 2015 at 7:25 PM, Carlos Rafael Giani mailto:d...@pseudoterminal.org>> wrote: > I tried to use the nitrogen6x' camera, and saw that no ov5642 hardware was > detected. The kernel module was loaded. > With the fido kernel and the exact same hardware, it works just fine. > Is this a known issue? Added Boundary's fellows on Cc. -- 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 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Build problems with MSC Q7, Yocto and Chromium
On 2015-10-29 09:10, Gary MacDonald wrote: Thanks, I'm using the MSC provided build of Yocto which is based on Dizzy, my GCC version is 4.8.4. the log file is as follows: Build Configuration: BB_VERSION= "1.24.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-14.04" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "q7imx6_demo" DISTRO= "poky" DISTRO_VERSION= "1.7.1" TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa9" TARGET_FPU= "vfp-neon" meta meta-yocto meta-yocto-bsp= "dizzy-msc:ff482c2522f7092216a4ac7b335393a5294d97d5" meta-msc-ldk-core = "MyMscLdk:ea32771751fe4747d3f4bcaaf3587cb024410337" meta = "master:1c61d459a72806e1277d789f12d696e3bf5d1504" meta-fsl-arm.git = "dizzy:de09415bac404f1edd25f0d84f90b2dc3ce7bb82" meta-fsl-demos.git = "dizzy:48cb0bcdd226d2e7eee1fdc222713e1dff93342c" meta-oe = "dizzy:6413cdb66acf43059f94d0076ec9b8ad6a475b35" meta-gnome= "master:77582ef1bedd7c36c6aa708ffd474d613e55ad9d" meta-browser = "master:6ae140b29f0201fe3bb470da8c96c9e142294ebf" NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Running task 5138 of 5140 (ID: 7, /home/ub3/msc-ldk/sources/meta-msc-ldk/meta-msc-ldk-core/recipes-core/images/msc-image-base.bb <http://msc-image-base.bb>, do_rootfs) NOTE: recipe msc-image-base-1.0-r0: task do_rootfs: Started WARNING: log_check: There is a warn message in the logfile WARNING: log_check: Matched keyword: [warn] WARNING: log_check: warning: Schema 'org.freedesktop.gstreamer-0.10.default-elements' has path '/desktop/gstreamer/0.10/default-elements/'. Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated. ERROR: Error: The image creation script '/home/ub3/msc-ldk/build/CE85-demo/tmp/work/q7imx6_demo-poky-linux-gnueabi/msc-image-base/1.0-r0/temp/create_image.sdcard' returned 1: 0+0 records in 0+0 records out 0 bytes (0 B) copied, 1.6863e-05 s, 0.0 kB/s Model: (file) Disk /home/ub3/msc-ldk/build/CE85-demo/tmp/deploy/images/q7imx6_demo/msc-image-base-q7imx6_demo-20151027094908.rootfs.sdcard: 726MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End SizeType File system Flags 1 4194kB 12.6MB 8389kB primary lba 2 12.6MB 721MB 709MB primary 766+1 records in 766+1 records out 392400 bytes (392 kB) copied, 0.000782631 s, 501 MB/s mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows mkfs.vfat: unable to create /home/ub3/msc-ldk/build/CE85-demo/tmp/work/q7imx6_demo-poky-linux-gnueabi/msc-image-base/1.0-r0/boot.img mkfs.fat 3.0.26 (2014-03-07) WARNING: exit code 1 from a shell command. ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /home/ub3/msc-ldk/build/CE85-demo/tmp/work/q7imx6_demo-poky-linux-gnueabi/msc-image-base/1.0-r0/temp/log.do_rootfs.12583 NOTE: recipe msc-image-base-1.0-r0: task do_rootfs: Failed ERROR: Task 7 (/home/ub3/msc-ldk/sources/meta-msc-ldk/meta-msc-ldk-core/recipes-core/images/msc-image-base.bb <http://msc-image-base.bb>, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 5139 tasks of which 5138 didn't need to be rerun and 1 failed. It's not really clear why this is failing (no error message at the point of failure). Try applying this patch to your meta-fsl-arm tree to see if it helps: commit 928e817c442b0771f89317289046f51c07460b0f Author: Gary Thomas Date: Mon Jun 15 08:41:33 2015 -0600 image_types_fsl: Fix boot.img overwrite error On Thu, Oct 29, 2015 at 10:53 AM, Otavio Salvador mailto:otavio.salva...@ossystems.com.br>> wrote: Hello Gary, On Thu, Oct 29, 2015 at 5:55 AM, Gary MacDonald mailto:garyma...@gmail.com>> wrote: > I have an MSC Q7 board and I'm trying to build Yocto to include an > accelerated Chromium. > > I seem to be really struggling to get the HW acceleration/GPU to kick in. > I'm trying to get the OSSystems meta-browser layer to work, but for some > reason I'm unable to fathom, the build always fails at do_rootfs when I add > the CORE_IMAGE_EXTRA_INSTALL+="chromium" into the local.conf file. The MSC is not supported by FSL Community BSP so it may include subtle changes which impact this feature, or not. I suggest you to use Fido - or Jethro with GCC 4.9 - for Chromium as it is known to have issues with GCC 5.2 at this moment. Apart from that, I suggest you to check the rootfs error to see if it provides any tip where the problem is. -- Otavio Salvador
Re: [meta-freescale] Build problems with MSC Q7, Yocto and Chromium
On 2015-10-29 01:55, Gary MacDonald wrote: I have an MSC Q7 board and I'm trying to build Yocto to include an accelerated Chromium. I seem to be really struggling to get the HW acceleration/GPU to kick in. I'm trying to get the OSSystems meta-browser layer to work, but for some reason I'm unable to fathom, the build always fails at do_rootfs when I add the CORE_IMAGE_EXTRA_INSTALL+="chromium" into the local.conf file. Can you post the error (log) file somewhere? It will be hard to help without more detail. If anyone has any suggestions as to how I can get the meta-browser layer/Chromium to build or just to get the hardware acceleration going in a browser I'd be very grateful. I'm getting fed up with banging my head against the wall on this... -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Booting fido on sabrelite through u-boot
On 2015-10-28 14:51, Maciej Tucholski wrote: Hi I’m using a sabrelite board (https://boundarydevices.com/product/sabre-lite-imx6-sbc/) I used it in the past for QNX and linux, this time I am trying to get yocto 1.8 (aka fido) running on it. I was able to get fido to build on an Ubuntu machine, and I have the images, rootfs .dtb etc etc, however I am not able to boot the kernel on the board. I made several different attempts via SD card, and TFTP What I was able to find out is that in order to boot using an SD card, the u-boot stored in SPI needs to be tweaked like so: mw.l 0x020d8040 0x3040 && mw.l 0x020d8044 0x1000 reset or replaced with SPI to SD loader (https://wiki.linaro.org/Boards/MX6QSabreLite) However no luck with either approach. Currently I am xfering the fido zImage via tftp, and I am trying to get the bootz command to load it, but it hangs up on “Starting kernel ...” I am not sure if I didn’t build this right, or what exactly is going on, but I’m stuck and can’t figure this out. If I could get the kernel to build, then perhaps I can use the SD card, or nfs for the rootfs. Apologizes for any missing information, I’m new to this scene, but I worked with the board and u-boot quite a bit Most likely, the reason it hangs is because of missing bits. Did you load the appropriate DTB image? Did you set the boot params? Both of these are normally set via a script loaded from the SD card and executed as part of the boot process. It's not clear to me why you can't just boot from the SD card? -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra] errors while building boundary kernel 3.14.28
On 2015-10-19 14:07, Carlos Rafael Giani wrote: Hm, this doesn't fix it :( What rev of meta-fsl-arm-extra are you using? Ian posted some updates to this recipe recently - perhaps you could try them? Am 2015-10-19 um 21:46 schrieb Otavio Salvador: On Mon, Oct 19, 2015 at 5:26 PM, Carlos Rafael Giani wrote: I tried to build an image for a nitrogen6x, using the newest master version of Poky, meta-openembedded, and meta-fsl-arm & meta-fsl-arm-extra. However, the kernel doesn't compile. I get lots of errors like: | arch/arm/mm/cache-l2x0.o: In function `nop_flush_kern_cache_louis': | cache-l2x0.c:(.text+0xa38): multiple definition of `nop_flush_kern_cache_louis' | arch/arm/mm/dma-mapping.o:dma-mapping.c:(.text+0x1438): first defined here | arch/arm/mm/cache-l2x0.o: In function `nop_flush_user_cache_all': | cache-l2x0.c:(.text+0xa48): multiple definition of `nop_flush_user_cache_all' | arch/arm/mm/dma-mapping.o:dma-mapping.c:(.text+0x1448): first defined here | arch/arm/mm/cache-l2x0.o: In function `nop_flush_user_cache_range': | cache-l2x0.c:(.text+0xa58): multiple definition of `nop_flush_user_cache_range' | arch/arm/mm/dma-mapping.o:dma-mapping.c:(.text+0x1458): first defined here At least one other person apparently had the same problem, since I found this log paste: http://pastebin.com/rwu5a6ru Any ideas what's the cause? Yes; it needs: https://github.com/Freescale/linux-fslc/commit/22f692548037e39809c32759b5600ee066ef59e9.patch -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra][PATCH v2 1/6] linux-boundary: Bump kernel version to 3.14.28
On 2015-10-08 07:12, Otavio Salvador wrote: Gary, On Thu, Oct 8, 2015 at 10:07 AM, Gary Thomas wrote: On 2015-10-05 19:09, Ian Coolidge wrote: Kernel based on 3.14.28-1.0.0 GA release Removal of linux-boundary_3.10.53 kernel recipe Main changes are graphics update to 5.0.11p4.5 and SoloX support Uses defconfig which is universal to all current Boundary Devices boards Signed-off-by: Ian Coolidge With the recent changes to kernel-module-imx-gpu-viv, this kernel needs a patch for the 'galcore' module to successfully load. Once this patch is in place, along with the update to kernel-module-imx-gpu-viv, X11 graphics work again. Rather than provide a patch to the kernel recipe, here is the change so it can be integrated directly into the kernel. While Ian don't apply the patch, do you mind preparing the patch for the layer? I could, but it seems a bit hasty. I imagine that Ian will work this properly into their kernel quite soon. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra][PATCH v2 1/6] linux-boundary: Bump kernel version to 3.14.28
On 2015-10-05 19:09, Ian Coolidge wrote: Kernel based on 3.14.28-1.0.0 GA release Removal of linux-boundary_3.10.53 kernel recipe Main changes are graphics update to 5.0.11p4.5 and SoloX support Uses defconfig which is universal to all current Boundary Devices boards Signed-off-by: Ian Coolidge With the recent changes to kernel-module-imx-gpu-viv, this kernel needs a patch for the 'galcore' module to successfully load. Once this patch is in place, along with the update to kernel-module-imx-gpu-viv, X11 graphics work again. Rather than provide a patch to the kernel recipe, here is the change so it can be integrated directly into the kernel. -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world Index: kernel-source/arch/arm/kernel/setup.c === --- kernel-source.orig/arch/arm/kernel/setup.c +++ kernel-source/arch/arm/kernel/setup.c @@ -1081,3 +1081,11 @@ const struct seq_operations cpuinfo_op = .stop = c_stop, .show = c_show }; + +/* export the cache management functions */ +#ifndef MULTI_CACHE + +EXPORT_SYMBOL(__glue(_CACHE,_dma_map_area)); +EXPORT_SYMBOL(__glue(_CACHE,_dma_unmap_area)); +EXPORT_SYMBOL(__glue(_CACHE,_dma_flush_range)); +#endif -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [PATCH] kernel-module-imx-gpu-viv: Better work-around for change in name of busfreq-imx.h
The renaming of include/linux/busfreq-imx6.h to include/linux/busfreq-imx.h
is not consistent over the many kernel versions currently being built. This
changeset works around this inconsistency by creating a local symbolic link
to whatever file is actually present in the kernel sources.
Signed-off-by: Gary Thomas
---
...x-kernel-version-check-for-3.14-based-ker.patch | 35 --
.../work-around-include-file-rename.patch | 17 +++
.../kernel-module-imx-gpu-viv_5.0.11.p7.1.bb | 9 +-
3 files changed, 25 insertions(+), 36 deletions(-)
delete mode 100644
recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/platform-Fix-kernel-version-check-for-3.14-based-ker.patch
create mode 100644
recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/work-around-include-file-rename.patch
diff --git
a/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/platform-Fix-kernel-version-check-for-3.14-based-ker.patch
b/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/platform-Fix-kernel-version-check-for-3.14-based-ker.patch
deleted file mode 100644
index 3dc0617..000
---
a/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/platform-Fix-kernel-version-check-for-3.14-based-ker.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From 617bdbec386a1237e2a148989318cc4a1360788a Mon Sep 17 00:00:00 2001
-From: Otavio Salvador
-Date: Tue, 18 Aug 2015 23:08:48 +
-Subject: [PATCH] platform: Fix kernel version check for 3.14-based kernels
-Organization: O.S. Systems Software LTDA.
-
-The build fail about the bus frequency header (linux/busfreq-imx6.h)
-not being found is caused by the mistaken check for the wrong kernel
-version.
-
-This patch fixes it by adding the right kernel version to be checked.
-
-Upstream-Status: Pending
-
-Signed-off-by: Otavio Salvador
- .../os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git
a/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
b/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
-index a2e72ff..241614a 100644
a/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
-+++
b/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
-@@ -40,7 +40,7 @@
- #include
- #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0)
- #include
--#elif LINUX_VERSION_CODE < KERNEL_VERSION(3, 14, 0)
-+#elif LINUX_VERSION_CODE < KERNEL_VERSION(3, 15, 0)
- #include
- #include
- #else
---
-2.1.4
-
diff --git
a/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/work-around-include-file-rename.patch
b/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/work-around-include-file-rename.patch
new file mode 100644
index 000..8840727
--- /dev/null
+++
b/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv/work-around-include-file-rename.patch
@@ -0,0 +1,30 @@
+From 3ec514cf260b82f4701b6fed521ce470d9faf8c9 Mon Sep 17 00:00:00 2001
+From: Gary Thomas
+Date: Tue, 6 Oct 2015 09:32:22 -0600
+Subject: [PATCH] kernel-module-imx-gpu-viv: Better work-around for change in
name of busfreq-imx.h
+
+The renaming of include/linux/busfreq-imx6.h to include/linux/busfreq-imx.h
+is not consistent over the many kernel versions currently being built. This
+changeset works around this inconsistency by creating a local symbolic link
+to whatever file is actually present in the kernel sources.
+
+Signed-off-by: Gary Thomas
+Upstream-status: Innapropriate [requires OE recipe support]
+
+Index:
kernel-module-imx-gpu-viv-5.0.11.p7.1/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
+===
+---
kernel-module-imx-gpu-viv-5.0.11.p7.1.orig/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
kernel-module-imx-gpu-viv-5.0.11.p7.1/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c
+@@ -74,11 +74,8 @@
+ #include
+ #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0)
+ #include
+-#elif LINUX_VERSION_CODE < KERNEL_VERSION(3, 14, 0)
+-#include
+-#include
+ #else
+-#include
++#include "busfreq-imx.h"
+ #include
+ #endif
+ #endif
diff --git
a/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv_5.0.11.p7.1.bb
b/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv_5.0.11.p7.1.bb
index 3218b4e..7e8414b 100644
--- a/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv_5.0.11.p7.1.bb
+++ b/recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv_5.0.11.p7.1.bb
@@ -10,7 +10,14 @@ inherit module
SRC_URI = "${FSL_MIRROR}/${PN}-${PV}.tar.gz \
file://updatemakefile.patch \
- file://platform-Fix-kerne
Re: [meta-freescale] [meta-fsl-arm] Error in recent build
On 2015-10-06 05:49, Otavio Salvador wrote: On Mon, Oct 5, 2015 at 7:00 PM, Gary Thomas wrote: On 2015-10-05 15:28, Otavio Salvador wrote: On Mon, Oct 5, 2015 at 6:18 PM, Gary Thomas wrote: I've updated my Poky/Yocto build to the latest master: meta:eac61f37e36099f74485dab398b57f3812826d17 meta-fsl-arm:e76622d2b89952f817005ca0bf35751707f9 I'm now getting this error: | /local/p0382-cutting-edge_2014-11-21/tmp/work/imx6qsabresd-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p7.1-r0/kernel-module-imx-gpu-viv-5.0.11.p7.1/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c:78:32: fatal error: linux/busfreq-imx6.h: No such file or directory | #include It turns out that this module will not build with a kernel based on 3.14.38_6pq_ga which includes this commit: commit c3ae4b04ea47e32a2d7a953fd7a3089c6e07701c Author: Anson Huang Date: Mon Apr 13 14:13:17 2015 +0800 MLK-10788-2 ARM: imx: rename busfreq from imx6 to imx As busfreq need to cover both i.MX6 and i.MX7 and maybe later SoCs, so better to change the name to support common imx SoC. Signed-off-by: Anson Huang I received this error with both the off-the-shelf layers and imx6qsabresd as well as the meta-fsl-arm-extra trying to build the boundary devices with a newer kernel based on this branch. At this point, it's not clear to me the best way to fix this. Agreed; I think the easiest way is to backport this commit for linux-fslc fork and get out of the patch in the module. Would you be willing to help to do this? Sure, I can look at it (I'm mostly interested in the linux-boundary recipe, but I'll see if I can find a good/extensible solution for all kernels). Any particular recipe I should look at [first]? I would backport this to the linux-fslc 3.14-1.0.x-mx6 which offers fixes on top of the 3.14.28 GA kernel. Once we do that, we can put the same patches on the other kernels if need. Couldn't the patch for kernel-module-imx-gpu-viv just be adjusted for 3.14.38? Right now, it tests for #elif LINUX_VERSION_CODE < KERNEL_VERSION(3, 15, 0) why not change it to #elif LINUX_VERSION_CODE < KERNEL_VERSION(3, 14, 38) It seems that the change of busfreq-imx6.h => busfreq-imx.h happened before 3.14.38 -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm][PATCH] qt4: Fix *.la pollution
Recent [platform dependent] changes to QT_CONFIG_FLAGS allow
some C-preprocessor defines to creep into *.la (libtool) files.
This are not allowed (or even handled) and cause linker errors
when trying to link against these libraries.
This patch removes the incorrect/erroneous preprocessor directives
to leave the *.la files useable once again. The change is done in
a post-processing step to clean up the *.la files as they are only
used externally to this package.
Signed-off-by: Gary Thomas
Upstream-status: Innapropriate [OE patch causes the problem]
---
recipes-qt/qt4/qt4-imx-support.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/recipes-qt/qt4/qt4-imx-support.inc
b/recipes-qt/qt4/qt4-imx-support.inc
index 10eac09..0efb564 100644
--- a/recipes-qt/qt4/qt4-imx-support.inc
+++ b/recipes-qt/qt4/qt4-imx-support.inc
@@ -21,3 +21,8 @@ QT_CONFIG_FLAGS_append_mx6 = "
-I${STAGING_KERNEL_DIR}/include/uapi \
-DLINUX=1 -DEGL_API_FB=1 \
-DQT_QPA_EXPERIMENTAL_TOUCHEVENT=1"
+# The QT_CONFIG_FLAGS can pollute *.la files with -Dxxx
+do_compile_append_mx6 () {
+find lib -name "*.la" | xargs -n1 sed -i 's/-D.*=1//g'
+}
+
--
1.9.1
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Error in recent build
On 2015-10-05 15:28, Otavio Salvador wrote: On Mon, Oct 5, 2015 at 6:18 PM, Gary Thomas wrote: I've updated my Poky/Yocto build to the latest master: meta:eac61f37e36099f74485dab398b57f3812826d17 meta-fsl-arm:e76622d2b89952f817005ca0bf35751707f9 I'm now getting this error: | /local/p0382-cutting-edge_2014-11-21/tmp/work/imx6qsabresd-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p7.1-r0/kernel-module-imx-gpu-viv-5.0.11.p7.1/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c:78:32: fatal error: linux/busfreq-imx6.h: No such file or directory | #include It turns out that this module will not build with a kernel based on 3.14.38_6pq_ga which includes this commit: commit c3ae4b04ea47e32a2d7a953fd7a3089c6e07701c Author: Anson Huang Date: Mon Apr 13 14:13:17 2015 +0800 MLK-10788-2 ARM: imx: rename busfreq from imx6 to imx As busfreq need to cover both i.MX6 and i.MX7 and maybe later SoCs, so better to change the name to support common imx SoC. Signed-off-by: Anson Huang I received this error with both the off-the-shelf layers and imx6qsabresd as well as the meta-fsl-arm-extra trying to build the boundary devices with a newer kernel based on this branch. At this point, it's not clear to me the best way to fix this. Agreed; I think the easiest way is to backport this commit for linux-fslc fork and get out of the patch in the module. Would you be willing to help to do this? Sure, I can look at it (I'm mostly interested in the linux-boundary recipe, but I'll see if I can find a good/extensible solution for all kernels). Any particular recipe I should look at [first]? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Error in recent build
I've updated my Poky/Yocto build to the latest master: meta:eac61f37e36099f74485dab398b57f3812826d17 meta-fsl-arm:e76622d2b89952f817005ca0bf35751707f9 I'm now getting this error: | /local/p0382-cutting-edge_2014-11-21/tmp/work/imx6qsabresd-amltd-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p7.1-r0/kernel-module-imx-gpu-viv-5.0.11.p7.1/kernel-module-imx-gpu-viv-src/hal/os/linux/kernel/platform/freescale/gc_hal_kernel_platform_imx6q14.c:78:32: fatal error: linux/busfreq-imx6.h: No such file or directory | #include It turns out that this module will not build with a kernel based on 3.14.38_6pq_ga which includes this commit: commit c3ae4b04ea47e32a2d7a953fd7a3089c6e07701c Author: Anson Huang Date: Mon Apr 13 14:13:17 2015 +0800 MLK-10788-2 ARM: imx: rename busfreq from imx6 to imx As busfreq need to cover both i.MX6 and i.MX7 and maybe later SoCs, so better to change the name to support common imx SoC. Signed-off-by: Anson Huang I received this error with both the off-the-shelf layers and imx6qsabresd as well as the meta-fsl-arm-extra trying to build the boundary devices with a newer kernel based on this branch. At this point, it's not clear to me the best way to fix this. -- -------- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra][PATCH 1/6] linux-boundary: Bump kernel version to 3.14.28
On 2015-10-02 17:05, Gary Thomas wrote: On 2015-10-01 18:22, Ian Coolidge wrote: Updated kernel recipe to 3.14.28 and added universal defconfig which works across all BD's boards. Signed-off-by: Ian Coolidge --- .../linux/linux-boundary-3.10.53/defconfig | 386 .../linux/linux-boundary-3.14.28/defconfig | 406 + recipes-kernel/linux/linux-boundary_3.10.53.bb | 17 - recipes-kernel/linux/linux-boundary_3.14.28.bb | 17 + 4 files changed, 423 insertions(+), 403 deletions(-) delete mode 100644 recipes-kernel/linux/linux-boundary-3.10.53/defconfig create mode 100644 recipes-kernel/linux/linux-boundary-3.14.28/defconfig delete mode 100644 recipes-kernel/linux/linux-boundary_3.10.53.bb create mode 100644 recipes-kernel/linux/linux-boundary_3.14.28.bb I've tried this series of patches, along with Poky/Yocto (latest master) meta = "master:eac61f37e36099f74485dab398b57f3812826d17" meta-fsl-arm = "master:10471566d2868b07f8ac832b94d5e98a463826ba" meta-fsl-arm-extras = "master:daeab6d460a0163c6ae69982180cd8aa5a2c1a7c" + patch series Alas, X11 still fails to come up :-( Log attached. Does this work for you? Am I missing something? Actually I just realized this is only still 3.14.28 which will not work with the current Vivante (GPU) firmware. Any ideas on when 3.14.38 will be coming along? Thanks -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm-extra][PATCH 1/6] linux-boundary: Bump kernel version to 3.14.28
On 2015-10-01 18:22, Ian Coolidge wrote: Updated kernel recipe to 3.14.28 and added universal defconfig which works across all BD's boards. Signed-off-by: Ian Coolidge --- .../linux/linux-boundary-3.10.53/defconfig | 386 .../linux/linux-boundary-3.14.28/defconfig | 406 + recipes-kernel/linux/linux-boundary_3.10.53.bb | 17 - recipes-kernel/linux/linux-boundary_3.14.28.bb | 17 + 4 files changed, 423 insertions(+), 403 deletions(-) delete mode 100644 recipes-kernel/linux/linux-boundary-3.10.53/defconfig create mode 100644 recipes-kernel/linux/linux-boundary-3.14.28/defconfig delete mode 100644 recipes-kernel/linux/linux-boundary_3.10.53.bb create mode 100644 recipes-kernel/linux/linux-boundary_3.14.28.bb I've tried this series of patches, along with Poky/Yocto (latest master) meta = "master:eac61f37e36099f74485dab398b57f3812826d17" meta-fsl-arm = "master:10471566d2868b07f8ac832b94d5e98a463826ba" meta-fsl-arm-extras = "master:daeab6d460a0163c6ae69982180cd8aa5a2c1a7c" + patch series Alas, X11 still fails to come up :-( Log attached. Does this work for you? Am I missing something? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world [717731.779] X.Org X Server 1.17.2 Release Date: 2015-06-16 [717731.779] X Protocol Version 11, Revision 0 [717731.779] Build Operating System: Linux 3.19.0-15-generic x86_64 [717731.779] Current Operating System: Linux nitrogen6x 3.14.28-1.0.0_ga+yocto+g4f49331 #1 SMP PREEMPT Fri Oct 2 11:12:37 MDT 2015 armv7l [717731.779] Kernel command line: mxc_hdmi.only_cea=1 console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait fixrtc root=/dev/mmcblk1p2 [717731.779] Build Date: 02 October 2015 11:20:47AM [717731.779] [717731.779] Current version of pixman: 0.32.6 [717731.779] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [717731.779] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [717731.779] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Oct 2 22:59:03 2015 [717731.784] (==) Using config file: "/etc/X11/xorg.conf" [717731.784] (==) Using config directory: "/etc/X11/xorg.conf.d" [717731.784] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [717731.794] (==) No Layout section. Using the first Screen section. [717731.794] (==) No screen section available. Using defaults. [717731.794] (**) |-->Screen "Default Screen Section" (0) [717731.794] (**) | |-->Monitor "" [717731.794] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [717731.794] (**) | |-->Device "i.MX Accelerated Framebuffer Device" [717731.794] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [717731.794] (**) Option "BlankTime" "0" [717731.795] (**) Option "StandbyTime" "0" [717731.795] (**) Option "SuspendTime" "0" [717731.795] (**) Option "OffTime" "0" [717731.795] (==) Automatically adding devices [717731.795] (==) Automatically enabling devices [717731.795] (==) Automatically adding GPU devices [717731.796] (WW) The directory "/usr/share/fonts/X11/misc/" does not exist. [717731.796] Entry deleted from font path. [717731.796] (WW) The directory "/usr/share/fonts/X11/TTF/" does not exist. [717731.796] Entry deleted from font path. [717731.796] (WW) The directory "/usr/share/fonts/X11/OTF/" does not exist. [717731.796] Entry deleted from font path. [717731.796] (WW) The directory "/usr/share/fonts/X11/Type1/" does not exist. [717731.796] Entry deleted from font path. [717731.796] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [717731.796] Entry deleted from font path. [717731.796] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [717731.796] Entry deleted from font path. [717731.796] (==) FontPath set to: [717731.796] (==) ModulePath set to "/usr/lib/xorg/modules" [717731.796] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [717731.797] (II) Loader magic: 0x1c2a48 [717731.797] (II) Module ABI versions: [717731.797] X.Org ANSI C Emulation: 0.4 [717731.797] X.Org Video Driver: 19.0 [717731.797] X.Org XInput driver : 21.0 [717731.797] X.Org Server Extension : 9.0 [717731.798] (II) xfree86: Addin
Re: [meta-freescale] [meta-fsl-arm PATCH v2 5/5] Move mxs-base.inc contents to imx-base.inc
On 2015-09-24 07:59, Otavio Salvador wrote:
On Thu, Sep 24, 2015 at 10:47 AM, Daiane Angolini wrote:
On Thu, Sep 24, 2015 at 9:32 AM, Otavio Salvador
wrote:
The consolidation of all i.MX related base settings allow for a more
global view of the settings in place. Up to now, the i.MX 23 and i.MX
28 SoCs were using the mxs-base.inc file, causing fragmentation.
The changes necessary to keep all i.MX 23 and i.MX 28 reference boards
working properly has been done, some values need to be reworked to
The consolidation of all i.MX related base settings allows a more
global view of the settings in place.
One of the causes of this patch is the fragmentation caused by i.MX23
and i.MX28 SoCs using mxs-base.inc.
The changes needed to get i.MX23 and i.MX28 SoCs working have been
included in imx-base.inc file already, ...
I reworked this as:
---
The consolidation of all i.MX related base settings allows a more
global view of the settings in place.
One of the causes of this patch is the fragmentation caused by i.MX23
One of the reasons for this patch ...
and i.MX28 SoCs using mxs-base.inc.
The changes needed to get i.MX23 and i.MX28 SoCs working have been
included in imx-base.inc file already and some values required rework
to apply to specific SoC families to avoid regressions.
---
Better?
apply to SoC families instead of global setting but the price for
clearness seems worth it.
This piece I don't understand. Are additional changes needed for
future (#FIXME)? Or you are still talking about the motivation of this
patch?
No; just explaining there are changes to avoid regressions. I reworked
the commit log.
...
+UBOOT_MAKE_TARGET_mxs = "u-boot.sb"
+UBOOT_MAKE_TARGET_mx51 = "u-boot.imx"
+UBOOT_MAKE_TARGET_mx53 = "u-boot.imx"
+UBOOT_MAKE_TARGET_mx6 = "u-boot.imx"
+UBOOT_MAKE_TARGET_mx6sl = "u-boot.imx"
+UBOOT_MAKE_TARGET_mx6sx = "u-boot.imx"
Why are you duplicating for sl and sx?
I don't see imx6ul
My fault; I will expand it.
+UBOOT_MAKE_TARGET_mx7 = "u-boot.imx"
+UBOOT_MAKE_TARGET_vf = "u-boot.imx"
+
+UBOOT_SUFFIX_mxs = "sb"
+UBOOT_SUFFIX_mx51 = "imx"
+UBOOT_SUFFIX_mx53 = "imx"
+UBOOT_SUFFIX_mx6 = "imx"
+UBOOT_SUFFIX_mx6sl = "imx"
+UBOOT_SUFFIX_mx6sx = "imx"
Why are you duplicating for sl and sx?
I don't see imx6ul
Ditto.
+UBOOT_SUFFIX_mx7 = "imx"
+UBOOT_SUFFIX_vf = "imx"
+
+UBOOT_ENTRYPOINT_mxs = "0x40008000"
UBOOT_ENTRYPOINT_mx51 = "0x90008000"
UBOOT_ENTRYPOINT_mx53 = "0x70008000"
UBOOT_ENTRYPOINT_mx6 = "0x10008000"
@@ -132,6 +149,7 @@ PREFERRED_PROVIDER_virtual/libg2d_mx6ul = ""
# Handle default kernel
IMX_DEFAULT_KERNEL = "linux-imx"
+IMX_DEFAULT_KERNEL_mxs = "linux-fslc"
IMX_DEFAULT_KERNEL_mx5 = "linux-fslc"
IMX_DEFAULT_KERNEL_mx6 = "linux-fslc-mx6"
IMX_DEFAULT_KERNEL_mx6ul = "linux-imx"
@@ -140,8 +158,16 @@ PREFERRED_PROVIDER_virtual/kernel ??=
"${IMX_DEFAULT_KERNEL}"
SDCARD_ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext4"
IMAGE_FSTYPES ?= "ext4 sdcard.gz"
-
-SERIAL_CONSOLE = "115200 ttymxc0"
+IMAGE_FSTYPES_mxs ?= "ext4 uboot.mxsboot-sdcard sdcard.gz"
+
+SERIAL_CONSOLE_mxs = "115200 ttyAMA0"
+SERIAL_CONSOLE_mx51 = "115200 ttymxc0"
+SERIAL_CONSOLE_mx53 = "115200 ttymxc0"
+SERIAL_CONSOLE_mx6 = "115200 ttymxc0"
+SERIAL_CONSOLE_mx6sl = "115200 ttymxc0"
+SERIAL_CONSOLE_mx6sx = "115200 ttymxc0"
+SERIAL_CONSOLE_mx7 = "115200 ttymxc0"
+SERIAL_CONSOLE_vf = "115200 ttymxc0"
Can you, please, explain why we cannot have SERIAL_CONSOLE any more
and only override for mxs?
I will rework this.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm][PATCH] kernel-module-imx-gpu-viv: Upgrade to 5.0.11.p7.1 for 3.14.38-6QP_ga release
KSUM =
"file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
inherit module
-SRC_URI = "${FSL_MIRROR}/imx-gpu-viv-kernel-${@'${PV}'.replace('5.0.11.p6.3',
'5.0.11.p6.3-beta')}.tar.gz \
- file://platform-Fix-kernel-version-check-for-3.14-based-ker.patch"
+SRC_URI = "${FSL_MIRROR}/${PN}-${PV}.tar.gz \
+ file://updatemakefile.patch \
+ "
-SRC_URI[md5sum] = "6d46da80de94e98ee68ab1a75f384b89"
-SRC_URI[sha256sum] =
"e4b02fc0c9bdbfc7ecc67a0bad0917e788921c8f2444d99bd77daae7f3cd95df"
-
-S = "${WORKDIR}/imx-gpu-viv-kernel-${@'${PV}'.replace('5.0.11.p6.3',
'5.0.11.p6.3-beta')}"
+SRC_URI[md5sum] = "a251a94390986371f75b338ad938e46f"
+SRC_URI[sha256sum] =
"9aaef0a62bc2be69dc568228192b060c54970b5c700fee602d83a4d13e04a9b3"
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] optimisation reg
On 2015-09-08 05:37, Sachu Sanal (NeSTIT) wrote: Dear all, How can exclude gstreamer package from the yocto build root file system. It's much simpler to think in terms of what you can add to an image. Try starting with a simpler image and then add any bits you might need. For example, if you want to build basically core-image-sato but don't want gstreamer, you'll need to include the bits it is including but leave out gst-player (and perhaps others) as that's what's dragging in gstreamer (at least gstreamer 1.0) -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] IMX.6Q OpenCV image processing performances
On 2015-08-31 04:01, Duronea Jean-baptiste wrote: Hello, I tested Opencv face detection algorithm on Freescale IMX.6Q SabreSD Evalboard. Results are really bad, between 500ms (320x240px) and 1.5sec(640x480px) of processing time per image. I'm wondering if this is the correct time, or i'm doing something bad, or missing something. Can you share me your results so i can compare ? Exactly what are you using to test this? If you can share the code (or point to a public example/test), along with the data (images) you use, we might be able to provide more insight. n.b. I'd be very interested in these results as well but don't have the code at hand to test it nor the time to write it :-) -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Can't fetch file
On 2015-08-28 07:32, Nikolay Dimitrov wrote: Hi Gary, On 08/28/2015 03:54 PM, Gary Thomas wrote: On 2015-08-28 05:29, Nikolay Dimitrov wrote: Hi Gary, On 08/28/2015 01:57 PM, Gary Thomas wrote: With the latest meta-fsl-arm master (a6048db8a0fb5c79ca0e0d0f6f23c853ce2eb0d5) I'm getting this error: ERROR: Function failed: Fetcher failure for URL: 'http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.6.bin;fsl-eula=true'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /local/p0382-cutting-edge_2014-11-21/tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/libfslcodec/4.0.6-r0/temp/log.do_fetch.7 ERROR: Task 370 (/local/poky-cutting-edge/meta-fsl-arm/recipes-multimedia/libfslcodec/libfslcodec_4.0.6.bb, do_fetch) failed with exit code '1' Any ideas how to proceed? It seems that it works for me: picmaster@cruncher:~/work/yocto-master/build$ find ./ -name libfslcodec-4.0.6.bin picmaster@cruncher:~/work/yocto-master/build$ bitbake libfslcodec Loading cache: 100% |#| ETA: 00:00:00 Loaded 2360 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.27.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-7.8" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "imx6qsabresd" DISTRO= "poky" DISTRO_VERSION= "1.8+snapshot-20150828" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU= "vfp-neon" meta meta-yocto= "(nobranch):393bd7496d71eb101f21234c1233a2d18fd2c73e" meta-oe meta-multimedia meta-networking meta-python = "(nobranch):985fca448f2593f5e5aeba07656eb8f2dad60183" meta-fsl-arm = "(nobranch):a6048db8a0fb5c79ca0e0d0f6f23c853ce2eb0d5" meta-fsl-arm-extra = "(nobranch):b9e1b7395042d313a8c757627a2fd07b6a401e94" meta-fsl-demos= "(nobranch):4dbe83280842f37cd4776705770665ca3211ab68" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 460 tasks of which 375 didn't need to be rerun and all succeeded. picmaster@cruncher:~/work/yocto-master/build$ find ./ -name libfslcodec-4.0.6.bin ./tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/libfslcodec/4.0.6-r0/libfslcodec-4.0.6.bin picmaster@cruncher:~/work/yocto-master/build$ repo info Manifest branch: master Manifest merge branch: refs/heads/master Manifest groups: all,-notdefault Project: Documentation Mount path: /home/picmaster/work/yocto-master/sources/Documentation Current revision: master Local Branches: 0 Project: fsl-community-bsp-base Mount path: /home/picmaster/work/yocto-master/sources/base Current revision: master Local Branches: 0 Project: meta-fsl-arm Mount path: /home/picmaster/work/yocto-master/sources/meta-fsl-arm Current revision: master Local Branches: 0 Project: meta-fsl-arm-extra Mount path: /home/picmaster/work/yocto-master/sources/meta-fsl-arm-extra Current revision: master Local Branches: 0 Project: meta-fsl-demos Mount path: /home/picmaster/work/yocto-master/sources/meta-fsl-demos Current revision: master Local Branches: 0 Project: meta-openembedded Mount path: /home/picmaster/work/yocto-master/sources/meta-openembedded Current revision: master Local Branches: 0 Project: poky Mount path: /home/picmaster/work/yocto-master/sources/poky Current revision: master Local Branches: 0 Regards, Nikolay Oddly, it's working now for me as well (although it failed a number of times before I sent the original email). No problem, that's why I double-checked here. Could be a local ISP or a server issue, who knows. Have a nice day, Nikolay The truly odd thing is that I use a local mirror and that particular file was already in my downloads directory when this ran so it should not have even been trying to fetch the file. If it happens again, I'll try to gather more info... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Can't fetch file
On 2015-08-28 05:29, Nikolay Dimitrov wrote: Hi Gary, On 08/28/2015 01:57 PM, Gary Thomas wrote: With the latest meta-fsl-arm master (a6048db8a0fb5c79ca0e0d0f6f23c853ce2eb0d5) I'm getting this error: ERROR: Function failed: Fetcher failure for URL: 'http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.6.bin;fsl-eula=true'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /local/p0382-cutting-edge_2014-11-21/tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/libfslcodec/4.0.6-r0/temp/log.do_fetch.7 ERROR: Task 370 (/local/poky-cutting-edge/meta-fsl-arm/recipes-multimedia/libfslcodec/libfslcodec_4.0.6.bb, do_fetch) failed with exit code '1' Any ideas how to proceed? It seems that it works for me: picmaster@cruncher:~/work/yocto-master/build$ find ./ -name libfslcodec-4.0.6.bin picmaster@cruncher:~/work/yocto-master/build$ bitbake libfslcodec Loading cache: 100% |#| ETA: 00:00:00 Loaded 2360 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.27.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-7.8" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "imx6qsabresd" DISTRO= "poky" DISTRO_VERSION= "1.8+snapshot-20150828" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU= "vfp-neon" meta meta-yocto= "(nobranch):393bd7496d71eb101f21234c1233a2d18fd2c73e" meta-oe meta-multimedia meta-networking meta-python = "(nobranch):985fca448f2593f5e5aeba07656eb8f2dad60183" meta-fsl-arm = "(nobranch):a6048db8a0fb5c79ca0e0d0f6f23c853ce2eb0d5" meta-fsl-arm-extra = "(nobranch):b9e1b7395042d313a8c757627a2fd07b6a401e94" meta-fsl-demos= "(nobranch):4dbe83280842f37cd4776705770665ca3211ab68" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 460 tasks of which 375 didn't need to be rerun and all succeeded. picmaster@cruncher:~/work/yocto-master/build$ find ./ -name libfslcodec-4.0.6.bin ./tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/libfslcodec/4.0.6-r0/libfslcodec-4.0.6.bin picmaster@cruncher:~/work/yocto-master/build$ repo info Manifest branch: master Manifest merge branch: refs/heads/master Manifest groups: all,-notdefault Project: Documentation Mount path: /home/picmaster/work/yocto-master/sources/Documentation Current revision: master Local Branches: 0 Project: fsl-community-bsp-base Mount path: /home/picmaster/work/yocto-master/sources/base Current revision: master Local Branches: 0 Project: meta-fsl-arm Mount path: /home/picmaster/work/yocto-master/sources/meta-fsl-arm Current revision: master Local Branches: 0 Project: meta-fsl-arm-extra Mount path: /home/picmaster/work/yocto-master/sources/meta-fsl-arm-extra Current revision: master Local Branches: 0 Project: meta-fsl-demos Mount path: /home/picmaster/work/yocto-master/sources/meta-fsl-demos Current revision: master Local Branches: 0 Project: meta-openembedded Mount path: /home/picmaster/work/yocto-master/sources/meta-openembedded Current revision: master Local Branches: 0 Project: poky Mount path: /home/picmaster/work/yocto-master/sources/poky Current revision: master Local Branches: 0 Regards, Nikolay Oddly, it's working now for me as well (although it failed a number of times before I sent the original email). -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm] Can't fetch file
With the latest meta-fsl-arm master (a6048db8a0fb5c79ca0e0d0f6f23c853ce2eb0d5) I'm getting this error: ERROR: Function failed: Fetcher failure for URL: 'http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.6.bin;fsl-eula=true'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /local/p0382-cutting-edge_2014-11-21/tmp/work/cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi/libfslcodec/4.0.6-r0/temp/log.do_fetch.7 ERROR: Task 370 (/local/poky-cutting-edge/meta-fsl-arm/recipes-multimedia/libfslcodec/libfslcodec_4.0.6.bb, do_fetch) failed with exit code '1' Any ideas how to proceed? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH] u-boot: Ensure LS1021 ARM Generic Timer CompareValue Set 64-bit
On 2015-07-05 20:40, Chris Kilgour wrote:
This patch addresses a problem mentioned recently on this mailing list: [1].
In that posting a LS1021 based system was locking up at about 5 minutes after
boot, but the problem was mysteriously related to the toolchain used for
building u-boot. Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM
generic PL1 physical time CompareValue register to all-ones with a 32-bit
value. This causes the timer compare to fire 344 seconds after u-boot
configures it. Depending on how fast u-boot gets the kernel booted, this
amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by
default compiler options, word sizes, or binutils versions. At any rate this
patch makes the manipulation explicitly 64-bit which alleviates the issue.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014400.html
Verified; this does indeed fix the problems I was having when U-Boot was
built using GCC 4.9.2
Index: u-boot-2015.04/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
===
--- u-boot-2015.04.orig/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ u-boot-2015.04/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -28,7 +28,7 @@
#define RCWSR4_SRDS1_PRTCL_SHIFT 24
#define RCWSR4_SRDS1_PRTCL_MASK 0xff00
-#define TIMER_COMP_VAL 0x
+#define TIMER_COMP_VAL 0xull
#define ARCH_TIMER_CTRL_ENABLE(1 << 0)
#define SYS_COUNTER_CTRL_ENABLE (1 << 24)
Index: u-boot-2015.04/arch/arm/cpu/armv7/ls102xa/timer.c
===
--- u-boot-2015.04.orig/arch/arm/cpu/armv7/ls102xa/timer.c
+++ u-boot-2015.04/arch/arm/cpu/armv7/ls102xa/timer.c
@@ -58,7 +58,8 @@ int timer_init(void)
struct sctr_regs *sctr = (struct sctr_regs *)SCTR_BASE_ADDR;
if (!readl( &sctr->cntcr )) {
-unsigned long ctrl, val, freq;
+unsigned long ctrl, freq;
+ unsigned long long val64;
/* Enable System Counter */
writel(SYS_COUNTER_CTRL_ENABLE, &sctr->cntcr);
@@ -71,8 +72,8 @@ int timer_init(void)
asm("mcr p15, 0, %0, c14, c2, 1" : : "r" (ctrl));
/* Set PL1 Physical Comp Value */
-val = TIMER_COMP_VAL;
-asm("mcrr p15, 2, %Q0, %R0, c14" : : "r" (val));
+val64 = TIMER_COMP_VAL;
+asm("mcrr p15, 2, %Q0, %R0, c14" : : "r" (val64));
gd->arch.tbl = 0;
gd->arch.tbu = 0;
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm][PATCH v3 04/13] u-boot-ls1: update to revision v2015.01-630-g6ba8eed
On 2015-07-21 08:08, Liu Ting wrote:
A branch was created :)
http://git.freescale.com/git/cgit.cgi/ppc/sdk/u-boot.git/log/?h=sdk-v1.8.x
Thanks!
-Original Message-
From: meta-freescale-boun...@yoctoproject.org [mailto:meta-freescale-
boun...@yoctoproject.org] On Behalf Of Gary Thomas
Sent: Tuesday, July 21, 2015 9:59 PM
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [meta-fsl-arm][PATCH v3 04/13] u-boot-ls1:
update to revision v2015.01-630-g6ba8eed
Ping.
On 2015-07-08 04:12, Gary Thomas wrote:
On 2015-07-07 02:16, b28...@freescale.com wrote:
From: Ting Liu
Changes:
1. Rebased on git://git.denx.de/u-boot.git v2015.01-487-gab92da9 2.
Applied another 143 FSL/backported patches (git log ab92da9..) 3. add
DEPENDS on dtc-native as u-boot brings in device tree files 4. use
u-boot-with-spl-pbl.bin for nand 5. replace with u-boot-dtb.bin when
swapping the image endianness
Signed-off-by: Ting Liu
---
.../u-boot/{u-boot-ls1_2014.07.bb => u-boot-ls1_2015.01.bb} | 9
+
1 file changed, 5 insertions(+), 4 deletions(-)
rename recipes-bsp/u-boot/{u-boot-ls1_2014.07.bb =>
u-boot-ls1_2015.01.bb} (83%)
diff --git a/recipes-bsp/u-boot/u-boot-ls1_2014.07.bb
b/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
similarity index 83%
rename from recipes-bsp/u-boot/u-boot-ls1_2014.07.bb
rename to recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
index ad1dd4b..d68a326 100644
--- a/recipes-bsp/u-boot/u-boot-ls1_2014.07.bb
+++ b/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
@@ -10,9 +10,9 @@ LIC_FILES_CHKSUM = " \
file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c \
"
-SRCBRANCH = "sdk-v1.7.x"
+SRCBRANCH = "master"
SRC_URI = "git://git.freescale.com/ppc/sdk/u-
boot.git;branch=${SRCBRANCH}"
-SRCREV = "659b6a23a8b1f3026200bc6352dbacef53f4dcb1"
+SRCREV = "6ba8eedbcdc4b063f59a63e6288b938af739e8ad"
Do you know why this latest SDK doesn't have it's own branch?
Previous SDK releases had their own branch. Why doesn't this one?
It makes it more difficult to track the repo for non-Freescale LS1 boards.
LOCALVERSION ?= "-${SRCBRANCH}"
@@ -20,7 +20,7 @@ S = "${WORKDIR}/git"
inherit fsl-u-boot-localversion
-DEPENDS += "change-file-endianess-native"
+DEPENDS += "change-file-endianess-native dtc-native"
PROVIDES += "u-boot"
do_compile_append () {
@@ -28,9 +28,10 @@ do_compile_append () {
then
for config in ${UBOOT_MACHINE}; do
case "${config}" in
-*spi*) tclsh ${STAGING_BINDIR_NATIVE}/byte_swap.tcl
${S}/${config}/u-boot.bin ${S}/${config}/u-boot.swap.bin 8
+*spi*) tclsh ${STAGING_BINDIR_NATIVE}/byte_swap.tcl
+ ${S}/${config}/u-boot-dtb.bin ${S}/${config}/u-boot.swap.bin 8
mv ${S}/${config}/u-boot.swap.bin ${S}/u-boot-
${type}.${UBOOT_SUFFIX};;
*sdcard*) mv
${S}/${config}/u-boot-with-spl-pbl.bin ${S}/${config}/u-boot.bin;;
+*nand*) mv ${S}/u-boot-with-spl-pbl.bin
+ ${S}/u-boot.bin;;
esac
done
fi
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm][PATCH v3 04/13] u-boot-ls1: update to revision v2015.01-630-g6ba8eed
Ping.
On 2015-07-08 04:12, Gary Thomas wrote:
On 2015-07-07 02:16, b28...@freescale.com wrote:
From: Ting Liu
Changes:
1. Rebased on git://git.denx.de/u-boot.git v2015.01-487-gab92da9
2. Applied another 143 FSL/backported patches (git log ab92da9..)
3. add DEPENDS on dtc-native as u-boot brings in device tree files
4. use u-boot-with-spl-pbl.bin for nand
5. replace with u-boot-dtb.bin when swapping the image endianness
Signed-off-by: Ting Liu
---
.../u-boot/{u-boot-ls1_2014.07.bb => u-boot-ls1_2015.01.bb} | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
rename recipes-bsp/u-boot/{u-boot-ls1_2014.07.bb => u-boot-ls1_2015.01.bb}
(83%)
diff --git a/recipes-bsp/u-boot/u-boot-ls1_2014.07.bb
b/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
similarity index 83%
rename from recipes-bsp/u-boot/u-boot-ls1_2014.07.bb
rename to recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
index ad1dd4b..d68a326 100644
--- a/recipes-bsp/u-boot/u-boot-ls1_2014.07.bb
+++ b/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
@@ -10,9 +10,9 @@ LIC_FILES_CHKSUM = " \
file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c \
"
-SRCBRANCH = "sdk-v1.7.x"
+SRCBRANCH = "master"
SRC_URI = "git://git.freescale.com/ppc/sdk/u-boot.git;branch=${SRCBRANCH}"
-SRCREV = "659b6a23a8b1f3026200bc6352dbacef53f4dcb1"
+SRCREV = "6ba8eedbcdc4b063f59a63e6288b938af739e8ad"
Do you know why this latest SDK doesn't have it's own branch?
Previous SDK releases had their own branch. Why doesn't this one?
It makes it more difficult to track the repo for non-Freescale LS1 boards.
LOCALVERSION ?= "-${SRCBRANCH}"
@@ -20,7 +20,7 @@ S = "${WORKDIR}/git"
inherit fsl-u-boot-localversion
-DEPENDS += "change-file-endianess-native"
+DEPENDS += "change-file-endianess-native dtc-native"
PROVIDES += "u-boot"
do_compile_append () {
@@ -28,9 +28,10 @@ do_compile_append () {
then
for config in ${UBOOT_MACHINE}; do
case "${config}" in
-*spi*) tclsh ${STAGING_BINDIR_NATIVE}/byte_swap.tcl
${S}/${config}/u-boot.bin ${S}/${config}/u-boot.swap.bin 8
+*spi*) tclsh ${STAGING_BINDIR_NATIVE}/byte_swap.tcl
${S}/${config}/u-boot-dtb.bin ${S}/${config}/u-boot.swap.bin 8
mv ${S}/${config}/u-boot.swap.bin
${S}/u-boot-${type}.${UBOOT_SUFFIX};;
*sdcard*) mv ${S}/${config}/u-boot-with-spl-pbl.bin
${S}/${config}/u-boot.bin;;
+*nand*) mv ${S}/u-boot-with-spl-pbl.bin ${S}/u-boot.bin;;
esac
done
fi
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm][PATCH v2 24/32] opencv: Update configuration and add data for demos
On 2015-07-16 17:08, Lauren Post wrote: What about the v4l2 fix - I don't see in the link below. Should I rework patch to keep the v4l. # Camera cannot work with libv4l EXTRA_OECMAKE += "-DWITH_LIBV4L=OFF" Isn't this a bit too heavy handed? Wouldn't it would keep most USB cameras from being usable as well? -Original Message- From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] Sent: Thursday, July 16, 2015 4:30 PM To: Post Lauren-RAA013 Cc: meta-freescale@yoctoproject.org Subject: Re: [meta-freescale] [meta-fsl-arm][PATCH v2 24/32] opencv: Update configuration and add data for demos On Thu, Jul 16, 2015 at 4:22 PM, Lauren Post wrote: - Disable libav if not building with commercial license. - Disable V4L2 as it can't work with camera Signed-off-by: Lauren Post This patch can be dropped. I have cooked one patch for 'opencv', for meta-oe, to fix the libav support and the opencv-samples is covered by the default recipe[1]. 1. http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/opencv/opencv-samples_2.4.bb#n22 -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [meta-fsl-arm][PATCH] u-boot-ls1: Fix 'nand' builds
Builds for 'nand' booting were failing because of an incorrect path
during compilation.
Signed-off-by: Gary Thomas
---
recipes-bsp/u-boot/u-boot-ls1_2015.01.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
b/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
index 716105f..0a1fb80 100644
--- a/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
+++ b/recipes-bsp/u-boot/u-boot-ls1_2015.01.bb
@@ -30,8 +30,7 @@ do_compile_append () {
case "${config}" in
*spi*) tclsh ${STAGING_BINDIR_NATIVE}/byte_swap.tcl
${S}/${config}/u-boot-dtb.bin ${S}/${config}/u-boot.swap.bin 8
mv ${S}/${config}/u-boot.swap.bin
${S}/u-boot-${type}.${UBOOT_SUFFIX};;
-*sdcard*) mv ${S}/${config}/u-boot-with-spl-pbl.bin
${S}/${config}/u-boot.bin;;
-*nand*) mv ${S}/u-boot-with-spl-pbl.bin ${S}/u-boot.bin;;
+*nand* | *sdcard*) mv ${S}/${config}/u-boot-with-spl-pbl.bin
${S}/${config}/u-boot.bin;;
esac
done
fi
--
1.9.1
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] OpenCV capture
On 2015-07-14 08:33, Carlos Rafael Giani wrote: On 07/14/2015 04:13 PM, Gary Thomas wrote: I'd like to use OpenCV with my i.MX6 system to capture and process data directly from the camera(s) I have connected to the CPU. Sadly, these cameras (CCS, MIPI) produce I420 data but the OpenCV capture code can only work with GBR24. Is there a way to make this conversion happen, perhaps using the VPU/IPU (I'm not sure which)? I420 -> RGB/BGR should be doable with IPU and G2D. I recommend using G2D, since it is much more straightforward to use. GBR is not supported, but could you swap G and B inside OpenCV? Perhaps. How would I set things up to do this conversion in the IPU/G2D? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] OpenCV capture
I'd like to use OpenCV with my i.MX6 system to capture and process data directly from the camera(s) I have connected to the CPU. Sadly, these cameras (CCS, MIPI) produce I420 data but the OpenCV capture code can only work with GBR24. Is there a way to make this conversion happen, perhaps using the VPU/IPU (I'm not sure which)? -- ---- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Device tree question
On 2015-07-13 09:18, Gary Thomas wrote:
On 2015-07-13 09:14, Robin Findley wrote:
On 07/13/2015 10:37 AM, Gary Thomas wrote:
A bit off topic, but perhaps someone here knows the answer :-)
If my device tree has a device/element that is enabled, why would
that device be disabled when I boot? I have this on my (LS1021) board:
quadspi@155 {
compatible = "fsl,ls1-qspi";
#address-cells = <0x0001>;
#size-cells = <0x>;
reg = <0x 0x0155 0x 0x0001 0x
0x4000 0x 0x0400>;
reg-names = "QuadSPI", "QuadSPI-memory";
interrupts = <0x 0x0083 0x0004>;
clock-names = "qspi_en", "qspi";
clocks = <0x0003 0x0001 0x0003 0x0001>;
big-endian;
amba-base = <0x4000>;
num-cs = <0x0002>;
status = "okay";
s70fl01gs@0 {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
compatible = "spansion,s70fl01gs";
spi-max-frequency = <0x02faf080>;
reg = <0x>;
partition@0 {
label = "s70fl01gs-0";
reg = <0x 0x0400>;
};
};
};
However when I boot the system, this device is disabled.
# cat /proc/device-tree/soc/quadspi@155/status
disabled
I know this must happen very early on as the device driver
for this device is never even probed.
Any ideas where/why this becomes disabled and how I keep that
from happening?
Have you checked the rest of your device tree files (top-level and includes)
to see if quadspi is referenced anywhere else? A later assignment can
override an earlier one.
Yes and no, there are no overrides.
Besides, the listing above is from dumping the compiled device
tree using fdtdump, so includes and multiple sections addressing
the same element have been collapsed.
I found the culprit! My quadspi element was being disabled
by U-Boot (not sure why, this was just part of the LS102x common code)
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Device tree question
On 2015-07-13 09:14, Robin Findley wrote:
On 07/13/2015 10:37 AM, Gary Thomas wrote:
A bit off topic, but perhaps someone here knows the answer :-)
If my device tree has a device/element that is enabled, why would
that device be disabled when I boot? I have this on my (LS1021) board:
quadspi@155 {
compatible = "fsl,ls1-qspi";
#address-cells = <0x0001>;
#size-cells = <0x>;
reg = <0x 0x0155 0x 0x0001 0x
0x4000 0x 0x0400>;
reg-names = "QuadSPI", "QuadSPI-memory";
interrupts = <0x 0x0083 0x0004>;
clock-names = "qspi_en", "qspi";
clocks = <0x0003 0x0001 0x0003 0x0001>;
big-endian;
amba-base = <0x4000>;
num-cs = <0x0002>;
status = "okay";
s70fl01gs@0 {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
compatible = "spansion,s70fl01gs";
spi-max-frequency = <0x02faf080>;
reg = <0x>;
partition@0 {
label = "s70fl01gs-0";
reg = <0x 0x0400>;
};
};
};
However when I boot the system, this device is disabled.
# cat /proc/device-tree/soc/quadspi@155/status
disabled
I know this must happen very early on as the device driver
for this device is never even probed.
Any ideas where/why this becomes disabled and how I keep that
from happening?
Have you checked the rest of your device tree files (top-level and includes)
to see if quadspi is referenced anywhere else? A later assignment can
override an earlier one.
Yes and no, there are no overrides.
Besides, the listing above is from dumping the compiled device
tree using fdtdump, so includes and multiple sections addressing
the same element have been collapsed.
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Device tree question
On 2015-07-13 08:51, Nikolay Dimitrov wrote:
Hi Gary,
On 07/13/2015 05:37 PM, Gary Thomas wrote:
A bit off topic, but perhaps someone here knows the answer :-)
If my device tree has a device/element that is enabled, why would
that device be disabled when I boot? I have this on my (LS1021) board:
quadspi@155 {
compatible = "fsl,ls1-qspi";
#address-cells = <0x0001>;
#size-cells = <0x>;
reg = <0x 0x0155 0x 0x0001
0x 0x4000 0x 0x0400>;
reg-names = "QuadSPI", "QuadSPI-memory";
interrupts = <0x 0x0083 0x0004>;
clock-names = "qspi_en", "qspi";
clocks = <0x0003 0x0001 0x0003 0x0001>;
big-endian;
amba-base = <0x4000>;
num-cs = <0x0002>;
status = "okay";
s70fl01gs@0 {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
compatible = "spansion,s70fl01gs";
spi-max-frequency = <0x02faf080>;
reg = <0x>;
partition@0 {
label = "s70fl01gs-0";
reg = <0x 0x0400>;
};
};
};
However when I boot the system, this device is disabled.
# cat /proc/device-tree/soc/quadspi@155/status
disabled
I know this must happen very early on as the device driver
for this device is never even probed.
Any ideas where/why this becomes disabled and how I keep that
from happening?
Is it possible to have an invalid device node parameter, which can
cause the node to become disabled? Have you seen related warn/err
messages in the bootlog? Also, is the ls1-qspi driver enabled in the
defconfig (stupid question, but sometimes we do such things :D).
No warnings/errors and the driver is enabled in the config.
What puzzles me is that the device tree says it should be enabled
but at run time it is not :-(
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
