tkaiser

I'm OK with adding sysstat since it's small and data collection for sar/sadc (which may affect performance or add unnecessary writes to SD) is disabled by default.

Maybe this is not strictly related to Orange Pi PC but a few weeks ago I had problems with booting my device - mainly OpenELEC and I had to debug it somehow using serial port and the terminal. Unfortunately my PC is rather far from the place where I keep OPiPC. So I was forced to prepare separate device - cheap STM32 MCU based terminal display with 2.2" LCD screen directly supplied from Orange Pi PC 3.3V. It can be used also with other devices which allow serial console debugging.
Watch below videos for more details and the code:


Maybe someone finds it useful.

Since the question came up a few days ago on linux-sunxi IRC and Igor2 provided a nice tutorial to activate Ethernet Gadget mode, I added the necessary one-liner patch to our repo (disabled by default) and built now a kernel with all the necessary stuff patched and enabled: http://kaiser-edv.de/tmp/4U4tkD/Armbian_3.4.112_g_ether_kernel.tar.bz2
 
To get the idea please read through Igor2's Readme: http://igor2.repo.hu/tmp/opi_usb_gadget.txt
 
You should run a recent Armbian installation (apt-get update/upgrade), then extract the contents of the tar archive above somewhere, install the stuff using dpkg and then reboot:
tar xf Armbian_3.4.112_g_ether_kernel.tar.bz2 sudo dpkg -i linux-*.deb sudo reboot Then to be able to use the OTG as Ethernet Gadget device I found that we need a slight modification (since it's not /sys/bus/platform/devices/sunxi_usb_udc/role but /sys/bus/platform/devices/sunxi_usb_udc/otg_role):
echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role modprobe g_ether echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role Et voilà: In the very same moment the MacBook that powers the BPi M2+ I test with notified me that a new network device appeared and this looks like:
bash-3.2# system_profiler SPUSBDataType [...] RNDIS/Ethernet Gadget: Product ID: 0xa4a2 Vendor ID: 0x0525 (PLX Technology, Inc.) Version: 3.33 Speed: Up to 480 Mb/sec Manufacturer: Linux 3.4.112-sun8i with sunxi_usb_udc Location ID: 0x14200000 / 5 Current Available (mA): 500 Current Required (mA): 2 BSD Name: en6 So from now on I can use the H3 board as network interface en6
 
If you know how to benefit from something like that (eg. using an USB powered NanoPi M1 -- BPi M2+ is simply too expensive -- as encrypting network device, eg. for offloading OpenVPN stuff), please try the aforementioned stuff out and report back.
 
I wonder whether we should not enable this one-line patch and the appropriate kernel config by default...

Since the question came up a few days ago on linux-sunxi IRC and Igor2 provided a nice tutorial to activate Ethernet Gadget mode, I added the necessary one-liner patch to our repo (disabled by default) and built now a kernel with all the necessary stuff patched and enabled: http://kaiser-edv.de/tmp/4U4tkD/Armbian_3.4.112_g_ether_kernel.tar.bz2
 
To get the idea please read through Igor2's Readme: http://igor2.repo.hu/tmp/opi_usb_gadget.txt
 
You should run a recent Armbian installation (apt-get update/upgrade), then extract the contents of the tar archive above somewhere, install the stuff using dpkg and then reboot:
tar xf Armbian_3.4.112_g_ether_kernel.tar.bz2 sudo dpkg -i linux-*.deb sudo reboot Then to be able to use the OTG as Ethernet Gadget device I found that we need a slight modification (since it's not /sys/bus/platform/devices/sunxi_usb_udc/role but /sys/bus/platform/devices/sunxi_usb_udc/otg_role):
echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role modprobe g_ether echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role Et voilà: In the very same moment the MacBook that powers the BPi M2+ I test with notified me that a new network device appeared and this looks like:
bash-3.2# system_profiler SPUSBDataType [...] RNDIS/Ethernet Gadget: Product ID: 0xa4a2 Vendor ID: 0x0525 (PLX Technology, Inc.) Version: 3.33 Speed: Up to 480 Mb/sec Manufacturer: Linux 3.4.112-sun8i with sunxi_usb_udc Location ID: 0x14200000 / 5 Current Available (mA): 500 Current Required (mA): 2 BSD Name: en6 So from now on I can use the H3 board as network interface en6
 
If you know how to benefit from something like that (eg. using an USB powered NanoPi M1 -- BPi M2+ is simply too expensive -- as encrypting network device, eg. for offloading OpenVPN stuff), please try the aforementioned stuff out and report back.
 
I wonder whether we should not enable this one-line patch and the appropriate kernel config by default...

Next try. This time I did not use the BPi M2+ (read as: any H3 device featuring an OTG port!) as transparent bridge between its Ethernet and the USB OTG port but configured a working connection between OTG port and USB port of my MacBook using a static IP configuration. On BPi M2+ I used this interface file:
 
 
 
This results in somewhat weird settings (hwaddress being ignored) but since everything's working fine I don't care that much:
 
 
 
Again approx. 115 Mbits/sec iperf throughput when using a short (AWG20 rated) USB cable between both devices. I also tried out my 'well known crappy cable' (I use normally to demonstrate how bad Micro USB for DC-IN is). This is 1m long instead of 20cm and throughput here is just 109 Mbits/sec (no transmission retries shown via ifconfig so it seems there's either a lower layer involved to verify data integrity or it's just latency due to cable length)
 
Potential use cases:
Simple wired interconnection: You have an OPi Lite and don't want to use an Ethernet dongle: Make the Lite the dongle. In g_ether mode all that's needed is connecting the Lite via USB to a second device and the Lite appears there to be an external USB-Ethernet adapter. You get transfer speeds that slightly exceed Fast Ethernet just using a simple USB cable USB-to-Ethernet adapter: Use an NanoPi M1 or BPi M2+ as external USB-to-Ethernet dongle (needs bridging -- see above). Both boards can be powered through the Micro USB OTG port (but then you have to take care to limit max cpufreq to approx 600 MHz to not exceed 500mA consumption. Or you use a device known to provide more amperage: USB3 ports have to provide 900mA and with Apple MacBooks from 2012 or younger you get 1100mA on the USB ports) Wi-Fi dongle: Using the same method you can attach any OPi Lite (or any of the other boards having a Wi-Fi interface) via USB to a host and using a bridged connection between wlan0 and usb0 the H3 SBC starts to act like a WiFi dongle. The last 2 use cases above are pretty boring or even weird. Now the fun stuff:
Use a cheap H3 device like OPi One between a slow router and the internet to offload VPN encryption (zador came up with this link a few weeks ago. You get the idea even just by looking at the pictures) Use a cheap H3 device as secure VPN endpoint (allow accesses to your VPN only when they originate from a sealed H3 device that will be used as Ethernet adapter from Windows machines... where tampering/installing software might not be allowed by an IT department or you simply can't trust them) Use Linux' transparent proxy support to implement an ad filter on a cheap H3 device between host and Internet (pretty easy using eg. squid and the gazillions of available tutorials) I'll have to test that with Windows soon since a customer of us has the problem that their centralized IT department doesn't allow installation of any software on their road warrior's laptops, they've to deal with a web based application that can't be fixed right now due to IT weirdness but the whole problem seems solveable by providing a bunch of NanoPi M1 that act as intelligent network devices (providing 3G access and fixing the web application on the fly through a transparent proxy approach -- it's just exchanging half a million article numbers )
 
BTW: NanoPi M1 and BPi M2+ start when powered through the Micro USB OTG port. On every Orange there's a switch in between that needs a small tweak: http://blog.atx.name/orange-pi-pc-first-impressions/ (Orange Pis also accept DC-IN through the Micro USB port but won't start so unless you fix that you need to provide DC-IN either through the barrel jack or GPIO pins)

In the meantime I found a 2nd use case: Using NanoPi M1 as Ethernet dongle doing fancy network stuff (for example handing this out to others to force them connecting them to their local network only through the H3 Ethernet dongle to ensure an uncompromised VPN endpoint for example)
 
NanoPi M1 could be powered reliably through an USB computer port given a short USB cable with low resistance is used and some settings are adjusted to ensure consumption never exceeds 2.5W which is possible limiting CPU clockspeed to 600 MHz for example (500mA should be provided at 5V --> 2.5W)
 
Why NanoPi M1 instead of small Oranges? Since the latter would require a little hardware tweak to power on when connected to an USB computer port through their OTG port: http://blog.atx.name/orange-pi-pc-first-impressions/

Post #6.
 
 
What do you plan to do with the M1? Using it with a 5MP camera module? I ask since this is still the only use case or why to buy a NanoPi. To be honest: Apart from the camera module NanoPi M1 with 1GB DRAM is almost identical to Orange Pi PC but the latter is faster (due to better voltage regulator and better overall heat dissipation limiting throttling situations) and costs less even when shipping is also considered. I still feel I'm overseeing something.
 
BTW: Regarding French Post I made some (pretty bad) experiences. My daughter moved to Montpellier last year and it was always 'adventure time' sending her parcels

Another "funny" use case: use OTG port for FEL, loading u-boot, kernel, initramdisk and few other files, then in initrd script configure g_ether and use rootfs on NFS through USB link.

I think there should be some trade-offs somehow. That maybe why Wens suggested me to look at the "dynamic overlays" path, where basic pins will be present in mainline DT, but not activated a special peripherals until some overlays would be loaded.

Next try: I removed the line from /etc/rc.local and added usb0 to /etc/network/interfaces as outlined here (assigning a static MAC address and changing the port role to OTG from within the 'pre-up' condition). I also added creation of br0 bridge device containing both eth0 and usb0:
root@bananapim2plus:~# cat /etc/network/interfaces.g_ether auto lo iface lo inet loopback # Wired adapter #1 auto eth0 iface eth0 inet dhcp auto usb0 iface usb0 inet dhcp hwaddress ether 82:bc:09:47:28:a9 pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role' auto br0 iface br0 inet dhcp bridge_ports eth0 usb0 (beware: this way the device itself won't be reachable via IP from the network since DHCP will fail with this configuration and it's just a transparent bridge between eth0 and usb0). The usb0 NIC on the Linux side appears as en6 on my MacBook when connected through USB:
bash-3.2# ifconfig en6 en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 6a:95:6f:ac:30:2b inet6 fe80::6895:6fff:feac:302b%en6 prefixlen 64 scopeid 0xe inet 192.168.83.200 netmask 0xffffff00 broadcast 192.168.83.255 nd6 options=1<PERFORMNUD> media: autoselect (10baseT/UTP <full-duplex>) status: active bash-3.2# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.83.1 UGSc 13 0 en6 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 8 10366 lo0 169.254 link#14 UCS 0 0 en6 192.168.83 link#14 UCS 2 0 en6 192.168.83.1/32 link#14 UCS 1 0 en6 192.168.83.1 bc:5:43:be:c1:e1 UHLWIir 14 506 en6 1169 192.168.83.200/32 link#14 UCS 0 0 en6 192.168.83.245 0:c:29:9c:17:3a UHLWIi 1 306068 en6 1200 So time to test raw throughput to another GBit connected OS X machine (192.168.83.245): ~115 Mbits/sec in both directions. This is the limitation of the g_ether device since BPi M2+'s GBit Ethernet device eth0 isn't here the bottleneck (680/930 Mbits/sec between BPi M2+ and the Mac Mini). So network performance of the g_ether device slightly outperforms a Fast Ethernet port (below 100 Mbits/sec). Nice.

...has been reduced to $5 maybe due to some public poking

We should stop talking about Samsung SoCs when it's Nexell instead: http://forum.armbian.com/index.php/topic/1409-sysbench-quick-cpu-perf-amd64-phenom2-pine64-xu4-a20/?view=getlastpost

Hi @tkaiser,
 
Unfortunately, this task isn't finished ...
First, all my patches have been submitted to linux-sunxi mainline almost 3 months ago and nothing is merged yet.
Several reasons lead to that : patches format, email issues, email headers corrupted, this last one is been solved/workarounded recently : Maxime Ripard told me that my tests using "git send-email" worked but earlier tests with "msmtp" didn't. I should now resend my patches soon as "v5"...
Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs (well, there so much GPIOs, is that really important to save them ?). @Wens suggested me strongly to go with overlays like C.H.I.P guys did.
So, this is a new task for me : getting familiar with Dynamic Overlays loaded from UserSpace !
I will have to study that , recompile new kernel of the OF flag, tests, overlay prototypes, etc.
I hope to met expectation, especially that "time is the missing ingredient" !
 
Ciao !

Thx for firmware and instructions. @slinde and/or @markbirss: Please remember that fex file should be exchanged (and reboot in between) and one minor tweak should also be applied, see my last comment: https://github.com/igorpecovnik/lib/commit/60e935b34e3ed8b2ed14cf812fc30b08506b1651#commitcomment-17864605
 
EDIT: F*ck, we're moving really quick! So I think @Igor has to add the firmware bits to the specific package (and then please also change the USB detect mode since we're then finally done with X2)

