jock

Hello!
 
If you mean overclock the cpu, it depends on your sample. rk3318 are rated for 1.1ghz, for so far it looks like a software limitation rather than a hardware one. Some people pushed them up to 1.5ghz, but the increased horsepower is not worth the heat at all IMHO.
About overlocking the ddr, actually they are underclocked at 333mhz: dynamic reclocking requires a proprietary Trust OS blob, but this won't allow CPU to go beyond 1.1ghz. On the other side, booting the device at 667mhz caused many boards to not boot at all (notably X88 Pro 10 market models)
 
About the LED Clock, if you mean the frontal led panel, there is a kernel driver + userland application which work together; they do the job, but are rather suboptimal for technical reasons and not included into regular images.

@Ineptitude unfortunately the driver is not yet included into armbian. I tried to take a quick look to it and there is the usual mess of preprocessor directives to compile and run on the various manufacturer platforms, plus some low general quality code. I gave it some hours for inspection, then I gave up. Perhaps I will give some more love to it sooner or later, but I don't promise anything.

@jock I finally managed to extract the firmware. Here's the trust partition https://drive.google.com/file/d/1E7mxBVE1lUshqdcjqTMfxKQMW2iLUvye/view?usp=drive_link. And here's the rest of the backup https://drive.google.com/drive/folders/165r4bV3jFj8Ptx4yY2sXmbmOUOBIMWaW?usp=drive_link. I've been trying to install Armbian via USB cable, but no luck so far, always getting Test device fail. Thanks 

It doesn't work for me on same board, but shorting any data lines to each other pushed chip to mask rom on boot.
 
I have 1.5G/8G version, and it doesn't boot armbian or multitool from sd/emmc - it just hangs on boot with no output to console (1500000 and 115200 speed)

Have a box with rk3528 here and did some work some weeks ago, mainly to get a kernel and multitool running on it.
It works, but I didn't publish an image for it yet (only available in source code), plus my board does not want to boot from sdcard and had no time and no will to further study it better.

Yeah, we live in the clouds and sometimes we land to go to the grocery store ...

Yeah, we live in the clouds and sometimes we land to go to the grocery store ...

Hi @n3o
 
please don't say things I've never said. I won't do what you wrote. You are still free to use my (hard) work because I believe in healthy sharing, which is already the basis of my work on libreelec. Without @jock and @fabiobassa these boxes would not have this level of support.
 
Cheers
Michele

Hi! I've got this MXQPRO_V73 board here with an RK3229, an esp8089, 1GB of RAM, and 8GB of storage. When I insert the SD card with the Multitool, it doesn't boot. All I get is the red light, no blue light, and no HDMI output or IP connection.
I've been trying to find the UART port, but no luck so far.Any idea where it might be?
Thank you very much

Why not buy an Armbian supported SBC? Most TV-Boxes are crap. Overheating and low-quality. For better quality you also pay a lot more. So then why not buy a good SBC?

RK3399 ain't that expensive and has great IO. RK3588 is high end so cost more, but it's future proof.
OrangePi5+ should be best value. I don't have it, so can't say much about it. 
NanoPi R6S/R6C isn't that expensive. The C has NVMe and USB3, and very fast CPU.
 
If you want to use full sized HDD's then look at the Odroid HC4. It has the S905X3. As powerful as RPi4(when not OC) and 2 SATA for full sized HDDs. But no USB3 or other IO. It does have HDMI.
 
RK3568 is also a SoC that has great IO and not too expensive. Not sure if there are Armbian supported boards with it.
RK3566 less IO but still better than any RPi.

I only had one ok TV-Box from a bunch. The Mecool KM6 with S905X4, but that doesn't have Armbian support. S905X3 should have better support. But you are never certain all hardware will work.
TV-box manufactures ofter use different components for the same model TV box. So some people might have wifi working, but others don't.

@jock
with updated uboot
 
I can add that no armbian with kernel higher than 4.4 ever run on this board, all did crash. Wrong CPU/DDR freq ?
updateduboot.txt
 
Edit:
Oh, it just runned after few power unplugs ...
HDMI ok, strange xD
 
works!.txt
 
lan 100Mbit also ok
[   34.223396] rk_gmac-dwmac 30200000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   34.288631] rk_gmac-dwmac 30200000.ethernet end0: PHY [stmmac-0:00] driver [Rockchip integrated EPHY] (irq=POLL)
[   34.297804] rk_gmac-dwmac 30200000.ethernet end0: No Safety Features support found
[   34.297885] rk_gmac-dwmac 30200000.ethernet end0: PTP not supported by HW
[   34.299134] rk_gmac-dwmac 30200000.ethernet end0: configuring for phy/rmii link mode
[  290.306195] rk_gmac-dwmac 30200000.ethernet end0: Link is Up - 100Mbps/Full - flow control rx/tx
 
