gounthar reacted to tparys in How would you implement a super precise clock with a board running Armbian?
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.
gounthar reacted to jernej in Orange Pi Zero (H2+/H3) TV Out on Mainline, WORKING
@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.
gounthar reacted to Strontium in Orange Pi Zero (H2+/H3) TV Out on Mainline, WORKING
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
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.
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:
gounthar reacted to Technicavolous in How would you implement a super precise clock with a board running Armbian?
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).
can't find the project we used, but this one makes the point -
Sounds like fun!
gounthar reacted to Heisath in How would you implement a super precise clock with a board running Armbian?
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.
gounthar reacted to tparys in How would you implement a super precise clock with a board running Armbian?
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.
gounthar reacted to rubenvb in Mainline VPU
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.
gounthar reacted to Igor in Armbian continuous integration
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:
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).
- 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
gounthar reacted to lanefu in Armbian the Virtual Machine
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.
* 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?
gounthar reacted to NicoD in A SBC for computing - your thoughts
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.
gounthar reacted to Werner in [Invalid] - nodejs 14 under Armbian 21.02.3 Buster installieren
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)
gounthar reacted to kampff in NanoPC-T4 + EdgeTPU (PCIe M.2)
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):
gounthar reacted to SteeMan in A SBC for computing - your thoughts
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
32GB emmc (or more optional)
good external storage options (m.2 or other)
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.
gounthar got a reaction from Werner in A SBC for computing - your thoughts
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.
gounthar reacted to arox in A SBC for computing - your thoughts
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.
gounthar reacted to lucky62 in Device tree translation
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..
gounthar reacted to XFer012 in OrangePi Zero2 - Allwinner H616
Ok, so let's see the steps I followed.
1. Installed Armbian Unstable for OrangePi Zero2:
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):
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
gounthar reacted to NicoD in OrangePi Zero2 - Allwinner H616
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.
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.