fabiobassa

DISCLAIMERS (PLEASE READ):
- Everything in this post is provided AS-IS. This is not an official Armbian-supported target, and neither the Armbian project nor I am responsible for any damage, data loss, or broken devices caused by flashing or testing these images.
- As with other TV boxes, please assume there may be board variants, undocumented hardware changes, weak power supplies, and marginal NAND/eMMC chips. Test carefully before writing anything to internal storage.
- Please keep discussion and support in the forum thread, not in the official Armbian issue tracker.
 
Hi all,
I would like to share my work on bringing Armbian to Rockchip RK3128 TV boxes.
These boxes are quite old now, and I do not think they are especially common anymore. Still, I suspect a lot of people may have one lying around somewhere in a drawer, unused after Android updates stopped or the original firmware became too slow to care about. I also had several of them lying around at home, which is what pushed me to start this project in the first place. Since I could not find an RK3128 Armbian effort comparable to the RK322x one, I decided to try doing the port myself. Another important motivation was simply to reduce e-waste: if even some of these old boxes can be turned into usable Linux machines again instead of being thrown away, that already feels worthwhile to me.

 
First and foremost, I want to send special thanks to @jock and @fabiobassa for their RK322x TV box work on this forum. Their work was the foundation that made this RK3128 effort much easier to start from.
 
1. Main references and source code:
Blog post with the full write-up: https://chieunhatnang.de/p/building-armbian-for-rockchip-rk3128/ Follow-up post for kernel 6.6.89 work: https://chieunhatnang.de/p/building-armbian-for-rockchip-rk3128-part-2/ Build scripts and releases: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts RK3128 kernel 4.4 tree: https://github.com/chieunhatnang-personal/linux-kernel-4.4-rk3128-tvbox RK3128 kernel 6.6 tree: https://github.com/chieunhatnang-personal/linux-kernel-6.6-rk3128-tvbox  
2. Current status
At the moment I have two kernel lines:
`4.4.194`, the older vendor-based line, which is already usable in practice `6.6.89`, the newer line, which allows these boxes to run a more up-to-date Armbian userspace  
What works in the current build:
Custom U-Boot based on Rockchip U-Boot 2017.09 All four CPU cores, up to 1.2 GHz CPU frequency scaling and governors DRAM frequency control, both dynamic and fixed NAND, eMMC, SD card, and USB booting. The booting order is: USB >> SD Card >> NAND/eMMC (NAND and eMMC cannot be enabled at the same time because they share pins) OTG and EHCI/OHCI USB support Ethernet Wi-Fi support for SSV6051P, ESP8089, and several Realtek chips GPU acceleration UART1 and UART2, configurable  
Kernel `6.6.89` status in a bit more detail:
CPU DVFS is stable after replacing the inherited/leakage-based OPP assumptions with a board-specific RK3128-safe table. The stable points I ended up using are `216 / 408 / 600 / 816 / 1008 / 1200 MHz` DMC / RAM devfreq works. In practice, simply enabling `dmc` works much better than I first expected, and boards can settle at different normal rates such as `396 MHz` or `456 MHz` GPU on `6.6.89` uses `Lima`, not the old Mali blob stack. That gives a maintainable Mesa/DRM path and hardware-accelerated OpenGL ES instead of depending on a legacy userspace blob VPU/video decode is still the weak point. I tried both `RKMPP` and `Hantro/V4L2` directions, but video processing is still limited, so I do not consider this a polished media-playback setup yet  
What does not work yet / known limitations:
Bluetooth: not implemented or at least not validated, because I do not have a board with Bluetooth to test VPU / hardware video decoding is not in good shape yet SD card and SDIO Wi-Fi are currently using PIO mode on both kernel lines. This is slower than DMA, but stable enough for normal use  
 
