hartraft

Here's a package comparison I did today of fresh installs (yesterday) of Armbian and Debian. Unfortunately, I forgot to do an update/upgrade of Armbian before listing the packages, so Armbian may appear to be slightly out of date compared to Debian, but the comparison took me too long to repeat it just for that update.
 
comparison in pdf
comparison in csv
 
Here are the 28 Armbian packages I updated after the comparison:
 
armbian-config armbian-firmware armbian-zsh avahi-autoipd base-files curl
  debian-archive-keyring groff-base iputils-arping iputils-ping libbsd0
  libcurl3-gnutls libcurl4 libnss-myhostname libpam-systemd
  libpython3.7-minimal libpython3.7-stdlib libssl-dev libssl1.1 libsystemd0
  libudev1 linux-libc-dev openssl python3.7 python3.7-minimal systemd
  systemd-sysv udev
 

@tionebrr
Source : https://www.rockchip.fr/RK3399 datasheet V1.8.pdf
 
1.2.1 Microprocessor
 Dual-core ARM Cortex-A72 MPCore processor and Quad-core ARM Cortex-A53MPCore processor, both are high-performance, low-power and cached application processor
 Two CPU clusters.Big cluster with dual-coreCortex-A72 is optimized for high-performance and little cluster with quad-core Cortex-A53 is optimized for low power.
<... >
 PD_A72_B0: 1st Cortex-A72 + Neon + FPU + L1 I/D cache of big cluster
 PD_A72_B1: 2nd Cortex-A72+ Neon + FPU + L1 I/D cache of big cluster
<... >
 PD_A53_L0: 1st Cortex-A53 + Neon + FPU + L1 I/D Cache of little cluster
 PD_A53_L1: 2nd Cortex-A53 + Neon + FPU + L1 I/D Cache of little cluster
 PD_A53_L2: 3rd Cortex-A53 + Neon + FPU + L1 I/D Cache of little cluster
 PD_A53_L3: 4th Cortex-A53 + Neon + FPU + L1 I/D Cache of little cluster
<...>
 
3.2 Recommended Operating Conditions
The below table describes the recommended operating condition for every clock domain.
Table 3-2 Recommended operating conditions
Parameters Symbol Min Typ Max Units
Supply voltage for Cortex A72 CPU BIGCPU_VDD 0.80 0.90 1.25 V
Supply voltage for Cortex A53 CPU LITCPU_VDD 0.80 0.90 1.20 V
Max frequency of Cortex A72 CPU 1.8 GHz
Max frequency of Cortex A53 CPU 1.4 GHz
 

Mine is still crashing like a clockwork every 24 hours and leaves me generally with a corrupted OS and data.
 
I know you are a small team and you had to takle many obstacles to release the Helios64, believe me im a fan of your work, product and armbian in general, i m aware of the effort every involved person puts into this project.
 
But i would appreciate a bit more news about the current status of developement.
 
As far as i can see there is no status or developement overview on the current issues, not on your blog nor on twitter.
 
The only information we get are in various topics across the forum on armbian.
 
Is there a possibility to let us know more about the ongoing research and inform us about the progress and persued assumed solutions?
 
Also I wonder if those issues are genreal rk3399 gonvernor etc. problems, or if it applies specifically for the Helios64?
 
Thank you in advance for your reply.

Yeah recovering would require you to boot the board from microSD card (using any recent image for Helios64). Then you will need to use the right tool (e.g dd or fsarchiver) to write your system backup on the M.2 SSD.
 
If you use eMMC only for u-boot then unlikely to get corrupted and would be easy to restore even without a backup since it's just u-boot there. But it cost you nothing you backup the 1st 100MB of the eMMC with dd.
 
This is the kind of question that would require some guideline at some point on our wiki ;-)

We will provide soon instruction on how to update SATA controller (JMB585) firmware with the latest version. Let see if it has positive impact or not.
 
For the new revision we will reinforce noise filtering on the SATA controller in case this is part of the root cause in some cases.

I have disabled zram, as it was suggested by someone on Reddit.
 
I am now running the latest kernel, but absolutely no kernel in my history of this thing has been stable.

I got the following serial console the last time it crashed (But could not edit my post due to limits):
 
[10105.431800] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: rcu_sched_clock_irq+0x7a4/0xce0 [10105.432752] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G C 5.10.21-rockchip64 #21.02.3 [10105.433526] Hardware name: Helios64 (DT) [10105.433872] Call trace: [10105.434093] dump_backtrace+0x0/0x200 [10105.434418] show_stack+0x18/0x68 [10105.434714] dump_stack+0xcc/0x124 [10105.435016] panic+0x174/0x374 [10105.435288] __stack_chk_fail+0x3c/0x40 [10105.435626] rcu_sched_clock_irq+0x7a4/0xce0 [10105.436004] update_process_times+0x60/0xa0 [10105.436373] tick_sched_handle.isra.19+0x40/0x58 [10105.436778] tick_sched_timer+0x58/0xb0 [10105.437118] __hrtimer_run_queues+0x104/0x388 [10105.437502] hrtimer_interrupt+0xf4/0x250 [10105.437861] arch_timer_handler_phys+0x30/0x40 [10105.438258] handle_percpu_devid_irq+0xa0/0x298 [10105.438659] generic_handle_irq+0x30/0x48 [10105.439012] __handle_domain_irq+0x94/0x108 [10105.439384] gic_handle_irq+0xc0/0x140 [10105.439715] el1_irq+0xc0/0x180 [10105.439995] arch_cpu_idle+0x18/0x28 [10105.440310] default_idle_call+0x44/0x1bc [10105.440665] do_idle+0x204/0x278 [10105.440950] cpu_startup_entry+0x28/0x60 [10105.441298] secondary_start_kernel+0x170/0x180 [10105.441700] SMP: stopping secondary CPUs [10105.442057] Kernel Offset: disabled [10105.442365] CPU features: 0x0240022,6100200c [10105.442740] Memory Limit: none [10105.443021] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: rcu_sched_clock_irq+0x7a4/0xce0 ]---
root@helios64:~# uname -a
Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux
root@helios64:~#
 
