gounthar

Armbian desktop running on Orange Pi Zero2 with kernel 5.13

With the mentioned fixes applied, happy to report everything works, except hdmi, wifi, and the other 2 USBs (tested not working with added settings in armbianenv). It is quite usable now as a little x display and screen updates seem to keep up as tested using smtube mpv videos.
 
 

 
 
PS. 4" SPI display also works well - first time I got it to work using DRM drivers. Looks like DRM development is almost complete - if the second screen damage repairs can be fixed then we can forget about the fbtft drivers forever.

Good news. Full-fledged working images (20210827) of ArmbianTV for P2 and M2  are ready. All the equipment works in them and you can start and configure the system via an HDMI monitor and a keyboard/mouse. 
 
M2
 
https://disk.yandex.ru/d/OBDO8BU2y1M6ug
 
https://users.armbian.com/balbes150/rk3566/
 
 
P2
 
https://disk.yandex.ru/d/neKXsYolKXgLzg
 
https://users.armbian.com/balbes150/rk3568/

Hi, I recently received this board and I was able to get the docker started. Maybe someone may find it useful.
After installing via "armbian-confix" if try to start docker service with
$ systemctl start docker  we get this error: 
● docker.service - Docker Application Container Engine    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)    Active: activating (auto-restart) (Result: exit-code) since Tue 2021-08-24 20:09:34 MSK; 26ms ago      Docs: https://docs.docker.com   Process: 11947 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)  Main PID: 11947 (code=exited, status=1/FAILURE) dpkg: error handling package docker-ce (--configure):  installed docker-ce package post-installation script subprocess returned error exit status 1 In "journalctl -xe" we get the following - "Running iptables --wait -t nat -L -n failed with message: `# Warning: iptables-legacy tables present, use iptables-legacy to see them\niptables: Operation not supported.`, error: exit status 1."
And to fix it, you need to use the following command:
$ update-alternatives --set iptables /usr/sbin/iptables-legacy Then restart the service and docker works.

Which is your kernel version?
 
This is 4.3.1 branch which should work with kernel 5.13: https://github.com/jernejsk/FFmpeg/commits/v4l2-request-hwaccel-4.3.1-new
 
gstreamer also made a ton of progress in last few days and it currently passes even more H264 conformance tests than ffmpeg. However, you need to build latest source from git.

Interesting, but not affordable: https://www.cnet.com/tech/computing/facebook-shares-its-time-card-atomic-clock-tech-to-speed-internet-services/

Hi Ubobrov
 
You seem to be the expert on using the Cedrus decoder under Armbian so I've got a few questions that I'm hoping you would be kind enough to answer:
 
Have you tried 4K@30fps h264 playback using cedrus/v4l2-request with mpv?
 
Have you tried the most recent 5.10 Libreelec AW kernel patches? I'm hoping Balbes can include these in the Armbian AW kernel as standard.
 
Have you also got an Allwinner H6 board? Your guide should also work for H6 devices. I've got a T95 Max.
 
I noticed in your guide to building ffmpeg you disable vaapi and vdpau. Why? Was that just to save build time or do you have another reason? It may no longer be required to rebuild ffmpeg, maybe v4l2-request is enabled in the regular deb now?
 
It looks like libvdpau-sunxi isn't required and it hasn't been updated in years so I presume its dead.

I just upgraded my Pinebook Pro touchpad firmware. Wow! It's especially helpful with Armbian, which lacks the extensive synclient controls of other distros that can partially mitigate the former touchpad lag and hysteresis. Even with synclient, it's a huge improvement!
https://forum.pine64.org/showthread.php?tid=14531
 

@gounthar also maybe here some other idea?
https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/

I don't know especially for the 4B but other models usually can be powered trough GPIO pins 2 and 6 which are shorted to the other powering option like barrel  plug or microUSB/USB-C. So the consumption is basically limited by the line resistance and the power supply.

I just successfully build and boot image with legacy u-boot and legacy kernel. A lot of dirty things around, but it works. I am unable to push things further, so anyone can proceed from here. Enabling Wifi and BT https://github.com/armbian/build/pull/2620

Mandatory for proper testing. Everyone who tinkers with SBCs should have such a thing. Also they are dirt cheap.

For what it's worth, Microsemi sells lots of stuff designed by Jackson Labs Technologies, which might open up the market options.
 