Thanks !

That's the main problem for the general solution you propose. Looking into the base device tree of the kernel (rk322x.dtsi), that gpio pin (gpio 2, pin RK_PB3) is declared in use only by gigabit ethernet devices. Also looking in the original device trees of the boards there is no other trace than gigabit ethernet pin. Surely no tv box with rk322x has been produced with gigabit ethernet, so from that point of view it could be safe to enable it.
 
But looking at the base dtsi is not enough to declare that any board does not use that pin: as it happens on r29/r2b/h20, any other manufacturer may have decided that the pin may control something more or less important, or perhaps it is internally wired to something, tinkering with that may affect other boards. It is a remote possibility, though it can happen.
 
Multitool (and libreelec too) has the pin enabled by default, so we will see if it can have side effects on other boards.

in first first part --> at ddr and Board model
 
U-Boot 2021.04-armbian (Aug 08 2021 - 18:00:55 +0200)

@ego worker thanks for checking in. Perhaps the bootloader installed in the internal flash memory is too old. I see that u-boot is v2021.04, but current one is v2022.04.
Your version is not applying the device tree overlays at all, hence the instability and the missing HDMI when trying to run armbian.
 
You may try to transfer the updated bootloader from the sdcard to the internal flash with:
 
sudo dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=32k skip=1 seek=1 count=32  
but also double check that you have overlays=led-conf7 in /boot/armbianEnv.txt (check also on both the internal flash and sdcard; u-boot should take the one from the boot device, but bugs in u-boot are around the corner...)
 

That's the main problem for the general solution you propose. Looking into the base device tree of the kernel (rk322x.dtsi), that gpio pin (gpio 2, pin RK_PB3) is declared in use only by gigabit ethernet devices. Also looking in the original device trees of the boards there is no other trace than gigabit ethernet pin. Surely no tv box with rk322x has been produced with gigabit ethernet, so from that point of view it could be safe to enable it.
 
But looking at the base dtsi is not enough to declare that any board does not use that pin: as it happens on r29/r2b/h20, any other manufacturer may have decided that the pin may control something more or less important, or perhaps it is internally wired to something, tinkering with that may affect other boards. It is a remote possibility, though it can happen.
 
Multitool (and libreelec too) has the pin enabled by default, so we will see if it can have side effects on other boards.

I already opened a pull request on armbian, when it will be accepted, new kernel will be built with fixes, but I have no control on when the new kernels will be built by the armbian servers.

Yes, it is expected that is so: you must run rk322x-config, set led-conf7 and reboot (or setup led-conf7 manually in /boot/armbianEnv.txt)
 
Legacy kernel is discontinued, has some reason only for those who have old boards with NAND. You have no reason to stay with legacy kernel, it's old, insecure and unmaintained!

I already opened a pull request on armbian, when it will be accepted, new kernel will be built with fixes, but I have no control on when the new kernels will be built by the armbian servers.

Tryed the 6.1.55 install by the book and looks also working like 6.1.50 hand patched.
Attaching install and dmesg logs. RK3228B55.zip
 
Shall being good if some more user with desktop installed can testing it so Joke can getting it better verified that is working and putting it in the current release if all is OK.
 
PS: The kernel install is still complaining of missing firmware that it have doing longer time now but my RK3318 box is not doing it on all kernels i have running on it.

@MattWestB I've uploaded convenient deb packages with update dtbs for both kernel 6.1 and 6.5; now they should be finally fixed and work, at least I tested on my board and they work pretty fine.
 
You can download the deb package from here - for your installed system with kernel 6.1 you may want to download and install linux-dtb-current package
Please do a backup as you already did of the /boot/dtb directory on your existing installation!
 

@Benedito Portela Here it is a debian buster minimal image with latest 6.5 kernel. I did not had time to test it though, so try it with an sdcard first!
 
edit: tested the image, it works plenty well!

Here is another dmesg txt from my r29 board.
R29dmesg.txt

Ok, I need to better check what is going on with kernel 6.1 then; perhaps it is a misalignment with the base dtb, but I will try to be more specific tomorrow. Thanks in the meantime!

The Debian version has nothing to do with the underneath hardware. It's just that if you use an older image simply you miss some corrections and compatibility fixes here and there that allowed the eMCP boards work in a stable way.

Ok, I need to better check what is going on with kernel 6.1 then; perhaps it is a misalignment with the base dtb, but I will try to be more specific tomorrow. Thanks in the meantime!