3. Image implementation
I also made two RK3128 Armbian images based on existing RK322x Armbian images rather than building everything from scratch:
Armbian 22.02: Based on the build provided by @jock, running kernel 4.4.189 Armbian 26.02: Based on the official Armbian build for rk322x, running kernel 6.6.89  
In both cases, the idea was the same: keep the working RK322x Armbian userspace as a base, then replace the RK322x-specific parts with RK3128 ones, while the kernels themselves are based on Rockchip kernel sources.
 
Compared with the original RK322x images, the RK3128 work mainly replaces or adds:
boot.cmd / boot.scr changes so the boot flow can handle NAND and USB properly RK3128-specific Wi-Fi drivers and boot-time module loading logic rk3128-config a delayed Wi-Fi loader service RK3128-specific motd information the RK3128 kernel, DTB, and overlays  
For the `6.6.89` image specifically, there is some extra image-level cleanup and repackaging:
remove the RK322x kernel / dtb / u-boot / BSP packages from the donor image pin those RK322x packages so they do not come back on upgrade install the RK3128 `6.6.89` Debian kernel packages rebuild the BSP package under the RK3128 name  

 
4. Quick installation notes
All required files are available from the releases page:
The releaes page: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts/releases Armbian 26.02 image: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts/releases/download/kernel-6.6-armbian-26-v1.0/A26-release-20260415.zip Armbian 22.02 image: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts/releases/download/kernel-4.4-armbian-22-v1.1/release-20260412.zip
There are three installation layouts that are currently supported:
 
1. SD card only Pros: safest option, does not touch internal storage, easy to test and easy to remove, and if a board has an SD slot it can still be useful even when NAND/eMMC is completely dead Cons: slower than internal storage, and not every board has an SD slot Best for: first boot, testing, and boards where you want to keep the original Android install untouched 2. Full install to NAND / eMMC Pros: fastest and cleanest setup, uses the internal storage already present on the board Cons: overwrites the original Android install, and old NAND/eMMC may already be unreliable Best for: boards with healthy internal storage when you want a fully self-contained install 3. Hybrid install: bootloader on NAND / eMMC, rootfs on USB or SD card Pros: usually the most practical option for old TV boxes, works well when internal storage is only reliable enough for bootloader pieces, and can also help on boxes with problematic Android boot behavior Cons: more manual than the other methods, still depends on internal storage for the bootloader, and performance depends on the USB drive or SD card used Best for: boxes with weak or aging internal NAND/eMMC, or boxes where you want to avoid a full install to internal storage
  I describe each method in more detail below.
 
4.1. Install and boot from SD card
Prepare:
idbloader.img uboot.img trust.img rootfs.img Create an MBR partition table on the SD card, leave the first 16 MB empty, create one Linux partition, then write:
idbloader.img to the raw device at seek=64 uboot.img to the raw device at seek=16384 trust.img to the raw device at seek=24576 rootfs.img to the first partition, not to the whole disk
  Example:
DEV=/dev/sdX sudo parted -s "$DEV" mklabel msdos sudo parted -s "$DEV" mkpart primary ext4 16MB 100% sudo partprobe "$DEV" sudo dd if=idbloader.img of="$DEV" seek=64 conv=fsync sudo dd if=uboot.img of="$DEV" seek=16384 conv=fsync sudo dd if=trust.img of="$DEV" seek=24576 conv=fsync sudo dd if=rootfs.img of="${DEV}1" bs=4M status=progress conv=fsync sync I also provide a bootcardmaker.sh helper script in the same release directory to simplify this process.
 
