168 replies to this topic

[A.A.]

See in OE-A

 

defconfig
CONFIG_CMDLINE="libata.force=1:1.5Gbps bmem=192M@64M bmem=220M@512M memc1=788M ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs rw rootflags=sync"
defconfig-proxy
CONFIG_CMDLINE="libata.force=1:1.5Gbps bmem=192M@64M bmem=384M@512M memc1=788M ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs rw rootflags=sync"

[WanWizard]

Still not merge: https://github.com/v...-vuplus/pull/72

So have to wait till this happens first.

 

Appearently their development team is unavailable because of Covid-19.

 

We've pushed to get this done, and they found someone else to push the PR button.

[Erik Slagter]

"Bus error" is not 100% defined, but often means something like unaligned memory access. For a MMU prohibiting access one way or another, usually a "segmentation fault" is raised.

[A.A.]

@Erik

 

Yes, on x86 and arm is a symptom of unalignments.

 

For now I am disassembling the private libs:

 

libxbmc_base.so

https://pastebin.com/Qeztcmjf

 

xbmc.helper

https://pastebin.com/KzJ10AZd

 

I see there are indeed encoding funcs.

To see what is failing I need more time to recompile with symbols (or maybe use the debug packages as 2nd option) and branch serial to GDB..

 

Maybe this weekend

 

Cheers

A.A.

[A.A.]

And now the ldd output of kodi-stb mipsel

 

https://pastebin.com/1a2rD11M

 

 

@WTE:you mean this?

 

    libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x74ce1000)

    libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x74aa0000)

 

 

but it doesn't seem used in the closed source bins:

 

root@vuduo2:~# ldd /usr/bin/xbmc.helper
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x76e12000)
    libm.so.6 => /lib/libm.so.6 (0x76d94000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x76d5c000)
    libc.so.6 => /lib/libc.so.6 (0x76bd0000)
    /lib/ld.so.1 (0x77013000)

 

root@vuduo2:~# ldd /usr/lib/libxbmc_base.so
    libpthread.so.0 => /lib/libpthread.so.0 (0x770c1000)
    librt.so.1 => /lib/librt.so.1 (0x770a9000)
    libdvb_base.so => /usr/lib/libdvb_base.so (0x76c3f000)
    libdvb_client.so => /usr/lib/libdvb_client.so (0x76c28000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x76a2d000)
    libm.so.6 => /lib/libm.so.6 (0x769af000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x76977000)
    libc.so.6 => /lib/libc.so.6 (0x767e9000)
    /lib/ld.so.1 (0x77112000)
root@vuduo2:~#

so maybe libcrypto is just for samba?

Edited by A.A., 10 June 2020 - 22:27.

[A.A.]

@Erik

 

I got a suggestion:  sigbus is alignment trap

[WTE]

I get the same error when I close kodi. So I think this can been ignored.

When kodi even don't start and doesn't make a log file then something else is not ok on your box.

 

You first need to know what the strange VU plugins do. Is this only for v3ddriver or something else.

 

Second maybe ssl is need by libdvb_base.so or libdvb_client.so

Edited by WTE, 11 June 2020 - 09:42.

[A.A.]

>Second maybe ssl is need by libdvb_base.so or libdvb_client.so

 

No, I checked with ldd as well.

Now I am not at home and cannot check but I am pretty sure.

 

I'll rebuild an image and maybe link with ld instead of gold.

As said, to remove any doubts the solution is GDB.

A.A.

[Erik Slagter]

@Erik

 

I got a suggestion:  sigbus is alignment trap

 

Yeah that's what I am saying!?

[A.A.]

@Erik

 

heh, indeed

 

I've got a second advice today:

<khem> ant_: dont use gold on mips

[Erik Slagter]

gold = loader/linker?

 

BTW x86 does allow unaligned access (although severily penalised in duration, so you really should avoid it). I am not sure about x86-64, I am assuming here that AMD did "the right thing" and made it illegal too. The great advantage of trapping it is that you can spot any place where it happens without help from compiler, assembler and linker AND that you can chose to handle the trap (if implemented properly) in software (like FPU emulation) if you really can't avoid it for whatever reason. It will probably be only marginally slower than having the CPU handle it itself.

 

