Posts by chewitt

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.

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?

Quote from Da Flex

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

Quote from Sniperassault

Do I have to remove the eMMC for do this?

No, just create SD cards to test.

Quote from Sniperassault

If this happens, it means the box is definitely dead, right?

Correct, unless you find the original Android ROM..

Quote from Sniperassault

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.

It's years since I booted the Generic image so I have fuzzy recall, but press keys when the syslinux prompt is showing and it should stop and allow you to correct and type 'run' and not enter the installer.

Another idea if it's failing early is edit syslinux.cfg and remove 'quiet' from boot params and it will dump the system log to screen. If it fails with an obvious kernel splat take a picture and share it. Or take a video on a phone in slow-mo mode with a high frame rate and the resulting video can be scrolled through to look for errors.

In 99%+ of cases where a user reports "Kodi doesn't start" the OS is running happily in the background and if SSH has been enabled you can login via SSH to capture logs. If SSH is not enabled, drop 12.0 files in the 'Updates' Samba share and reboot to downgrade to the earlier release and enable SSH, then update to the problem version again.

Alternatively, boot from a 12.0 installer USB, interrupt boot and type 'run' to boot/run from USB instead of installing, then enable SSH to access the console and edit syslinux.cfg in the internal drive's boot partition (mounted under /var/media/) to append 'ssh' to kernel boot params so the SSH daemon is forced to start on boot. Then shutdown and reboot to the problem OS to poke around and share logs.

Or just do as suggested; access the 'Logfiles' share on 'a' problem box and upload the zip here. Until you share some evidence of the problem we have no idea what the issue might be, and cannot do anything more for you.