4. 2. Full install to NAND / eMMC
Prepare:
rkxx_loader_vx.xx.xxx.bin parameter.txt uboot.img trust.img rootfs.img  
Then:
Boot the board normally Connect a USB cable to the OTG port Open RKDevTool v2.69 In Advanced Function, erase the first 0x10000 sectors with Start LBA = 0x0 and Count = 0x10000 Press ResetDevice Wait for the board to return in MaskROM mode Go to Download Image Flash Loader, parameter, U-Boot, Trust, and rootfs  

 
4. 3. Hybrid install: bootloader on NAND / eMMC, rootfs on USB or SD card
This is the layout I use most often, and in practice it is probably the most useful one for old TV boxes.
It is especially useful when internal NAND/eMMC is still good enough for Loader / parameter / U-Boot / Trust, but not reliable enough for a full root filesystem. A common symptom on these old boxes is that Android starts to boot and then hangs, or that the internal storage is simply too unreliable to trust with a full install.
In this hybrid layout:
Internal NAND/eMMC stores Loader, parameter, U-Boot, and Trust The root filesystem lives on USB or SD card Important:
rootfs.img is a filesystem image, not a full disk image Write rootfs.img to a partition such as /dev/sdX1, not to the whole device Tools like BalenaEtcher are the wrong fit for this particular image layout Example:
sudo dd if=rootfs.img of=/dev/sdX1 bs=4M status=progress conv=fsync sync  
4.4. Post-install configuration
After the board boots successfully, you can configure it either from the local console over HDMI or remotely over SSH if Ethernet is connected.
Default login:
user: root password: 1234 The first login will ask you to change the password.
 
After that, run:
rk3128-config This is the board-specific configuration tool for enabling and adjusting hardware features that may differ between RK3128 boxes.
The most important options are:
Wi-Fi chip selection RAM dynamic frequency: disabled by default. Enabling it can improve performance, but on some boards it may cause kernel hangs. If that happens, switch it back to disabled SD card storage enablement when booting from another device Display resolution OTG mode selection  
5. Testing feedback is welcome
If anyone here has RK3128 boards and wants to test, feedback would be very useful, especially for:
Board photos and PCB markings Whether the board uses NAND or eMMC Boot method that works: SD, USB, NAND, eMMC Which Wi-Fi chip is present Serial logs, dmesg, and failure reports If there is enough interest and enough board coverage, I would be happy to keep improving this, cleaning it up further, and making it easier for other people to test.
 
6. Credits
- @jock and @fabiobassa for the RK322x TV box work on the Armbian forum, which provided the main starting point, the images and practical reference for this RK3128 effort
- Rockchip for the original kernel code base used as the foundation for both kernel lines
 

@chinhhut
Glad you got success .
Don't forget to put a like that helps @jock and myself in community reputation
 
 
 

@Harleyyyu
Your project could be interesting , I would suggest to open a dedicated 3ad on It own so people can contribute.
 
As you have already realized by yourself quite all  hardware and drivers aspects of this rk322x soc have bene investigated by @jockand/or @ilmich
 
But if you achieve any progress on GENERAL drivers and performance that isn't already been discussed or achieved you can came back here to share
 
Thanks

@Harleyyyu
Your project could be interesting , I would suggest to open a dedicated 3ad on It own so people can contribute.
 
As you have already realized by yourself quite all  hardware and drivers aspects of this rk322x soc have bene investigated by @jockand/or @ilmich
 
But if you achieve any progress on GENERAL drivers and performance that isn't already been discussed or achieved you can came back here to share
 
Thanks

@Harleyyyu

my 2 cents thought .....

We are talking about a 10 dollars soc . Is already a great milestone it is " just working"
Anyway.. If you achieve any good result let's us know

Sorry @Harleyyyu, but me and @fabiobassa were a bit puzzled about your journey within the hardware video decoding.
 
I recently tested the kernel 6.18 (but I am pretty sure it works fine also in kernel 6.12/6.6/6.1), but everything was already in place even with zero-copy DMA buffers, using the LibreELEC patches which are already compiled in the mainline kernel shipped with armbian for years right now.
 
Then there is also this apt repository I brought up few months ago with ffmpeg already patched and some instructions to run mpv with hardware decoding, which so far works for me either in virtual terminal and wayland (although sometimes with some glitches).
 
Just to let you know, because it looks like hardware video decoding, HDMI and GPU things are unsupported, but actually everything works fine.

@jockNow, I've finally solved this problem. Successfully flashed the latest version of armbian, https://github.com/armbian/community/releases/download/26.2.0-trunk.151/Armbian_community_26.2.0-trunk.151_Rk3318-box_noble_current_6.12.63_gnome_ desktop.img.xz

