devman got a reaction from manuti in Big sale on Odroid MC1
Probably, depending on your content type and target device. I did some rudimentary testing with transcoding on the NanoPi M3, and it technically worked.
I had stability issues though, so I switched to a small/cheap x86 box that supported hardware transcoding.
devman reacted to Igor in Armbian 19.11.y release notes
Upgrading your Armbian to v19.11.y
This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
Choose latest version of 19.11.x and select upgrade according to this scheme:
Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
Main build system changes
Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
LIB_TAG="v19.08" to your build config file which by default is:
userpatches/config-default.conf Then run your script as you did before.
Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.
In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.
Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
devman reacted to mu-b in Espressobin support development efforts
Well I've fixed my instability issue. The root cause was the same as https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots, and it was power related. The fix was to replace the 470uf/16V capacitor (component EC1 on the schematic) sat immediately behind the 12V DC jack which under testing leaked under certain temperature conditions (variations). As such the board is now stable and has been running OpenWRT 18.06.2 for 24 hours with memtester and stress running continuous during that entire time.
I'll leave it a few more days, after that I'm going to assume that its fixed and that is what NetGate were referring too when they mention 'a power related component'.
And GlobalScape will not tell you, they know of the problem, in a reply from Kevin Liu he says 'Yes, I do have knowledge regards the power related component issue.' when I asked which component it was so i could attempt to replace myself.
devman got a reaction from gounthar in Which boards to get a VPN server and a VPN client?
heh, sorry, I mean that the neo2 has no wifi. It's a ethernet-only board, and (without breaking out the pin header) only one usb-A port soldered.
The neo plus 2 might be closer to what you're looking for, but it's not a board I have. Should be very, very similar in performance though.
devman got a reaction from gounthar in Which boards to get a VPN server and a VPN client?
I'm running wireguard on a pair of nanopi neo2's, and iperf is giving me >200mbps throughput at ~40% load
devman reacted to Igor in Monitoring your system health with HTOP (big.LITTLE)
... and I have build it and pushed to Armbian stable repository (Stretch, Xenial and Bionic; armhf+arm64). First boot scripts also creates CPUfreq config based on CPU count. More can be added if there is an interest ... Package can be installed via apt update and upgrade while auto config feature will work only on self made images.
devman reacted to @lex in Monitoring your system health with HTOP (big.LITTLE)
Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
DEB package and source code in case you want to extend or fix things.
Be aware the process list and task can be very intrusive if you want to monitor many things at once.
It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
devman reacted to chwe in Daily (tech related) news diet
You probably should link to the original post cause the Register tends to be a bit....
His statements in the whole context sound a way more reasonable:
besides a few SBCs, ARM SoCs are 'only' found in Android, where power-consumption matters a way more (it matters for servers as well but it's not the 'main' thing, whereas for mobiles it is).. Routers etc. are mostly driven by MIPS. Intel tried once (with throwing a bunch of money into it) to enter the android world but they horribly failed and canceled more or less their low consumption small chips...
and that is actually true, Armbians buildscript is also x86 only, cause it might be hard to find good build servers to natively build our images on ARM.
Price matters.. The more volume, the lower the price.. See (android) TV-boxes.. where intel has no chance to enter the market..
well, I quoted this one just cause it's funny.
I programmed once my calculator, it was painful cross-platform an on itself.. But that's more related to the capabilities of it.. I think @JMCC is one of the few here who compiles debian packages on the SBCs itself (except @wtarreau)..
make a nice case and don't tell him that there's a pinheader on it, maybe he don't see a difference..
Don't get me wrong, willy's buildfarm (https://www.cnx-software.com/2019/01/07/nanopi-neo4-build-farm-rk3399-overclocking/) is great, but not everyone wants to build such a farm just to avoid cross-compiling.
besides merging he probably never contributed a single bit to ARM development on Linux (I could be wrong here, I don't have record on which sub-systems he contributed in the beginnings). But as he stated multiple times, he's more 'kernel manager' and gate-keeper than programmer.. Just read through a few speaks from him to get a clue about his job in kernel development.
It's not that he dislikes arm.. There are multiple statements where he was in favour for an arm based machine (especially during the spectre/meltdown phase he made some of them). But where others try to be as polite as possible, he prefers a rather strong wording to make his points clear. And I would say he has enough valid arguments to point out why arm is nowhere on server at the moment.
IMO not at all, development of linux on arm won't stop cause Linus says that he doesn't think that arm will make it on the server market.. All our SBCs (except maybe the SolidRun) aren't server SoCs. We deal mostly with TV-box SoCs here.. As long as they push their stuff upstream and the code quality is good, he will merge it.. He just points out clearly why (in his opinion) arm won't enter the server market.. There aren't (m)any affordable workstations nor notebooks nor simple desktop computers based on arm, so that people deploy stuff on ARM. Even on bigger distros (Debian, Ubuntu, Suse etc.) arm is only the side-kick of x86 or AMD64. I don't think that this will change soon. Just look at commercial binary only software... If there's Linux support for it, it's mostly x86 only.. More or less nobody provides arm64 or armhf packages of their binaries..
devman got a reaction from lanefu in Is Mali GPU driver available in Mainline for H3?
I remember reading the history of the Lima project a while ago, and it basically comes down to that ARM doesn't WANT an open-source implementation of the graphics drivers, as they make a not-insignificant amount of money licensing theirs.
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.