jock

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

@n3o  The members trying to help you are highly experienced. The important point here is for you not to treat their specific instructions as merely "suggestions" after which you go off and do your own thing.   That is where the frustration lies. 
 
Based on the energy other users and you have spent on this, I would just buy some other TV box or SBC that is already known to run Armbian without any issues instead of trying to resurrect an old tired piece of hardware.   Unless you are really short on cash,  this is what I would do.  However, if you really are so short on cash that you cannot afford another $20USD on something else, then I believe your priorities are all wrong.
 
I have an H20 RK3228A tv box that is in transit that has some documented booting issues with Armbian.  In a way, I am happy to see how this whole episode has progressed.  I'm happy because now I know what NOT to do.

Seriously, are you thinking that thousands of log lines of the original android (I read kernel 3.10) are of any use?
Paste the logs of the problematic boot, not when it goes well, damn!

!! DEPRECATED !!
Instructions in this thread are oudated and superseded by the new experimental APT repository for hardware video decoding ffmpeg.
Please refer to this thread from now on!
 
Hello, recent upgrades to armbian are regarding kernel 5.15.
I noticed that many v4l2 fixes and enhancements went into this release, so I decided to compile ffmpeg using LibreELEC patched version and mpv over it.
mpv turns out to be statically linked with ffmpeg, so I propose it here for people who is interested in cutting edge kernel and wants to do some tests.
 
This has been tested on Debian Bullseye and Ubuntu Hirsute on following platforms:
Rockchip RK3228/9 (kernel 5.10, 5.14) Rockchip RK3288 (kernel 5.14) Rockchip RK3318/28 (kernel 5.15)  
It should work on allwinner platforms too, but I didn't test it there.
Binaries are built by me on developing boards.
 
The binary for armhf is available here
The binary for arm64 is available here
 
Copy the binary into /usr/local/bin directory of your system (mpv-armhf for 32 bit systems, mpv-arm64 for 64 bit systems):
sudo cp mpv-armhf /usr/local/bin/mpv  
Install dependencies for Debian Bullseye and Ubuntu Hirsute:
apt install libass9 libbluray2 librubberband2 libsdl2-2.0-0 libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1 libx264-160 libx265-192 libxss1 libxv1 libfdk-aac2  
I have had issues with dependencies on Debian Buster/Ubuntu Focal, in particular libx264-160 and libx265-192 are not available there.
I Solved the issue downloading the packages from Debian Bullseye web page and manually installing them.
There may be the need for some other dependency depending upon your actual installation.
 
Run mpv in a virtual terminal (videos up to 4K) with this CLI:
mpv --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4>  
Mpv can be run in X11 with this other CLI, but due to buffer copying it requires a good CPU - rk3228 and rk3328 won't even play 720p, rk3288 do 720p fine:
mpv --vo=gpu --hwdec=auto-copy --gpu-context=x11egl --gpu-hwdec-interop=drmprime-drm <video.mp4>  
This is an experiment and your mileage may vary a lot:
H.264 codec should be well supported around the boards; H.265 has more limited support VP8 should be generally supported VP9 seems to still require some work.

Actually I forgot to update the first post: the FAT partition has now been changed to NTFS to overcome the 4GB maximum file size limitation of FAT32.
I think I made a post about that, but forgot to update the first post. Sorry, I'm going to fix that right now!
 
Despite that, the multitool works exactly the same as before.