Willy Moto

Rock5 model B  is up for preorder now - pay $5 now and get $50 off when it ships in Q2 https://www.cnx-software.com/2022/01/09/rock5-model-b-rk3588-single-board-computer/?amp=1 Its going to be a beast - about 4x performance of rk3399 multi core and GPU up to 10x performance in some tests

@Wester_Minsk
 

I suppose you want to build a uboot for supporting booting from usb3 .
This isn't a simple task and if it was simple,  somebody else already could had done for all of us. It is needed deep knowledge of processes undergoing the compilation and the modding of c sources. It isn't just a flag " boot from usb3..." but a chain on changes to do to the code, if someone already has written a code for it

By the way here is the link
https://github.com/rockchip-linux/u-boot

but then don't ask for assistance in what when and where apply patch since if this infos were clear and well known uboot already had have usb3 support.

But you really welcome to study and share your results

I switched to - Armbian 22.02 - Debian Bullseye minimal - mainline kernel 5.15.16

Everything is ok on my board.

I migrated the system to a usb3 ssd drive, and connected a usb3 hub with a 1 Gbit LAN.

On the new version of the image, the armbian-config works fine after migration.
 
Thank you so much for the new release!!!

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.

Minor upgrade!
 
Not so many fancy things, this time, but those interested in rtl8723cs, rtl8703bs and ssv6051 wifi chips may give a look into!
 
I upgraded the Debian Bullseye Minimal image (not the others) to kernel 5.15.16 kernel.
Also deb packages have been updated for manual upgrade to avoid system reinstall (instruction on first page, as usual).
 
@Zippy may be particularly interested in this.
 
Enjoy and give feedback!

1) Yes, I experienced similar issues expecially with an rk322x board in the past. I did many tests and apparently reducing the current to the wifi gpio pin improved situation. The fact is sdcard, wifi and emmc are somehow bound together being all attached to mmc controllers. Often an issue in a device prevents another to work correctly. It could also be some buggy driver, an interrupt with bad timing and thousands more things.
2) There should already be a watchdog driver, nonetheless it complains in dmesg about something and I never really tested it
3) rk3318 and more generally all 64-bit rockchip armbian kernels differ quite a lot from mainline. There are plenty of patches applied over mailine kernel to make these socs work better and more stable. This is the list of patches applied to rk3399 and rk3328/18. Many of them just add device trees for various supported boards, but many others also add functionality and fix broken things in mainline kernel. Rebuilding the kernel packages is quite easy, armbian build scripts are all automatized and you just need to run a script and select what you want for which board. Armbian documentation explains all the process briefly. When you are done, you will find the deb kernel, headers and dtb packages in output/debs directory of armbian installation. Just copy them on your board and install with dpkg. If something goes wrong, multitool allows access to existing mmc via shell to do maintenance, but also can be used to made a backup of the existing content that can be restored in case something goes wrong.
 
yes, me too. It seems to happen only with bullseye, buster is fine.
I don't know which one is the offending party, but I guess it is a bug in armbian since it uses a special zram partition to keep the log during runtime to reduce flash memory wearing.

@chinhhut

Try these steps:
1) push the little switch inside the hole while inserting a male-male cable into the otg
2) on another linux machine you should have now a new device (lsusb will help you) and you can run rkdeveloptool
3) rkdeveloptool ld should List Device
4) rkdeveloptool rd 3 should Reset Device into mode 3  ( maskrom )
5) rkdeveloptool db MiniLoaderAll.bin ( of course from your path) should upload a temporary loader to recognize the internal emmc
6) if all is successfull until now you can rkdeveloptool wl 0X0 yourimage.img . This should flash the internal emmc .

DISCLAIMER: very " dangerous" approach , be ready to have the opportunity to short the emmc clock pin to ground to go back into mask rom
 
MiniLoaderAll.zip

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

FYI, if anyone is interested in advancing Armbian support for H616, I just fixed reboot issue on mainline kernel for OrangePi Zero2. In fact, I started collecting H616 patches in hope to create LibreELEC image. Patches can be found here: https://github.com/jernejsk/linux-1/commits/h616-full
 
Note: U-Boot needs this hack: https://github.com/jernejsk/u-boot/commit/d420184997f302f546bb0862b1774cca6b43fb9a Without it, Linux will hang at loading Panfrost driver.

Good day all!
 
