Page MenuHomePhabricator

Enlightenment issue on armhf
Closed, ResolvedPublic


I have built and installed the latest EFL 1.20.5 & Python-EFL 1.20.0 & Enlightenment 0.21.10 & Terminology 1.1.1 on Debian stable Stretch armhf.
The EFL built with flags:

--enable-xinput22 --enable-image-loader-webp --enable-drm --enable-v4l2 --with-x --enable-harfbuzz --enable-multisense --enable-systemd  --enable-fb --disable-tslib --enable-elput --enable-wayland --enable-gl-drm --with-opengl=es --enable-egl

All builds fine, but Enlightenment doesn't start on RPI.
Enclosed the e-crashdump.

pavroo created this task.Oct 31 2017, 8:47 AM
zmike reassigned this task from zmike to cedric.Oct 31 2017, 8:53 AM

I don't see any crash on this backtrace. It seems to look more like a deadlock which is strange considering it was generated from a crash. Could you compile EFL with CFLAGS="-O2 -g -ggdb3" ? Also do you have valgrind ? And which version of the RPi do you have ?

Yes, will build it again with the additional flag.
I have valgrind 3.7.0 installed.
It's RPi 3 model b with the latest Raspbian installed on it.

Compiled again, no changes, enclosed e-crashdump.

Not much more understandable. Can you start enlightenment manually and pass -valgrind as an option to enlightenment_start ?

Sure, done.

Hum, is that all of it ?

Just stopped and that's it.

So the problem is not a crash and doesn't really give us much to see in the trace. It doesn't even seem to have started enlightenment at all. Any clue what could be going on here @zmike @ManMower ?

dkasak added a subscriber: dkasak.Nov 1 2017, 5:20 PM

Can I try to provide some community support here? I have E working on armhf - a Cubox i4Pro:

processor : 0
model name : ARMv7 Processor rev 10 (v7l)
BogoMIPS : 7.54
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10

( x 4 )

While I have no idea what's causing your issue, might I suggest that you try building the way I did? Download from ... and then create a script: with the contents:

export LIBRAW_CFLAGS=-I/usr/include/libraw
export PKG_CONFIG_PATH=/opt/efl/lib/pkgconfig
export CFLAGS="-O3 -g3 -ffast-math -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard"

./ -i \
  --autogen_args=efl:--enable-drm+--enable-gl-drm+--enable-systemd+--enable-wayland+--enable-egl+--with-opengl=es,enlightenment:--enable-wayland+--enable-xwayland+--enable-wl-drm+--enable-wayland-clients+--enable-wayland-egl+--enable-systemd \

This builds E that can run in X or Wayland mode, and works with software or OpenGL rendering in both modes. You may need to alter / remove the LIBRAW_CFLAGS bit. You need to run it as root.

raster added a subscriber: raster.Nov 1 2017, 9:54 PM

i also have e working on arm (odroid xu3 and raspberry pi3 at the moment).... your valgrind log shows nothing wrong (it's efl library loader warnings and that's normal). your gdb backtrace (crashdump) seems to be missing frames in threads. that's odd. i see very strange things like /usr/lib/arm-linux-gnueabihf/ (the last one) is stuck in a lock. everything else is also stuck in locks. it's like there is some seriously lock problem there... and everything is getting stuck (xlib, efl and more). FYI i stopped using raspbian on rpi and moved to arch as it was easier to work with especially with wayland as everything is always up to date.

pavroo added a comment.Nov 2 2017, 2:12 PM

I don't use the script, couse have to build debs, but used your flags, thank's.

I don't and will not use Arch, but thank's.

My Enlightenment build works fine, the problem was with the EFL flags. The present ones are:

CFLAGS= -O3 -g3 -ffast-math -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
efl:  --enable-drm --enable-gl-drm --enable-systemd --enable-wayland --enable-egl --with-opengl=es

All fine, Enlightenment 0.20.10 works ok on Raspbian/Debian Stretch.
Now cooking the latest 0.22.0 - works fine on i686 and amd64, waiting for ARM build.
Thank's all of you, can be closed.

raster added a comment.Nov 2 2017, 4:59 PM

I don't and will not use Arch, but thank's.

I didn't say to use it... but it works fine on arch. The fact that is see a lock hung in every backtrace including inside xlib itself screams to me of a deeper problem. my build scripts for arm use:

-O3 -ffast-math -fexpensive-optimizations -frename-registers -ftree-vectorize -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -fvisibility=hidden -g
raster closed this task as Resolved.May 12 2018, 1:03 AM