[VDR*ELEC] LibreELEC/AMLGX (arm) Probleme/Diskussion

Der Wunsch kam auf, Probleme, die explizit LE/AMLGX betreffen aus dem anderen Thread rauszuhalten.

Wobei ich sagen muss, der andere Thread ist mir schon zu unübersichtlich geworden.

Erstmal der Stand:

Ich teste mit Odroid N2+ und LE mit AMLGX startet soweit und kann benutzt werden. Als Ausgabedevice habe ich softhddevice-drm-gles gewählt.

Meine aktuellen Probleme:

- Plugins, die nicht funktionieren: skindesigner, live.

- Das Ausgabedevice softhddevice-drm-gles

- Beim Kanalwechsel sehe ich erst ein sehr buntes Bild mit sehr viele Farben statt einem Schwarzbild.

- Das bunte Bild kommt auch, bevor ich im Web ein Video öffne und dieses abgespielt wird.

- Beim Kanalwechsel sieht das Bild erst blass aus, dunkelt aber kurze Zeit später noch nach bevor das Kanalinfo-OSD verschwindet.

- Der Deinterlacer funktioniert gar nicht. Das liegt wohl an den Treibern/Kernel/o.ä.

Für skindesigner hat rell etwas an libsrvg und rust gebastelt. Das muss ich noch testen, das dauert aber etwas, da ich ein Neubuild machen muss. Ich denke meine eigenen Versuche haben die Toolchain geröstet.

Für den Kanalwechsel hoffe ich bald ein Video aufnehmen zu können, wenn der HDMI Grabber da ist, funktioniert und ich ihn zum laufen bringen kann.

Zitat von @rell

Noch nicht getestet, aber vielleicht löst es das Problem. Das Problem liegt an librsvg, wenn ich mich richtig erinnere. Mit dem Patch oben wird die Version gepusht und nutzt das onboard rust.

Ich habe deinen Patch eingespielt. Allerdings baut es nicht mehr:

checking for cos in -lm... yes
checking for dlopen... yes
checking for armv8a-libreelec-linux-gnueabihf-cargo... no
checking for cargo... no
configure: error: cargo is required.  Please install the Rust toolchain from https://www.rust-lang.org/
FAILURE: scripts/build _librsvg during configure_target (default)
*********** FAILED COMMAND ***********
${PKG_CONFIGURE_SCRIPT} ${TARGET_CONFIGURE_OPTS} ${PKG_CONFIGURE_OPTS_TARGET}

Das war - glaube ich der Grund - warum ich rustup mit reingenommen habe.

Meine Versuche mit cargo, cargo-snapshot in der package.mk waren bisher erfolglos.

Zitat von rell

Probier mal ein cargo:host bei den depends.

Hier hat ein AMLGX build mit diesem branch funktioniert, allerdings habe ich vorher das system-tools addon gebaut und da ist cargo auch in den Abhängigkeiten.

cargo:host habe ich eingetragen und nun wird ein Build von llvm:host versucht und der geht auch schief. Allerdings finde ich die Kommandos, die ausgeführt werden sollen, sehr seltsam und auch irgendwie falsch.

/usr/bin/ccache: invalid option -- 'D'
[4/3211] Building ASM object lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o
FAILED: lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o 
/usr/bin/ccache -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS <viel mehr Kommandozeile>

Direkt hinter dem /usr/bin/ccache fehlt doch das eigentliche Kommando: Compiler, Assembler, was auch immer.

Endlich habe ich es geschafft. Es musste "nur" die Build-Konfiguration von llvm geändert werden.

Der Build hat 2 extreme Nachteile:

1. Er löst das Problem mit librsvg nicht. Der Fehler taucht immer noch auf

2. Die Build-Zeit verlängert sich geschmeidig um 2 Stunden und das ist etwas sehr viel.

So langsam denke ich, es liegt an den Compile-Flags von rustc für librsvg.

Zitat von rell

Keine Ahnung, was da ist, aber bei mir läuft der Build ohne patches durch. Kannst du mir deinen build cmd sagen, dann teste ich das bei mir nochmal "frisch"?

