On 02/09/2011 12:31 PM, Simon Busch wrote:
On 02/09/11 at 07:24pm, Koen Kooi wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09-02-11 19:16, Khem Raj wrote:
On Tue, Feb 8, 2011 at 1:39 PM, Tom Rini<[email protected]> wrote:
On 02/08/2011 02:17 PM, Simon Busch wrote:
Neon support in evas is currently broken for the palmpre machine. If we
enable neon
support evas causes alignment trap errors and lets the device freeze in
the end. This
should be reverted after the bug in evas code is found and fixed.
Signed-off-by: Simon Busch<[email protected]>
---
recipes/efl1/evas.inc | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/recipes/efl1/evas.inc b/recipes/efl1/evas.inc
index eb64d7a..ad30eba 100644
--- a/recipes/efl1/evas.inc
+++ b/recipes/efl1/evas.inc
@@ -7,7 +7,7 @@ DEPENDS_virtclass-native = "freetype-native libxext-native
libpng-native jpeg-na
inherit efl
BBCLASSEXTEND = "native"
-INC_PR = "r0"
+INC_PR = "r1"
FILESPATHPKG =. "${BPN}-${PV}:${BPN}:"
python populate_packages_prepend () {
@@ -83,6 +83,9 @@ EVAS_CPU_TWEAKS = ""
# Disabled for now, see
http://thread.gmane.org/gmane.comp.window-managers.enlightenment.devel/25194
#EVAS_CPU_TWEAKS_armv7a = "--enable-cpu-neon"
+# Neon support for evas is broken on palmpre currently (causes the device
to freeze)
+EVAS_CPU_TWEAKS_palmpre = "--disable-cpu-neon"
+
# common options
EVAS_OECONF = " \
--x-includes=${STAGING_INCDIR}/X11 \
Shouldn't this be changing the armv7a EVAS_CPU_TWEAKS that's above yours to
be uncommented and as a --disable?
that would disable neon for all armv7a machines probably not what is
needed here.
Actually, that was how I did it :) The NEON code that was added doesn't
build with gcc 4.3.x and binutils 2.18.x, so I disabled it by not
enabling it. If it builds and works with gcc 4.3.x nowadays we should
enable it and find out why the palmpre breaks.
Evas builds fine these days with neon support enabled but it enables it by
default. I really need to find the cause of the breakage on the palmpre but
don't have too much time to debug it so this is a interim solution only
until the bug is found and fixed.
My only concern is that are we sure other armv7a targets aren't also
having fatal problems?
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
