guidol

My Logitech C270 is found by armbian as UVC-camera:
 
# lsusb
Bus 005 Device 003: ID 046d:0825 Logitech, Inc. Webcam C270
 
[70995.555217] usb 5-1: new high-speed USB device number 3 using ehci-platform
[70995.931843] usb 5-1: New USB device found, idVendor=046d, idProduct=0825, bcdDevice= 0.12
[70995.931859] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=2
[70995.931867] usb 5-1: SerialNumber: 91E09A20
[70996.019769] uvcvideo: Found UVC 1.00 device <unnamed> (046d:0825)
[70996.133336] uvcvideo 5-1:1.0: Entity type for entity Extension 4 was not initialized!
[70996.133361] uvcvideo 5-1:1.0: Entity type for entity Extension 6 was not initialized!
[70996.133374] uvcvideo 5-1:1.0: Entity type for entity Extension 7 was not initialized!
[70996.133388] uvcvideo 5-1:1.0: Entity type for entity Processing 2 was not initialized!
[70996.133401] uvcvideo 5-1:1.0: Entity type for entity Extension 3 was not initialized!
[70996.133413] uvcvideo 5-1:1.0: Entity type for entity Camera 1 was not initialized!
[70996.133914] input: UVC Camera (046d:0825) as /devices/platform/soc/1c1d000.usb/usb5/5-1/5-1:1.0/input/input0
[70996.134373] usbcore: registered new interface driver uvcvideo
[70996.134383] USB Video Class driver (1.1.1)
[70997.474714] usb 5-1: set resolution quirk: cval->res = 384
[70997.476055] usbcore: registered new interface driver snd-usb-audio
 
System diagnosis information has been uploaded to http://ix.io/2mBL
 

Fixes pushed.

