devman reacted to sfx2000 in Support of Raspberry Pi
I would agree - and there's not a lot of value add for the effort that would be needed to support three different Broadcom SoC architectures - the RPi community has their own rich ecosystem, and there's formal support from Ubuntu (and other distros) if one wants more than what Raspbian has.
Where Armbian shines - the project brings mainline support for SoC's (Rockchip, Allwinner, Amlogic are good examples) that do not have the best vendor support (old and outdated BSP's, bootloaders, etc) - RPi doesn't need that level of support. If Armbian wasn't there, many of these boards would be less than useful for many.
devman reacted to hatschi1000 in Helios4 Support
Talking about anecdotes: Some of you might remember the issue of booting my helios4 with 2 HGST Deskstar HDDs I had approx. half a year ago (https://forum.armbian.com/topic/6033-helios4-support/?do=findComment&comment=57981).
After we weren't able to find a solution on why the specific problem appeared here on the forum, I got in contact with @gprovost directly and after some back and forth messaging he kindly asked for the defective board to be sent back to Singapore. Soon after I received a fixed board back with which the problem did not appear anymore.
Right now I'm still tinkering around my setup (2x2TB HDD in btrfs-RAID1 underneath OMV4 with (at some point at least) an automated offsite backup using btrfs-snapshots), without having had any significant problems - a big thumbs up to @gprovost and the entire helios team for the straightforward communication and flawless exchange of the faulty carrier board.
devman got a reaction from esbeeb in Have "Supported" boards been "Torture-Tested" for storage/disk-IO?
Umm.. the Helios4 kits (full or just the board) come with all the necessary cables. SATA power, SATA data and AC adapter. The only thing you need to source yourself is the drives.
devman reacted to chwe in Banana Pi Zero
Wow, what a groundbreaking contribution to this thread. Especially cause you pointed clearly out
What's childish the bigger picture what you think what should change [/sarcasm]
For your notes: I've this board at home, I did some tests with it and finally lost the interest... I'm not a:
guy, so doing this stuff needs much more time for me than for a professional (and get false or not properly written stuff from professionals annoys me quite fast)... Even before I had the board at hand, we (as armbian community) pushed the vendor to:
Fix voltage regulation for CPU Release schematics Figured out that ETH is on CON4 (you could figure it out when reading the schematics carefully, but nowhere else) So even if this board does not get 'official armbian support', the childish armbian community helped to improve the situation for this board. To my knowledge, neither the boardmaker nor someone else sent a PR with the needed patches for full or csc support for this board to armbians github...
devman got a reaction from manuti in tried out armbian on orangepi one allwinner h3, thanks
The major difference between those three images is:
Stretch : modern 4.x (14? 17?) kernel, based on Debian
Bionic: modern 4.x (14? 17?) kernel, based on Ubuntu
Xenial: legacy 3.4 kernel, based on Ubuntu
The modern kernels are generally pretty-close-to-mainline linux, thanks to the hard work of the guys in the linux-sunxi group.
Since not everything has been reverse-engineered, it doesn't (yet) support all the device features.
h3consumption will not work with the modern kernels, so is not included
The legacy kernel is based off a vendor-provided kernel that has been cleaned up and had a few dozen (hundred) security patches on top of it.
It's based of the now end-of-life 3.4.y kernel tree that was initially released in 2012 and was marked end-of-life in 2016 following the final 3.4.113 update
All the hardware should work with these kernels, but the anything that relies on a modern kernel (eg. btrfs) won't work, and you'll be missing the last 2 years of security/stability updates.
devman reacted to TonyMac32 in Powering through micro USB
**UPDATE August 9 2018**
After some messing around I determined I had some sort of contaminant on my Tinker Board GPIO pins interfering with their conductivity. I have rerun my GPIO powering test and added the results below, there is no additional drop ( @tkaiser, @Frank Wu I apologize for the bad information) Other small updates include a possible reason for the small voltage reporting measurement error.
After having received an official Tinker Board Power supply, I submit my findings:
Test load hardware: Tinker Board S with internal voltage monitoring
Condition: No peripherals save mouse/keyboard/small cooling fan to prevent throttling
Load: minerd --benchmark
Measurement: For this I diverged from my typical labor-intensive periodic check with a meter and instead allowed the Tinker S to do the work. It for sure added noise to the measurement, and so some uncertainty, however I think for the purpose here it is sufficient.
The Tinker S reads low when you get to the 5.0V area. I measured the system voltage at 5.11V using the chassis supply, Tinker reported 5.02, however the values converged as they approached 4.7 Volts. This is possibly due to the reference voltage for the ADC drifting ever so slightly with or without load. With the new GPIO information, my meter and the Tinker Board were registering almost exactly the same voltage (within 0.02 volts) during the test, at 5 volts under load.
As to the supply itself:
Laser marked info is a nice touch, molded strain reliefs at the adapter and the plug, rocker switch for power, and 18 AWG wire.
5.0 V 3.0 A. This will be operating near the bottom end of the spec for USB peripherals on the Tinker due to voltage drop. The wire is heavy gauge and is in a "lamp cord" format, the jacket is flexible so I don't foresee too many internal strain breaks in anyone's future while using this supply. Data:
Analysis/Commentary (very loose format):
Using a 5.25 V chassis supply with my standard issue 1.5 meter 20 AWG cable that has seen a few hundred mate/unmate cycles for comparison, you can see that the system really needs to see more than 5V at the microUSB connector, and that cable age and wire gauge matter (my cable showed significantly more than 200 mV of drop, the new Tinker Board supply is showing a good bit less (the 4.9+ V spike is an anomaly I am attributing to the sudden release of electrical load)
Keeping an eye on the dmesg for indications of my USB peripherals resetting yielded no complaints. It is experiencing excursions just below the acceptable minimum, so that will be something to look out for. There is also the simple reality that the Tinker Board is not adequately cooled to pull this sort of current continuously, it goes into thermal throttling within seconds under full CPU load.
Recommendations for consumers:
This supply will work, and is at least on par with the other similar units on the market. The large conductors reduce one of the most common causes of voltage drop, and connector, I assume, is validated to exceed the 1.8 Amp minimum spec requirement for micro USB as per @Frank Wu. Such a validation provides some insight into the voltage loss, as increased voltage loss results in increased power dissipation at the connector, the thing being actively minimized by such design/test work.
Recommendation to ASUS:
If it is at all possible request the supplier increase the output voltage of this supply by 250 mV. At that point it could be considered the "go-to" supply for anyone wanting to maintain the micro-USB RPi form-factor compatibility.
devman reacted to tkaiser in Benchmarking CPUs
@numbqq from Khadas executed sbc-bench on a Vim 2 with Bionic and kernel 4.17: https://forum.khadas.com/t/cpu-frequency-up-to-2ghz/2010/24?u=tkaiser
I added your and his numbers + some potential insights to Results.md. So no need to re-test with Vim 2 (maybe only again with latest sbc-bench version since detailed results provide a lot more info. But I would still prefer Bionic/Stretch when testing with kernel 4.9 again )
devman reacted to tkaiser in Benchmarking CPUs (not yet a research article)
NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant):
Why are results irrelevant? For two reasons:
Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.
devman reacted to pzw in Beginner asks: How to power small LEDs from the OPi Zero
Since LEDs are current devices, they cannot be easily controlled in the voltage domain. So if you do not want to do pwm control, then you need to do current control. PWM control is a lot easier!
You need to use a driver circuit to control your LEDs. That can be as simple as a uln2803 chip, or a complicated current limiting discrete circuit.
First figure out what the voltage is you need to control, and the total amount of current. Then we might be able to help.
devman reacted to tkaiser in [preview] Generate OMV images for SBC with Armbian
After latest armbian-config updates the following will now also be tweaked if OMV is installed this way:
Disable Armbian's log2ram in favour of OMV's folder2ram Device workaround for Cloudshell 1 (checks presence on USB bus -- for this to work the Cloudshell 1 must be connected when installing OMV!) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working -- for this to work the Cloudshell 2 must be connected when installing OMV!)) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf
So only remaining difference to the 'dedicated' OMV images is now the following: The dedicated OMV images
set the correct timezone at first boot replace swap entirely with zram limit rootfs resize to 7.3 GB and automatically create a 3rd partition
BTW: There is currently no OMV uninstall routine and there will most probably never be one. While you could probably succeed with an 'apt purge openmediavault' this is also not recommended since too many leftovers will remain. If for whatever reasons after installing OMV you want to stop using it it's strongly recommended to start over from scratch with a freshly burned new image.