curse

When I am asked about Debian and its derivatives, I usually jokingly answer "IMHO Debian is stable ... outdated". I say this because Debian targets x86 as the main architecture. Because the x86 architecture has been feature complete for decades, you can also use older stable program releases with full functionality and it takes time till new releases trickle in. But we play with the ARM architecture and there the development is still at the  bleeding edge. Program releases can therefore not be up-to-date enough,  and usually still require pending patches. Fedora is tracking mainline  quite close.
To check what the current status is, I recently conducted a small experiment. My current system is based on fedora FC34 and is due to WIP patches and current release versions on a well-functioning state. Many of the components I added manually have recently landed in recent mainline versions. I have now copied a rootfs with the content from the upcoming fedora FC37 KDE Plasma Desktop Spin into a free partition of my NVME and added my current kernel build. After I also added a boot stanza to the extlinux.conf to start this new system, I restarted my device. After the obligatory first start configuration, I then had an equally functioning system as with my old FC34 but without further modifications to any userspace component.
Hence my claim: with current pure mainline userspace releases you can have out-of-the-box support.
Unfortunately, I can't say to what extent this experience can be transferred to Debian and its derivatives. It depends on the releases it currently carries.
The firmware and kernel will still need some out of tree components for a while, but this is easy to handle. And I am sure that one or the other userspace program sooner or later will also be rebuilt with some patches for early adaptation of new features. Development will never end.

Do you know if it is sufficient to install packaged falkon, qt and gstream packages on Ubuntu Jammy/Debian bullseye to get thing working or there is the need to compile something by hand?
I ask because it would be nice to have some out-of-the-box solution to say that the path is traced and things are getting squared.
 
Thanks!

Even better, 6.1.0.
 
Browsers that are using the qt5-qtwebengine backend in a wayland environment (e.g. Falkon) are working flawless. The Qt Multimedia module uses the gstreamer framework and wayland uses proper KMS/DRM support.

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

Announce:
 
Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis!
This means that you can now download images for CSC boards (including rk3318-box) browsing from https://github.com/armbian/community
 
Images are built from trunk, GPG-signed and SHA-sum is provided.
 
I also removed the manual instructions for upgrades: Armbian 22.08 release is imminent and from that time on it will be sufficient to use apt to get kernel upgrades too! Thanks for your patience!
 
Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers.
 
Enjoy!

It appears it does not matter when you plug in HDMI cable. But for 3d printer owners out there I made a parametric cooler case(well top of it anyway)
https://www.thingiverse.com/thing:5447782
Certainly sorts out the overheating issue for the time being. Tested with cpuburn-a53
ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /root/temp; cat /root/temp  

Found info from this post:
 
Some general info her on u-boot for RK. https://u-boot.readthedocs.io/en/latest/board/rockchip/rockchip.html
 
1. Can you boot from Multitool.img ? , IF no then its will not be possible to boot Armbian from sdcard.
2. If you can , burn Armbian 22.08 - Debian image found inn first post  to sdcard.
3. Burn Multitool.img to another sdcard or mount image on Linuxpc
 
Manuel mount multitool.img
From terminal.
 
cd $HOME/Downloads/  
# find first unused device  , /dev/loop(24)
losetup -f  
# Mount img on /dev/loop24
 
sudo losetup -P /dev/loop24 multitool.img  
# Open file-browser  MULTITOOL/bsp/
# copy uboot.img and trustos.img to $HOME/Download Linuxpc
# Insert sdcard to linuxpc and find dev of sdcard / often last sdX
 
lsblk -f  
# My sdcard is assigned /dev/sdf
 
# DD uboot and trust IMG to sdcard armbian
# Replace /dev/SDCARD  to your dev for sdcard like sdf

 
sudo dd if=uboot.img of=/dev/SDCARD seek=16384 conv=fsync sudo dd if=trustos.img of=/dev/SDCARD seek=24576 conv=fsync  
If this not work you can copy the generic DTB rk3318-box.dtb form multitool.img to sdcard.
You find generic DTB on root /  multitool.
Copy this to /boot/dtb/rockchip SDCARD to overwrite DTB on Armbian image.
 
Or burn older Armbian img to test if they boots form sdcard when Android on internal storage.
 
Happy booting!!
 
 

Thank you for the tips @jock
 
 
I have 2 H96max+ RK3328 ∕ 4GB  tvboxes.
 
Armbian 22.08 - Debian Bullseye minimal - mainline kernel 5.18.10
 
BOX1 :  On internal eMMC
BOX2:   Boot Armbian from SDCARD  , Android on internal eMMC
 
Benchmark from terminal:
mbw 1000  
Box1 : RAM 667Mhz CPU @ 1,3GHz
AVG    Method: MEMCPY    Elapsed: 0.82118    MiB: 1000.00000    Copy: 1217.764 MiB/s
AVG    Method: DUMB    Elapsed: 0.88632    MiB: 1000.00000    Copy: 1128.263 MiB/s
AVG    Method: MCBLOCK    Elapsed: 0.27756    MiB: 1000.00000    Copy: 3602.800 MiB/s
 