I started to discover the problem from the attempt to extract dts and dto files from backup.  And this task  was not easy for me (I still can not to do it). But I found a workaround for my main purpose. I just install TERMUX + termux:boot (https://termux.com/) on the native firmware and got what  I need (octoprint).
 
@jock thank you again for your img and feadback

Likewise, but perhaps they are totally overloaded for years in advance?

I would also like too see more community involvement in maintaining the project, since wishes are way too big for capacity project has. A lot of solutions got stuck in this stage. 
 
Armbian project already struggle and there is very little of interest to help project helping community.
https://docs.armbian.com/User-Guide_FAQ/#is-armbian-an-operating-system
 
How to proceed?
https://docs.armbian.com/Developer-Guide_Build-Preparation/
https://docs.armbian.com/Process_Contribute/
The process will receive support.

@Elmojo
I know is not fine answer to a question with another question but in this case
 
comes very natural ask  : why did you modded it ??? Just for fun ? You didn't have a defined purpose in trying linux ?

Anyway, just to answer , in my personal study case I have done on it:
voip pbx ( asterisk)
network nas
network firewall
pihole dns firewall
openvpv, wireguard and tinc vpn
home assistant
volumio
special ip cam monitoring and data acquisition

and I guess I could experiment more..... if only I would study more potential applications

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

New version 20211017 kernel 5.10.73 and 5.14.12. A significant change is the transition to a new version of u-boot with support for running any system from USB to M1 (rk3328). Now you can run any test system from USB media. So far, only USB 2.0 is working.

@Willy Moto Yes, your observation is right: load average is broken on legacy kernel. For some reason, it idles with a value of 4.00, where instead mainline kernel correctly idles with a value of 0.00

The most offending things are:
1. emmc settings
2. cpu frequency
 
eMMC settings are the most dangerous. Leave all the options unchecked in the eMMC panel.
CPU frequency safe setting is 1.1Ghz (which is the default). Not all chips can reach 1.3Ghz.
 

@jockSorry for an extremely late reply. I was on vacation in distant lands(visiting my mom in Sweden), and the only monitor I had available to use there was an old 1024x768 monitor which I couldn't get to work with Armbian. The only thing that worked was the Multitool.
Well, I'm back home in the Canary Islands with the volcanoes now.
So finally. I can report that the WiFi on my H96Max+ (RK3328) works with the last idea you had
https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=127240
Thank you for all the help.

@curse
I think I spot the issue: from dmesg I see that the brcmfmac driver is using the standard nvram file, but the standard nvram does not work because it is for BCM4334 and not for AP6334.
This time I propose you to paste this file over /lib/firmware/brcm/brcmfmac4330-sdio.txt, reboot and try again.
 
If the problem is that one, it is very strange because the driver is supposed to find automatically the right nvram file, it has always worked that way but for some reason this time does not.

First things first; i haven't experienced any panics, crashes or other similar bugs. The new image runs smoothly as far as i can tell.
Seondly; Kivy finally *bleep* works. After compiling 20+ builds with different configurations, throwing the tv off the wall, buying a new tv and starting all over again, i found out that the issue was to do with Mesa not playing nice with the anti-aliasing Kivy applied, which resulted in a black screen. It still runs at 10-15 fps, but i think that's due to this build of Kivy being built with OpenGL instead of OpenGL ES, so i'm currently in the process of building Kivy with GLES support. At least we're making progress and i can't thank you guys enough for thinking this trough with me (or actually 'for me').
 
So for anyone who happens to come across this post with the same problem, set the 'multisamples' in the 'graphics' config to '0' like this (which may or may not help for you):
 

 
EDIT: After building Kivy with OpenGL ES support, the whole ui works smoothly at around 30 - 70fps. Have a good weekend!

@pakos96
Hello! I guess you are saying that is lagging because desktop is not very reactive. For start, it is wisely suggested in armbian to disable the xfce desktop compositor (Menu -> System -> Window Manager Tweaks).
Don't expect very fast graphical performance, mali-450 is still a limited GPU. Also, until I don't enable the RAM frequency scaling, the RAM is fixed at 330 MHz (instead of usual 667 or 800 MHz) and this is a huge hit for general graphical performance.
 
@usual user As far as I see, armbian hirsute should have oibaf repository enabled and so Mesa comes as the latest development release

Update!
 
Images with mainline kernel have been updated to Debian Bullseye (minimal) and Ubuntu Hirsute (xfce desktop) with kernel 5.10.68.
Kernel is the same major version as previous mainline images, but Bullseye and Hirsute should provide significant newer software packages (including new Mesa libraries for those interested in graphics).

Cool, thanks for reporting!
My box was also stable for hours with your ddrbin, so I think I will promote it as the new default

14 hours up time on eMMC, with  Doker +HA + Pihole load. 
At the beginning there was one freeze, after which I removed the parameter "rk3318-box-emmc-hc200"  from the armbian-config. 
Then it works stably. 
This is already much better than it was, the changes are obvious. 
I will pick up a good sdcard, and start from it to eliminate the eMMC problem and continue testing. 

@fabiobassa:
Here are some photos of my TV box for your inspection.  Though @jock already said it's a NAND memory model.
 
Do you think it's a good idea if I replace the CPU heatsink with a larger one to increase the cooling effect? 

 

@Wester_Minsk thanks for the logs.
I extracted the ddrbin from the backup you posted above and made an image with that. The ddrbin is the thingy that initializes the DDR memory, an initialization with bad timings may be harmful for the system stability, so give a shot to this experimental image (it's a debian bullseye with command line only):
 
https://users.armbian.com/jock/rk3318/Armbian_21.11.0-trunk_Rk3318-box_bullseye_current_5.10.64_minimal.img.xz
 
edit: if you try this on sdcard, be sure to erase the eMMC completely first!