jock

@tommy I Didn't ever try retroarch. I took a look on snes emulation on libreelec and surprisingly it was working quite well on rk322x. I tried once to compile snes9x for rk322x and also was working fairly well in X.org, but performance dropped when I tried any scaling 2X filter. That said, I would suggest to you, as @fabiobassa said, to try and see if you can avoid X.org, maybe trying to compile with GBM/DRM support so you get fullscreen without passing through the X server. Also you should tell which kernel are you using, it may be important.

@dotbg Some boxes with rk3566/rk3568 are sold with 8GB (gigabytes) of RAM. That chip is capable to address such amount of ram, yet you have to trust the chinese manufacturers and vendors that they really put 8Gb of RAM in the box rk322x instead is not able to go above 2GB (gigabytes). Everything beyond on a rk322x is surely fake.

Legacy kernel is provided by rockchip, you installed legacy kernel and rockchip does not provide updates. So no kernel updates for you. You can although move to mainline current kernel, which will receive regular updates. Use armbian-config to do so, but do that only if it is suitable for your system! (NAND is not supported, SSV6051/6251 wifi is not supported) About the reboot issue, since I don't know anything about your system and due to the huge variety of tvboxes around, you have to solve that on your own.

@Willy Moto Yes, your observation is right: load average is broken on legacy kernel. For some reason, it idles with a value of 4.00, where instead mainline kernel correctly idles with a value of 0.00

Indeed, you need to install the first megabyte from any armbian image onto the eMMC starting from sector 0. That's all you need. The suggested experimental way with the multitool is better because it patches the installed bootloader, otherwise your board may brick and you need to rescue using the maskrom mode, which is difficult on eMCP.

@curse Yes, it is possible. Temperatures are quite varying with these chips and reportings are not very reliable IMHO. The problem is very similar with rk322x too. Cpu usage in top is the sum of all cores/processors, so it can go beyond 100% if your process is doing multithreaded work.

You can install Armbian on eMCP using latest multitool: it is still experimental and you have to overwrite the existing Android. Once Armbian is installed, the bootloader will search for bootable devices in this order: sdcard -> USB -> eMCP

@Gausus Your chip is definitely an AP6334/BCM4334, it declares that way to the system. Printings on the chip cages are fantasious chinese characters which does not relate to anything known. Can't say anything more about, the nvram.txt you took from github is the one which I know is working pretty fine on my box, which is an Ap6334 too, but it can be your board configuration is different and not handled well with that nvram, but fixing this is beyond my possibility.

The most offending things are: 1. emmc settings 2. cpu frequency eMMC settings are the most dangerous. Leave all the options unchecked in the eMMC panel. CPU frequency safe setting is 1.1Ghz (which is the default). Not all chips can reach 1.3Ghz.

@Gausus You have to copy /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt over /lib/firmware/brcm/brcmfmac4334-sdio.txt and reboot

@ArkhanLKI guess for "Install" you intend "Burn image on flash", since there is no such install option in multitool. Besides that, it could be that the board has a slightly different memory and it does not like the default settings. If I'm right, the issue is the same 1T/2T Command Rate problem. The latest version of the multitool is able to autodetect this setting from the existing Android, and also allows to manually change the setting from the menu. The only issue is that, at the moment, you are stuck with the problem and the only things you can do are: - clean the eMMC using maskrom mode and rkdeveloptool or - use the serial and clean the first sectors of the eMMC using u-boot

Ok, i read again your last message and I see that the last thing you did was (most probably) install back Android via multitool and you get that, am I right? Debugging via serial will tell something more, but you may also try mwronglyaskrom mode and rkdeveloptool to erase the mmc and boot from sdcard. That's bad multitool is not booting with such error, but is it possible you installed back the wrong Android image (maybe coming from another box)? If so, it could be that DDR memory is wrongly initialized and makes the system unstable; even the multitool can't cope with that and for that problem you need to erase mmc.

