lanefu

Consumption update: All settings below made with 'IoT settings' (DRAM downclocked to 132 MHz, USB turned off):
 
- only Ethernet active, idle: below 500 mW (475 mW measured)
- only Wi-Fi active, idle: below 550 mW (450-520 mW measured, please keep in mind that actual consumption depends on your environment)
- both Ethernet and Wi-Fi disabled, idle: below 410 mW (400-410 mW measured)
 
That means in featureless mode OPi Zero consumes almost as less as an RPi Zero but more importantly in connected situations (be it wired or wireless) consumption is way below RPi Zero since there adding USB Wi-Fi dongles or an USB Ethernet adapter adds significantly to overall consumption).
 
This also means that difference between Ethernet active and disabled is just 70 mW (we saw 200 mW with all other H3 boards so far, the difference might be due to H2+ not featuring Gbit Ethernet capabilties any more and/or different Ethernet magnetics on this board).
 
All in all that looks really promising. A board that performs at RPi 2 level keeps real-world consumption below RPi Zero level while having almost RPi 3 feature set (Wi-Fi + Ethernet, but here Ethernet is not hanging off USB but is real, and here we have 4 real USB ports that do not have to share bandwidth). Combine that with the PoE option we can only hope that Xunlong will start to solder 1 MB SPI NOR flash as default in the future, then this board would already be perfect.

WiFi is planned, BT also.
 
Opi zero (and PC2) just arrived on my desk today and I got Armbian running on it in no time   We need to add wireless drivers and apply fine tuning ... PC2 will be tested later.
 

Hi,
 
a few months ago I have build a USB to UART "multiplexer" device, to monitor my multiple Orange Pi PC's using only one USB connection to a separate Host [1].
 
You can connect up to 8 hosts to the device simultaneous. And you can switch between the different inputs.
Only one USB connection is needed to your host you want to use as master.
A commandline tool is available to control the device.
 
Its also possible to send data through the device to the connected hosts. It works like a normal USB to serial adapter.
It is not possible to read the incoming data from all connected hosts simultaneous.
 
I am use it to log the boot process of my cluster nodes [2].
 
Maybe someone is interested. It is OpenSource and OpenHardware [3].
 
---
 
[1] The device: https://klautesblog.blogspot.de/2016/09/usb-serial-multiplexer-usb2serialmux.html
[2] My cluster: https://klautesblog.blogspot.de/search/label/ChinaCluster
[3] Git project: https://git.okoyono.de/klaute/USB2SerialMux

Hello,
 
I know this will be a controversial subject, but I often like to see what's happening in a devel repository by browsing commits.
 
I start by looking at the commit titles (first commit message line) to approximate the interest that particular entry is to me, then if deemed interesting, I'll read the full commit message to understand what it is about, then if still interested I'll go read the code.
 
I think this is a fairly straightforward approach to digging in a codebase or development stream, avoiding to loose time on things outside of interest scope, and allowing to focus on specific subjects.
 
So, in order for this workflow to be doable, the commit messages content need a minimum level of details, which is what I'm asking the community to act upon.
 
Would it be possible to mandate a bit more work on that front ?
 
I'm not against messages like "Whitespace fix", "Typo fix", "Better comment", anything that explains a bit what the code diff is about.
 
WDYT ?
 
PS: I think armbian is not so bad wrt $SUBJECT, it just needs a little bit more. I've seen far worse projects where I wouldn't even ask for better commitmsgs, so take that as an endorsement of the (already good) quality level of the work done.
 
Thanks

Building using Docker should not be much different from standard setup, but we could use more testing, polishing and enhancements for the build process.
 
This includes
testing and providing logs for full image build to check if current workarouns for loop devices are working or need adjustments enhancing Dockerfile if there are any options that may make default experience better testing whether Docker implementation on Windows works fine for full image builds

512MB variant is available too: https://www.aliexpress.com/store/product/New-Orange-Pi-Zero-H2-Quad-Core-Open-source-512MB-development-board-beyond-Raspberry-Pi/1553371_32761500374.html (unfortunately SPI flash not populated by default) 

Infrastructure is in the process of moving to professional grade server in any case since current low power, low cost server XU4 can't cope with the traffic and I don't have any alternatives left in this range.
 
