jock

@Ikesankom hello, no I didn't test it yet. Actually, I have been busy with other issues and totally forgot to test for the upgrade path.
If you have a bit of patience I may give it a shot in the next few days, probably tomorrow.

Ok then I would first try with a pristine image on a different sdcard if possible, just to understand if the problem is the sdcard itself or something messed up in the kernel

Hello, I had a feedback from @ilmich and now I'm back with a couple of device trees you can test on the multitool and see if they change something.
 
I'm not sure they will fix your issue, because it may be necessary to recompile u-boot too and that would cost me a bit more time to setup the whole thing, but in the meantime you can try these two dtbs overwriting rk322x-box.dtb in extlinux folder of the multitool.
 
Try both of them and tell me if any (or both) do have any effect
 
 
rk322x-box.dtb.2 rk322x-box.dtb.1

They aren't officially supported, but there are many TV boxes that are Community Maintained and available on the Armbian download page.
 
No need to remove the binaries, your warnings are good enough.

@Hqnicolas thanks for the instructions, but I already have a backup of my box I had taken with multitool.
The problem that is puzzling me is why the box does not boot from sdcard when the emmc is empty, something which is absolutely normal for other rockchip devices.

i have one of those boards, the silkprint on the PCB says RK3528_DDR3, that's the one I used to bring up the mutltool for rk3528.
A major "problem" I have it is that the board does not boot from sdcard when the eMMC is blanked. I had no time to understand what is the reason behind. Though it should boot when a bootloader is available in eMMC.

@Netraam31 I did a quick check on a board with rk3328 (not rk3318, but should be the same) and you can use both the USB2 OTG port or the USB3 port as peripheral.
in the device tree the device usb@ff580000 is the USB2 OTG port controller and usb@ff600000 is the USB3 port controller.
 
I quickly tried ethernet gadget to check if it works. This command loads the USB ethernet gadget module. which is a bit of "deprecated" in favor of configfs, but it is handy for tests (run it with the USB cables connected):
modprobe g_ether iSerialNumber=0x00000001  
Then a device usb0 should spawn on both the machines, which is nothing more and nothing less than a regular network interface. You have to give an address to both the endpoints and then you should be able to ping and exchange data.
 
The result is that, at the current state of the kernel 6.1 I have right now (but 6.6 is exactly the same, since nothing changed), the USB 3.0 port is working plenty well, instead the USB 2.0 port is suffering the same problems experienced for rk322x, which disconnection and system freeze.
 
Things seems to have changed with kernel 6.8, where also the USB 2.0 ports seems to work, thanks to the upstreamed fix for clock gating. You should be able to upgrade to kernel 6.8 installing the linux-image-rockchip64-edge package or, more appropriately, via armbian-config.
 
Don't forget to put kernel and dtb packages in hold if you modify them manually, otherwise updates will overwrite your modifications!
 
 
 

@Netraam31 hello! You're in the right direction, dr_mode="otg" simply can't work without a micro/typec usb connector. The main feature of the OTG port is the capability to switch on the fly in host or peripheral mode, but to do that a fifth pin in required. Regular USB-A ports have only 4 pins, so when you get them you surely cannot exploit the OTG feature.
The USB port is still called OTG because it is "dual role" (host vs. peripheral), but simply cannot switch automatically, hence you have to change it in the device tree.
 
Finally what is true for the rk322x is true also for rk3318: during my tests the peripheral mode was not behaving correctly without disabling the clock gating and adjusting the core reset timing. The clock gating issue has been fixed in kernel 6.8 (the patch addresses the issue on 6.6), but the reset timing can still give some trouble.
 
Mass storage mode was my testbed, along ethernet emulation; what is still not working at all is the audio gadget which, I guess, uses isochronous mode which is still buggy.
 
Anyway you surely have to set the OTG port as device mode you have to use dr_mode="peripheral" in the device tree. On rk322x there is a quick device tree overlay to do that, without editing and fiddling with details. I don't remember if there is a similar overlay for rk3318/rk3328, but I guess not.
 
Notice also that you will not see any USB device connected on the other side when USB2 port is in peripheral mode until a gadget is set up.
There are several guides around (especially for raspberry pi) on how to setup a gadget, you can use them to actually test the port.
 
 
 

@moddien Why did you try to burn the image in the eMMC without being sure it would have worked?
If you can boot multitool again, clean the eMMC and start fresh.
 
I have prepared an armbian bookworm image with opensource optee in place of the proprietary one, you can download from here; I have not tested it at all, so can't guarantee it works.
If you want to try it, first clean the eMMC with multitool and then try to run the image from an sdcard to see the outcome.
 
 

@moddien Why did you try to burn the image in the eMMC without being sure it would have worked?
If you can boot multitool again, clean the eMMC and start fresh.
 
I have prepared an armbian bookworm image with opensource optee in place of the proprietary one, you can download from here; I have not tested it at all, so can't guarantee it works.
If you want to try it, first clean the eMMC with multitool and then try to run the image from an sdcard to see the outcome.
 
 

@fortdevv you're welcome and thanks for reporting 👍

@tj13You get details by hooking up a USB uart adapter and reading the serial console output of the boot process.

Hey, @jock! After selecting led-conf7 (R29 MXQ, R2B MXQ, H20) in rk322x-config, the screen was displayed immediately without the need to boot from the SD card. Thank you for helping me install Armbian on my tv box.

Temporarily network maintenance issue at that segment Sadly can't fix remote. Tomorrow...

Wrote on mobile

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

Two same boards but different cpu.
Rockchip labeled works fine with armbian, multitool and libreelec.
The board with huawei labeled cpu has the previously described problem, multitool and armbian stop working after a minute.
Method of switching bootloaders suggested by @jock  works.

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

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

@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!
 

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.
 

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.
 
 

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.