Das Hauptproblem liegt wohl an dem Host bzw. dem Host-Compiler und den installierten Bibliotheken. Hier habe ich Debian 12 laufen und readline und ncurses und wie, bzw. ob die überhaupt gelinkt sind.

Zitat von rell

Ich habe mir ein Image für die WetekPlay2 gemacht und das bootet, alles lässt sich installieren, VDR läuft, aber auf dem Schirm kommt nichts Das ging schonmal... Suche geht weiter. Bis auf dass kein Bild kommt, ging jedenfalls das install skript fast Wenn läuft stelle ich einen MR. Das verkürzt eine frische Installation auf 4 Kommandos :p

Perfekt Das aktuelle Install-Script läuft schon ziemlich gut.

Interessehalber wollte ich mal schauen, was genau in librsvg Probleme macht - auch wenn ich davon nicht viel verstehe

Thread 1 "vdr" received signal SIGILL, Illegal instruction.
0xf2858eb0 in rsvg_handle_new_with_flags () from /usr/lib/librsvg-2.so.2
#0  0xf2858eb0 in rsvg_handle_new_with_flags () from /usr/lib/librsvg-2.so.2
#1  0xf2859654 in rsvg_handle_new_from_gfile_sync () from /usr/lib/librsvg-2.so.2
#2  0xf28594b8 in rsvg_handle_new_from_file () from /usr/lib/librsvg-2.so.2
#3  0xf2c789d4 in cImageImporterSVG::LoadImage(char const*) () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#4  0xf2c79e90 in cImageLoader::LoadImage(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
   from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#5  0xf2c757a0 in cImageCache::LoadSkinpart(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#6  0xf2c7635c in cImageCache::GetSkinpart(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, int) () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#7  0xf2c9d2a4 in cFuncDrawImage::PreCacheImage() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#8  0xf2cfee64 in cArea::Cache() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#9  0xf2cc021c in cViewElement::Cache() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#10 0xf2cb1a48 in cView::PreCache() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#11 0xf2cb40e0 in cViewChannel::PreCache() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#12 0xf2c64148 in cSkinDesigner::CacheViews() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#13 0xf2c65728 in cSkinDesigner::Init() () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#14 0xf2c65898 in cSkinDesigner::DisplayChannel(bool) () from /usr/local/lib/vdr/libvdr-skindesigner.so.2.6.3
#15 0x000cfe94 in cDisplayChannel::cDisplayChannel(int, bool) ()
#16 0x000cfff4 in cDisplayChannelExtended::cDisplayChannelExtended(int, bool) ()
#17 0x000728f8 in main ()

Das Disassemble ergibt dann