Next, I will share my problem-solving journey. I found that I couldn't enter maskrom/loader mode anyway, and when I accidentally inserted the USB flash drive into the multitool.img into the TV box and powered it directly on, I found that it actually started the system directly in the USB flash drive. So I guess that it may have changed the boot order after flashing the loader.bin before, and the armbian system I flashed in before it continued to toss before it could be configured, probably because the system files of the root partition were corrupted, causing it to not boot normally. Therefore, I simply tried to flash the firmware of the rk3188-box in the official community directly into the USB flash drive, because after these images are flashed into the USB flash drive, there is only the root partition, that is, the system. And there is no boot partition. I guess the boot partition may have been written somewhere else, and I don't need to worry about it anymore. So, I plugged the USB flash drive into the latest rk3318 firmware into the box and waited for a few minutes after powering on it directly and starting it, it obtained the IP address assigned by my router DHCP, I was so excited, I quickly connected to the rk3318-box through SSH, and made the preliminary configuration. Quickly enter the command armbian-install and select item 2, and immediately write the system on the USB flash drive to emmc. After the writing is completed, turn it off, unplug the USB flash drive, power on, wait for a few minutes, and the startup is successful. It means that I have successfully flashed the phone this time. Thank you very much for your help. @jockand @fabiobassa, You're passionate and highly skilled.

I'm currently trying to build my own kernel for armbian bookworm, using this Github Linux-rockchip: linuxtv-rkdevc-hevc-v2 (6.16-rc1) Goal is to try and make hantro work with native mainline V4L2-Request-API to achieve zero-copy decoding and bypass the legacy Rockchip MPP.

i just want to experiment the OS and the VPU it self at this point

@Joshua allen
 
asking for private chat to solve personal issues  is the most unappropriate way to act in a public forum.
 
For several reasons:

1) your problem could be the same problem for other people sharing your issues, so solving for you could be solving for many
2) this is an hobby for us and not job.     Job is paid, hobby is for free.          if you need help for your personal issue you can give an advice asking for paid help
3)this really is the worst approach to an open community of people that friendly and mutual try to help each others
 
that said....
would you share what is your problem, since you already asked for help ( private help..) in another post ?

describe what is working, what not, attach procedures and photos of board , explain your moves and results
 
We will try to give you a helpful  hand.

I solved the issue !
I flashed the latest armbian release raw image to the sdcard and plugged it in the TV box. It magically booted from the SDCard and now I have mmcblk2 as a block device. Now I can run armbian-install command to get everything going correctly.

fast search found that 8089 use 40Mhz not 26 so its ignored https://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447345.html
was a talk on kernel developer , some 8089 ignore also 40Mhz some need also 8622 need some 26Mhz or not 

@Jerry Falken
I am pretty sure you jumped in this 3ad without reading all of it, and this is unfair .

You are right, it is huge, but such question you ask have been already answered in the past many times , and I will answer just as a form of courtesy , but will not go back in the future on the same question again

If you look at your board you can spot 3 pads : tx rx gnd . That is all is needed, no 5 volts just tx rx gnd
Those pads are the "uart" , in other words there you will see ALL that happens when the board starts, if is a rk 322x or other fake print, if it is ddr3 or ddr2 manyyyyy manyyy infos to debug the whole process. For me it is a 3229 with ddr3 memory but uart will tell you
Go find in the 1st post the speed of uart to use with putty or minicom ( spoiler :1500000 🙃 )

just for sake of coriousity, this si the setting I have in my lab: ALWAYS and I repeat ALWAYS a uart connected to debug what is going so if you need answer.. post the right questions and not generic ones 

g on

Update: I was right, it is an allwinner system
 
