jock

@astrosky you'd definitely want to go with an armbian supported SBC rather than tinkering with a tvbox. Yes, tvboxes usually have one exposed UART, but it is for debug and is already in use for kernel and system logs. It can be altered to be used as a general purpose UART, but requires some effort (modify bootloader, change the kernel device tree) that IMHO it is not worth for. SBCs have their own exposed pins with two or more UARTs, SPI, I2C, I2S and GPIOs that you may easily use without having to solder and desolder things on the board. They are more suitable for serious projects.

@Caio Lima Viana Hello, should be easier to install the system on the eMMC via multitool, configure at your pleasure and then do a backup of the eMMC with the multitool ?

Hello, sorry but without logs or detailed symptoms it is impossible to give any advice

The installation script has been fixed and should work as intended right now. Perhaps your boards bricked for other reasons? If you don't provide details it is extremely difficult to give support.

Mmmh, apparently all the users directories have been emptied 🤔 Perhaps @Igor can help us about?

You're welcome. Normally, after burning the image on eMMC, you should do SHUTDOWN in multitool, remove power, unplug the sdcard and restore power.

@moddien thanks for the firmware, I will try to inspect as soon as possible. Usually the first page of the thread and the last 3/4 pages are enough to get up to date with recent developments. Many useful experiences are scattered through the thread, but usually the most important things are collected in the first page.

Hello, there can be dozen of problems with those symptoms: the kernel does not boot, the image you used is bad, the board is unsupported and does not boot, HDMI does not work on your board, the eMMC is empty, etc... etc... You should try a newer image with a mainline kernel (4.4 is unsupported and unmaintained anymore) and possibly provide UART serial logs to debug the problem.

@astroskyhello, first of all in the kernel 6.x (I don't remember which release exactly) something changed that caused issues with HDMI on several rk3328/rk3399 boards. I have had no issues and on my setup, which is not complex at all, just a standard 1920x1080 monitor, HDMI works perfectly. Some other users have found issues though, and the cause is not yet known and I'm not able to try and test it because I don't have such issue 🤷‍♂️ I wonder, since you need GPIOs, why don't you use a real SBC board - it is something I always suggest in place of tvboxes for new projects, since they are supported much better.

@fortdevv you're welcome and thanks for reporting 👍

@IronIgel there's also a small paragraph in the first page about special hardware with a link to a guide on how to fix the issue.

@moddien Hello! Yes, a serial adapter would indeed provide some debug info that can be useful. I don't remember such "r3229q-221p" board, so perhaps it is a new board. Be sure to use the latest multitool first. User @svdmk had a similar problem, you can check the latest two pages of this thread for some reference. At the moment the solution is a bit of a hack and involves switching bootloaders, which is not the easier thing to do.

Hello all, bootloader packages have been rebuilt and now upgrades should be fine!

@KanexMarcus probably your board is a r29 and you need to enable the led-conf7 device tree overlay in /boot/armbianEnv.txt. Unfortunately it is a manual procedure that has to be done manually from the multitool.

Hello everyone, the broken upgrade process is my fault and I apologize everyone for the inconvenience. The reason behind the broken upgrade process is the merge of the rockchip and rk322x families, which introduced this regression. The problem went undetected because upgrades happens once in a while when there are armbian new releases. I will address the issue as soon as possible, in the meantime please avoid upgrading to latest armbian version. I will post here when I will be sure the issue is fixed! Thanks!

@KanexMarcus hello, why did you substitute the armbian device tree with the libreelec one? It is wrong and prevents the armbian device tree overlays to work correctly if you do so.

@AndrejM please read the first post of this thread, and prefer an updated image rather than an old one

Nope, because what works on your sample is not guarenteed to work on others. Overclock is just meaningless on these chips, you only lose stability and get higher temperatures for a very little increase in performance.

because the android stock bootloader allows to boot from sdcard if you package the bootloader on sdcard using the rockchip proprietary tools. The android stock bootloader is loaded first (because it is on emmc), but then it check for specific bits on sdcard; if found, it passes control to the sdcard Multitool and libreelec image bootloaders are made with proprietary tools, instead armbian uses a bootloader made with opensource u-boot tools and thus is not recognized as a boot device from stock bootloader. Mainline u-boot supports dtb overlays, USB and PXE boot - in addition to other basic features - that are not supported in stock android bootloader. To test the image before burning it on eMMC: if you burn an image that does not boot, you may soft-brick your board and then it would be required to short eMMC clock pin to enter maskrom mode and clean the eMMC flash to restore functionality. If you have a R29, R2B or H20 board, led-conf7 overlay is essential to get stable operation. Here is a post on how to activate it manually via multitool on eMMC or plugging the sdcard in your PC and editing the file (ignore the part on copying things around, they are now already in place).

@mocarela Yes, it is possible to boot from sdcard, but you need first to: erase the eMMC, so the SoC will attempt to boot from sdcard, or install armbian on the eMMC, whose bootloader gives priority to sdcard, then USB, then eMMC Also Rockchip SoCs always attempt to boot from eMMC, if they find a valid bootloader.

@mocarela this is the reference thread for rk322x Your board probably is a r29, r2b or h20 of some sort. Once installed, you have to login, run rk322x-config and select led-conf7 when appropriate. Reboot and you should get HDMI.

Nope, because this is a very specific problem of tvboxes; regular single board computer users and maintainers don't have to mess with such unknown variables. That is the main reason why tv boxes, along the funny and always changing hardware they carry, are not and will never be officially supported by armbian, but just by community members.

It looks to me way too complex from the maintenance point of view: users may create unwanted mixtures installing things from the multitool over already installed systems (for example 24.02 bootloader on an older armbian release); and also when armbian advances I have to keep the multitool binaries updated as well. It is already very tiring keeping the thing aligned against mainline kernel on every release I don't want to add another burden. One thing that solves all the boot problems is to reintroduce the OPTEE trust os: it surely does not unwanted things in the background, but then we lose some useful features. Otherwise I would keep the "manual" procedure for the time being for the problematic boards, until I get the hands on one of them and can study the issue with detail, or some bright idea pops out.

Yes they are "normal" errors: the brcmfmac driver probes for such firmware files, does not find them and proceeds with other filenames. It just reports what is an information as an error, and also does not report that it finally found a valid firmware file. brcm4334 chip has no clm_blob binary; AFAIK only newer/bigger broadcom chips have it, but older chips like 4330/4334 don't have and don't need it.

It is not possible unfortunately. The bootloader is built and packaged by armbian scripts, it is not supposed to have two different boot loaders for the same "board". Once the deb package with the bootloader is downloaded, it is unpacked and a script is run to upgrade it. The only thing I may think about is a flag somewhere on the filesystem that is checked by the script and avoids the real bootloader upgrade. Or people can manually do apt-mark hold linux-u-boot-rk322x-box-current to avoid the bootloader upgrade and that's it