Ben N Voutour

I overclocked the CPU to 1.4MHZ using the voltage 0x1437c8, governor = conservative.
opp-1200000000 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0x13d620>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1296000000 { opp-hz = <0x00 0x4d3f6400>; opp-microvolt = <0x137478>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1392000000 { opp-hz = <0x00 0x52f83c00>; opp-microvolt = <0x1437c8>; clock-latency-ns = <0x9c40>; status = "okay"; }; The system has been working steadily for several hours and the browser is working faster.
Earlier I tried to overclock to 1.4 using the voltage 0x1312d0, but the system received errors almost immediately as soon as I started the browser.
My DDR is still 533MHZ. I want to raise the frequency to 600 - 660MHZ.
As I said earlier, I use a radiator with a fan
 
Just in case, a photo test point for RK3318 v.1.4 to launch a TV box in the maskrom mode

No problem! I was intentionally being ironic  thanks again

then what is 1596000000 ?
that is what it returned for me as root #
"cat /sys/kernel/debug/clk/dpll/clk_rate"
should i try 1333? or 1600?
i'm gonna try 1066 first.
unless i'm missing something , some of these boxes can sort of handle the higher ddrbin, we might have to play a bit with it.
these boxes are a dime a dozen from most online stores....
 

The script allows you to go up to 800mhz, but I would not go further than 660MHz for a number of reasons

@Jock
Here Are Some DTB Dumps From 2022 to 2023 (Android 9/10/11/12)
The File Names Are "CRC32".dtb
DTB Dumps (2022~2023) (CRC32.DTB)

here is the English Translation for the Rk3318 TRM
Rockchip+RK3318+Datasheet+V1.0-20190806.en.ru en.pdf

@Jock
Here Are Some DTB Dumps From 2022 to 2023 (Android 9/10/11/12)
The File Names Are "CRC32".dtb
DTB Dumps (2022~2023) (CRC32.DTB)

here are some of the same dtb + kernel dumps of firmwares that seemed to work on my hk1 max rk3318 3328 fake?
https://drive.google.com/file/d/1q2x9a9gO5lHe54a6Y8SLlfidCSD7Ycga/view?usp=sharing

USB boot is a peculiarity of the u-boot shipped with armbian.
Normally you need to install armbian on eMMC and you get both SD and USB boot.
Since your eMMC in not functional, the only way to do USB boot on your board is to keep an sdcard with u-boot only in the slot (ie: delete the armbian partition from sdcard) and the hdd in the USB 2.0 plug.
USB 3.0 is not supported yet in u-boot.

Wouldn't it be easier to modify Armbian as you want it before installing it in the first place? I don't know how to do it, but example. Download @jock's Armbian, or compile your own. Modify the files on the .iso. write it to the SD card and install it on box 1 without the need to modify it later. Then do it on box 2, box 3, etc.

Good evening all,
Using the excellent instructions by @jock in Post #1, I was able to get Debian Bullseye desktop [xfce] installed on my Pulierde T9 box.
Everything is up and running, I can connect to my network, etc... So .... now what? lol
I did this mostly as an interesting little exercise, and also because I'm loathe to throw away usable tech. However, now that it's a functional little linux box, what can I do with it?
I have no need of any sort media streamer/server box, since I have a full server in my house.  I thought about maybe a pihole, or something to do with HomeAssistant, but I wouldn't know where to begin.
So here's my question: What should I do with this little beast now?
If it matters, this one is a RockChip 3328, 4GB RAM, 64GB ROM, Mali450 GPU
Thanks for all the hard work that went into making this project a possibility!
-E

hi Jock, Thanks for your efforts on Armbian for RK3318. I installed latest image on H96+ Max, everything works except wifi. Wifi isdetected but unable to connect(With valid credentials). Please sugges how to fix the issue.
Below are logs:
http://ix.io/3F2c

If it's a similar problem as I had with my H96 Max Plus (RK3328) 
@jock gave me a few good hints Here, 

@chinhhut @curse
The backup made by multitool (and rkdeveloptool) is per nature a full backup of all the physical eMMC sectors. It has no knowledge of the abstract structures like filesystem and files.
The compression gives back a more manageable file which is not the entire size of the eMMC, but up to a few gigabytes, depending on how much data is stored on the eMMC and how much compressible it is.
 
Indeed if you decompress it, you get the whole size of the eMMC, it is expected and it is advisable too. If it is not so, it means the backup process didn't went right.
 
Now should be clear there is a problem about the "blank" part: how we can know if a part is "blank" and not, for example, a piece of a file which just contains a long string of 0x00 bytes? This is crucial: if you say that you skip those parts which are, supposedly, blank, you may (and probably will) fail to restore files that contains long string of 0x00 bytes. You won't get 0x00s in those places, but you will instead find there the contents of the unwritten eMMC sectors.
 
So a full restore of all sectors is essential to restore the exact previous condition when doing a full backup.
 
One helpful thing that may be helpful here is to use the native page erase feature of eMMCs, which is the thing blkdiscard program do and is at the bottom of the famous TRIM feature: flash memories are divided into "pages", ranging from several kilobytes to few megabytes usually.
Erasing those pages using the discard command is very fast, much faster than zero-filling. You can erase all the pages of a whole eMMC in a few seconds, while zero-filling all the pages would require dozens of minutes.
 
Doing an erase with blkdiscard and then restoring the backup skipping the blank parts now becomes sensible!
There is an issue though: discarding pages does not fill them with 0x00 bytes, but with 0xff bytes, so the real blank parts now are not those which contains string of 0x00s but those which contains strings of 0xff bytes. Those may or may be not so common. Surely they are common in non-programmed sectors, but results may vary.
 
As a conclusion: restoring the whole count of eMMC sectors, despite being slower, is surely the simplest and most reliable way!

@chinhhut Actually armbian provides a way to introduce user-level patch files which can modify the behaviour of the installed system.
It means that you can, to some extent, launch sudo ./compile.sh and finally produce an image customized for your needs.
 
Armbian documentation will help you further.

You can try YUNoHost, it's cool I use it on my beelink gt-king pro with armbian-meson64 works fine and have many apps.
Today I try install of Swizzin, on my RK3328 box that's work ( install process need root user "su -" )
it's another possibility..
https://github.com/swizzin/swizzin
https://swizzin.ltd/getting-started/

I will study more how to patch some additional files but could you share the source code to build RK3318 image?
Thank you so much for your support.

First page, github repository has always been public

Now that is something I may be interested in! Thanks for the ideas!

It depends upon your actual board and how much it is well built.
Keeping all the emmc options off is the most stable but also the slowest setting.
Enabling DDR or HS200 modes may improve the eMMC throughput a lot, but may also make your eMMC not work anymore and depends upon your board quality.
Despite eMMC declare their supported modes and kernel is perfectly able to select the best suited, it is not possible to resort to automatic selection because of the board quality.
HS200 mode is preferred over DDR.
 
rk3318-config is telling you: select the board configuration looking on the markings of the board. The right configuration solve problems with devices detection like leds, wifi, bluetooth and improve general stability
You have to open the box and look at the signature of the board: that is the "name' of the board. Most external devices of the boards (emmc, sdcard, infrared receiver, USB ports, HDMI, etc...) are usually wired to the same GPIO pins to the SoC described in the reference design. This is the base configuration.
Some manufacturers wire other devices (leds, but also wifi, and others too) in a different way, so you need to fix the configuration for specific boards, hence you need to select the right one here.
If your board is not in the list, it means that nobody (actually me) has ever made a configuration for your specific board, so use the Generic option.
There is no 'trial and error" here, you have to know the board name, otherwise stick to generic one.
 
About the leds, I don't know your setup, but after first rk3318-config run, the main led is configured as "power on".
The behavior can be easily changed setting the appropriate trigger in /sys/class/leds/working/trigger file (see google for that, "working" is the name of the led).
 
I hope so. I would like to merge soon, but it depends upon the compatibility reports that are posted here.
 
 
Could be useful, yes. Useful also are photos of the board to identify the signature and chips.
 
I don't think it is possible to tag single posts. It would not useful though: the board you find inside the box is not always the same.
We have seen that tv boxes with the same commercial name may contain different boards.
That's the reason because rk3318-config does not list boards per commercial name (H96Max+, HK1, T95P, ...) but per board signature.
 
Normally you don't need to read all the posts of the thread: the first post is regularly updated with all the information needed for newcomers and board specialties are integrated into rk3318-config to make life easier as soon as new boards appear.
 
A good idea though is to read the last couple of pages of the thread to quickly get updated to the latest bits. The whole thread will give you the idea of the progress, but a post about your board of one or two years ago will probably be outdated and not so useful. First page is always the source of truth.

!! 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.

it appears that someone has made a method to install libreelec for 3318/3328 on an sd card simply write the img file from libreelec to a usb sd card reader then fire up vmware with ubuntu and mount the usb sd in vmware and have the trust.img on the vm and send the command as root 
dd if=trust.img of=/dev/sdb seek=24576
unmount ant shut down the vm, then edit /extlinux/extlinux.conf to point to rk3318-box.dtb
then put the rk3318-box.dtb wherever you pointed the /extlinux/extlinux.conf file to.
eject the usb sd adapter from windows.
insert the sd card into the box and boot it up, it will resize the sd card to any remaining free space for libreelec
use version 10.0.1 rk3328-arm a1 box and it mostly works except bt/wifi/led/ir, but everything else more or less works normally

Руслан Зинеев
Привет , I used google translator to understand your post.
The uart speed is contained into the image : you can put the image on a sd and under folder  /boot you will find a config item.
but can you explain in english please exactly which is your problem ?
 EDIT: try to set your uart directly to 115200

you will lose initial infos but then you can follow ll the boot process
 

@mkultra
 
If you go to my post of 5 November you will find all the necessary instructions. You need upload a loader before doing anything
 
If you are tired or lazy to read the whole 3ad... Well...... that might be a obstacle...... ;-)

ok I just discovered the 'like icon' - I wasn't seeing it on my bright monitor so apologies for the 'late likes' 
will revisit the interesting rkdeveloptool tomorrow but still getting some errors
$sudo ./rkdeveloptool db MiniLoaderAll.bin
Creating Comm Object failed!