• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    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?
  2. Like
    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.

  3. Like
    lanefu got a reaction from gprovost in Helios4 Support   
    Have you created the filesystem, share, and the added the share to a service (SMB or NFS) and then enabled the service?  (it's kind of a long chain)

    can you run
    armbian-monitor -u  and share the link?
  4. Like
    lanefu got a reaction from TonyMac32 in Daily (tech related) news diet   
    That is NOT how I want to die.
  5. Like
    lanefu got a reaction from gprovost in Helios4 Support   
    The Helios will keep up for that just fine. DLNA might be another option to consider over samba

    Sent from my iPad using Tapatalk
  6. Like
    lanefu reacted to AZClusterboard in SOPINE build   
    I would love to help.  I have SOPINE stuff and an original Pine64 from the kickstarter.
  7. Like
    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.
  8. Like
    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                                                
  9. Like
    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.
  10. Like
    lanefu reacted to Leonardo in Latest update put my device in read-only mode. How do I fix that?   
    Hi Steve,
    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 
     - 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.
  11. Like
    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!
  12. Like
    lanefu got a reaction from Igor in Document about compiling a kernel, and rootfs for the firefly boards   
    Just kidding then!
  13. Like
    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:
    * DT
    * GPIO-I2C 
    Here is the excerpt :
    Kernel config:
  14. Like
    lanefu reacted to TonyMac32 in Support of Raspberry Pi   
    An RPi is not

    1) reliable
    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

  15. Like
    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 ).
  16. Like
    lanefu reacted to ebin-dev in Espressobin support development efforts   
    @FlashBurn @spqr
    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 ( 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
  17. Like
    lanefu got a reaction from qblueRed42 in What is your favorite Armbian Background   
    We have some really cool new Armbian Backgrounds.   Soon they will be rendered in high resolution.

    Which one is your favorite?  Please vote in the poll!

    See Gallery Here or links to individual items within poll.
  18. Like
    lanefu reacted to Anders in Seed our torrents   
    Hi Igor
    How about including "webseeds"/"http seeds" in your .torrent files? You already have a lot of mirrors (ex, so it would be very helpful if your torrent client could also download from all those mirrors.
  19. Like
    lanefu reacted to maxlinux2000 in Add undetected hdmi resolution to X11/Xorg   
    Mini tutorial
    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
    Section "Monitor"
    Identifier "HDMI-1"
    Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
    Option "PreferredMode" "1440x900"
    # reboot
  20. Like
    lanefu reacted to balbes150 in Bring up for Odroid N2 (Meson G12B)   
    Never connect a VCC contact for USB-TTL. Use only three GND Tx Rx Pins on all models.
  21. Like
    lanefu reacted to Igor in Slight limitations for posting in dev forums   
    Changed posting permission - one need 10 5 posts to post in RK3399 or Allwinner H6 forums.  
  22. Like
    lanefu reacted to JMCC in Le Potato / C2 / K2 4.19 LTS testing thread   
    BTW, seems like the Lima driver has been accepted for 5.2. Looking forward to seeing it released 
  23. Like
    lanefu reacted to Dianne S. in w1_gpio module fails on ASUS Tinker Board   
    Armbianmonitor: 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.


  24. Like
    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 (
    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..
  25. Like
    lanefu reacted to esbeeb in NanoPi Neo 2 LTS: net I/O speed tests, etc.   
    Dear moderator, could this topic be moved to the H5 subforum?  It's misfiled under the H2 & H3 subforum.  Thanks in advance.
    @lanefu, @Igor
    Sorry, I don't know who the other mods are.