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.
USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool
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
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. ;-)
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: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...
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. https://opensource.com/life/16/4/bulldog-gpio-library for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from https://github.com/SilverThings/bulldog. 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.
lanefu reacted to Heisath in Espressobin - Only 1 GB RAM detected on a 2 GB board
If this works consider to contribute (https://docs.armbian.com/Process_Contribute/) and maybe add a PR with your changes to the Github https://github.com/armbian/build
We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of).
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"...
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
- Before Start : 615MB
- After Start : 643MB
- After 10 minutes with an opened project : 648MB
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: 192.168.6.22 CPU temp: 44°C Usage of /: 12% of 15G storage/: 1% of 229G
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.
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
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
worker-03 Ready <none> 11m v1.17.3 192.168.0.106 <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.
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
Then use the attachment program to read from MAX6675
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.
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.