Hi!
I made some progress investigating my problem, but still have some
questions.
When I remove "thumb" from my TUNE_FEATURES qtwebengine runs without any
issues.
Can somebody acknowledge this behavior? Just to be sure it's not an
issue of some other part of my setup.
#1) Why could this be an issue? Should we insert a warning or does
anybody have a clue on how I/we could possibly fix this?
Is it possible to override thumb/arm mode setting for a
single package in yocto?
#2) Which TUNE_FEATURES are recommended for i.mx6q/dl?
I based our distro on fslc-base/framebuffer and our board
on sabresd which uses "thumb".
#3) What advatages/disadvantages does the (not) using of thumb mode
cause for my whole system?
I already discovered, that e.g.
libQt5WebEngineCore.so.5.9.4 grew from ~50mb to ~120mb.
#4) Do I need -mcpu=cortex-a9 for i.mx6? Or is -march=armv7-a enough?
GCC doc state it is used to further optimize code for the
target. Is there a reason why is it not set for imx6q/dl on sabresd?
Thanks in advance,
Peter
On 2018/03/12 at 08:55 Peter wrote:
Hi!
Did anybody successfully run a qtwebengine application built with
qt5.9 or 5.10 on rocko?
I'm building for i.mx6 (eglfs) and getting more or less the same
errors on 5.9 and 5.10.
The problem seems to lie somewhere in
qtwebengine/3rdparty/chromium/thirdparty/boringssl which makes it
quite an easy target to debug...
On 5.10 I get a bus errror (SIGBUS) because of an unaligned access:
./quicknanobrowser -platform eglfs http://heise.de/security
Alignment trap: not handling instruction ecd6cb04 at [<734fd3b8>]
Unhandled fault: alignment exception (0x001) at 0x734fcce1
pgd = d9a70000
[734fcce1] *pgd=69a75831, *pte=61c6359f, *ppte=61c63e7e
Received signal 7 BUS_ADRALN 0000734fcce1
#0 0x00007401b66a <unknown>
#1 0x00007401b4e6 <unknown>
#2 0x00007347ae48 <unknown>
#3 0x00007401b8e2 <unknown>
#4 0x00007635bbc0 <unknown>
[end of stack trace]
Calling _exit(1). Core file will not be generated.
If I use https qtwebengine simply complains about the webpage not
being available and throws the following error on the command line:
[503:523:0309/095037.841842:ERROR:ssl_client_socket_impl.cc(1129)]
handshake failed; returned -1, SSL error code 1, net_error -126
So I traced the error down to bsaes_ctr32_encrypt_blocks inside the
boringSSL implementation:
Starting program: ./quicknanobrowser -platform eglfs
http://heise.de/security
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
'/tmp/runtime-root'
QEglFSVivIntegration will set environment variable FB_MULTI_BUFFER=2
to enable double buffering and vsync.
If this is not desired, you can override this via: export
QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1
[New Thread 0x681d53c0 (LWP 565)]
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and
QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
qt.qpa.input: X-less xkbcommon not available, not performing key mapping
[New Thread 0x673603c0 (LWP 566)]
[New Thread 0x64a523c0 (LWP 567)]
[New Thread 0x640ff3c0 (LWP 569)]
[New Thread 0x638ff3c0 (LWP 570)]
[New Thread 0x630ff3c0 (LWP 571)]
[New Thread 0x628ff3c0 (LWP 572)]
[New Thread 0x620ff3c0 (LWP 573)]
[New Thread 0x618ff3c0 (LWP 574)]
[New Thread 0x610ff3c0 (LWP 575)]
[New Thread 0x608ff3c0 (LWP 576)]
[New Thread 0x600ff3c0 (LWP 577)]
[New Thread 0x5f8ff3c0 (LWP 578)]
[New Thread 0x5f0ff3c0 (LWP 579)]
[New Thread 0x5e8ff3c0 (LWP 580)]
[New Thread 0x5e0ff3c0 (LWP 581)]
[New Thread 0x5d8ff3c0 (LWP 582)]
[New Thread 0x5d0ff3c0 (LWP 583)]
[New Thread 0x5c8ff3c0 (LWP 584)]
[New Thread 0x5c0ff3c0 (LWP 585)]
[New Thread 0x5b8ff3c0 (LWP 586)]
[New Thread 0x5b0ff3c0 (LWP 587)]
[New Thread 0x5a81d3c0 (LWP 588)]
[New Thread 0x597ff3c0 (LWP 597)]
[Thread 0x597ff3c0 (LWP 597) exited]
Alignment trap: not handling instruction ecd6cb04 at [<7349b5f8>]
Unhandled fault: alignment exception (0x001) at 0x7349af21
pgd = d8d50000
[7349af21] *pgd=68a4e831, *pte=67c3059f, *ppte=67c30e7e
Thread 19 "Chrome_IOThread" received signal SIGBUS, Bus error.
[Switching to Thread 0x5d0ff3c0 (LWP 583)]
0x7349b5fc in _bsaes_key_convert () from
/usr/lib/libQt5WebEngineCore.so.5
(gdb) backtrace
#0 0x7349b5fc in _bsaes_key_convert () from
/usr/lib/libQt5WebEngineCore.so.5
#1 0x7349b98e in bsaes_ctr32_encrypt_blocks () from
/usr/lib/libQt5WebEngineCore.so.5
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
I couldn't find an option to use system ssl libs instead of chromium's
own libs or is there one hidden I'm not aware of?
One possible problem I could imagine is boringssl being built for the
wrong architecture, as there are multiple asm files for armv4, x86 and
so on... do you think that's a likely cause or might my toolchain be
broken somehow?
Thanks in advance & best regards,
Peter
--
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
