jock

@Ikesankom there are some messages in dmesg I don't like at all, but surely the the rootfs UUID seems to be the wrong one. You can alter it editing /boot/armbianEnv.txt and pasting the right one. When you are in the initramfs you have to manually mount /dev/sda1 somewhere and then you can edit the file. The right one is the one you get from blkid 4ca8....43ad; I don't know why the UUID changed after the upgrade, perhaps an sdcard was plugged in during the upgrade?

@astrosky your setup is involved but works, nonetheless the kernel can and will write its debug output to ttyS2 despite you stopped getty process, because getty just handles the login and interactive terminal. That can be easily fixed changing the kernel command line, but still the bootloader and trustos will use ttyS2 to output their debug info. If you're comfortable with occasional spourious data, then it's ok, but personally I would not rely on that if I would control something remotely like a boiler, a relais or whatever...

@Ikesankom Hello, your problem seems different than the bootloader issue described in this thread. In your case the bootloader is ok and the kernel boots fine, but the rootfs is not detected. It could be due to a missing module in the initramfs, which is weird because emmc/sdcard storage are built in the kernel and not as modules. It would be useful if you can submit the output of dmesg and blkid. initramfs has a limited set of commands, but you should be perfectly able to mount devices and write the output there.

@tj13 don't worry, it's no pain. Bug reports are always appreciated, but without logs or whatever it is very uneasy to guess if the problem is related with the broken installation script or whatever. Surely you can follow the posts of this thread to get a clue; if you installed the system in eMMC perhaps you can try the Multitool from this page and see if it works (I never tried it on TInkerboard), so at least you have a way to backup and access the filesystem. At last, the uart adapter suggested by @SteeMan can give some important hints about what went bad.

@Caio Lima Viana great job! Now it looks to me that u-boot is unable to work with the eMMC (it is dwmmc@30020000 device, or mmc0 in the uboot log), or for some reason is unable to find the device tree (FDT_BAD_MAGIC). It seems that there is something off with: the internal eMMC: the u-boot version is an old one, I wonder if your board is a recent one with eMCP (see first page) chip instead of regular eMMC the filesystem installed on the eMMC: you can use an sdcard with the multitool and get a shell, run fsck.ext4 /dev/mmcblk2p1 and see if finds errors; you can even mount the partition and inspect manually if /boot files are in place At the moment I have no more ideas, but these two above worth trying.

@Caio Lima Viana Yes, copying sdcard to emmc should work, there is no difference. About the reason it does not boot, if you don't get any output on the HDMI and the board does not answer on the network, serial UART is the essential tool to get some clue about. You can surely do a clean installation on eMMC with multitool, then "transplant" the whole rootfs, but if you don't know where the issue is, you may transfer the problem too and get stuck again.

@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).