gounthar

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. 

Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs).  With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported.  Your report is invalid for one or more of the following reasons (non-exhaustive list):
 
it is for an unsupported board or image (CSC/EOS/WIP/edge) it is for software that is not supported (such as userspace modules installed on top of the core operating system) it has been logged in the wrong forum (for example requests for help that are not actual bug reports) it lacks requested data (armbianmonitor output) it could have been easily solved by a quick search and/or reading documentation  
Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as Common issues / peer to peer technical support or General chit chat)

It seems that there is some dev movement for H616 on kernel 5.12 and also a fresh wip branch with many goodies
Anyone available for building a test image?

Hi Armbian Community,
   I am trying to get the Coral/Google NPU (M.2 PCIe key) to work with the NanoPC-T4. Without success.
 
I built Armbian with linux headers (5.4.48) and was able to apt install the gasket-dkms package.  (The EdgeTPU requires Google's Gasket and Apex drivers to be built as modules with DKMS, and thus requires the linux headers to be installed at /usr/src). Also, there was no conflicting Gasket or Apex module in the Armbian release prior to install (an issue found by other EdgeTPU systems on other distros).
 
My problem, I believe, has to do with the NanoPC-T4's PCIe. I have tried many different kernels (FriendlyElec's Core/Desktop/Buildroot releases using Rockchip's 4.4.179 kernel as well as various Armbian), and every time PCIe link training times out as follows:
 
[    3.161132] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[    3.161214] rockchip-pcie: probe of f8000000.pcie failed with error -110
 
I am currently at a loss for what to try next. If anyone has any ideas, then I would be forever grateful and enthusiastic to help debug and test.
 
Here is the full u-boot debug and kernel dmesg output for the Armbian build with Gasket/Apex modules installed (albeit never probed):
 
 

When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment.  The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase.  Instead they are likely to purchase one or a few to evaluate first.  That evaluation is not going to happen in a rack mount, but instead will happen on a desktop.  Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.
In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work.  One example of this is an hdmi port.  While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop.  Another example is cooling as mentioned in the above posts.  I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.
 
My ideal feature list would be:
1gbit POE ethernet port
4GB ram
32GB emmc (or more optional)
good external storage options (m.2 or other)
hdmi port
2 or more usb ports (at least one being usb3)
power port for non POE usage
optional case for desktop use with good thermals
optional rack mount with good thermals
 
The two things I think it shouldn't have:
- no wifi/bluetooth
The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.
- no SD card
The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media.  You only need another option to install/update the internal emmc and usb should be sufficient for that.  The sd support then just becomes an added cost with no real long term need.  It does require that booting from usb be well supported by the firmware.
 
Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.
 
My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.
 
Finally I'll mention price.  In my opinion you likely need the above described board at a price point no more than a RaspPi.  Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful.  Price will to an extent drive the evaluation process.  If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.
 

I want a stripped down board that has real 802.3af POE

The thing is I want to be able to incorporate my SBCs in some 19" rack (1 U preferably), in desk grommet, or any other type of enclosure, so I don't want a well designed enclosure, as it won't help me.

No WiFi, no SDCard, M.2 socket, eMMC, SPI Flash, USB-C (power plus host), 4GB RAM, big low profile heatsink, RTC, and GPIO with I2C, SPI, and pins with USB. As small and low height as possible.
Options would be NPU, more RAM, CSI and of course a SOM instead of the whole SBC.

My $0.02.

Many seems to think that theirs has to be very long and powerful (if you understand what I mean). In fact, a well designed enclosure can assume this function. And in any case the quality of the thermal interface is more important than anything else.

Imagine a new SBC is developed specifically designed for computing tasks and clustering but should also be available for a rather low price.
Which features should it have or not have? What do you think? Is it even possible?

I am thinking about automatic conversion of DTB extracted from Android firmware to DTB usable by Armbian (linux).
I am reading the docs about the DT but still I have no clear picture what is required to do this.
 
From the definition, the DT should be OS independent, so why the Android DTB cannot be used directly by Armbian/linux?
 
Currently I have in my mind only two things:
DTB can be older and not fit to the current standards Device names/types (used in compatible=) may be different in linux and thus not recognized Or am I wrong?...
 
This is new area for me, so any comments are welcome..
 

Ok, so let's see the steps I followed.
 
1. Installed Armbian Unstable for OrangePi Zero2:
https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
 
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
 
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
 
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
 
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
 
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  

You've been brave, but surrender, never
A bit a pity there's not more interest in this board. And I've not seen any other H616 SBCs coming. 
Their Orange(Armbian) images do seem ok. I wonder if we could not learn anything from their script/builds.
https://github.com/orangepi-xunlong/OrangePi_Build
They've copied Armbian, maybe Armbian should copy them now  
I don't know. Maybe this one should be a pass. Is the effort supporting it worth it? Tho the board is good for some use cases. 

And another: HK1 RBOX R3
 
I'll assume this chipset will only to continue to proliferate so I won't post more models and instead share any dtb I come across.

Hi all.
I recently bought the Odroid Go Super. It is a great handheld for emulation gaming. But that isn't the main reason why I bought it.
It can also run Linux, tho not Armbian.
In this video I show how I use Debian Buster from Meveric on the Odroid Go Super and I also review the hardware. Greetings.
 

@XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices