jock

@Jumperbillijumper from that link It seems t'ha t you already adked the same quesion in that thread and jock ( the same jock that is the author of all this stuff ) aleady answered there.
 
Please do not cross posting , thanks so much
 

You would try an Ubuntu distro and enable the oibaf repository to get cutting edge mesa.
Default mesa from debian and ubuntu is a bit older and does not contain specific fixes for mali-400/450
 
Oibaf repository is already set in /etc/apt/sources.list.d but the line is commented by default.
Removing the comment and then running apt update && apt upgrade should do the trick.
 
Also note that in X11 you may want to enable the vsync when possible, which turns out to perform much much better because with vsync on the driver will use page flipping, with vsync off will use buffer copy that reduces performances a lot.

@Dario Murgia Don't worry, it is not essential, it was just good to know. However the fix has been mainlined in armbian

GPU is only doing 3D graphics.
Media applications are accelerated by VPU, which is a totally different part of the chip. I think gstreamer is already quite capable of using the v4l2 interface to profit of media acceleration drivers already in mainline kernel (namely hantro and rkvdec for rk3318, both accelerating h.264, vp8, vp9 and hevc, but some codecs still have partial support on rockchip64 armbian branch).
Ffmpeg needs to be built with patches and in a custom way because kernel interface for codecs has been made "stable" very recently (I guess in kernel 5.19).
Also mpv has the capability to use hardware video decoding via v4l2, but still need a custom build because it uses in turn ffmpeg. There is this old thread where I provided a custom build binary of mpv, but it was for ubuntu hirsute and debian bullseye; surely it would require some adaptations and tinker if you want to run on newer distros.
 
Accelarerating youtube in a browser is a whole different story. I don't know what is the current status (maybe @usual user has some clues?), but surely it is much more challenging than standalone video playing.
 

@Seth Very much thank you for the photos!
I looked at them side by side trying to spot differences, and the board layout and printings seems exactly the same to me. The squared has a 2146 printed below the heatsink, the rounded has 2147; I may guess it is a something like lot number; the date "2020/06/29" maybe is the date when the board was designed. @FRIKIdelTO has the 2151 lot number but the same 2020/06/29 date on his board.
The differences are, as you already noticed, in some pads being populated with components or just unpopulated.
 
I may guess the fx8934 comes with an on-board crystal which is below the metal shield, instead the sp2734c requires an external crystal and the inductor too.
I checked the nvram files, and both the default shipped with armbian and the alternative version for the 2734c have the crystal set to 37.4MHz.
My HK1 board comes with an HK6334Q, has the external 37.4MHz crystal but works with the default firmware like the fx8934 that has no external crystal. Very messy 😄
 
About the HDMI, on kernel 5.19 it does not work on both of them or just on the "squared" one?
 
I cleaned, sorted and finally made a diff of the two nvram fiels I attach here for curiosity and study purposes.
You can see there are several calibration parameters that differs a bit, but there are also some obscure parameters like swctlmap that probably control some chip registers to behave in a way or another.
Use zless -R to see it correctly with colors.
diff-def-alt-nvram.txt.gz

@oolonthegreat This thread is for rk3318 and not rk3188; please open a new thread for that request and also remove the long log lists from here because they make the browsing from mobile very difficult.
 
@Aapo Tahkola I meant the four pads at the right of the IR receiver, not the three pads near the led array: those are clearly pads for diodes if you pay attention to the symbols.
Looking at the back of the @uehqsvbm's board, those four pads have a different wiring than the IR receiver and from the front side there is no immediate connection to the IR receiver; It is not 100% sure because there could be some in-board layer connecting them to IR, but I may guess those are not for IR. Also the central pads immediate connection is to a couple of components that seem to be resistances.
They could also be spare connection for leds, but in such case a single resistance would suffice and placing resistors there is a waste of components since the board does not have leds there.
 
Looking at the front side, the rightmost pad is surely ground (it has the reverse triangle symbol), and the leftmost maybe is VCC (there is a path going to IR receiver), maybe the two central pads are uart RX/TX.
 
About the led blinking led issue, this is what google suggests as first answer: https://linuxreviews.org/HOWTO_Control_LED_Lights

Yes, you can. Actually the choice to remove any Android code from the board is a deliberate choice by me 😝 but has some performance and compatibility reasons, since this way the user is in control of the ddrbin, miniloadloader/SPL and trustos.
 
The explanation is not exactly simple because these three pieces then cause unwanted behaviours, especially  the proprietary trustos does not allow rk3318 to run above 1.1GHz. I guess rockchip put an artificial cap because the chip can run fine at 1.3GHz or even overclocked at 1.5GHz. A pro of the proprietary trustos is that it allows DDR frequency scaling, that is not allowed by the opensource trustos, but to overcome this I patched the ddrbin to use ram at 667MHz with great benefits in terms of multimedia and general performance. If you run stock Android you are forced to use the "stock" ddrbin at 300/333 MHz because the rockchip boot always happens from internal flash... so it's a chain of issues and to avoid all of these hassles I prefer to erase Android and start fresh.
 
