• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    hartraft reacted to SIGSEGV in We want YOU for armbian   
    Hello @Igor, @Werner,
    I'm open to collaborating to the armbian project, my background is on software development and system administration and I have a small Helios64 to test things with.
  2. Like
    hartraft reacted to Heisath in eMMc drive filled to 90% overnight and no idea why.   
    might need to do 
    sudo ncdu -x /  
    Then you can navigate through a tree-view, and figure out where the size comes from. 
    As a general step-by-step guide:
    - use "df -h" (or something like that), to figure out which device / mountpoint is getting full
    user@builder:~$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 1,6G 1,2M 1,6G 1% /run /dev/sda3 79G 31G 44G 41% / tmpfs 7,9G 0 7,9G 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup /dev/sda2 94M 5,2M 89M 6% /boot/efi tmpfs 1,6G 136K 1,6G 1% /run/user/1000 We now know, /dev/sda3 is fullest, and is mounted on /
    - next use "sudo ncdu -x /" to check the contents / where the space goes:
    ncdu 1.15.1 ~ Use the arrow keys to navigate, press ? for help --- / -------------------------------------------------------------------------- 17,2 GiB [##########] /home 8,5 GiB [#### ] /usr 2,0 GiB [# ] swapfile 1,0 GiB [ ] /var 760,0 MiB [ ] /root 508,4 MiB [ ] /opt 251,1 MiB [ ] /boot 11,6 MiB [ ] /etc 68,0 KiB [ ] /tmp 36,0 KiB [ ] /snap e 16,0 KiB [ ] /lost+found 8,0 KiB [ ] /media e 4,0 KiB [ ] /srv e 4,0 KiB [ ] /mnt e 4,0 KiB [ ] /cdrom @ 0,0 B [ ] libx32 @ 0,0 B [ ] lib64 @ 0,0 B [ ] lib32 @ 0,0 B [ ] sbin @ 0,0 B [ ] lib @ 0,0 B [ ] bin Total disk usage: 30,1 GiB Apparent size: 28,8 GiB Items: 789697 We see that most storage goes to /home, /usr and the swapfile.
    As the interface is interactive, you can just navigate down the folder structure to find the culprit.
  3. Like
    hartraft reacted to halfa in Armbian 21.05.2 Focal with Linux 5.10.35-rockchip64: fancontrol die in error, fans not spinning   
    For anybody passing by, the issue is due to the fact that for some reason the armbian-bsp-cli-helios64 package for 21.05.2 (EDIT: clarify, 21.05.1 is fine as seen below) was build with the old udev rule (for 4.4 kernels):
    $ ls armbian-bsp-cli-helios64_21.05.1_arm64.deb\data.tar\.\etc\udev\rules.d\ 10-wifi-disable-powermanagement.rules 50-mali.rules 50-rk3399-vpu.rules 50-usb-realtek-net.rules 70-keep-usb-lan-as-eth1.rules 90-helios64-hwmon.rules 90-helios64-ups.rules $ ls armbian-bsp-cli-helios64_21.05.2_arm64.deb\data.tar\.\etc\udev\rules.d\ 10-wifi-disable-powermanagement.rules 50-mali.rules 50-rk3399-vpu.rules 50-usb-realtek-net.rules 70-keep-usb-lan-as-eth1.rules 90-helios64-hwmon-legacy.rules 90-helios64-ups.rules The content of the 90-helios64-hwmon.rules is indeed correct and match the 5.10.x kernel device tree: https://github.com/armbian/build/blob/master/packages/bsp/helios64/90-helios64-hwmon.rules
    I tried reversing the build system to find why the old file was used instead of the other, but the best I could find is
    # in config/sources/families/include/rockchip64_common.inc 395 ### Fancontrol tweaks 396 # copy hwmon rules to fix device mapping 397 if [[ $BRANCH == legacy ]]; then 398 install -m 644 $SRC/packages/bsp/helios64/90-helios64-hwmon-legacy.rules $destination/etc/udev/rules.d/ 399 else 400 install -m 644 $SRC/packages/bsp/helios64/90-helios64-hwmon.rules $destination/etc/udev/rules.d/ 401 fi  
  4. Like
    hartraft reacted to halfa in Armbian 21.05.2 Focal with Linux 5.10.35-rockchip64: fancontrol die in error, fans not spinning   
    Posting here following what was recommended on twitter.
    After updating my helios64 earlier this week and rebooting to get the new kernel, I realized it was suspiciously silent.
    A quick check to sensor temps readings and physical check made me realize the fan were not spinning.
    After a quick read on the wiki, I checked fancontrol which was indeed failing:
    root@helios64:~ # systemctl status fancontrol.service ● fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/fancontrol.service.d └─pid.conf Active: failed (Result: exit-code) since Fri 2021-05-28 00:08:13 CEST; 1min 42s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 2495 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS) Process: 2876 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE) Main PID: 2876 (code=exited, status=1/FAILURE) May 28 00:08:13 helios64 fancontrol[2876]: MINPWM=0 May 28 00:08:13 helios64 fancontrol[2876]: MAXPWM=255 May 28 00:08:13 helios64 fancontrol[2876]: AVERAGE=1 May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: At least one referenced file is missing. Either some required kernel May 28 00:08:13 helios64 fancontrol[2876]: modules haven't been loaded, or your configuration file is outdated. May 28 00:08:13 helios64 fancontrol[2876]: In the latter case, you should run pwmconfig again. May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Failed with result 'exit-code'.  
    Basically fancontrol expect a device in /dev to read the sensors value from, and that device seems to be missing. After a bit of poking around and learning about udev, I managed to manually solve the issue by recreating the device symlink manually:
    /usr/bin/mkdir /dev/thermal-cpu/ ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input systemctl restart fancontrol.service systemctl status fancontrol.service Now digging more this issue happen because udev is not creating the symlink like it should for some reason. After reading the rule in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and a bit of udev documentation, I managed to find how to test it:
    root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] Reading rules file: /etc/udev/rules.d/90-helios64-hwmon-legacy.rules Reading rules file: /etc/udev/rules.d/90-helios64-ups.rules [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0 USEC_INITIALIZED=7544717 run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0 ' <-- something is wrong here, there is no target Unload module index Unloaded link configuration context. After spending a bit more time reading the udev rule, I realized that the second argument was empty because we don't match the ATTR{type}=="soc-thermal" condition. We can look up the types like this:
    root@helios64:~ # find /sys/ -name type | grep thermal /sys/devices/virtual/thermal/cooling_device1/type /sys/devices/virtual/thermal/thermal_zone0/type /sys/devices/virtual/thermal/cooling_device4/type /sys/devices/virtual/thermal/cooling_device2/type /sys/devices/virtual/thermal/thermal_zone1/type /sys/devices/virtual/thermal/cooling_device0/type /sys/devices/virtual/thermal/cooling_device3/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert1/type root@helios64:~ # cat /sys/devices/virtual/thermal/thermal_zone0/type cpu <-- we where expecting soc-thermal and after rewriting the line with the new type, udev is happy again
    # Edit in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and add the following line after the original one ATTR{type}=="cpu", ENV{HWMON_PATH}="/sys%p/temp", ENV{HELIOS64_SYMLINK}="/dev/thermal-cpu/temp1_input", RUN+="/usr/bin/mkdir /dev/thermal-cpu/" root@helios64:~ # udevadm control --reload root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0/temp HELIOS64_SYMLINK=/dev/thermal-cpu/temp1_input USEC_INITIALIZED=7544717 run: '/usr/bin/mkdir /dev/thermal-cpu/' run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input' Unload module index Unloaded link configuration context. Apparently for some reason the device-tree changed upstream and the thermal type changed from soc-thermal to cpu?
  5. Like
    hartraft reacted to wurmfood in Kobol Team is taking a short Break !   
    Enjoy your well deserved break. It's been a rough year for all of us, but I will saying that getting my Helios64 set up and running has been a welcome diversion and bright spot during this time.
    Thanks all and I can't wait to see what comes next.
  6. Like
    hartraft reacted to gprovost in Kobol Team is taking a short Break !   
    It’s been 3 months since we posted on our blog. While we have been pretty active on Armbian/Kobol forum for support and still working at improving the software support and stability, we have been developing in parallel the new iteration of Helios64 around the latest Rockchip SoC RK3568.
    However things haven’t been progressing as fast as we would have wished. Looking back, 2020 has been a very challenging year to deliver a new product and it took quite a toll on the small team we are. Our energy level is a bit low and we still haven’t really recovered. Now with electronic part prices surge and crazy lead time, it’s even harder to have business visibility in an already challenging market.
    In light of the above, we decided to go on a full break for the next 2 months, to recharge our battery away from Kobol and come back with a refocused strategy and pumped up energy.
    Until we are back, we hope you will understand that communication on the different channels (blog, wiki, forum, support email) will be kept to a minimum for the next 2 months.
    Thanks again all for your support.
  7. Like
    hartraft reacted to tkaiser in How to provide and interpret Debug output   
    Armbian implements some basic 'system logging' at every startup and shutdown and contains a little utility to provide this collected information combined with some more useful debug info from user installations. All that's needed is executing 'sudo armbianmonitor -u' (or armbian-config --> Software --> Diagnostics) and then all this support related information is uploaded to an online pasteboard service automagically (see example output) 

    How to interpret this wall of text? The output is best read from bottom to top since the most important information is collected during upload:
    At the bottom /proc/interrupts contents to check for IRQ affinity problems (interrupt collissions on some CPU cores negatively affecting performance) Then last 250 lines dmesg output are included. Here you might find important information wrt the last (kernel) events that happened on the machine uptime output including average load statistics (1, 5 and 15 min) free output telling how much physical memory is available and how much swap and/or zram is used (you need to look directly above whether zram is active or not to interpret the 'Swap:' line) vmstat output contains virtual memory usage information since last reboot iostat output contains the same but allows for a 'per device' view since all devices are listed with individual statistics (so it's easy to spot IO bottlenecks by looking at these numbers and also looking at %iowait value) 'Current system health' displays what the system is actually doing while uploading the debug log (on systems where DC-IN monitoring is available also allowing for underpowering diagnosis -- if you read here numbers below 5.0V stop reading the log and tell the user to fix his underpowering issues first) In case the installation has been moved from SD card to other storage nand-sata-install.log will be included in the output 'Loaded modules' allow to look for module related problems If it's an Allwinner board running legacy kernel the whole script.bin contents are included 'Installed packages' shows version numbers of relevant Armbian packages 'Group membership of' should list all groups the user is member of. If this line is missing ignore the whole contents and ask the user to re-submit debug info, this time doing it correctly not as root but using 'sudo armbianmonitor -u' (group memberships are important to understand certain problems, eg. users not being member of audio group won't have success getting noise out of their devices) If the board is PCIe capable list of attached PCIe devices is included The lsusb output lists all connected USB devices and also information about speed (12M, 480M, 5000M) and protocol/connection details (mass-storage vs uas for example) If the user installed the lshw utility and verbosity is set to 4 or above in /boot/armbianEnv.txt some more disk related information will be included  
    Important: The debug output also contains all collected support files that follow this naming scheme: /tmp/armbianmonitor_checks_* -- so if a user complains about 'transmission so slow' or 'latest files are always missing' ask him to run 'armbianmonitor -c /path/to/torrent-storage' and afterwards 'sudo armbianmonitor -u' without a reboot in between since then the checking results will also be contained.
    Everything above of this information at the output's bottom is result of regular logging at startup and shutdown (the contents of /var/log/armhwinfo.log). 
    At startup the following items are logged: dmesg output, /etc/armbian-release and /boot/armbianEnv.txt contents, lsusb and lscpu output, /proc/cpuinfo and /proc/meminfo contents, network interface information, available partitions and filesystems, on Allwinner boards where /boot/script.bin points to, some metadata information for all MMC media connected to the host (eg. SD card and/or eMMC) and some system health information.
    At shutdown iostat, vmstat and free output are added to /var/log/armhwinfo.log as well as the last 100 lines from dmesg output. If these '### shutdown' entries are missing after reboots the system crashed while shutting down.
  8. Like
    hartraft reacted to piter75 in How to make a SD card bootable with U-Boot   
    @Chalix You have done quite a research already
    Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
    U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
    You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
    The recipe to write the images to device (more or less) is to be found here.
  9. Like
    hartraft reacted to lyuyhn in Information on Autoshutdown / sleep / WOL?   
    Any news on this side? I'm really looking forward to be able to suspend and use wol!
  10. Like
    hartraft reacted to Polarisgeek in Does anyone actually have a stable system?   
    Just wanted to add my experience as maybe someone can get something semi-useful out of it. 
    I started out with 3 - 4TB drives with 2 of them in Raid 1 and the 3rd on it's own.  I installed OMV and CUPS on a Micro SD card.  Even from the very beginning, I always had trouble restarting the system.  Sometimes it would boot after 3 tries, sometimes it would take 20 tries.  I watched and it was never the same issue twice that caused the boot failure.  I removed drives, plugged in different combo's, several fixes on the forums, anything I could think of and nothing really seemed to make a difference.  The good news was that once it was up and running, it ran great.  I had 2 months of uptime with no issues.  Then i'd run an update and have a heck of a time getting it restarted.  Just figured that's the way it was and hoped things would get better as the software matured.  
    I'm now on my second iteration with 5 - 14TB (Thanks Uncle Joe) drives in Raid 6.  After 2 months, i've had 2 random crashes for unknown reasons, one at 3 days and the other after 7 days.  Aside from running updates and rebooting, it's been running solid for me.  I'm only running OMV and a CUPS server.    Getting to this point was a huge PITA.  I spent nearly 8 hours trying to get it up and running over the course of a Sunday.  It seemed like no matter what I did, i'd have a Kernel Panic during the setup process, and then the system wouldn't boot at all giving different errors every time.  So i'd re-download the image, and attempt to install from scratch again.  I played with installing different options, in different sequences (as much as possible), without much luck.  I verified the download every time.  I finally tried using USBImager, as an alternative to BalenaEtcher, and found that wring to the sdcard seemed better and the installation seemed better, although it did panic a couple times.  Once I finally got it running, I gave it some time, installed all the updates, reboot several times in between setting up OMV for testing and have been happy with it since.  The biggest difference now is that I don't worry about rebooting as it comes right up the first time instead of several tries like the first iteration.  
    Overall, i've been happy with mine.  I'm very new to the Linux environment so it's been fun learning a new thing.  Keep up the great work!
  11. Like
    hartraft got a reaction from gprovost in Does anyone actually have a stable system?   
    My system has been "stable" running the LK 5.9. I updated to 5.10 in the past but had issues with stability under small load, not rebooting through omv etc. so I went back to the previous version. 
    Running MergerFS / SnapRAID / LUKS on Seagate Ironwolves with the 1.2ghz frequency 
    $ uname - a
    Linux helios64 5.9.14-rockchip64 #20.11.3 SMP PREEMPT Fri Dec 11 20:50:18 CET 2020 aarch64 GNU/Linux
    $ uptime
     20:25:53 up 67 days, 19:23, 2 users, load average: 0.08, 0.12, 0.12
    I'm sticking with this until things get clearer but would like to get full use of my NAS hardware... 
  12. Like
    hartraft reacted to aprayoga in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    Hi all, you could download the SATA firmware update at https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_update_00021_200624.img.xz
    1. Download the sd card image
    2. Flash the image into a microSD card
    3. Insert microSD card into Helios64 and power on. Helios64 should automatically boot from microSD. If Helios64 still boot from eMMC, disable the eMMC 
    4. Wait for a while, the system will do a reboot and then power off if firmware flashing succeed.
       If failed, both System Status and System Fault LEDs will blink
    5. Remove the microSD card and boot Helios64 normally. See if there is any improvement.
    Our officially supported stock firmware can be downloaded from https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_factory_00020_190702.img.xz. If there is no improvement on newer firmware, please revert back to this stock firmware.
    e5dfbe84f4709a3e2138ffb620f0ee62ecbcc79a8f83692c1c1d7a4361f0d30f *Helios64_SATA_FW_factory_00020_190702.img.xz 0d78fec569dd699fd667acf59ba7b07c420a2865e1bcb8b85b26b61d404998c5 *Helios64_SATA_FW_update_00021_200624.img.xz  
  13. Like
    hartraft reacted to aprayoga in UPS service and timer   
    @SIGSEGV @clostro the service is triggered by udev rules.
    @wurmfood, I didn't realize the timer fill the the log every 20s. Initial idea was one time timer, poweroff after 10m of power loss event. Then it was improved to add polling of the battery level and poweroff when threshold reached. Your script look good, we are considering to adapt it to official release. Thank you
  14. Like
    hartraft reacted to P.P.A. in Understanding Hardware-Accelerated Video Decoding   
    I've taken peeks at threads related to hardware decoding (of H.264 and HEVC, mainly) on Allwinner and Rockchip platforms on and off, sometimes dabbled in trying and failing to implement solutions recommended there. Being a complete amateur, I find the topic very opaque and confusing, with various different components that need to interface with each other, be patched in sync, and sometimes change drastically between kernel versions, etc. Today I sat down and read up on these subjects, scouring wikis, documentation, this forum, and assorted other sources to try and understand how this works. In this post I will attempt to compile what I've learned on the different software components involved, their relationships, their current status, and solutions to the problem. I hope people more knowledgeable will correct me when I get something wrong or cite outdated information. Stuff which I am highly uncertain of I will print in italics.
    (This post is going to focus on mainline implementations of Cedrus/Allwinner, I haven't looked into Hantro/Rkvdec/Rockchip specifics yet. I will speak only of H.264 and H.265/HEVC; I don't understand the high/low stuff and didn't pay attention to other codecs.)
    Basics: Video codecs like H.264, H.265/HEVC, MPEG-2, etc. are standardised methods which serve to more efficiently encode and decode videos, reducing their filesize. Software en-/decoding is very CPU-intensive. Modern GPUS and ARM SoCs therefore contain specialised hardware (VPUs) to delegate these tasks to. Working hardware decoding is particularly important for underpowered ARM CPUs.
    Drivers: Topmost in the stack are the VPU drivers. These are Sunxi-Cedrus/Cedrus V4L2 M2M and Cedar [Is this the legacy one?] on Allwinner; Hantro and Rkvdec on Rockchip. These are all still in development, but Cedrus already fully supports H.264, and partially supports HEVC, and is already usable in the mainline kernel.
    APIs: In order for anything (userspace APIs, libraries) to make use of the VPU drivers, you need backends/APIs. For Cedrus, there is the unmaintained libva-v4l2-request backend which implements VA-API, the legacy VDPAU implementation libvdpau-sunxi, and as of kernel version 5.11, H.264 has been merged into the uAPI headers. Different applications may make recourse to one or another of these APIs.
    Libraries: FFmpeg and GStreamer. provide libraries and APIs of their own to other applications but can (importantly!) also output directly to the framebuffer. FFmpeg must be patched to access either libva-v4l2-request or the Cedrus driver headers. GStreamer directly accesses kernel headers since 1.18 (works on 5.9, not on 5.10; 1.20 will support 5.11.)
    Media players: mpv and depends on FFmpeg for hardware acceleration (and must be patched together with it). VLC can be set to access libva-v4l2-request directly. Kodi 19.0+ supports hardware acceleration out of the box without any out-of-tree patches.
    Display server: An additional complication is drawing the output of any of the above on screen. Most successful implementations I've seen bypass X11 and either output directly to the framebuffer or force a plane/display layer on top of any X windows. Wayland apparently makes this easier by allowing applications to use their own DRM planes, but this hasn't been explored much yet. Kodi 19.0 works with all three windowing systems (X, Wayland, and gbm).
    Codec status:
    Taken from the LibreElec thread (which reflects LibreElec's status and is ahead of what works elsewhere, but outlines hardware limitations):
    Many people have managed to make it work on their machines using different approaches. Note that some of these solutions are one or two years old, and kernel developments since may have changed the situation. Ordered from newer to older:
    LibreElec – kernel + ffmpeg + Kodi: LibreElec is a Just-Enough-OS with the sole purpose of running Kodi, a media player. It's at the bleeding edge and usually implements codecs and features well before mainline or other distros. It achieves this by heavily patching everything up and down the stack, from the Linux kernel over FFmpeg to Kodi itself. These patches could all be applied to an Armbian build, but there are a lot of them, they're poorly documented, and you'd need to dig into their github to understand what they all do. LibreElec runs Kodi directly without a desktop. kodi-gbm is a package that can be installed on Armbian and functions similarly.
    Key contributors to the project are @jernej and @Kwiboo, who sometimes post about their work here (and have been very helpful with questions, thank you). @balbes150 includes some of LibreElec's patches in his Armbian-TV builds, but I don't know which.
    Kodi 19.0: 
    LibreElec patches + mpv:
    @megous – Kernel 5.11 + GStreamer: This implementation, done here on a PinePhone (A64), patches the 5.9 kernel and uses a recent version of GStreamer (1.18 and up), whose output is rendered directly to a DRM plane via kmssink. (No X or Wayland.)
    GStreamer 1.18 works with the 5.9 kernel. It does not work with 5.10, because of numerous changes to the kernel headers in this version. In 5.11 the H.264 headers were moved into the uAPI; the master branch of GStreamer reflects this, but there haven't been any releases with these patches yet. It'll probably be in repositories with GStreamer 1.20; until then you can build it from source.
    @Sash0k – patched libva-v4l2-request + VLC: This updates bootlin's libva-v4l2-request and follows the Sunxi wiki's instructions for enabling VLC to make use of it. It works on the desktop. This only works for H.264 and breaks HEVC. When I tried to replicate this approach on a recent Armbian build, I discovered that the h264.c files in the kernel (that libva-v4l2-request draws on) have changed considerably between 5.8 and 5.10, and I lack the understanding to reconcile libva-v4l2-request with them.
    @ubobrov – old kernel + libcedrus + libvdpau-sunxi + ffmpeg + mpv: This approach, which supports encoding decoding of H.264 uses the libvdpau-sunxi API and ports the legacy driver to mainline as a loadable kernel module and if I understand it correctly, ubobrov ported a legacy feature to mainline. In the post quoted below the kernel is 4.20, but the same method has been successfully applied to 5.7.8 by another user. It requires that the board's device tree be patched, as documented in ubobrov's github repository.
    The summary seems to be that none of the current implementations on Allwinner boards really play nice with X or desktop sessions, and it's best to output directly to the framebuffer. Kwiboo has forked FFmpeg and mpv to make good use of new and unstable kernel features/hardware acceleration which will take a while to make their way upstream. The recent 5.11 move of stateless H.264 out of staging and into the uAPI should facilitate further developments.
    I intend to try some of these things in the nearer future. Thanks to everyone who works on mainlining all of this VPU stuff, and to users here who contribute solutions and readily & patiently answer questions (Jernej especially). I hope I didn't post any falsehoods out of ignorance, and welcome any corrections.
    Other related threads here:
  15. Like
    hartraft reacted to endecotp in Differences Between Armbian and Debian   
    I was really just "wondering out loud" about whether you could solve the problem of having Armbian-specific tools that need maintenance by instead re-using the existing, and maintained, functionality in Debian Installer.
    In the past I've used Martin Michlmayr's installer for the QNAP-TS119, which works more like this.  I think one of the installation methods for the NSLU2 was also based on a modified Debian Installer.
    Anyway just a thought.
    I've been finding a few more of these differences.  For example, find /etc -name '*armbian*'.  It would be useful to have a list, maybe a diff of the filesystems trees with an unmodified Debian or something.  I'm pretty familiar with how vanilla Debian works and I worry that the superficial similarity is misleading.
    This is just some honest feedback from an old Debian and ARM user but new Armbian user.  I appreciate that resources are limited; I know how that feels.  Thanks again for all the hard work.
  16. Like
    hartraft reacted to kgblack in Differences Between Armbian and Debian   
    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
  17. Like
    hartraft reacted to allen--smithee in Helios64 - freeze whatever the kernel is.   
    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
  18. Like
    hartraft reacted to Vin in Helios64 - freeze whatever the kernel is.   
    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.
  19. Like
    hartraft reacted to gprovost in Image Backup/Restore from Boot(Emmc)+System(M.2-SSD)   
    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 ;-)
  20. Like
    hartraft reacted to gprovost in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    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.
  21. Like
    hartraft reacted to dieKatze88 in How to do a full hardware test?   
    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
    my armbian monitor:
  22. Like
    hartraft reacted to aprayoga in RK3399 Legacy Multimedia Framework   
    @JMCC Thanks for the hint. i'll take a look.
  23. Like
    hartraft reacted to 0utc45t in Backup method for system installed on SSD (slot1)   
    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.
  24. Like
    hartraft reacted to lanefu in Regional Armbian Apt mirrors   
    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!
  25. Like
    hartraft reacted to slymanjojo in Helios64 - freeze whatever the kernel is.   
    Been Running stable since  21.02.3 Buster.
    cat /etc/default/cpufrequtils
    No VDD tweaks.