Just “boot loops” when attached to some displays affecting distos listed below.
I feel like there is some boot code that is testing the display, and should “fail” rather than crash.
Even if I set the board to boot to CLI: systemctl set-default multi-user.target
It crashes then “boot loops”.
Headless is OK, so long as the display is detached, or as long as our main test monitors are not attached (works with some monitors). FWIW, main test monitors run with many other boards just fine (including the M1).
I have messed around with the display settings in config.txt. No luck.
Useless, the problem occurs earlier. I’ve written about in the only available review already:
And of course does the problem apply to all their ‘OS images’ since they’re all the same crap. Everything that’s important does not live in the rootfs of the countless crappy Linux OS images they provide but in the first sectors of your boot media.
There is the bootloader stored, the files that do hardware initialisation and the kernel (inaccessible to you since this is all unmodified Android stuff).
If you want to change something, you’ll have to become a Linux expert and setup a build environment to fix their mistakes on your own by recompiling the so called ‘BSP’ for this board. Since the manufacturer isn’t interested or not able to do so.
I still don’t get why people don’t look through the forums before buying these paperweights…
Well, I do. I provide reviews, so no matter what, I gotta give it try (sigh).