• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    lanefu got a reaction from OrangePee in Need your help - what else beside Etcher   
    added annotation that it may container spyware
  2. Like
    lanefu got a reaction from Tido in Need your help - what else beside Etcher   
    I've updated our canned response to below.... I saw no need to revoke Etcher's status.. as it is easier to install, but I updated it's description to be more....accurate
    Armbian's archives can be uncompressed with 7-Zip on Windows, Keka on OS X and 7z on Linux.
    Images shall only be written with imaging tools that validate burning results.  This saves you from corrupted SD card contents.
    Approved Tools:
    USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool
  3. Like
    lanefu reacted to TonyMac32 in Armbian v20.05 (Kagu) Planning Thread   
    I don't see any reason not to, the patchset is a lot of backported stuff anyway.

    I have a cranky Asus board here that kernel panics on boot with our 4.4 (sounds familiar), I might scab the device tree into something mainline likes and skip legacy for the moment.
    @Lanefu, we need to make sure the big patch isn't "undoing" any of the other patches, I got most of it cleaned up, but not all.

    Sent from my Pixel using Tapatalk

  4. Like
    lanefu reacted to barish in Espressobin support development efforts   
    Despite of all the seemingly bad news, I boldly ordered a batch of 10 EspressoBin V7 recently. Globalscale promised to test them for me for stability (I am not interested in squeezing out the last bit of performance), and I tested them again after reception: They all seem to run stable with Ubuntu Xenial (the "newest" image provided by Globalscale) and with Armbian kernel 4.19.59-mvebu64.
    Since there is still a few weeks till they go on duty, if anyone is interested in a particular test on them, I am willing to do so. I am not into kernel development, so I would need some instruction. ;-)
  5. Like
    lanefu got a reaction from Werner in THE testing thread   
    that's super awesome @Igor!
  6. Like
    lanefu reacted to Igor in THE testing thread   
    One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.

    After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: Its still more or less a data collection without any proper analysis ...
  7. Like
    lanefu reacted to sgjava in Fast GPIO access   
    After working with sysfs and libgpiod as cross platform solutions I was wondering if there was a faster way using /dev/mem or mmio? I know this gets more bare metal and SBC specific, but for some things you may want absolute speed. for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from Is there a more generic way to do this and not lose performance? Using my generated JNA wrappers for libgpiod I get about 2K writes per second. In Python I think it's about 70K using libgpiod Python bindings. I realize you may not always need 1 MHz GPIO writes, but it would be neat to offer this in a more generic way.
  8. Like
    lanefu reacted to Heisath in Espressobin - Only 1 GB RAM detected on a 2 GB board   
    If this works consider to contribute ( and maybe add a PR with your changes to the Github
    We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of).
  9. Like
    lanefu reacted to m][sko in What's your favorite heat sink   
    I mount this one on Hikey970
    I can only recommend!

  10. Like
    lanefu reacted to Igor in THE testing thread   
    FYI. I am talking with Olimex to produce this board in a quantity of around 20 pcs.
  11. Like
    lanefu reacted to klode82 in IDE like VSCode or Atom for Pine64 on Armbian Debian Buster   
    In these days I've spend time in order to searching for something useful.
    I've found cudatext CudaText 
    For me is a good chance to have a good IDE, expect for git integration, but as we says in Italy... "you cannot have a drunk wife and a full barrel"... 
  12. Like
    lanefu reacted to klode82 in IDE like VSCode or Atom for Pine64 on Armbian Debian Buster   
    Only to complete the information, on my Pine64 (with the script suggested by @lanefu:
     - Before Start : 580MB RAM
     - After Start : 1.22GB RAM
     - After 10 minutes with an opened project : 1.74GB RAM
    With CudaText:
     - Before Start : 615MB
     - After Start : 643MB
     - After 10 minutes with an opened project : 648MB
  13. Like
    lanefu reacted to yam1 in Big sale on Odroid MC1   
    Here is what I did with one of mine - added $7.5 neo core as standalone terminal with back to back ethernet and serial connections :-)

  14. Like
    lanefu reacted to guidol in SSH welcome message   
    I like this picture - as welcome message
    _ _ ____ _ _ _ ____ | \ | | _ \(_) | \ | | ___ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_____| Welcome to Armbian Buster with Linux 5.6.2-sunxi64 package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb [20.05.0-trunk] firmware [20.05.0-trunk] config[20.05.0-trunk] branch[dev] System load: 0.02 0.02 0.00 Up time: 7:49 hours Local users: 2 Memory usage: 21 % of 477MB IP: CPU temp: 44°C Usage of /: 12% of 15G storage/: 1% of 229G  
  15. Like
    lanefu reacted to Igor in THE testing thread   
    New Armbian CI autotest facility:

    USB PSU:

  16. Like
    lanefu reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
    @JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
    I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

    As my example -  what I am currently working and IMHO could be implemented by 20.05:
    - setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
    - merging mainstream kernel config in the non-hardware areas could go into this release
    - firmware split up with @ning
    ... more Jira's during a week.
    Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
  17. Like
    lanefu got a reaction from Narly9999 in O Pi projects? Application?   
    they did another campaign recently
  18. Like
    lanefu reacted to grunlab in Enable PIDs cgroup   
    - I've reinstalled one of the cluster node using the last image Armbian_20.02.1_Odroidxu4_buster_current_5.4.19_minimal.img:
    adrien@bastion:~ $ kc get node worker-03 -o wide
    worker-03   Ready    <none>   11m   v1.17.3   <none>        Debian GNU/Linux 10 (buster)   5.4.19-odroidxu4   docker://19.3.8
    - pids cgroup is enabled on this image:
    adrien@worker-03:~$ cat /proc/cgroups | grep pids
    pids    3    97
    - No more warning at kubernetes logs level and the node looks stable for the moment :-)
    I think this topic can be closed now.
  19. Like
    lanefu reacted to mantouboji in SPI on OrangePi One Success   
    After some hack,  I use the SPI port on OPi One to connect with a MAX6675 board. 
    The SPI port on One is SPI0,  so armbianEnv.txt should include these:
    overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_spi_cs=0  
    the MAX6675 connects to OPi One as:
    MAX6675                       One GPIO
    VCC                                 PIN17
    GND                                PIN20
    SCK                                 PIN23
    CS                                   PIN24
    SO                                  PIN21
    Then use the attachment program to read from MAX6675
  20. Like
    lanefu reacted to manuti in What's your favorite heat sink   
    Same here (I think @tkaiser shared this model here and everybody copied his idea). 
  21. Like
    lanefu reacted to goathunter in pine64: massive date/time clock problem   
    After about 10 days, two of my Pines are stable. The third one keeps time jumping. This morning, it took me several "set time/reboot" sequences before I was finally able to stop it from time jumping. There's clearly still a problem in 5.3.9 with some AllWinner clocks.

    The patch posted earlier in this thread still seems to be the best workaround to this problem, even if some think it isn't the correct workaround. I have not tried to patch 5.3.9 with that patch, though I may give it a try if I continue to have problems.
  22. Like
    lanefu reacted to Igor in Rename Supporter to Donator   
    Changed a little.
    @guidol Too late  I adjusted and applied all changes.
    red_donator.xcf white_donator.xcf green_donator.xcf
  23. Like
    lanefu reacted to guidol in Rename Supporter to Donator   
    no problem  I had issues to center the text - so you did it.
    I only did try to help out a little bit  
  24. Like
    lanefu reacted to Werner in Rename Supporter to Donator   
    Same as I do
  25. Like
    lanefu reacted to sfx2000 in PREEMPT-RT PATCH for Allwinner H5   
    Curious as to why one wants to apply the patches for preempt-rt in the first place? Do you have a reason/application that would benefit? Most times, one can see an overall decrease in application performance, and to take advantage of preempt-rt, the application must call pthreads in a very specific way - which means that many times, the app must also be rebuilt.
    My reason for asking - if preempt-rt was so awesome, it would already be in the upstream linux kernel mainline and not require the patch. Avoiding politics around preempt-rt - many of the benefits here can be done without the patches, by selecting an appropriate scheduler - schedutil looks fairly interesting at the moment.
    I work on networking oriented applications that have hard deadlines, on MIPS, PowerPC, ARM (both 32bit ARMv7a and 64-bit), and never had a need to apply the preempt-rt patches.
    By networking oriented applications - I'm saying 20mSec framing for SIP-RTP (VoIP apps), along with 3GPP/UMTS signalling - if that ain't close to real-time, I don't know what is.