If you still want to go the "Android" mixed way, @hexdump wrote a document on his github on how to do, but I always forget the bookmark the link... That's still something that should be exclusive for the power user because that belong to the same class of those I explained above are around the corner.
 

@n3o  As a moderator of these forums, I have been watching your postings.  You are abusing these forums and the people that contribute to them.  (Everyone, especially @RaptorSDS and @jock have been very willing to invest a lot of time to help you)   However, repeatedly you have been given specific information that you ignore, been given advise that you ignore and then you come back with more and more questions.  There are very limited people resources working on Armbian (and even less with TV boxes).  You alone are consuming way more developer time than any one individual has the right to receive.  This is open source, and therefore users are needed to contribute as much as they consume in resources from the community in order for this to work.  This is not a school where you can come to be taught how everything works, demanding the attention of everyone else to teach you. 
 
Your latest questions are now venturing into very deep and difficult areas of code (none of which is expected to work on these TV boxes as has been mentioned to you).  If you want to continue down the path you are going, you first need to become an expert at these topics on known working platforms, then you can try to apply that expertise on TV boxes.  You may not realize it, but the questions you are asking, are essentially asking for weeks if not months of developer help to get working, if it is at all possible.
 

I will never stress out that THESE issues reported by you are the exact reasons to chose a properly supported Single Board Computer from the officially supported list and not buy crap like supercheap tvboxes. If you don't have the time, will and skills to solve troubles, tvboxes may end up being a large source of frustration. The very same problems are the main reason tvboxes are NOT OFFICIALLY SUPPORTED and NOT ENDORSED by Armbian project; tvboxes are just a community effort to have fun with them and avoid some waste, but the mileage can vary greatly. Here are the FAQs

I will never stress out that THESE issues reported by you are the exact reasons to chose a properly supported Single Board Computer from the officially supported list and not buy crap like supercheap tvboxes. If you don't have the time, will and skills to solve troubles, tvboxes may end up being a large source of frustration. The very same problems are the main reason tvboxes are NOT OFFICIALLY SUPPORTED and NOT ENDORSED by Armbian project; tvboxes are just a community effort to have fun with them and avoid some waste, but the mileage can vary greatly. Here are the FAQs

I will never stress out that THESE issues reported by you are the exact reasons to chose a properly supported Single Board Computer from the officially supported list and not buy crap like supercheap tvboxes. If you don't have the time, will and skills to solve troubles, tvboxes may end up being a large source of frustration. The very same problems are the main reason tvboxes are NOT OFFICIALLY SUPPORTED and NOT ENDORSED by Armbian project; tvboxes are just a community effort to have fun with them and avoid some waste, but the mileage can vary greatly. Here are the FAQs

Not until a sample happens to arrive in my hands

@n3o  You bricked your own device and neglected to create a backup before doing so?  At this point I would think you are just trolling.  I have given up on trying to convince you that your time is better spent elswhere.   I'll let the other forum members decide for themselves if helping you is worth their time. 

@n3o I think it's time you put this to bed and find something else that runs armbian without involving the entire forum.  At this point you are wasting your time. 
 
Like was mentioned by @RaptorSDS, the fact that android was corrupted should be highly suspicious and I would think points to some hardware defect. 
 
If you finally give up I would think one of the fully supported sbc's would be a good start if you want to still try to run Armbian.  
 
 
 
 

Because you have to change it in /sys/class/leds/working with the behaviour you'd like

Indeed if network manager does not work, the ethernet won't get an IP automatically. Perhaps the ssv6051 driver makes the network manager crash? (you may try to blacklist the driver).
 
The ssv6051 driver is the same as legacy, but some things have been necessarily changed to work on mainline kernel. In your case, it is not just a problem of the detection of the chip, but there is some kind of communication issue because the driver can't read the efuse from the chip (that, in fact, is the reason of the bad detection).

Not until a sample happens to arrive in my hands

Impossibile, perhaps you did not follow the instructions correctly (ie: erase the internal eMMC first)
 
ssv6051 driver is crap, in your particular case for some reason is not able to detect correctly the chip version and indefies it as ssv6051q, instead it is ssv6051p, but I don't know the reason.
For the ethernet part, it usually just works in the uttermost majority of situations, there has never been the need to do adjustments on any board, so it sounds strange that on yours it does not work.

@chinhhut Ah ok, an error during shutdown... well I never experienced such issue, may be an error in the kernel or in the trust OS which is leading some spurious interrupt after secondary cores are brought down... I'm not able to recognize anything specific from that crash dump, but I may suggest you do add "panic=10" in the kernel command line: this way, when a kernel panic happens, the kernel may still try to reboot after 10 seconds so you don't get stuck.