I don't mind extending a forum a little bit.
 
If we are adding a new forum, where? Here:
 
General discussion
 
3rd party builds
Openelec, Gentoo, RetrOrangePi, Android, ...

Sorry, misunderstanding, it's quite the opposite. I'm only concerned about fixes/improvements that don't get back 'upstream'. I consider Armbian not a distro but a build system and in the meantime some sort of joined development approach (at least that was one of my goals promoting Armbian).
 
With regard to "yet another forum": micro communities tend to create micro realities (see banana-pi.org or pine64.org forums for worst examples) and it wouldn't be the first forum run by individuals that got shut down since the 'owner' got bored after some time when a huge amount of knowledge and efforts was already collected there and is then lost forever.
 
@moondeck: It would be great to prevent just another orphaned/dead Armbian subforum somewhere (see pine64.org or orangepi.org) so please create a sticky thread there sending people searching help for Armbian to http://docs.armbian.com/  (forum link is there twice, this should be sufficient).

https://www.sendspace.com/filegroup/wOi2h%2FyA2aQMRnrr%2BfGNYA
 
for the png and ans files.
 
and to view it:
 
http://imgur.com/aA4LVrP
 

 
 
by me.
 
=)
 
tell me what you guys think.
 
 
 

I am happy to report success when using native 1280x1024 resolution on an older Samsung 191T display using
h3disp -m33 -d on an Opi Pc updated to 5.20.
On the other hand the 8192cu driver delivered with 5.20 does not work, wireless only started to work after local
recompiling and installation of the module as described in the documentation.
Power to the device also had to be cut and reapplied.
 
Thanks for the nice work!
gnasch

In order to make armbian better, we need your help with testing. 
 
Why?
there are simply too many boards to handle, there are task which can't be automatized, there are bugs which are not seen from our perspective. What kind of tests?
 

booting, user creation, updates, upgrades checking if basic supported functions work: video, audio, network, wireless, AP mode do nasty thing to your board and report. How to test?
Download nightly images from here. 

You want to test image which is not there?
Add those two parameters with desired targets to board's config and create a pull request. and / or
change to our daily build developer repository: deb http://beta.armbian.com $(lsb_release -cs) main utils $(lsb_release -cs)-desktop Note: you are entering developer area and things will sometimes be completely broken. Don't use this repository in production!
 
When bug is found?
 
* Provide logs with armbianmonitor -u or type as much data as you can.
 

Check if it's not already on the list and if not, add it there, [optional] Open a topic in issues support forum if you think we need to discuss it, [optional] Fix it.  
 

Ha! Totally overseen that. And that might also explain external Magnetics? Anyway: If OPi Zero really supports passive PoE then this would be the 2nd or even 3rd time (bootable SPI flash) that Xunlong silently listens to community and reacts on our demands

Have you already seen this low-end Marvell announcement (now on Kickstarter): http://www.cnx-software.com/2016/09/23/marvell-espressobin-board-with-gigabit-ethernet-sata-pcie-and-usb-3-0-to-launch-for-39-and-up-crowdfunding/
 
I would prefer this since I would never ever implement SOHO/home RAID (again). ZFS+raidz2 is ok for more than 2 disks, everything else stinks (especially all those cheap HW RAID chips) if you don't have every SPoF lying around (since otherwise the R in RAID becomes a joke)

Ok, so, I went a little overboard with this but here is my current NanoPi Neo setup. They are all running the latest Ubuntu build, if anyone wants the output of anything let me know. 20 units in total.
 

 

I have installed  JackD and  Guitarix  on my OpiPC+ and it looks promissing. As Soundcard i have plugged in a cheap Behringer UCA202 