Normally no, multitool does not mess with clocks and voltages, moreover it is designed to run the board at maximum 800 MHz for extreme precaution. Using restore instead of burn is right the same thing; restore will just pick from backups folder, burn picks from images folder. You may erase eMMC completely and see if Armbian runs from sdcard: in such case maybe the eMMC is the first candidate as being faulty.

Surely will increase the cooling effect, but you should evaluate if you have overheating issues first.

@ArkhanLK It's hard to say if it is an hardware failute or not. Surely if reinstalling the original android does not work, most probably there is an hardware fault. Multitool also should always boot without issues, if it fails to boot with similar error messages, maybe your board is faulty. Did you try the cpu-stability overlay in /boot/armbianEnv.txt?

@pakos96 don't know anything about docker, maybe armbian-config has an automated script to install docker, you may check it out. Also you can post in the general chit chat community forum about, I'm sure there you may get a more detailed answer.

@pakos96 Ookay, got it! Glad to hear everything is fine Thanks for the photos, they are always useful to inspect the board!

@pakos96 Hello! I guess you are saying that is lagging because desktop is not very reactive. For start, it is wisely suggested in armbian to disable the xfce desktop compositor (Menu -> System -> Window Manager Tweaks). Don't expect very fast graphical performance, mali-450 is still a limited GPU. Also, until I don't enable the RAM frequency scaling, the RAM is fixed at 330 MHz (instead of usual 667 or 800 MHz) and this is a huge hit for general graphical performance. @usual user As far as I see, armbian hirsute should have oibaf repository enabled and so Mesa comes as the latest development release

Update! Images with mainline kernel have been updated to Debian Bullseye (minimal) and Ubuntu Hirsute (xfce desktop) with kernel 5.10.68. Kernel is the same major version as previous mainline images, but Bullseye and Hirsute should provide significant newer software packages (including new Mesa libraries for those interested in graphics).

What kind of board you have? We are facing an issue like that right now; for some reason u-boot does not detect the sdcard. BTW, the workaround is to burn the multitool on an USB stick, plug both the USB stick and the sdcard in box and then boot. multitool will happily boot from USB, from there you can burn an image into eMMC, if it is your desire.

Nope, it looks like there is nothing really interesting. Maybe it's just the mesa Lima driver which is just too old. I sorted out the display problems, but then other issues regarding the i2s bus with kernel 5.14 came up. I think I can build a couple of fresh images with the 5.10 kernel which is good enough for now.

All bootloaders allows that, just because the bootloader is not involved in. The kernel driver does the thing: it wasn't there before, hence for performance reason booting at high DRAM frequency was good. Now it the driver is there, so there is no necessity to boot at high DRAM frequency because the driver can do the thing during run-time. You board however has NAND 100%, see clarification on first page.

It says ddr2, but actually works fine with ddr3 too. BTW, I need to update the rk322x_loader to be more compatible. For example, ddr3 frequency is set to 660 Mhz, but it may cause malfunction on some boards: it is unnecessary nowadays because newer armbian releases (even on mainline kernel!) have the dram memory controller driver to allow run-time and on-demand frequency scaling. About the "spectek" bootloader: we noticed that some rare boards only like that old bootloader, using the newer rk322x_loader results in lockups and unstability.

You have to use the multitool stepnand install method for that, otherwise won't work.

Hmm, actually I built an newer image with kernel 5.14 and hirsute and the Lima driver is not playing nice at all. I tried both the stock mesa coming with Hirsute and latest development mesa and both of them cause the login screen to appear just as you describe: black screen and the cursor. Lima driver is somehow complaining with these lines in dmesg: [ 39.136659] [drm:lima_sched_timedout_job [lima]] *ERROR* lima job timeout [ 39.136801] lima ff300000.gpu: fail to save task state from Xorg pid 1654: error task list is full [ 39.136818] lima ff300000.gpu: gp task error int_state=0 status=a so I got to investigate this issue too... edit: uff... ok it seems that the issue is due to the missing operating points in the device tree. I always fall into every time there is a new kernel