Dump of assembler code for function rsvg_handle_new_with_flags:
   0xf2858e90 <+0>:     push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
   0xf2858e94 <+4>:     sub     sp, sp, #572    @ 0x23c
   0xf2858e98 <+8>:     sub     sp, sp, #1024   @ 0x400
   0xf2858e9c <+12>:    mov     r6, r0
   0xf2858ea0 <+16>:    ldr     r0, [pc, #732]  @ 0xf2859184 <rsvg_handle_new_with_flags+756>
   0xf2858ea4 <+20>:    mov     r7, #0
   0xf2858ea8 <+24>:    ldr     r0, [pc, r0]
   0xf2858eac <+28>:    ldr     r0, [r0]
=> 0xf2858eb0 <+32>:    mcr     15, 0, r7, cr7, cr10, {5}
   0xf2858eb4 <+36>:    cmp     r0, #4
   0xf2858eb8 <+40>:    bne     0xf2859088 <rsvg_handle_new_with_flags+504>
   0xf2858ebc <+44>:    ldr     r0, [pc, #716]  @ 0xf2859190 <rsvg_handle_new_with_flags+768>
   0xf2858ec0 <+48>:    add     lr, sp, #1024   @ 0x400
   0xf2858ec4 <+52>:    add     r9, lr, #24
   0xf2858ec8 <+56>:    add     r1, sp, #536    @ 0x218
   0xf2858ecc <+60>:    mov     r2, #512        @ 0x200
   0xf2858ed0 <+64>:    ldr     r0, [pc, r0]
   0xf2858ed4 <+68>:    ldr     r8, [r0, #32]
   0xf2858ed8 <+72>:    mov     r0, r9
   0xf2858edc <+76>:    bl      0xf2841990 <memcpy@plt>

mcr? Soso. Tante Google sagt dann z.B. sowas

Zitat

MCR and MRC don't exist in ARMv8.

MCR and MRC does not exist on AARCH64?

I am trying to compile "mrc" and "mcr" instruction on AARCH64 based on Board but I am seeing below error message tmp/ccqOHmrK.s: Assembler messages:…

stackoverflow.com

Error: unknown mnemonic `mcr' for aarch64? - Architectures and Processors forum - Support forums - Arm Community

Mir ist nicht ganz klar, was hier gemeint ist mit aarch32/64 und ein unterschiedlicher Befehlssatz.

Ich kann kein Rust, aber die entsprechende Funktion

#[no_mangle]
pub unsafe extern "C" fn rsvg_handle_new_with_flags(flags: RsvgHandleFlags) -> *const RsvgHandle {
    let obj = glib::Object::builder::<CHandle>()
        .property("flags", HandleFlags::from_bits_truncate(flags))
        .build();

    obj.to_glib_full()
}

deutet eher auf glib (oder das rust binding) als Ursache, als auf librsvg.

Zitat von rell

Da bin ich total überfragt... Jedenfalls klappt LE mit skindesigner nicht. Bei CE funktionierts, oder?

Ich habe den Skindesigner produktiv laufen und unter CE funktionierts. Und genau das ist mein Problem. librsvg, skindesigner, rustc sind in beiden Fällen identisch. Es gibt beim Bauen keinen speziellen Switch. Es ist sogar auch noch dieselbe Maschine und trotzdem gibt es Unterschiede zur Laufzeit. Also muss es einen Unterschied zwischen CE und LE geben, den Unterbau betreffend.

Ich habe versucht den HDMI-Videograbber zu aktivieren, allerdings ohne Erfolg. Kodi funktioniert einwandfrei, aber vom VDR bekomme ich da kein Bild und kann leider kein Video erzeugen, daß das Problem anschaulich darstellt. Sehr merkwürdig das Ganze.

Die Ursache für skindesigner und live wurde gefunden.

Die Ursache ist die "cp15 barrier emulation". Alles klar.... Ich hatte befürchtet, ich müsste die Kernel-Konfiguration patchen:

32bit rust compiler doesn't run new kernels. (only legacy will work)

To run 32bit rustc you need enabled cp15 barrier emulation. (This is removed in ARMV8 arch and needed to emulated by the kernel) Please reenable like in legacy…

forum.armbian.com

Aber es reicht, wenn der rustc Compiler geändert wird von

arm-unknown-linux-gnueabihf auf armv7-unknown-linux-gnueabihf

Damit werden zwar armv6 nicht mehr unterstützt, aber das sollte hoffentlich zu verschmerzen sein. Es betrifft z.B. RPI 1.

Zitat

CP15, the System Control coprocessor, provides control of many features of the core....

Documentation – Arm Developer

Was immer der auch macht.

abi.cp15_barrier = 2. Ich weiß gar nicht mehr, wie das reinkam, aber das hat etwas mit dem Kernel zu tun. Hardware oder Software Emulation. 2 (HW), 1 (SW). Ich denke für 1 müsste man tatsächlich die Kernel-Konfiguration für den Build ändern.

Aber mehr weiß ich dazu auch nicht. Mein ganzes Wissen habe ich jetzt ausgebreitet

Zitat von rell

nur zur Info, ich habe jetzt einen Odroid aufgesetzt, und kann deine Probleme nachstellen. Komisch, dass das Nachdunkeln und die Klötzchen bei der WetekPlay2 nicht auftreten.

Juchuuu. Ich habe mir das nicht eingebildet Sehr beruhigend.