systemctl stop display && systemctl disable display && systemctl mask displayThat ^ 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/.nocompatThat ^ 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.
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.
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.
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.
If 12.0 works and 12.2 (or 13.0) does not work the issue is most likely in the kernel, or we broke EFI boot, but the latter would likely be flagged on a bunch of hardware. Without some kind of log/error to provide a hint on where the problem is, it's hard to comment.
CN60 is listed here https://docs.mrchromebox.tech/docs/supported-devices.html so the hardware is supported. How old is the MrChromebox firmware?
If neither LE or Armbian images for the board boot, it's either bad hardware or something in common boot code that both distros share. Do you have a UART cable that can be attached to show early boot output?
It's also possible that ERROR! Customer ID not match! comes from something on eMMC storage, i.e. it's not empty. As I said, it's the first time I see that text so I'm unsure what generates it. Google searching on that exact text generates zero results, which is odd as the GXL:BL1:9ac50e:a1974b;FEAT:ADFC31AC;POC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0; line has a bunch of hits and IIRC EMMC:0 means it does not see bootable anything there.
Perhaps go ahead and remove the eMMC chip if you have the tools/skills. At this point there's nothing to loose, right?
I think your GPU is not supported on any Linux
How do you explain it working on 12.0 then ???
This is normal/expected when calling ldd against the lib (not sure why it worked before). Either way this doesn't impact the lib when working with Kodi, and we've submitted a PR to change error logging: https://github.com/emilsvennesson…helper/pull/625
Do I have to remove the eMMC for do this?
No, just create SD cards to test.
If this happens, it means the box is definitely dead, right?
Correct, unless you find the original Android ROM..
GXL:BL1:9ac50e:a1974b;FEAT:ADFC31AC;POC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0;
ERROR! Customer ID not match!
The first line is what I would normally expect to see on a GXL (S905X) board indicating BL1 (silicon) cannot find BL2 (software) to boot the board. The second line i've never seen before and my first thought given the wording, is that BL1 is looking for a locked BL2, e.g. in addition to the normal FIP creation process, the boot firmware has been encrypted (signed) with a specific customer key.
The eMMC is blank though, so you can experiment with e.g. VIM1, VIM2, LaFrite, LePotato, Radxa Zero 'board' images written to an SD card to see what happens on the UART connection. Create the SD card then change the dtb filename in extlinux.conf to meson-gxl-s905x-p212.dtb and see what happens. If any of them run u-boot without experiencing a fail/reset/reboot cycle, you got lucky and the FIP sources for that board will work with your box too. If you see the Customer ID error again BL1 is locked and the only firmware that will boot the board is the original Android ROM that's been signed with the correct key. I have a hunch it's the latter scenario, but the only way to find out is trying.