You're using sysbench (calculating prime numbers, on some CPUs with optimized engines -- eg. NEON/ARMv8 -- on some not). Sysbench can not be used to compare different architectures (unless your job is to calculate prime numbers, then this might matter for you since you get your prime numbers in less time). Do a simple google search for
sysbench kitchen sink site:armbian.com

Hi all,
 
since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:
 
Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.
 
My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.
 
But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:
 
Get kernel 4.6 (or even better 4.7-rc) up and running including the following:
Ethernet (required) USB, leds, serial and so on (required and works already since this is just .dts stuff) THS (required -- please also see issue #360)) WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple) HDMI (nice to have) SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?) Anyone?   Edit: THS update: http://irclog.whitequark.org/linux-sunxi/2016-06-13#16729515;

Just successfully tested another Realtek usb wifi dongle with the OPI ONE. Both AP and managed mode work as decribed for 0bda:0179 Realtek Semiconductor Corp. in instructions.
 
lsusb
 
Bus 001 Device 009: ID 0bda:8179 Realtek Semiconductor Corp. ( noname identified as 8188EU )
 
Aliexpress Link : http://www.aliexpress.com/item/1pc-Mini-USB-WiFi-Wireless-802-11-n-g-b-150M-LAN-Adapter-Network-Card/32292872916.html

Hi all,
 
since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:
 
Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.
 
My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.
 
But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:
 
Get kernel 4.6 (or even better 4.7-rc) up and running including the following:
Ethernet (required) USB, leds, serial and so on (required and works already since this is just .dts stuff) THS (required -- please also see issue #360)) WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple) HDMI (nice to have) SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?) Anyone?   Edit: THS update: http://irclog.whitequark.org/linux-sunxi/2016-06-13#16729515;

Thanks for at least some encouragement While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure.

Since I listed the history of different BSP kernels and settings a few posts above and have been asked by a fellow what's different between a recent Armbian Xenial desktop build and for example this OS image here based on loboris' build script... I thought: let's give it a try.
 
First big surprise: All the overheating issues we thought would've been resolved are still there in an OS image released a few weeks ago!
 
This image uses the insane overvolting settings from loboris so H3 is all the time fed with at least 1.3V and jumping up to 1.5V (see on the left the Vcore values). This way it's ensured that even when the board is totally idle SoC temperature will be close to 60°C (I've a heatsink applied to my Orange Pi PC Plus I tested with so be prepared that without a heatsink it gets even worse):
 

 
I installed RPi-Monitor and let the thermal fix script do its job to cure the installation:
root@OrangePI:~# wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh | /bin/bash Installing RPi-Monitor. This can take up to 5 minutes. Be patient please [x] done Checking and installing sunxi-tools if not available [x] done Patching RPi-Monitor to deal correctly with H3 [x] done Now you're able to enjoy RPi-Monitor at http://192.168.83.156:8888 root@OrangePI:~# wget -q -O - http://kaiser-edv.de/tmp/H9rWPf/fix-thermal-problems.sh | /bin/bash Trying to fix thermal settings on this board. This might take a few seconds up to 3 minutes. Please be patient. Starting now. Done Successfully repaired broken overvolting/overclocking settings. Reboot necessary for changes to take effect root@OrangePI:~# reboot Afterwards the VDD_CPUX voltage switched fine grained, temperatures looked better but of course this is still far from perfect since in loboris kernel the 1.3 GHz cpufreq step is missing so now with the sane settings maximum cpufreq isn't 1536 MHz but 1200 MHz.
 
I made also quick sysbench runs using 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' (these are the three temperature peaks you see in the graph above):
Insane overvolted settings allowing 1536 MHz max: 116.3053 seconds After applying thermal fixes allowing 1200 MHz max: 117.9727 seconds And finally after rebooting the board into the normal Armbian installation allowing 1296 MHz max: 109.2925 seconds Since I refrain from using an annoying fan both the insane overvolted settings and the sane known as 'bronco settings' perform identical which is absolutely no surprise since with loboris overvolted settings H3 overheats way too early and therefore throttling is more heavy than with sane settings. Running with Armbian performance increases automagically since we optimized also our kernel settings and allow way more cpufreq steps (interested in details? Then read from here on)
 
I wanted to test other stuff (GPU/X11) but unfortunately loboris kernel not only misses the 113 patches we apply to the newer BSP kernel (just a few hundred security fixes still missing between 3.4.39 and 3.4.112) but also essential USB HID drivers eg. for my Apple keyboard and mouse so I wasn't even able to login. I then thought about replacing the old kernel with our latest Armbian kernel:
 
 
 
But to no avail since after converting our kernel image to the uImage the outdated u-boot on all the older OS images expects I rebooted and our kernel paniced since I failed to provide a way to look for the rootfs: http://pastebin.com/ehyk1XhQ
 
Anyway: I won't waste any more time with this since it's just crazy to use an image based on a horribly outdated 3.4.39 kernel lacking so much fixes and features. I could confirm that the most recent version of the GC2035 camera driver we included in Armbian yesterday is way better than the one included in this/loboris image, that thermal/performance settings still suck, no support for Wi-Fi on the new Oranges there, no access to eMMC (though it should work with loboris install_to_emmc script but I haven't tested since I don't want to wipe out my nice Armbian installation on eMMC) and so on.
 
Since I also don't know which real world applications make use of OpenGL ES (apart from irrelevant benchmarks and some games where it seems to be confirmed that Armbian's switch to the new BSP kernel and clocking Mali 400 with 600 MHz increases performance by 30%) I saw also no need to further waste time with testing other images. But as usual: YMMV