Also, if you're looking for accurate clocks you can disconnect and take indoors, the term you're looking for is GPS Holdover. Just fair warning that the more accurate the clock, the longer it might take with view of the sky before it hits full accuracy (though Microsemi won't advertise that). FYI, double oven temperature compensated oscillators can get better accuracy than the some commercial grade atomic clock options, but may take up to 3 days of warmup to get to full spec..
 
But if you're going to procure a couple and take them inside, consider a battery backup to avoid the initial training time, and make sure they get lots of sunlight before you need them.

@Cesar Berci it got me interested enough that I ported changes to v5.10 with cleaner approach. Here you have commit: https://github.com/jernejsk/linux-1/commit/ad153ef6ee5be33531187f97d5fa0c07455dc795
NOTE: You have to enable tve node in DT you want. I did that in OPi PC.

Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian.  It seems to work totally fine, with a few caveats.
First: Sample images of it in action -> https://imgur.com/a/vXQEM
Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11
Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11
 
Howto:
just put the patch into userpatches for the sunxi-next kernel, and build.  it should apply cleanly. Its for H2+/H3.  I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards.
 
You then need to edit /boot/armbianEnv.txt
add tve to overlays to enable it.  the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this.  If you want to turn TV out off, just remove tve from the overlays line.
My armbianEnv.txt overlays looks like this:
overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well:
extraargs=drm.debug=0xF Its not needed, unless you really want the debug info.
 
Notes:
1. The default mode is PAL, with 720x576 resolution.  Thats outside of normal PAL displayable area, and so the screen overscans.
I dont know how to correct this, although its mostly just annoying with terminals.
I also don't know how to change the video mode to NTSC.
 
2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity.  Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded.
A way to resolve this is use :
# apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one.  its much easier to read.  Look at the help for fbterm to work out everything it can do.
 
3. I used the program "fim" to display the test images.  there are others for doing stuff on the terminal.
 
4. I haven't tried X.  I am not interested in running an X terminal on a TV, but it should probably work fine.
 
Other than that it all seems good.  I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy)
 
The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND.  i soldered one inside my RCA connector, it fits fine and isn't too difficult.  IF you don't do this the image will bloom and look like total crap, so you have been warned.
 
As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it.  I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build.  If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian.
 
EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver.  I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system.
Original code is here:
https://github.com/Icenowy/linux/tree/tve-v2

Back in the day we would take a Rubidium source like an SA.22c (can be found on ebay ~$100 - $150) and make a GPS Disciplined Oscillator. The rubidium was accurate for the short period (hours) and the GPS held it really accurate for long time (years).
 
https://www.microsemi.com/document-portal/doc_view/136649-sa22c-user-guide-2017
 
can't find the project we used, but this one makes the point -
https://hackerstuebchen.de/making-a-rubidium-gpsdo
 
Sounds like fun!

Hi,
 
how long does the time have to stay within the 1/60th of a second requirement? Minutes? Hours?
 
I think there are tutorials out there on how to use common GPS modules (ebay search for raspi gps gives some), most of the ublox ones also have a rather precise timing output. From the website (ublox) it seems the also sell modules explicitly made for time synchro.
Depending on how long you want to keep the devices in sync it might be acceptable to only sync them before you start filming (?) and have the device clock continue when gps goes away. 
 
If a really precise clock is required I would maybe turn away from SBCs (boards with multithread, multiprocessors) have a tendency to have problems with jitter (obv. reasons).   If you need a precise time (as in your link) I'd suggest going for a simple microcontroller. There you can grab the GPS signal once, and then setup an internal timer - which are pretty precise considering the micro does only a thing at a time (if you go for cheap AVR ones). Afterwards just have the timer run out every 1/60th of a second and toggle a IO pin. Time reference done.
 
EDIT: Bonus: If you are in Europe (although other regions probably have similar services) you could also use DCF77 to do the initial sync.

On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
 
Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
 
You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
 

Here. And read the posts above about Kodi
 
 

What is the "mainline" status of the VPU code for rk3399? in both kernel and ffmpeg (and, well, kodi)?
 
It seems there were quite big changes for kernel 5.11, but I haven't see any updated ffmpeg patches to match the changes in the kernal uapi headers.
Does Armbian keep track of any of these media patches somewhere? I can't seem to find anything relevant in the armbian/build repo on github :(, and only the "outdated" (mismatching with kernels >=5.11) in the LibreElec repos.

In the past few weeks I have been working to improve processes of deploying our work. Scripts that runs in the background are combination of tools that are build into the main tool and additional scripts that run on the server. They are (will be) summed in a (private) scripts repository, but the functioning - which could be interested for any maintainer - are summed in this document:

https://docs.armbian.com/Process_CI/
 
Welcome to add your ideas, especially for the merge request part, which remain unchanged. Otherwise its planned to extend this automation to execute tests, similar or the one from @William Bonnet on virtual image (image already boots insite Github actions) and real hardware (need implementation).
 
Examples:
 
- updating images and kernel update for families that those boards belong to: rockpro64, station-p1, station-m1, odroidc2, odroidn2, odroidc4, odroidhc4, odroidxu4, nanopir4s, udoo, cubox-i, rockpi-s, rockpi-e, rockpi-n10. nanopct4, espressobin, tinkerboard
- building under Docker and booting qemu image inside Github action (WIP, not enabled yet)
- upstream kernel changes for a few families caused rebuild and updating of both repositories
 

https://github.com/armbian/build/issues/2886

Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

Here's what we have so far.

* a linux 'family' called virtual.conf
* a kernel config called linux-virtual-current.config
* a board called virtual-qemu.wip
 
The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
 
I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
 
I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

Next steps:

* automatically resize and convert resulting image to qcow2 format
* solve how to add cloud-init to image
* solve for installing grubEFI for booting and whatever partition layout is needed
* figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
* strip extra hardware drivers out of kernel and make this thing lean

PS Did I mention Desktop Works too?

 
 
 

Version 20210513. Fixed startup with Legacy kernel, now these images work correctly.

I just want 32 N1 cores. No need for any other I/O than a Gbit ethernet port. 
More would be nice. My M4V2/N2+ do everything I need. Just for rendering and building I can use more performance. Being able to do these jobs on a dedicated device would be nice.
Tho a workstation with 32 N1 cores is more awesome.