I'd guess that you haven't forced recovery boot mode so the box is still looking for kernel.img and dtb.img files that don't exist in the AMLGX image. Read: https://wiki.libreelec.tv/hardware/amlogic
Posts by chewitt
-
-
-
it looks like the web site sorts ascending by default and I might/probably have been grabbing an old nightly.
I had a hunch that might have happened. If it's any consolation you're not the first sort-order victim
-
See if the latest LE13 nightly has support?
-
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
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.
-
Code
Display MoreOct 12 16:58:58.548558 LibreELEC kernel: brcmfmac: F1 signature read @0x18000000=0x17294359 Oct 12 16:58:58.552580 LibreELEC kernel: ------------[ cut here ]------------ Oct 12 16:58:58.552778 LibreELEC kernel: WARNING: CPU: 2 PID: 351 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:934 brcmf_chip_attach+0x888/0x97c [brcmfmac] Oct 12 16:58:58.552862 LibreELEC kernel: Modules linked in: ir_nec_decoder(+) videobuf2_dma_contig(+) brcmfmac(+) rc_khadas brcmutil videobuf2_memops rtc_hym8563 gpio_pca953x meson_ir(+) khadas_mcu v4l2_mem2mem videobuf2_v4l2 rtc_meson_vrtc videobuf2_common gpio_keys_polled cfg80211 rfkill pkcs8_key_parser fuse nfnetlink Oct 12 16:58:58.552939 LibreELEC kernel: CPU: 2 PID: 351 Comm: (udev-worker) Not tainted 6.8.0 #1 Oct 12 16:58:58.553048 LibreELEC kernel: Hardware name: Khadas VIM3L (DT) Oct 12 16:58:58.553117 LibreELEC kernel: pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) Oct 12 16:58:58.553182 LibreELEC kernel: pc : brcmf_chip_attach+0x888/0x97c [brcmfmac] Oct 12 16:58:58.553251 LibreELEC kernel: lr : brcmf_chip_attach+0x5fc/0x97c [brcmfmac] Oct 12 16:58:58.553316 LibreELEC kernel: sp : ffff800083643650 Oct 12 16:58:58.553380 LibreELEC kernel: x29: ffff800083643650 x28: 000000001810c030 x27: 000000001810c028 Oct 12 16:58:58.553445 LibreELEC kernel: x26: 0000000000000003 x25: ffff000007b9e900 x24: ffff8000811bbd28 Oct 12 16:58:58.553512 LibreELEC kernel: x23: 000000000000000b x22: 00000000ffffffff x21: ffff000007b9e948 Oct 12 16:58:58.553576 LibreELEC kernel: x20: 000000000000000f x19: 000000000000083e x18: 0020000000000000 Oct 12 16:58:58.553646 LibreELEC kernel: x17: 0000000000000000 x16: 0000000000000000 x15: ffff00007f384f70 Oct 12 16:58:58.553713 LibreELEC kernel: x14: ffff00007f384f60 x13: ffff00000b01b400 x12: 00000000000000a0 Oct 12 16:58:58.553803 LibreELEC kernel: x11: ffff00000b01b400 x10: 0000000000001320 x9 : 0000000000000001 Oct 12 16:58:58.553869 LibreELEC kernel: x8 : 000000000008031c x7 : 0000000000000018 x6 : 0000000000000080 Oct 12 16:58:58.553933 LibreELEC kernel: x5 : 000000000000007f x4 : 0000000000000000 x3 : 0000000000000000 Oct 12 16:58:58.553997 LibreELEC kernel: x2 : 0000000000000000 x1 : 0000000000000005 x0 : 000000000000000f Oct 12 16:58:58.554067 LibreELEC kernel: Call trace: Oct 12 16:58:58.554145 LibreELEC kernel: brcmf_chip_attach+0x888/0x97c [brcmfmac] Oct 12 16:58:58.554210 LibreELEC kernel: brcmf_sdio_probe+0x26c/0x8e8 [brcmfmac] Oct 12 16:58:58.554274 LibreELEC kernel: brcmf_sdiod_probe+0x130/0x230 [brcmfmac] Oct 12 16:58:58.554338 LibreELEC kernel: brcmf_ops_sdio_probe+0x15c/0x228 [brcmfmac] Oct 12 16:58:58.554401 LibreELEC kernel: sdio_bus_probe+0x13c/0x1e8 Oct 12 16:58:58.554463 LibreELEC kernel: really_probe+0x188/0x3c4 Oct 12 16:58:58.554533 LibreELEC kernel: __driver_probe_device+0x7c/0x16c Oct 12 16:58:58.554614 LibreELEC kernel: driver_probe_device+0x3c/0x110 Oct 12 16:58:58.554679 LibreELEC kernel: __driver_attach+0xf8/0x204 Oct 12 16:58:58.554743 LibreELEC kernel: bus_for_each_dev+0x74/0xd4 Oct 12 16:58:58.554807 LibreELEC kernel: driver_attach+0x24/0x30 Oct 12 16:58:58.554870 LibreELEC kernel: bus_add_driver+0x114/0x224 Oct 12 16:58:58.554933 LibreELEC kernel: driver_register+0x5c/0x124 Oct 12 16:58:58.555012 LibreELEC kernel: sdio_register_driver+0x28/0x34 Oct 12 16:58:58.555090 LibreELEC kernel: brcmf_sdio_register+0x18/0x24 [brcmfmac] Oct 12 16:58:58.555154 LibreELEC kernel: brcmf_core_init+0x10/0xed0 [brcmfmac] Oct 12 16:58:58.555218 LibreELEC kernel: brcmfmac_module_init+0x74/0xd4 [brcmfmac] Oct 12 16:58:58.555282 LibreELEC kernel: do_one_initcall+0x68/0x1fc Oct 12 16:58:58.555346 LibreELEC kernel: do_init_module+0x58/0x1e4 Oct 12 16:58:58.555412 LibreELEC kernel: load_module+0x2014/0x20cc Oct 12 16:58:58.555475 LibreELEC kernel: init_module_from_file+0x84/0xc4 Oct 12 16:58:58.555538 LibreELEC kernel: idempotent_init_module+0x16c/0x294 Oct 12 16:58:58.555601 LibreELEC kernel: __arm64_sys_finit_module+0x64/0xc8 Oct 12 16:58:58.555667 LibreELEC kernel: invoke_syscall+0x48/0x110 Oct 12 16:58:58.555733 LibreELEC kernel: el0_svc_common.constprop.0+0x40/0xe0 Oct 12 16:58:58.555798 LibreELEC kernel: do_el0_svc+0x1c/0x28 Oct 12 16:58:58.555870 LibreELEC kernel: el0_svc+0x38/0xf0 Oct 12 16:58:58.555947 LibreELEC kernel: el0t_64_sync_handler+0x120/0x12c Oct 12 16:58:58.556012 LibreELEC kernel: el0t_64_sync+0x1a4/0x1a8 Oct 12 16:58:58.556075 LibreELEC kernel: ---[ end trace 0000000000000000 ]--- Oct 12 16:58:58.556140 LibreELEC kernel: brcmfmac: brcmf_chip_cores_check: CPU core not detected Oct 12 16:58:58.556206 LibreELEC kernel: brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed! Oct 12 16:58:58.556275 LibreELEC kernel: brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed Oct 12 16:58:58.556339 LibreELEC kernel: brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
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.
-
I'm looking for the Horus addon (acestream) like crazy, there's no way to find it
Good
As per the forum rules that you acknowledged on registration but clearly didn't read .. piracy fans are not welcome here.
-
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.
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
This was merged an hour before you posted: https://github.com/LibreELEC/LibreELEC.tv/pull/9376
-
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.
-
Have you run "rpi-eeprom-config --edit" ?? .. You need to append BOOT_ORDER=0xf416 to the device to have it boot from NVME.
-
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.