Posts by chewitt

S905L is the same CPU (opps) as S905W but omits VP9 codec support in silicon and (the important bit) uses Mali 450-MP2 not the normal Mali 450-MP3 so the kernel will lock-up when trying to bring the GPU online if using S905X/S905W device-tree files. I added support for S905L boards last year so there is a device-tree file (p271) that can be used, but I'm not sure that's the issue because u-boot is reporting S905W when reading chip properties. That kind of thing is commonly faked in vendor u-boot with cheap boxes, but we're using upstream. It's harmless to experiment with the p271 dtb file though.

I think it's more likely the board just has low-bin (out of spec) RAM chips that need timings to be tweaked to work.

Quote from madmax2

What is the cause and how to fix this?

This is a bug in the widevine.helper add-on which has been fixed upstream, but might not be publised in an add-on update? - You'd need to check their release notes. I've seen the same a week ago when prompted to update. It won't ever complete, but unpacking has already been done so either restart Kodi or reboot the box over SSH and all should be fine.

debug <inputstream.adaptive>: [WV-CDM-Library] CDM version: 4.10.2662.3

The version I am using is ^ and since I wasn't prompted to update when initiating playback, I assume this is the latest. I don't really pay much attention to widevine versions as I rarely see issues with it. Service add-ons (Netflix, Prime, etc.) are normally where issues arise, as those pretent to be a browser (but are not browsers) and are thus more fragile and prone to breakage.

I've no idea about Netflix (as I don't subscribe) but the current/latest widevine libs are working fine with e.g. ViwX (for ITV in the UK) on an RPi5 and RK3588 board; both are aarch64 devices.

The current H265 decoder has seen no real-world development since 2020 and will be dropped from the kernel in the mid-term future. It is not possible to use the vendor kernel decoders because Amlogic implemented them around their own proprietary DRM (rendering, not media encryption) framework which aside from being poor quality code, would be a total nightmare to port to the upstream kernel, and also requires amcodec support in Kodi which was intentionally dropped back in 2018. I'm aware of two other Amlogic media codec efforts; one is also stalled with no current plan to resume. The other is being actively worked on, but I'm still waiting to see initial H264 code (with HEVC, VP9, MPEG2, AV1, etc. to follow) so this is not anything that will bring results soon.

This should explain https://wiki.libreelec.tv/hardware/intel…generic/laptops

This image is built using the VIM1 u-boot (2025.07) defconfig but using the p281 FIP files from bumerc

https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-12.90.1-p281.img.gz

systemctl stop display && systemctl disable display && systemctl mask display

That ^ will stop the harmless error message about display service.

The AMLGX image is not for everyone. The H265 decoder is not fully developed and 'is what it is' for now. The only real-world way to fix seeking is to re-rip or re-encode videos to H264 which works much better.

touch /storage/.update/.nocompat

That ^ will allow the downgrade. It won't brick the box, but you need to remove all Kodi add-ons and the libwidevine cdm folder (if anything uses libwidevine) as they were updated to newer aarch64 versions too. Also note that the Library will revert to the state it was in before you updated, i.e. it will not show any content added since the bump (you will need to rescrape).

NB: As there is no real-world difference in the state of the Amlogic hardware decoders in LE11 and LE12/LE12.2 there's probably no benefit to the downgrade. As you wish though..

I'll add rtw88/rtw8821a_fw.bin to the default firmware(s) that we pick into the image.

I can see PCI and ACPI warnings/errors in the system log and an iwlwifi 'microcode' (firmware) error/dump, and then GPU segfault messages once Xorg starts. As the nvidia drivers have faulted there is probably no DRM (Direct Rendering Manager) connector and GPU device visible to the kernel so the kmsprint command in the pastecrash script fails and you see the 'no modesetting' error.

I associate ACPI warnings and unexplainable things like firmware errors with power issues, so I'm wondering if the PSU is able to sustain the current draw needed in early boot and the spikes seen when the WiFi card and GPU are brought online. The GPU model suggests this is 10-15 years old hardware, so age could be a factor.

Quote from bumerc

Does mainline u-boot work with LE? I made a test build with acs.bin for p281.

LE official images use 2025.07 while the ones in my test share should be using 2025.10. If you fork the amlogic-boot-fip repo on GitHub and push a branch with a 'p281' fileset containing that acs.bin and share a link, I can build an image using it.

Quote from Wyrman

Does anyone have any thoughts.

Failing to mount the persistent /storage area normally indicates either a messed-up EXT4 filesystem or perhaps indicates a dying SD card* as more minor issues like a 'dirty' filesystem resulting from a power pull (most users pull the cord instead of shutting down gracefully first) should be automatically fixed through fsck during boot. If you attach a USB keyboard to the RPi4 you can run console commands on the screen. The initramfs environment is rather limited in what's available but dmesg, mount, fsck, etc. are present and that's enough to attempt manual mount of /storage to see what the underlying error message(s) are.

* the "it worked on my laptop" is normally irrelevant as Windows can only see the first partition on the card which is VFAT formatted, not the second which is EXT4 and used for storage.

Quote from bumerc

It looks like a fake s905w SoC (S905W) revision 21:b (a2:2). Since the BL30 complains about "Wrong chip a0."

I suspect the FIP files for p212 were generated before the existence of S905W boards; hence the 'wrong' (unknown) chip error. The VIM1 files are newer and thus accomodate the chip, even if the wrong RAM size is being detected.

Sniperassault For the sake of a simple test, create an SD card for VIM1 but configure meson-gxl-s905w-p281.dtb as the dtb to use and see if that gets further through boot?

See if https://chewitt.libreelec.tv/testing/LibreE…0.1-p212.img.gz works any better?

This is not using the VIM1 acs.bin in the u-boot recipe but might work (or not).

Please use pastebin or similar for sharing logs; it's easer than creating files and uploading/downloading them.

GXL:BL1:9ac50e:a1974b;FEAT:ADFC31AC;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:AA;USB:8;LOOP:1

^ This and no 'customer ID' message is good, it means BL1 is looking for bootable SD or USB media. Experiment with AMLGX board images that (except for the 'box' image) include upstream u-boot, not old LE 9.x images.

I'm not sure whether Chromeboxes boot using syslinux or EFI boot, but the boot menu is in the syslinux.cfg file (for syslinux) or a file under the EFI directory for EFI. Both files are human readable and you should be able to edit the boot menu to change the default option from install to live, then you don't need to hit a key. You can also place "textmode" somewhere in the list of boot params and the box will boot to a text console instead of Kodi. That's sometimes useful for narrowing down whether it's the kernel that causes the problem or not. If the OS is usable then the issue probably lies in the userspace side of the graphics stack and if you manually start Kodi via its systemd service while also accessing via SSH to tail logs, you might get some clues. Adding "ssh" to boot params forces the daemon to start.