We provided this week experimental Armbian images with mainline kernel for a few H3 boards. On the official download pages there are a few variants with 4.6.7 lurking around and here you find some with 4.7.2: http://kaiser-edv.de/tmp/w8JAAY/
  Those for the NEO are also suitable for NanoPi M1 and OPi One/Lite, the one for OPi PC Plus can be used on any of the larger Oranges (no Ethernet on +/+2/+2E -- don't ask please, this is stuff for later) since they all use the same more sophisticated voltage regulator being able to adjust VDD_CPUX in 20mW steps (VDD_CPUX is the voltage the CPU cores are fed with). The procedure is called dynamic voltage frequency scaling and the idea behind is to lower voltage on the CPU cores when they're running at lower clockspeeds and vice versa.   Works pretty well with legacy kernel in the meantime but it required a lot of work to come up with optimal settings that are still reliable (undervolting the CPU causes stability problems and data corruption!) while also providing best performance results (lower VDD_CPUX voltage, less heat, later throttling). For details please read through the whole issue here: https://github.com/igorpecovnik/lib/issues/298   So what has changed with mainline kernel now? In Armbian we use megi's kernel branch containing Ethernet and dvfs/THS patches and a few others. What's still missing and what do you get now when trying out these mainline images? No HDMI, no audio, no sophisticated SBC stuff like I2C, SPI and so on (unless you know how to deal with device tree overlays).   But USB, Ethernet on all Fast Ethernet equipped devices (no network on GbE models currently!), cpufreq scaling / dvfs, working WiFi and with 4.7 also the opportunity to test out USB OTG and the new schedutil cpufreq scheduler.   My 4.7.2 Armbian releases contain also a new armbianmonitor variant that can deal with mainline kernel on H3 boards (different templates needed and a different method to get VDD_CPUX values -- fex file vs. device tree) and can install cpuminer. Why cpuminer? To test the efficiency of throttling settings -- see below. As usual RPi-Monitor can be installed using 'sudo armbianmonitor -r' and now cpuminer will be installed by 'sudo armbianmonitor -p' (p for performance measurements).   To let cpuminer run in fully automated mode do a 'touch /root/.cpuminer', then minerd in benchmark mode will immediately start after booting and results will be collected by RPi-Monitor (not on the status page but only on the statistics page -- actual values aren't interesting only behaviour over time!)   Dvfs settings for Orange Pi PC and the other SY8106A equipped H3 devices already look good and work quite well (although I would tweak them here and there) while those settings for the H3 devices with the more primitive voltage regulation do not.   I used a NanoPi NEO for the test but the results apply to all H3 boards that use only 2 different VDD_CPU voltages: NanoPi M1/NEO/NEO-Air and OPi One/Lite. Unlike the Oranges NanoPI M1 and NEO overheat more easily, the latter especially (maybe due to smaller PCB size, single bank DRAM configuration and LDO regulators nearby the SoC?). And tested on the only remaining NEO that does not wear a heatsink.   In the beginning I allowed 1200 MHz max cpufreq but since I neither used heatsink nor fan throttling had to jump in to prevent overheating. In this mode H3 started running cpuminer at 1200 MHz, clocked down to 1008 MHz pretty fast and from then on always switched between 624 MHz (1.1V VDD_CPU) and 1008 MHz (1.3V VDD_CPU). The possible 816 MHz (1.1V) in between were never used. Average consumption in this mode was 2550 mW and average cpuminer score 1200 khash/s:     I then limited max cpufreq to 816 MHz through sysfs and let the test continue. In the beginning H3 switched between 624 and 816 MHz but since SoC temperature further decreased H3 stayed then all the time at 816 MHz and below 75°C (the highest allowed cpufreq at the lower VDD_CPU core voltage with megi's settings!). Average consumption in this mode was 2420 mW and average cpuminer score 1350 khash/s.   This is how cpufreq and temperatures correlated over time:
  So we got an increase in performance from 1200 to 1350 khash/s (+12.5%) while being able to lower consumption by 130 mW (2550 mW vs. 2420 mW) so not only performance increased but also performance per watt ratio if we manually adjust maximum cpufreq and forbid everything above 816 MHz. Quite the opposite of what one would expect   At least it should be obvious that dvfs settings for the small H3 devices need some attention. I monitored consumption through AXP209 on a Banana Pro feeding the H3 device through its USB port. The high voltage fluctuations due to the NEO's voltage regulator constantly switching between 1.1V and 1.3V can be seen until 8:12, then the '30 minutes average value' stabilized at 8:42 and the real consumption difference could be read: 130 mW:         With legacy kernel we defined a lot more possible cpufreq/dvfs operating points so let's give it a try: Same hardware setup (same NEO, same USB-to-Micro-USB cable from Banana Pro to NEO, same upright position for nearly identical thermal behaviour), same DRAM clockspeed (408 MHz) but different DVFS/THS settings of course:     If we compare mainline kernel with max cpufreq limited to 816 MHz and legacy kernel we get 4.7.2: 1350 khash/s, ~74°C, constant 816 MHz cpufreq, 2420 mW reported consumption 3.4.112: 1150 khash/s, ~80°C, 648-720 MHz cpufreq, 2610 mW reported consumption Looking at numbers 1 to 3 it simply feels weird: lower clockspeed, lower performance but higher temperatures. Would be an indication for different thermal readouts between mainline and legacy kernel (we had the same issue half a year ago when switching from BSP u-boot to mainline: temperature readouts 10-15°C lower).   But fortunately I also monitored consumption and there it's 200 mW more. On the same hardware with the same hardware setup. So there is really something happening on the NEO that wastes more energy when running minderd with legacy kernel and that might be responsible for higher temperatures and more aggressive throttling leading to lower performance (at least that's the only possible reason I can imagine)   Since we already know that on the NEO adjusting DRAM clockspeed with legacy kernel makes a huge difference regarding consumption and temperatures (see post #13 here) maybe the whole problem is related to different DRAM config on the NEO (single bank vs. dual bank on all other H3 devices) and something's wrong with mainline kernel here? Don't know but already decided to repeat the test with NanoPi M1 (dual bank DRAM config but also the primitive 1.1/1.3V voltage regulation)

I've done a PR for applying those Dynamic DT Overlays patches into "sunxi-next".
Next thing to do is to apply it also into "sunxi-dev".
 
EDIT : "sunxi-dev" done ! it was a bit more work since part of the patches were not required anymore in 4.8.x

task : armbian-gc2035-fswebcam package script posted on GITHUB and merge request issued.
 
https://github.com/gravelrash/lib/blob/master/extras/fswebcam.sh
 
Pending acceptance / rejection / comments.

EDIT: The tutorial below is based on outdated instructions. With the most recent Raspbian images the same is possible with less efforts using the g_ether module. All details here: https://gist.github.com/gbaman/975e2db164b3ca2b51ae11e45e8fd40a
 
Today arrived both a RPI 3 and a RPi Zero. I want to use the latter to confirm some consumption measurements we're currently doing to prepare Armbian low-power (or IoT) settings for a couple of boards (see here and here for details)
 
To my surprise I wasn't able to login to RPi Zero without soldering wires or GPIO header since I've no Micro-HDMI cable/adapter, my only Micro-USB adapter is a 90° one preventing to power the board when I want to connect an USB-Ethernet adapter so I thought: Let's use the RPi's USB OTG port like we do with some H3 boards: For both powering and USB gadget stuff in this case using as serial console via the g_serial module.
 

 
I found this nice tutorial here: https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/overview
  But they assume you are able to boot into Raspbian on your RPi which I can't so I thought about burning the SD card with Raspbian Jessie Lite the usual way but then inserting it into a card reader attached to one of my Armbian installations and do the modifications there. Works flawlessly, only minor caveat is that the kernel version then used is a bit outdated (4.4.0-rc5 while latest Raspbian already uses 4.4.11-v7).   So the steps are as follows: I burned the Raspbian image on OS X, ejected the card, then used an USB-SD-card reader and attached it to an Orange Pi PC running Armbian. In the next steps we will mount both SD card partitions, copy the stuff to the correct locations, add g_serial module to be loaded automatically and activate the necessary getty from within /etc/rc.local. Looks then like this: cd /tmp wget http://adafruit-download.s3.amazonaws.com/gadgetmodulekernel_151226a.tgz mkdir /mnt/sda1 mkdir /mnt/sda2 mount /dev/sda1 /mnt/sda1 mount /dev/sda2 /mnt/sda2 tar xf /tmp/gadgetmodulekernel_151226a.tgz cd tmp/boot/ # backup old kernel image mv /mnt/sda1/kernel.img /mnt/sda1/kernel_backup.img # move stuff to correct locations mv kernel.img /mnt/sda1/ mv overlays/* /mnt/sda1/overlays/ mv *.dtb /mnt/sda1/ cp -R modules/lib/* /mnt/sda2/lib/ echo 'g_serial' >> /mnt/sda2/etc/modules sed -i '/exit 0/isystemctl enable getty@ttyGS0.service' /mnt/sda2/etc/rc.local sync cd / umount /mnt/sda1 /mnt/sda2 (this will also work with any recent Linux distro and in case you burned the Raspbian image already on Linux you can do all the stuff above directly afterwards too).
 
Now back in OS X the RPi's OTG port simply connected with a good (20AWG rated) USB cable it looks like this:
Gadget Serial v2.4: Product ID: 0xa4a7 Vendor ID: 0x0525 (PLX Technology, Inc.) Version: 4.04 Speed: Up to 480 Mb/sec Manufacturer: Linux 4.4.0-rc5+ with 20980000.usb Location ID: 0x14200000 / 30 Current Available (mA): 500 Current Required (mA): 500 This 'UART adapter' appears as /dev/cu.usbmodem1421 and so it's time to login:
macbookpro-tk:~ tk$ minicom -D /dev/cu.usbmodem1421 -b 115200 Raspbian GNU/Linux 8 raspberrypi ttyGS0 raspberrypi login: pi Password: Linux raspberrypi 4.4.0-rc5+ #10 PREEMPT Thu Dec 24 22:52:14 EST 2015 armv6l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. pi@raspberrypi:~$ w 14:38:03 up 0 min, 1 user, load average: 0.48, 0.18, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT pi ttyGS0 14:37 1.00s 0.82s 0.03s w Now the fun begins, let's check out whether an Orange Pi Lite consumes less than RPi Zero or not!

Hey I managed to get the WiringOP libraries to build with the Python WiringPi libraries on my OPI One.     I wrote up a quick gist and made a dinky fork to save some people some time:
 
Orange PI WiringPi-Python Gist
 
PS: Igor, TKaiser, and other contributors.   Armbian is a really great distro. I'm very grateful for all your hard work.

i did a 4.6.4 kernel armbian build for my opi one yesterday. I was delighted. Ethernet worked. Docker worked after only an apt-get install. i launched a basic ubuntu xenial arm container and it held together. nothing like a 512 meg docker host
 
Tapatalk thinks its important to tell you im using tapatalk from a phone.

Those past days, I was working on getting DT ConfigFS Overlays into sun8i-dev.
 
Today, I've suddenly saw that the version from that we are using from https://github.com/megous/linux(branch orange-pi-4.6) change from 4.6.2 to 4.6.4.
I didn't care much until I figured out that we loose all the UART1/2/3/4 (only keeping the debug UART0) as well as all I2C (except the one on r_pio for PMIC).
 
So, "megous" github is back to almost what linux-sunxi github is providing, without all the patches for UART/I2C that I had prepared 3 months ago.
I get I will have to re-integrate them on our side until there merge into real linxx-sunxi branch.
 
 
 

Discussion thread for github issue 423 - glshim packaging. Related discussion is here. Glshim development happens here.
 
Current status: build script is mostly working, I'm fixing minor issues before making a github commit:
- avoid hardcoded dependencies
- make sure OpenGL apps can be built on target system
 
Once these are resolved, I'll post a link to my commit for an eventual review and will be ready to create a pull request.
 
----------
Unrelated topic: armbian build script fixes for Debian Jessie
Although only Ubuntu distribution is supported by armbian build scripts, Debian sid and above have all the necessary packages and should work fine. For Debian Jessie, emdebian repository should be added to apt sources, as described in cross toolchains wiki. Some of the cross toolchain packages have different names on Jessie as well. I have modified lib/general.sh file to account for those differences and be able to run armbian build scripts on my Debian Jessie machine. If there is interest, I could create an additional issue / pull request for this.

You're right !
I've done new build today, and it worked !
(Probably when I did it more than a week ago, still with 4.6.2, there was some patches missing about cpu throttling which is now included)

I posted 2 days ago some progress on Dynamic Device Tree Overlays, but I think I should report here too.
 
http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/#entry12696
 
 
I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.