lanefu reacted to Zaf9670 in Introduction
Just thought I would introduce myself and start on my 5 approved posts requirements.
ETAPrime is the reason I found out about this project and it's something I'd like to help out with when/where I can.
I currently have a few Raspberry Pi 3 B and 3 B+. I also have two Libre ROC-RK3399-PC that I'm looking forward to future support on with the community. I also enjoy gaming and 3D printing as my other hobbies.
Ask me anything? I guess?
lanefu reacted to balbes150 in nvidia jetson nano
Nano owners, can you test the ability to run an image on your instances ? I'm interested in a General startup to make sure this image is working.
lanefu reacted to windysea in A64 date/time clock issue
An ntp stratum is not related to accuracy nor precision - it is simply an indication of how many "hops" a given NTP server is from a reference clock. A stratum-0 is a reference clock (IE: atomic clock, GPS receiver, etc). A stratum-1 is the NTP server directly using that reference clock for time synchronization. An SBC with a serial GPS indeed can be a stratum-1 (the GPS would be stratum-0), and there are many public postings on doing this. In fact the NTPsec team is doing "research" on this topic and has published documentation regarding this.
The nature of the reference implementation of NTPd is specifically to maintain accurate time regardless of any hardware timers. Today's "50-cent" parts are still more stable than those orders-of-magnitude more expensive decades-ago when NTPd was first developed.
Google's NTP project may use their own "atomic clocks", but their public NTP servers tend to be on the poor end with respect to jitter. They're intended to be "close-enough", stable, and highly-available. They are not intended to be highly accurate. Their public NTP servers, for instance, implement leap-smearing rather than advertise a leap-second (when appropriate). For this reason Google strongly recommends not mixing their public NTP servers in a configuration with other NTP sources (bad things can happen, and in fact have happened in the past). Google's NTP servers also are behind anycast load-balancers. While this improves availability and end-device configuration simplicity it actually degrades performance.
In my own testing google's ntp servers typically have higher jitter than most of the larger NTP pool project pools, the latter of which are already commonly used as defaults in many OS distributions.
Configuring and building a non-tickless kernel is required in order to enable kernel-pps (aka "hard pps"), which typically has far less jitter than "soft pps". However, doing so even with the latest 5.1.y (DEV) kernels results in an unstable platform where the issue noted in this thread will manifest fairly frequently. It may just be that A64-based SBCs are not suitable to host NTP reference clocks and stratum-1 NTP servers but earlier kernels did not seem to have this issue so it may just be that a previous mitigation got lost along the way.
lanefu reacted to TonyMac32 in Overlays
I'm not sure what will and won't be a worthy overlay to put directly into Armbian itself with the current script structure, I intend to document the ones I add here, @martinayotte may as well if he's bored. :-P
I will be focusing on RPi GPIO compatibles, since those are nice pre-packaged devices in general. I have Tinker, RockPi 4, Le Potato/K2/C2, Tritium H2+/3/5, Rock64, Renegade, and some others.
Everything here is a placeholder at the moment.
Status Tinker Le Potato Meson64 Renegade Tritium Automation Hat Generic DAC (Pi) MCC 118 DAQ MicroDot PHAT Inky WHAT (e-ink) ENC28J60 for Pi
lanefu reacted to TonyMac32 in Overlays
I agree, which is why this is not under normal development as a topic. There is the reality, however, that people buying RPi-shaped boards want support for RPi peripherals and accessories, so my thought is to discuss ways to support that, while implementing a few on a platform that only has 1 board with gpio anyway (Rockchip). If it must be that I have a fork of the build system and stuff all of this in "user patches" then so be it, but I think we need to come up with a way to handle this per board rather than per family.
lanefu reacted to Leonardo in Latest update put my device in read-only mode. How do I fix that?
This is my first post here, I recently stared using Armbian, and it is really good. I had the same problem with my new Renegade board, this is the solution:
- Go to https://dl.armbian.com/renegade/archive/
- Get this file: Armbian_5.75_Renegade_Ubuntu_bionic_default_4.4.174_desktop.7z , 174 is the last version that works for Renegade
- Before upgrading, sudo apt-mark hold linux-image-arm64
The version 4.4.180/5.88 has this issue for Renegades, I am investigating.
lanefu reacted to Igor in Orangepi 3 / Lite2 / One+ / Pine H64
added (tested) preview images for H6 boards based on our sunxi64-dev kernel (5.1.7) hdmi works, network works, dvfs works, ... not all board features works apt upgrades will not be tested bugs are expected. Help in finding and resolving is more then welcomed!
lanefu got a reaction from Igor in Document about compiling a kernel, and rootfs for the firefly boards
Just kidding then!
lanefu reacted to @lex in Enable OV5640 on NanoPi A64
This weekend I was revising and testing the OV5640 for some A64 boards.
To enable the Camera (OV5640) on NanoPi A64 for the mainline kernel you have to update the following:
Here is the excerpt :
lanefu reacted to TonyMac32 in Support of Raspberry Pi
An RPi is not
2) the most cost-effective
3) worth $35
4) worth any more discussion.
The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.
Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.
Sent from my Pixel using Tapatalk
lanefu reacted to chwe in Support of Raspberry Pi
I see some decent moderator skills here... @Igor @lanefu we should change his official title here..
btw. if this thread goes back and forth.. I'll simply close it until the first iteration of a not VC4 based RPi is out (or someone wrote a bootloader which allows to boot without binaries provided by the foundation ).
lanefu reacted to ebin-dev in Espressobin support development efforts
Please find the updated bootloader here (u-boot is unchanged; WTMI is updated to 18.12.1) - it should solve the stability issues and it works fine on my V5_0_1 EspressoBin (https://pastebin.com/xJCtLXsH). The recovery images are also updated: sata-images and uart-images.
Could you please test if your EspressoBin ist stable now and if you can apply the pending cpufreq and xtal kernel patch without creating any further issues ?
Edit: links updated ; images are now available through Armbian servers
lanefu reacted to Anders in Seed our torrents
How about including "webseeds"/"http seeds" in your .torrent files? You already have a lot of mirrors (ex http://mirrors.dotsrc.org/armbian-dl/), so it would be very helpful if your torrent client could also download from all those mirrors.
lanefu reacted to maxlinux2000 in Add undetected hdmi resolution to X11/Xorg
I am putting here some notes for posterity
In the current version of armbian (testing H6) I use X11 / Xorg only reaches 1024x768, but my display reaches 1440x900.
To add this new resolution to the list of Settings/Display you have to give these commands:
# xrandr --listmonitors
(this command serves to see what it's called, the hdmi output)
# cvt 1440 900
# 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync )
# xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
# xrandr --addmode HDMI-1 1440x900_60.00
# xrandr --output HDMI-1 --mode 1440x900_60.00
If it works then modify Xorg with:
# sudo mcedit /etc/X11/xorg.conf.d/40-monitor.conf
Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
Option "PreferredMode" "1440x900"
lanefu reacted to Dianne S. in w1_gpio module fails on ASUS Tinker Board
Armbianmonitor: http://ix.io/1IrG Hi,
I'm running Armbian Stretch on a Tinker Board and trying to use a one-wire thermometer. I have this in /boot/armbianEnv.txt:
overlays=i2c1 i2c4 spi2 spidev2 uart1 uart2 w1-gpio However, when I boot the board, I see this in dmesg:
[Wed May 8 17:38:43 2019] rockchip-pinctrl pinctrl: unable to find group for node w1_pins [Wed May 8 17:38:43 2019] w1-gpio: probe of onewire@0 failed with error -22 Kernel version is Linux tinkerboard 4.19.33-rockchip #5.77 SMP PREEMPT Wed Apr 3 17:06:29 CEST 2019 armv7l GNU/Linux
Any ideas? I'm using the rockchip-w1-gpio.dtbo that was installed with the system.
lanefu reacted to chwe in Final Image for Nanopi M4 ?
"newest and fastest" quite often ends here:
that's why I don't care about such information without actually prove that the used card is really fast (forum search will guide you how you can test it)... Especially when it's about Images we (as armbian team) are not 'in charge'.
about which Image do we talk here? switched to Armbian or still on FriendlyElec's image?
a short reminder (https://forum.armbian.com/guidelines):
A support question must include the following: Board you use Issue you face Description of your set-up (e.g. powering, connected hardware, used SD-Card) 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!
besides being in 'Development' not 'Technical Support':
Development A section for more experienced users. For example for SoCs where Armbian support is currently not mature enough for full support, questions related to the build framework and 'Board Bring Up' for new boards we might consider supporting in the future. We can't provide the same level of support for WIP (work in process) SoCs cause kernels for those boards are simply not ready yet. Board Bring Up is mostly for experienced users which want to contribute in support for new boards/SoCs, a *please support random board* without any rational and no interest in contribution for such a support will simply be ignored. If you just want to point us to a new interesting board our water-cooler (General chit chat) is the right place for it.
btw. @lanefu can you adjust the text there? 'Technical support' isn't anymore.. so the text need some small adjustments..