Box2 : RAM 333Mhz (Android uboot) CPU @ 1,3GHz
AVG    Method: MEMCPY    Elapsed: 1.51033    MiB: 1000.00000    Copy: 662.107 MiB/s
AVG    Method: DUMB    Elapsed: 1.62614    MiB: 1000.00000    Copy: 614.955 MiB/s
AVG    Method: MCBLOCK    Elapsed: 0.54709    MiB: 1000.00000    Copy: 1827.854 MiB/s
 
To boot from sdcard when Android on internal storage.
1. Flash Armbian on sdcard
2. Download Multitool.img 
3. Mount multitool.img on linuxpc or flash to another sdcard.
4. Copy  trustos.img and uboot.img from bsp folder to a folder on linuxpc,
5 . DD trustos.img and uboot.img to sdcard Armbian from linuxpc
 
sudo dd if=uboot.img of=/dev/SDCARD seek=16384 conv=fsync sudo dd if=trustos.img of=/dev/SDCARD seek=24576 conv=fsync  
 
 

@jock Thanks for the info. On a side note, I found a small bug: when making the emmc backup, if the resulting file is bigger than 4Gb it will just stop there (because of the FAT size limit) and you will get a broken backup.
 
Probably could be solved by splitting the backup, for example along these lines:
# Split backup in 2Gb parts, with two-character suffixes dd if=/dev/mmcblk1 | gzip -c | split -b 2000m - tvbox-backup.img.gz. # Restore the backup cat tvbox-backup.img.gz.* | gzip -dc | dd of=/dev/mmcblk1  

@callegar@Willy Moto@MX10.AC2N
Ok, I double checked the cpu voltage supply and effectively it seems that in the latest device tree I pushed it way too low... The original device tree of my box said 1.375v@1.3Ghz, the voltage in mainline kernel says 1.300v@1.3Ghz and I set 1.200v@1.3Ghz. That is very good for temperatures and power consumption, but maybe it is a bit too low for stable operations.
 
I will rebuild the whole set of images, but in the meantime I updated the dtb deb package you can install that should fix issues: https://users.armbian.com/jock/rk3318/upgrade/linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb
 

UPDATE!!
 
Hello, I'm pleased to announce that rk3318 CSC configuration has been accepted into mainline kernel!.
This means that next Armbian release (probably August) will provide regular kernel upgrades offered by Armbian ecosystem via normal apt upgrade command.
Until then, please stay stick to the usual manual upgrade!
 
But there is something more: new update for the rk3318/rk3328 images!
Most important changes:
Kernel upgraded to version v5.18.6 Memory clock set to 667 MHz (was 333 MHz), providing a nice boost in general, desktop and GPU performance; despite this works fine on my board I always warn you to test images first via sdcard Introduces MGLRU patches from @yuzhaogoogle (you can read about here and search google for more details), which should provide much snappier experience especially on low-memory devices You can find the images and deb packages for upgrades browsing the directory pointed on first page as usual.
 
You can visit the Armbian MGLRU topic, if you have questions about the features or kernel issues (like crash dumps which involve kswapd, for example)
 
 

No. The Snapdragon 7c is different from the RK3318/RK3328. You'd have to find an image for the Snapdragon 7c. 

@MarcoFdN I updated the debian bullseye image and the upgrade packages to include the fix for bluetooth and rk3318-config script.

There was a simple way, and it was in front of my nose.

This is the standard way from the official instructions of the Armbian:
 
Start the install script:
nand-sata-install
I chose:
of booting from eMMC/NAND, system to SATA/USB
 
The system migrates to a USB3 SSD
Restart and boot the system from USB3
 
now a stable start with USB3

Well not just the kernel, but the whole rootfs must sit on SSD.
Plus if you cloned you sdcard on SSD, both sdcard rootfs and SSD rootfs have the same UUID, and this may confuse the kernel about which rootfs use at boot.
This is pretty normal if you think about it: how does the kernel can know if you want to boot from sdcard or boot from SSD when both contain the same bootable system?
The rootfs UUID is specified in /boot/armbianEnv.txt.
 
There are several approaches:
You clone the sdcard on SSD, then you remove the rootfs partition from the sdcard Install just the bootloader on the eMMC erasing the eMMC and then copying the first 4 megabytes of the sdcard (/dev/mmblk0) on the eMMC (/dev/mmcblk2) Change the UUID of the sdcard rootfs, but this will prevent the sdcard rootfs from full boot The most clean approach is #2, taking in account that you should not plug both sdcard and SSD at the same time when the same cloned filesystem is on them for the usual UUID reason of above.

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.

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

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.

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.

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

I noticed the same when I was trying to restore my backup. It got stuck at around 20-25 percent and I thought it might work better if I uncompress it first.
Oups, I have a 64GB eMMC, and the SD card I had at the time was only 16 or 32 GB. 
The backup is a raw disk image of the eMMC, and it will always be the same size as the eMMC until it's compressed, and "removing the blank data" is part of the compression process. 

@MX10.AC2N
 
As @curse noticed, probably you need the bison and flex packages to install headers. But you don't really need headers in case you don't want to compile kernel modules by yourself.

My French is not the best but for me it seems like the folders named "/boot/dtb-5.14.13-rockchip64/rockchip", "/boot/dtb-5.14.13-rockchip64/rockchip/overlay" and "/var/lib/initramfs-tools" are missing and the packages "bison" and "flex" needs to be installed.

And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around.