I'm glad to give something back to Armbian.

Banana Pi M2
PS: I don't use the latest Armbian toolchain. I'm using the .ignore_changes feature.
root@m2-bare:~# uname -a Linux m2-bare 4.5.4-sunxi #2 SMP Sat Jun 11 13:05:21 CEST 2016 armv7l GNU/Linux root@m2-bare:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 17: 0 0 0 0 GIC-0 29 Edge arch_timer 18: 11870 265608 31223 36550 GIC-0 30 Edge arch_timer 21: 0 0 0 0 GIC-0 50 Level sun4i_timer0 22: 0 0 0 0 GIC-0 83 Level sun5i_timer0 27: 0 0 0 0 GIC-0 82 Level 1c02000.dma-controller 28: 1653 0 0 0 GIC-0 92 Level sunxi-mmc 29: 8549 0 0 0 GIC-0 94 Level sunxi-mmc 30: 27 0 0 0 GIC-0 104 Level ehci_hcd:usb1 31: 0 0 0 0 GIC-0 105 Level ohci_hcd:usb2 40: 2251 0 0 0 GIC-0 60 Level sun4i-ts 41: 425 0 0 0 GIC-0 32 Level serial 42: 43646 0 0 0 GIC-0 114 Level eth0 48: 0 0 0 0 GIC-0 72 Level 1f00000.rtc 57: 0 0 0 0 sunxi_pio_edge 4 Edge 1c0f000.mmc cd 181: 43 0 0 0 sunxi_pio_level 0 Level brcmf_oob_intr IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 3407 15690 13225 7318 Rescheduling interrupts IPI3: 6 8 3 6 Function call interrupts IPI4: 0 0 0 0 CPU stop interrupts IPI5: 0 0 0 0 IRQ work interrupts IPI6: 0 0 0 0 completion interrupts Err: 0 root@m2-bare:~#

I did another test over night with 624MHz. It pretty much looks the same.
 

Beelink X2 running "lima-memtester 100M" and the setting "dram_clk = 648". Grey background entire time, but only running 1 core at end--it is possible that I messed up the heatsink when I opened it up to solder serial out.

Here is the result of my Beelink X2 running "lima-memtester 100M" and the setting "dram_clk = 648". Test went well, cube was spinning with grey background the whole time. I can see it disabled one cpu-core after about 30min.