Pi-hole 5.0 is out of the BETA-Phase !   
and has NO PROBLEMS to be installed on armbian focal   
( System diagnosis information has been uploaded to http://ix.io/2mgt )
Just use:
sudo apt install php-cgi php-common php php-sqlite3 -y && curl -sSL https://install.pi-hole.net | bash 
 
Pi-hole v5.0 is here! (2020-05-10 )
see: https://pi-hole.net/2020/05/10/pi-hole-v5-0-is-here/#page-content
After a successful beta testing and development period (many thanks to the beta testers!),
we are pleased to announce the release of 5.0 for general availability!
 
Important notice (One-way-ticket)
There are many fundamental changes between Pi-hole 4.x and 5.0 – as such, this is strictly a one way operation.  
Once you move from 4.x to 5.0, there is no way to go back; you will need to restore from a backup. 
 
Pi-hole 4.x to 5.0
To update to this new version from version 4.x,  run pihole -up  
 
Pi-hole 5.0 BETA to new 5.0 release:
If you have been running the 5.0 beta release, run pihole checkout master 
to move from the beta to the master branch.

@linuxjosef did you try to set the cpu governor to "conservative"?

I have some board where ondemand not really throttle down, but with conservative they ever did throttle down

@Igor @RussianNeuroMancer for the chronyd-bug with ubunutu focal you could take a look here
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005
where they found a problem/solution:
* Chrony can't start on platorms that map gettimeofday to clock_gettime64() * This is due to syscall filtering being correct on some but generic enough to cover all areas. as a temporary solution they wrote:
 
So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter. I’ll send a patch upstream. Meanwhile, you can disable the seccomp filter by running (as root): # sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony # systemctl restart chrony.service BTW: My NanoPi A64 with  armbian focal  kernel 5.6.12 is running
chronyd v3.5-6ubuntu6 normally:

System diagnosis information has been uploaded to http://ix.io/2mbU 

Yesterday stress test https://dl.armbian.com/_test-reports/2020-05-15_19.45.41.html was fatal for OPi Lite 2. Board powered off ... probably throttling is not working well (on all H6 ?) and critical temperature was reached.
 
@guidol Thanks.

@Igor @RussianNeuroMancer for the chronyd-bug with ubunutu focal you could take a look here
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005
where they found a problem/solution:
* Chrony can't start on platorms that map gettimeofday to clock_gettime64() * This is due to syscall filtering being correct on some but generic enough to cover all areas. as a temporary solution they wrote:
 
So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter. I’ll send a patch upstream. Meanwhile, you can disable the seccomp filter by running (as root): # sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony # systemctl restart chrony.service BTW: My NanoPi A64 with  armbian focal  kernel 5.6.12 is running
chronyd v3.5-6ubuntu6 normally:

System diagnosis information has been uploaded to http://ix.io/2mbU 

@Igor @RussianNeuroMancer for the chronyd-bug with ubunutu focal you could take a look here
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005
where they found a problem/solution:
* Chrony can't start on platorms that map gettimeofday to clock_gettime64() * This is due to syscall filtering being correct on some but generic enough to cover all areas. as a temporary solution they wrote:
 
So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter. I’ll send a patch upstream. Meanwhile, you can disable the seccomp filter by running (as root): # sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony # systemctl restart chrony.service BTW: My NanoPi A64 with  armbian focal  kernel 5.6.12 is running
chronyd v3.5-6ubuntu6 normally:

System diagnosis information has been uploaded to http://ix.io/2mbU 

You dont have a Raspberry Pi 4 with armbian These are Rockchip64 SBCs  
because there is no armbian for the Raspberry Pi

Anything is possible when using bleeding edge stuff  

For Retro-reasons:
I did buy a old Acme Systems FOX G20 (because it was cheap (10EUR) -
normally I would like own a Acme Systems Arietta G25 because of the formfactor / pinout).
The Fox has only 400Mhz and 64MB of Ram (Arietta has 128 or 256MB but same CPU-Speed)
but could boot a wheezy (Sorry no armbian) in 9MB
I do find it very cool this very low memory useage - while running the SSH/FTP-Server.
 
Also I like the company name  
Reminds me at the companys allways could be seen in Cartoon series
(ACME Co. = https://en.wikipedia.org/wiki/Acme_Corporation )

The original image on the companys webpage was "infected" with emdebian wheezy-grip which is long EOL
So I had to multistrap a new rootfs from the pure debian archive wheezy and transplant the modules/firmware to the newer rootfs (kernel is the same).

Was something nice to learn here while staying home

For Retro-reasons:
I did buy a old Acme Systems FOX G20 (because it was cheap (10EUR) -
normally I would like own a Acme Systems Arietta G25 because of the formfactor / pinout).
The Fox has only 400Mhz and 64MB of Ram (Arietta has 128 or 256MB but same CPU-Speed)
but could boot a wheezy (Sorry no armbian) in 9MB
I do find it very cool this very low memory useage - while running the SSH/FTP-Server.
 
Also I like the company name  
Reminds me at the companys allways could be seen in Cartoon series
(ACME Co. = https://en.wikipedia.org/wiki/Acme_Corporation )

The original image on the companys webpage was "infected" with emdebian wheezy-grip which is long EOL
So I had to multistrap a new rootfs from the pure debian archive wheezy and transplant the modules/firmware to the newer rootfs (kernel is the same).

Was something nice to learn here while staying home

I agree with Guidol's point of view.
 
But, so far
if you already have a tinkerboard lying on your desk if you know how to use etcher (or any other tool for creating a bootable disk) Then by following instructions given above and these on how to compile armbian you should be able to get your DAC up and running under armbian. And, maybe you will just have to adapt the "compatibility" line in the dts file ...
I would be glad to help you further, but without having the tinkerboard, and without having this dac it's hard to do more ...

No, I only tried ondemand. If you think this might help, I'll try it.

for non-multimedia: got a Pihole on a C2 Armbian Buster with Linux 5.6.8-meson64 without problems
"sleeping" idle at 33 degree
 
package bsp-kernel[20.05.0-trunk]  u-boot[20.05.0-trunk]   dtb       [20.05.0-trunk]
firmware                 [20.05.0-trunk]   config[20.05.0-trunk]   branch [dev]
 

for non-multimedia: got a Pihole on a C2 Armbian Buster with Linux 5.6.8-meson64 without problems
"sleeping" idle at 33 degree
 
package bsp-kernel[20.05.0-trunk]  u-boot[20.05.0-trunk]   dtb       [20.05.0-trunk]
firmware                 [20.05.0-trunk]   config[20.05.0-trunk]   branch [dev]
 

Ubuntu changed the location of the mini.iso file for the minimal Ubuntu (Server?) installer in their file servers (since the 20.04 release), it's now located here:
 
http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/mini.iso
 
The docs should be changed since it could be confusing for new users/developers.

I improved the dts of Phicomm N1 again.
The reasons are:
1. The Ethernet card of N1 is not very compatible with some switches. When the ethernet phy is activated, the flow control sometimes cannot be turned on, so  will get bad results during the speedtest.net . For this reason, I added a dts separately force_thresh_dma_mode, which is equivalent to flow control in software mode. But there are also side effects: tx performance is reduced. In addition, as auxiliary optimization items, set snps, aal; snps, txpbl = <0x8>; snps, rxpbl = <0x4>; their role is to improve the performance of the network card.
2. The phy reset-delay-us value of N1 is sometimes not enough. When running openwrt, sometimes the ethernet phy cannot be enabled, so the reset-delay-us value is increased.
Provide two dts files:
meson-gxl-s905d-phicomm-n1.dts: This is the default dts, used in most occasions, when the flow control can be turned on normally, this is the best choice
meson-gxl-s905d-phicomm-n1-thresh.dts: This is a dts with the force_thresh_dma_mode option enabled. It is applicable when flow control cannot be turned on. You can use force_thresh_dma_mode to control flow at the cost of a small amount of performance loss.
meson-gxl-s905d-phicomm-n1.dts meson-gxl-s905d-phicomm-n1-thresh.dts

@Igor  I did this already  
see 
 

Indeed, the configuration in the mvebu64.conf script is wrong.
 
The 2 CS 2 GB image is compiled with the same DDR topology parameter as the 2 CS 1 GB image (DDR_TOPOLOGY=2).
It appears that the configuration for the 2 CS 512 MB version is also wrong, as it points to the same topology file as the 1 CS version.
I guess this is not really a problem, because I'm not even sure that this variant actually exists.
 
So to answer my previous question:
What is used is only 512 MB from each chip.
 
If anyone needs it, here is the bootloader (U-Boot 2018.03-18.12) compiled with the correct topology (DDR_TOPOLOGY=7):
flash-image-ddr3-2g-2cs-1000_800.bin
 
Note that only changing the DDR_TOPOLOGY from 2 to 7 was not enough, because this configuration is also missing from the Marvell sources, even though that's the parameter used in the build examples.
The correct topology exists in the Armbian tree, but with the wrong name:
https://github.com/armbian/build/blob/master/packages/blobs/espressobin/DDR_TOPOLOGY_2-2g.txt
The A3700-utils-marvell/script/buildtim.sh script must also be adapted to accept a DDR_TOPOLOGY value higher than 6.

Great work Guidol! Thanks for all your tireless efforts!

to begin with... yeah!  
https://www.armbian.com/nanopi-a64/
 

I know most of you probably don't want to hear any more about this chip, but I recently fixed quite a few long standing issues.
It's not perfect yet, but it improves scanning/reliable reconnect, incoming frames missed in powersave, ping times, and rate selection.
Here's the patch set: https://github.com/fifteenhex/xradio/pull/12
Edit: rebased from karabek: https://github.com/dbeinder/xradio/commits/karabek_rebase
And some important comments about powersave: https://github.com/fifteenhex/xradio/pull/11#issuecomment-616226880
In short, relative to the current version, with powersave on, idle consumption is lower by 200mW, but with powersave off, it is 300mW higher
- so that should be a consideration if you want to integrate this into Armbian builds for tiny boards like OPZero.

Of course a 65MBit chip will never be fast, but I'd say it is pretty usable as an IoT node now. This hasn't seen much testing,  so your comments are appreciated.

@Ernest Kusa seeing your compile did work so well I was a little bit more "brave" and compiled the dev version
Armbian bullseye with Linux 5.6.5-sunxi   (non-minimal = console only image)
 
Also here no more problems - on my site - with ethernet going down/up.
Audio is working like on your current compiled image
I didnt check emmc, because I want to have there the android inside.
 
Welcome to Armbian bullseye with Linux 5.6.5-sunxi No end-user support: built from trunk & unsupported (bullseye) userspace! package bsp-kernel[20.05.0-trunk.111] u-boot[20.05.0-trunk] dtb [20.05.0-trunk.111] firmware [20.05.0-trunk] config[20.05.0-trunk] branch[dev] System diagnosis information will now be uploaded to http://ix.io/2iOj