my armbian monitor:
http://ix.io/2U0J

@JMCC Thanks for the hint. i'll take a look.

In case of disk failure... just copying the filesystem to a backup, which then is copied to a new disk, which is inserted to slot A and booted. It will not boot. I presume so, by the fact that I tried to repartition/resize that disk holding system in slot A and it failed to boot after that. So, there is something more involved, hints are visible by looking at mounts. I would like to get the system backupped. Know the needed bits and tweaks, so that I know that I can do it and it will work, in case of disk failure.

Some more mirror updates:
By default, geoip support will redirect you to the best regional mirror pool.   (it's not perfect) Armbian-config now supports mirror selection: depending on version of Armbian config you may need to first do code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } apt update && apt install jq -y to install missing dependency   Armbian-config -> personal -> mirrors FOSSHOST mirror changes: location specific Fosshost mirror domains are deprecated: us.mirrors.fossho.st us.mirorrs.fosshost.org uk.mirrors.fossho.st uk.mirrors.fosshost.org FOSSHOST is now front-ending mirrors via the Fastly CDN see announcement from FOSSHOST.org mirrors.fosthost.org and mirrors.fossho.st are all that is needed to use their Fastly CDN Because Fastly is an on-demand caching CDN, performance will vary by your physical location.  Some may experience a positive improvement, or some may experience a negative improvement. The FOSSHOST apt mirrors are most effective for those in Regions with poor internet connectivity and outside of greater Europe Currently our automatic redirect has FOSSHOST  in the round-robin pool for North America and Asia.   Those in China may want to use a China Specific mirror.  Those in Asia outside of China will likely benefit for choosing the Fastly mirror I recommend using the existing Armbian EU mirrors for those within Greater EU with good internet connectivity. Since these Mirrors are caching, they work best when under high utilization. Ex: Great for apt indexes and common packages, extremely popular image downloads during release.   Less ideal for unpopular images which won't be cached.  
We're very grateful for all our partners providing mirrors--and their extreme generosity in providing a vast amount of space.  We're always trying to optimize our package and image distribution.   Armbian's a unique project as our release output produces over 400 system images.   Seeding and distribution is significant.
 
If you have any questions or thoughts.. please share on this thread!
 
lanefu
 
 

@gprovost
Been Running stable since  21.02.3 Buster.
cat /etc/default/cpufrequtils
ENABLE=true
MIN_SPEED=408000
MAX_SPEED=1800000
GOVERNOR=ondemand
 
No VDD tweaks.
 

 

Could you guys update to latest  kernel (linux-image-current-rockchip64_21.02.3_arm64 / LK 5.10.21)  and revert to ondemand governor with the full range of frequency in case you were on performance mode.
 
Also remove any vdd voltage tweak you might have put in /boot/boot.cmd. If you had vdd tweak you will need to rebuild u-boot boot script after removing the lines in /boot/boot.cmd
 
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr  
Let us know how the new kernel improves the stability.

Hi folks,
 
just a heads up in this thread (maybe related to others experiencing boot issues with Helios64 and OMV5):
 
If you use the setup: OMV5, Multiple Hdds, LUKS encryption + UnionFS
 
then it is very likely that the machine does not come up instead is booting into revocery mode. That's because it cannot find any mountpoints because of LUKS. In order to get the helios booting again you have to add a "nofail" into the mergerfs option.
 
Unfortunately the merferfs pool does not getting mounted automatically once you decrypted the hdds within LUKS Plugin. That's a bit of a nuisance but it is bearable if you do not boot your machine every day. In my case I had to remove the nofail, the mergerfs did mount immediately and then I did put the nofail in again. There might be a more elegant possibility but at least it is a remedy to get the helios working again.
 
Jump over to the OMV-forums and do a search for LUKS + UnionFS + nofail and you find several threads about that issue.
 
I have no idea if it is better to swith to the merferfsfolder plugin because I have no knowledge so far if I just can change the plugins without any errors.

Yes

Whilst i'm satisfied with my Helios64 as well, i would have liked:
the original RK3399Pro as the NPU would have been useful in tensorflow for Photoprism (as a Google photos replacement). RK3588 would be even nicer but everyone is waiting on that chip more RAM, once Photoprism indexes photos, it easily runs out of memory. I limit the memory in docker now but its not ideal. Granted, there is an issue on their code so i just keep the container restarted each night NVMe for fast disk access Better HDD trays (already mentioned) the screw eyelets for the backpanel (1st pic below) not to be directly aligned with the eyelets for the backplane (2nd pic below) for easier assembly.

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.