U-Boot 2014.07 (Aug 28 2020 - 08:44:29) Allwinner Technology Mali: ERR: /home/work/share/akrd6/custom_relese/H3_ANDROID7.0_BOX_SDK_V1.0_20190702_eng/lichee/linux-4.4/modules/gpu/mali-utgard/kernel_mode/driver/src/devicedrv/mali/linux/mali_platform.c These where the smoking guns that caught my eye, i will likely install Armbian in this anyhow.

@dale
as usual shorting pins 6/7 on the well exposed nand

@Aroldo Bossoni
 
The optimal would be understanding the reason why the watchdog triggers, but could be a difficult task without a hint because of the closed source proprietary trust os.
 
The easiest thing is to provide armbian images with the opensource trust os rather than the proprietary, which is totally feasible because it just requires to swap a file in the armbian build scripts. That would blow the issue away, but unfortunately the proprietary trust os provided DDR scaling and virtual poweroff. The latter is a seldom used feature, but the DDR scaling provided a dramatic improvement in performance and it is hard to give up on that.
 
Swapping the things at runtime is not savvy: when u-boot updates, the proprietary trust os will be reinstalled overwriting whatever you put in there.
 
I would be happy with opensource Trust OS and no runtime DDR scaling, but stil having it at a fixed decent rate (660MHz, instead of the default 330MHz), but some boards do not boot at all when they are instructed to boot at 660MHz.

Hello everyone!
 
I'm willing to develop a script that automates firmware, u-boot, and ROM compatibility testing with the boards via OTG.
 
I've thought of a workflow something like this:
1. Download a list of files by type from several different sources.
2. Extract files from pre-built images, ROM, loader, u-boot.
3. Check for duplicate files by size and checksum.
4. Apply and test in stages: ROM, loader, u-boot, kernel, rootfs, network, video.
5. Log what worked and what went wrong.
6. Since this process can take hours, emit a beep when user interaction is needed.
 
What I need help with from you:
Is this idea feasible?
Will it produce results and facilitate the implementation process on rk322X boards?
Can it be reused and adapted for other boards?
 
I have little experience with ROMs and ARM firmware, but if it's feasible, I intend to create a public repository for the community to help me with the development.
Thank you for your attention!

@Virgilio Junior  you can use multitool, and use the "jump start" installation: you should be able to boot from sdcard and USB as well without doing the process by hand.
Forget about the NAND, it causes troubles you would not deal with

@Mateus Lima
 
It Is not the first neither will be the last time  that china manufacturers fake soc printing.
Have a look on allwinner forum 

Found with google: https://forum.armbian.com/topic/34923-csc-armbian-for-rk322x-tv-box-boards/page/96/#findComment-218361
 

In theory, it shouldn't

This was a watchdog and trust os issue.

For anyone having this issue, i fixed by building a new multitool from OP github: https://github.com/paolosabatino/multitool/tree/master
Changing the RK322x TRUST_OS to: rk322x_tee_1.0.1-72-gf230aa2.bin

And them building a new armbian build replacing the armbian TRUST_OS with this same one. "rk322x_tee_1.0.1-72-gf230aa2.bin"

if anyone needs the builded files "multitool and armbian" feel free to email me at vitorpicinin@gmail.com

Hi @jock,
Thanks for suggestion, led me to dig down and found your update on R29 GPIO. Since multitool hdmi was working, I used it's bash to mount emmc and add overlays=led-config7 to armbianEnv.txt. It worked!!!! Thanks a lot for all your contribution!

login via ssh

wich OS system Windows balenaEtcher, linux "dd" , do you perform checksum 

@Enzo Esteban
can you check with great precision the stamp on the cpu ? In second image

To me it seems a 3328 ......... and not a 3228 . Great difference my friend !!!!!!!!!!!!

If it is really a 3328 you are simply doing ALL WRONG . They are totally different cpu's and totally different drivers

The 3328 is a 64 bit aarch64 architecture

The 3228 is a 32 bit armhf architecture

BTW if you are in Brasil, try to contact this people . Basing on our early study they did a distro fitting on these cheap tvboxes

https://github.com/educabox/educabox/tree/main