Hello,
 
Thank you for this amazing project. It truly revived this old TV Box from the dead.
 
Firstly, I want to share my experience with my my board (HK1 Mini), which might be useful to others.
Booting mainline kernel builds from SD card was not possible, but It booted successfully once flashed to eMMC. On the other hand, legacy booted from SD card just fine.
Bricked my board using build "Armbian_23.08.0-trunk_Rk322x-box_bookworm_current_6.1.39_minimal", but then recovered using original firmware, FactoryTool and MaskROM.
For my eMMC chip (Samsung KLMAG2GEAC-B002) I have posted the pins below to enter MaskROM mode.
 
Everything works on legacy build (Armbian_22.02.0-trunk_Rk322x-box_bullseye_legacy_4.4.194_minimal).
However, Ethernet and WiFi on newer kernel versions does not. The build I am using is "Armbian_23.5.1_Rk322x-box_bookworm_current_6.1.30".
This is where I'm stuck and ask for help.
 
This board uses the SSV6051 network chip and rk322x-config detects it correctly, but does not give me the option to select the driver like it did on legacy build.
I have tested all the LED configs, but none fix the issue on mainline, while the default config worked perfectly on legacy.
SSV6200 driver and NetworkManager throw a bunch of errors on startup.
 
Here I have attached the logs and DTS/DTB.  I would greatly appreciate it if you could take a look.
Tell me if the DTB is incorrect in any way because binwalk found multiple locations from the backup.
hk1mini.dtb
hk1mini.dts
armbian-hardware-monitor.log
 
Thank you!
---
 
HK1 Mini Board (RK3229-D4-V02)
MaskROM pins for Samsung KLMAG2GEAC-B002 (or B001 - the last number is unclear)
 

Yes, this is exactly the way I suggest to take confidence with the system: erase the internal flash to zero (does not matter if NAND or eMMC) to remove any trace of Android; then use Armbian from sdcard to bring up the system, experiment with rk322x-config to setup the board correctly so, in case of mistake, just plug the sdcard in a PC and revert the error; install packages, services, reinstall armbian from scratch with another kernel or rootfs (Debian bullseye, bookworm, Ubuntu Jammy LTS, latest Ubuntu, etc...) and do all your own experiments on the sdcard.
 
When finally you notice that the base system is stable with the proper led-conf and you're happy with the software setup, transfer it to internal flash or install armbian on internal flash with multitool.
 
Also, IMHO, boards with NAND have much better use with external sdcard than internal flash, since NAND are supported only with ancient 4.4 kernel and they still are problematic. Keep them erased and live easier with external sdcard.
 

Yes, this is exactly the way I suggest to take confidence with the system: erase the internal flash to zero (does not matter if NAND or eMMC) to remove any trace of Android; then use Armbian from sdcard to bring up the system, experiment with rk322x-config to setup the board correctly so, in case of mistake, just plug the sdcard in a PC and revert the error; install packages, services, reinstall armbian from scratch with another kernel or rootfs (Debian bullseye, bookworm, Ubuntu Jammy LTS, latest Ubuntu, etc...) and do all your own experiments on the sdcard.
 
When finally you notice that the base system is stable with the proper led-conf and you're happy with the software setup, transfer it to internal flash or install armbian on internal flash with multitool.
 
Also, IMHO, boards with NAND have much better use with external sdcard than internal flash, since NAND are supported only with ancient 4.4 kernel and they still are problematic. Keep them erased and live easier with external sdcard.
 

Indeed it is a scrap chip, tvboxes are often made of scrap parts; so far I have seen that chip on other boxes with rk3318, this is the first time that wifi chip appears on a box with rk322x.
 
By the way, the image you are using is ancient!
You can take a newer image with legacy 4.4 kernel here (suitable for boards with NAND) and you can should use a recent mainline kernel image from here for the box with eMCP.
Note that the mainline kernel image will also work flawlessy on boards with NAND, just the NAND flash won't be available and you will have to use an external SDcard for those boxes.

For the H20_221_v1.71 board I have worked out the uart connections and maskrom enable point.   For maskrom, this is shorting out either the data or clock line.  I have no way to determine which unless I take this thing to the office and look at it on a logic analyzer.  The test points are probably very similar to the v1.5 board with the blue solder mask.
 
 
 

like i sad befor led are a old word it change some more
 
jock explain :
https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/?do=findComment&comment=163046
 
 
 
 
what do you mean recognize wifi ? complete empty SDIO device or a wifi with unknow id like 024c:D724 ( RTL8723DS , because i solder it myself  and no one else has this chip inside a rk322x box, so its not recognice automaticly )
Is wifi another problem ?  i thing that HDMI was your problem ?