I am currently working with Tensilica microcontrollers and they allow or forbid unaligned access depending on what type of memory (like "instruction" vs. "data" RAM or register space), even "worse" .

Edited by Erik Slagter, 12 June 2020 - 10:05.

[A.A.]

@Erik

 

for arm, when OE moved from gcc6 to gcc7 I got beaten by a compiler bug [1]: kernel was booting on quemu but not on real hardware.

In fact quemu was/is not strict about alignment

 

I don't know how mips suffers it, the first suggestion from TC people is to use the ld linker.

 

Let's hope it will not be the same nightmare...

 

Cheers

A.A.

 

[1]

https://gcc.gnu.org/...ug.cgi?id=82445

http://patches.linar...g/patch/118362/

[Erik Slagter]

We're now working on the next release candidate, which is based on sumo and it uses gcc-6.3 apparently. The now active develop branch is based on thud now, and that uses gcc-8.2 apparently. So I don't think we ever used gcc7 actually.

 

I was wrong. Excuse me.

 

Our current release candidate is on Pyro, we never switched to Sumo, in the end, due to various reasons.

 

So: rc: Pyro: 6.3, develop: thud: 8.2.

 

It seems like Sumo used gcc 7, but we've never had a release with it.

 

The next release will be Zeus BTW, but we're stepping carefully by first completely applying and testing thud.

Edited by Erik Slagter, 12 June 2020 - 14:10.

[A.A.]

Unfortunately I get the same SIGBUS even linking with ld.

For fun I have flashed OpenSPA 7.4.007-vuduo2 and kodi 18.7 starts.

 

Next is to boot with this OE-A kernel.

[Erik Slagter]

I think that was to be expected. I think it's unlikely that a linker introduces an unaligned memory access. If it would, it would certainly be a bug. I am thinking of two more likely scenarios:

 

- missing or overriding default (correct) alignments in the code itself

- a stray pointer that also happens to be unaligned

 

Last case is most probably imho.

[WanWizard]

I've got the develop build on most boxes working again, currently struggling with the VuDuo4K, which refuses the build webkit-gtk.

 

This smells like another icu issue:

2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/umachine.h:340:13: error: 'char16_t' does not name a type
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/uversion.h:173:55: error: 'UChar' does not name a type; did you mean 'UChar32'?
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/uchar.h:4036:33: error: 'UChar' has not been declared
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/uscript.h:631:45: error: 'UChar' has not been declared
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/putil.h:159:33: error: 'UChar' has not been declared
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/putil.h:181:23: error: 'UChar' does not name a type; did you mean 'UChar32'?

any idea what to clean and rebuild to get rid of it?

[foxbob]

Try this recipe, it collects without errors from me.

SUMMARY = "WebKit web rendering engine for the GTK+ platform"
HOMEPAGE = "http://www.webkitgtk.org/"
BUGTRACKER = "http://bugs.webkit.org/"

LICENSE = "BSD & LGPLv2+"
LIC_FILES_CHKSUM = "\
	file://Source/WebCore/rendering/RenderApplet.h;endline=22;md5=fb9694013ad71b78f8913af7a5959680 \
	file://Source/WebKit/gtk/webkit/webkit.h;endline=21;md5=b4fbe9f4a944f1d071dba1d2c76b3351 \
	file://Source/JavaScriptCore/parser/Parser.h;endline=23;md5=2f3cff0ad0a9c486da5a376928973a90 \
	"

DEPENDS = "glib-2.0 glib-2.0-native gettext-native zlib enchant2 libsoup-2.4 curl libxml2 cairo libidn2 gnutls \
           gtk+ gstreamer1.0 gstreamer1.0-plugins-base flex-native bison-native gperf-native sqlite3 \
           libxslt libpcre harfbuzz pango atk udev"

PR = "r6"
PV = "r95199"

BRANCH="vuplus-webkit"
SRCREV="9eed47d1f873a13759d3fd8ead72739b328d710a"

SRC_URI = "git://code.vuplus.com:/git/webkit-r95199-base.git;protocol=http;branch=${BRANCH};rev=${SRCREV} \
    file://0001-bison-3.patch \
    file://0001-fix-build-with-gcc-6.20.patch \
    file://0001-fix-build-issue-with-cglib-2.2.4.patch \
    file://webkit-gtk_fixed_crash_error.patch \
    file://maketokenizer.patch \
"

