Posts by chewitt

    if I use that test image you provided, will I be able to upgrade to the next release?

    The test image is based on LE13 nightlies and Kodi doesn't support downgrades. If you stop Kodi, remove /storage/.kodi, then update to LE 12.0.2 you'll end up with a working install as we don't touch u-boot (where the test patch was applied) after install.

    It might be easiest to stick to LE13 nightlies though. I've been using them (albeit on an RPi5) for months and things are stable. I'm not aware of anything that should be different on AMLGX other than it being AMLGX and thus less reliable than an RPi5 /shrug

    I've the same questions about why some users see this and not others. I have a hunch something changed in kernel or u-boot so it affects only new installs beyond a certain (unknown) point. I don't think it's related to board revision, although I know my board is from the last production batch that HK made; C2 was discontinued shortly after HK posted a sample to me.

    It fails to initialise the Broadcom WiFi chip on the device; hence no WiFi.

    I'm not sure what the issue is, but as a starting point please retest with the VIM3L image from https://chewitt.libreelec.tv/testing/ which is using a newer kernel.

    Code
    Feb 27 17:26:04.259217 LibreELEC kernel: Memory: 1523152K/2093056K available (13696K kernel code, 2220K rwdata, 3936K rodata, 10432K init, 856K bss, 45616K reserved, 524288K cma-reserved)

    The RPi5 2GB model was launched shortly after we shipped LE 12.0.1 and it requires some specific mesa graphics patches that don't exist in the 12.0.1 release. Use the latest nightly from https://test.libreelec.tv/12.0/RPi/RPi5/ (scroll down) and it should work fine.

    RPi4/5 boards don't support 4K60 at HDMI 4:2:0 which causes some issues with TV's that default to that mode. This is when config might be needed on the TV side to enable special modes (LG calls it Deep Colour, no idea what Sony might call it). However that issue will normally result in 4K50/59.94/60 modes not being detected and thus not being usable. It doesn't normally prevent you seeing the Kodi desktop. In your case it looks like something is being rendered (but messed up).

    If you add "video=HDMI-A-1:1920x1080M@60" to boot params in "cmdline.txt" (all on one line) it will force the initial HDMI output on the HDMI connector nearest the power connector to 1080p, which will eliminate a 4K issue from suspicion. If you also add "ssh" to boot params it will force the SSH daemon to start so you can SSH into the device to run "pastekodi" and share logs (share the URL generated here).

    Boot from USB and set "BOOT_ORDER=0xf461" via "rpi-eeprom --config" so the device can boot from NVME, then power off. Now image the M2 drive with the RPi5 image (same as you created the USB). Once imaging is complete, edit config.txt on the M2 drive to add "dtparam=nvme" then attach the NVME drive to the RPi5 and it should boot (make sure the USB drive is disconnected).

    The system log shows kernel boot in six seconds, which is overall fast. That likely means the delay happens on the Apple firmware side; figuring out what EFI firmware bootloader to use. If other OS boot faster, perhaps see what bootloader they use and think about switching the LE install to use the same one. That might ential a little experimenting and reworking of boot config files, but the format of e.g. grub2 vs. syslinux are fairly similar so it's not impossible. There is of course no wiki article or nice HOWTO guide for that so you'll need to take the initiative.

    The Apple IR receiver shows up as a Linux input device so you should be able to experiment with https://wiki.libreelec.tv/configuration/…ration-advanced to see if other remote devices are detectable (probably).

    It's not possible to configure multiple resolutions, but it shouldn't be necessary. Configure for 720p and Kodi should simply scale the older 480p media to 720p for output. The default behaviour for 4:3 content will be (or should be) to show vertical black bars left/right of the video. The alternative is to stretch media to 16:9 of use a zoom, but that usually sucks. You can experiment with options via the OSD menu once video is playing.

    The forum sees a moderate amount of attempted pharma spam from human 'bots' that bypass whatever technological registration/login restrictions are implemented. It's occasionally annoying, but the list is effective and overall impact is low so it stays.

    Moving back on-topic: There's an air of mystery around the trigger conditions, but ultimately the probably-radio-side cause is less important than ensuring retries (or resets, or doing something like that) result in a connection. It needs someone to run iwd and connman in debug mode and then trace what's observed in logs (both are reasonably verbose and somewhat human readable) against the actual code, and spot where the code/logic breaks. I too script. I can pseudo-read code to a point, but not well enough for this issue. It's not just about reading logs through. It probably requires some patching to add "printf" reporting of values that are being moved around between services.

    I think it's impossible to update python to 3.x in this LE version ?

    Correct, because the embedded version of Kodi used requires Python 2.x to function, and if you bump beyond that version of Kodi towards the Python 3.x era you'll find that support for proprietary decoding methods (amcodec) has been exorcised from Kodi.

    AMLGX on WP2 is usable but not perfect (and no internal tuners of course). I've not abandoned all hope that someone will revive work on the upstream hardware decoders to improve things, but i'm not hold breath. And I doubt anyone will ever get the internal tuners working. The technical gap between fixing up driver code enough to compile (which I already did) and rewiring it to modern kernel frameworks (which is way beyond my abilities) probably isn't too huge, but it takes a certain level of knowledge, persistence, and desire to wade through some horrible driver code, that doesn't come along often.

    Thanks for the feedback (and credit for the change is for MartinB not myself). The next challenge is to explain why this issue appears now (recently) and not years ago. In other words: what other change has someone done in the (u-boot/kernel) codebase to result in this being required?. Once that's been explained the upstream maintainers can think about pushing a global change to e.g. gxbb/gxl platform .dtsi files (not board level files) to fix the issue everywhere.

    In the short term I'll include the patch for C2 and see if it also solves a similar (but older) issue report on WeTek Hub.