Igor

It was a bug. apt update and apt upgrade will fix it.

Properly operational DVFS on H6 is already in Armbian 5.4.y ... But yes, we should bump things up. Not sure if this is the right moment to go for 5.8. ... but - is it safe to move 5.7.y to current?

Most likely not developed / ported to a modern kernel. In case you need this function, you need to remain on old stock kernel. Or contribute to the development.

In embedded world we compile on the desktop even its also possible native. Recommended way: https://docs.armbian.com/Developer-Guide_Build-Preparation/ Do what you have to do, copy resulting kernel to the board (image and dtb), install (dpkg -i *.deb) and reboot. Remember to push changes to Armbian, so that the next upgrade will contain your work otherwise you will need to repeat this over and over again on each regular kernel upgrade ...

On Linux we have a daemon but it doesn't work properly on ARM. Perhaps now it does ... would need to check. That's why Armbian have this: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization but it seems it doesn't work.

For Armbian, you need to test one image and without logs its hard to diagnose. armbianmonitor -u I also made our performance / stress test and there are no anomalies: https://dl.armbian.com/_test-reports/2020-06-23_06.42.28.html

19:56:17 up 1 day, 3:50, 1 user, load average: 15.19, 14.47, 10.24 and you also ran out of memory. I don't see in the log which process is eating resources ... can you run top or similar when you experience this slowness?

Validation status is gone: - if you add valuable content - if you support the project https://forum.armbian.com/subscriptions/ - automatically after 7 days

We host wireguard-tools package since they are not a part of a standard Debian. They have been updated now ... but you don't need this package because Wireguard is build into the kernel. Debian "apt install wireguard" is written badly: root@odroidc4:/home/igorp# apt install wireguard Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: dkms linux-image-4.19.0-9-rt-arm64 linux-image-rt-arm64 wireguard-dkms Suggested packages: python3-apport menu linux-doc-4.19 debian-kernel-handbook Recommended packages: fakeroot linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers firmware-linux-free apparmor The following NEW packages will be installed: dkms linux-image-4.19.0-9-rt-arm64 linux-image-rt-arm64 wireguard wireguard-dkms 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Need to get 40.9 MB of archives. After this operation, 228 MB of additional disk space will be used. Do you want to continue? [Y/n] n Abort. On Armbian you only need to configure Wireguard. You don't need any of those packages and 228MB of waste.

You are helping yourself while we don't know yet if we can afford to support this hw / your attempt - for dealing with a board that makes some noise and have some users we easily lost 20.000 - 30.000 EUR per year. Some initial work was already done, but it's not too late to unplug and go slow as everyone else. Here is a test you have to pass: https://github.com/armbian/build#support

By asking and if there will be some left ... V1.0 has some troubles and we are working on a redesign https://github.com/armbian/mpads When we will get a new batch (ETA= unknown) I will send you one.

Not anymore.

I have no info.

Thank you! You got a PM with detailed instructions.

How your tool row looks like? Mine:

In case of Focal, this was probably the problem - recreated initrd was sometimes corrupted and its been recently fixed by changing compression method. You need to re-download image. v20.05.4

Start here: https://docs.armbian.com/User-Guide_Getting-Started/ and here: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/

This is the case with most of hardware - hardware support is based on some ancient u-boot where similar hardware was brought up. They (chip maker) extend it for the new chip. Then chip integrator ads its own changes deploys boot loader and forget about. The same is with all / most others: https://github.com/hardkernel/u-boot/tree/odroidc-v2011.03 https://github.com/radxa/u-boot https://github.com/orangepi-xunlong/OrangePiH3_uboot Keeping things up to date is extremely expensive and only possible if we and community around this particular hw covers up. We provide mainline u-boot wherever this is possible, but we simply decided to skip imx8 boards since we have no resources to sponsor while not a single cent coverage for this job ever came from users nor from the vendor. Its a lot of work and we only lost huge amount of time. You don't even notice nor say thanks or give anything in return. As you need them (Microsoft owned boot loader / RTOS) to boot Raspberry Pi and lots of others. Welcome to the "open source". Reverse engineering is usually a part of the job to get this hardware to the mainline. Blobs are there to give them control over the hw. Its a private development kernel, a raw material. Far away from mainline Linux. Its a Linux where this device was brought up. This is the latest drop of development kernel which is developed by NXP for their customers (Solidrun). Due to the licence demands, they have to release the code. In whatever quality it is. Getting from here to proper stable mainline can easily cost a million. (for this particular chip I don't know how good or bad support actually is and if you need 1/4, 1/2 of that million. To know that its yet another investment into the R&D I have no plan to add on the top of existing jobs. https://www.armbian.com/nanopi-r2s/ https://www.armbian.com/nanopi-r1/ https://www.armbian.com/orange-pi-r1/ ... or do something to spark development, either commercially or non-commercially.

Personal support which covers laziness is only paid: https://github.com/armbian/build#support You can start here: https://forum.armbian.com/subscriptions/ or just study the documentation. Code is open, so you can see how things works.

As it is done, safe. But it doesn't look clean. I agree with that. One option would be to syncing Debian Chromium to our Focal repository, but we have no established process for such things and doing this manually is not an option. Fastest option prevailed which is why its called "workaround". There is little to no development around the desktop and I will not do anything about. I can't. "You" can ... if this bothers you hard enough. Other option is to ship Focal without Chromium or with snapped Chromium which opens other troubles and additional system refactoring.

Read my post again - you didn't follow my 1st advise: Likewise. https://github.com/armbian/build#support https://forum.armbian.com/subscriptions/

This disk is not mPCI but mSATA. It can't work.

How?

And you are willing to cover yearly support costs? All code and all transactions are public.

https://github.com/armbian/build/pull/2024#issuecomment-644629168