inherit autotools lib_package gtk-doc pkgconfig perlnative pythonnative

S = "${WORKDIR}/git"

EXTRA_OECONF = "\
	--enable-debug=no \
	--with-gtk=2.0 \
	--with-unicode-backend=glib \
	--disable-spellcheck \
	--enable-optimizations \
	--disable-channel-messaging \
	--disable-meter-tag \
	--enable-image-resizer \
	--disable-sandbox \
	--disable-xpath \
	--disable-xslt \
	--disable-svg \
	--disable-filters \
	--disable-svg-fonts \
	--disable-video \
	--disable-video-track \
	--with-target=directfb \
	--disable-jit \
	--enable-fast-malloc \
	--enable-shared-workers \
	--enable-workers \
	--enable-javascript-debugger \
	--enable-fast-mobile-scrolling \
	--enable-offline-web-applications \
	"

LDFLAGS += "-Wl,--no-keep-memory -lgthread-2.0"

CPPFLAGS += "-I${STAGING_INCDIR}/pango-1.0 \
            -I${STAGING_LIBDIR}/glib-2.0/include \
            -I${STAGING_INCDIR}/glib-2.0"

CXXFLAGS += " -std=gnu++98"

OECMAKE_GENERATOR = "Unix Makefiles"

EXTRA_AUTORECONF = " -I Source/autotools "

ARM_INSTRUCTION_SET = "arm"

COMPATIBLE_HOST_mips64n32 = "null"

CONFIGUREOPT_DEPTRACK = ""

do_configure_append() {
	# somethings wrong with icu, fix it up manually
	for makefile in $(find ${B} -name "GNUmakefile") ; do
		sed -i s:-I/usr/include::g $makefile
	done
	# remove hardcoded path to /usr/bin/glib-mkenums
	for makefile in $(find ${B} -name "GNUmakefile") ; do
		sed -i s:/usr/bin/glib-mkenums:glib-mkenums:g $makefile
	done
}

do_install_append() {
        rmdir ${D}${libexecdir}
        install -d ${D}/usr/bin
        install -m 0755 ${WORKDIR}/build/Programs/GtkLauncher ${D}/usr/bin/webkit.launcher
}

PACKAGES =+ "${PN}-webinspector bjavascriptcore"
FILES_libjavascriptcore = "${libdir}/libjavascriptcoregtk-1.0.so.*"
FILES_${PN}-webinspector = "${datadir}/webkitgtk-*/webinspector/"
FILES_${PN} += "${datadir}/webkitgtk-*/resources/error.html \
                ${datadir}/webkitgtk-*/images \
                ${datadir}/glib-2.0/schemas"

[WTE]

I've got the develop build on most boxes working again, currently struggling with the VuDuo4K, which refuses the build webkit-gtk.

 

This smells like another icu issue:

2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/umachine.h:340:13: error: 'char16_t' does not name a type
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/uversion.h:173:55: error: 'UChar' does not name a type; did you mean 'UChar32'?
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/uchar.h:4036:33: error: 'UChar' has not been declared
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/uscript.h:631:45: error: 'UChar' has not been declared
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/putil.h:159:33: error: 'UChar' has not been declared
2020-06-15 14:35:49 | /data/openpli/pli-oe/develop/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/webkit-gtk/r95199-r5/recipe-sysroot/usr/include/unicode/putil.h:181:23: error: 'UChar' does not name a type; did you mean 'UChar32'?

any idea what to clean and rebuild to get rid of it?

Seems vu+ uses it's own 5 year old version of webkit-gtk

https://github.com/v...bkit-gtk_git.bb

 

Probably it need a patch for the unicode char.

[Erik Slagter]

Yes, indeed. All the browser stuff in de VU+ BSP is ancient.

 

We have complained various times.

Edited by Erik Slagter, 15 June 2020 - 18:01.

[foxbob]

I searched for such a patch and did not find it. I found the recipe on OE-A.

Edited by foxbob, 15 June 2020 - 18:13.