lanefu

Hello from Armbian!  4K output is configured by default, however my monitor was not behaving properly.  Otherwise USB, ethernet, etc are working, And it is smoother than the ASUS tinkerOS 1.4
 
It could be that the MiQi is more robust bootloader wise, it might be able to overlook some formatting differences on the SD card where the Tinker Board cannot, my net crawling did uncover some comments to that effect concerning the Tinker Board being "inflexible".

Thank you, but I am not sure I need another board / new costs. Recently I denied two board donations, from board makers, with this (simplified) explanation: "We can't accept more boards, since we are small amateur group, overwhelmed with work / boards.". If they still want the board here, project is open - they can add it ... or try to make a deal.

I think this
means that he most likely used a prebuilt nightly image and upgraded it from the repository.
 
Anyway missing characters in the logs don't look good. Maybe voltage regulator or CPU frequency limits were lost during u-boot patches upgrade and now the board is undervolted/overclocked. I'll check the commits later.
 
Edit: CPU frequency limit and CVBS output settings was lost, I'll add a patch to fix this.

I upgraded to nightly beta.
 
I added to /etc/network/interfaces:
auto eth0
allow-hotplug eth0
iface eth0 inet manual
pre-up /sbin/ifconfig eth0 down
pre-up /sbin/ifconfig eth0 up
pre-up /sbin/ifconfig eth0 down
 
 
With this extra "pre-up" config I get full duplex connection (without only half duplex).
 
A: Macbook, Samsung TV: 100Mb/s full duplex
B: Old laptop Asus F5R, it is equipped with 10/100Lan card, but for some reason it is advertising itself 10Mb/s only (Live Ubuntu + Acronis True Image CD). Doesn't matter.
 
 
I use this little board for wlan0 to eth0 bridging and it's really good.
 

I'd like to add another method which I found "cleaner" and "easier".
Debian provides an easy way to set sysfs values after reboot via the /etc/sysfs.conf file and the /etc/sysfs.d/ directory.
(This is basically the same as the relation between the /proc/sys and sysctl.conf and sysctl.d.)
 
My use-case:
I wanted to set the red light on my OpiPC to the heartbeat effect.
This can be set manually with:
# echo heartbeat > /sys/class/leds/orangepi\:red\:status/trigger The sysfs files format is really simple:
# the path omits the /sys/ path/to/the/settings = value So all I had to do was:
# echo "class/leds/orangepi\:red\:status/trigger = heartbeat" > /etc/sysfs.d/red_led.conf One can modify the sysfs.conf itself, but it's more pluggable/manageable via .conf files under the sysfs.d directory.

Small update: Tried two more locations within the same building with OPi Lite and the other board with RTL8192CU MIMO dongle:
 
Location 1: 4 meters away, 2 walls in between, wall angle approx. 30°
 
Orange Pi Lite: 33 Mbits/sec on average
 
ODROID-C2 with MIMO USB dongle: 51 Mbits/sec on average
 
 
Location 2: 5 meters away, 2 walls in between, different direction compared to prior location.
 
Orange Pi Lite: 23,5 Mbits/sec on average:
 
 
ODROID-C2 with MIMO USB dongle: 31.4 Mbits/sec on average
 

As already done with other topics this will be the start of a new thread collecting more information over time.
 
Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here.
 
As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports:
 
RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1) Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi) RealTek RTL8723BS (used on Pine64+ and on CHIP for example) RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi)  
The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg.
 
Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance) Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals) Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run)  
So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible).
 
Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking).
 
Now the results:
 
NanoPi Air with el cheapo Xunlong aerial, AP6212 module, Kernel 3.4.113, no BT configured: 39 Mbits/sec and 188 retransmits on average. Full log: http://sprunge.us/aPXb
 
 
Pine64+ with same el cheapo Xunlong aerial, RTL8723BS module, Kernel 3.10.104, no BT configured: 39 Mbits/sec and 58 retransmits on average. Full log: http://sprunge.us/EffO
 
 
Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: http://sprunge.us/dWJV
 
 
ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: http://sprunge.us/Njhi
 
 
How to interpret the results?
 
The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead!  ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on) All 3 onboard Wi-Fi chips perform identical. This is due to single antenna 2.4 GHz Wi-Fi: 65Mbps bit rate resulting in ~40 Mbit/sec TCP/IP throughput with ideal/good/identical environmental conditions The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput  
Next steps:
 
Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set).
 
But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)

Zador, tkaiser, thanks a lot, it helped adding
overlays=sun8i-h3-usbhost2 sun8i-h3-usbhost3 into /boot/armbianEnv.txt and rebooting. DISCLAIMER: the overlay names may change as the development goes on.
 
Of course I realize it's a development kernel, and I'm not going to use it for any production installations. But as I'm evaluating the platform in general, I prefer using the latest development software. Do you feel comfortable if I report any issues in the same format on this forum? It's in my habit to report bugs or thought-to-be-bugs
 

No ! it is using kernel spidev transactions thru /dev/spidev*.* devices.

I don't know about specific WS2812 protocol, but doing an SPI transfer is about as simple as :
from pyA20 import spi spi.open("/dev/spidev0.0", mode=0, delay=0, bits_per_word=8, speed=5000000) data = [0,1,2,3,4,5,6,7,8,9] spi.xfer(data, len(data))

ill have to dig through my notes to show you.... at this point im uninspired to persue wiringOP because it just has so much junk in it. I see why werecat threw a fit on the orangepi forums a while back. 
so ill slowly start chasing the python route. someone forked pya20 specifally for the zero.... i updated the first post of this thread and added it as a resource. i did a quick test with onboard led and it seemed to work
 
anyway i think pursuing an autodetecting pya20.gpio fork is the most straightforward path.
 
Tapatalk thinks its important to tell you im using tapatalk from a phone.

https://www.armbian.com/kernel/
https://forum.armbian.com/index.php/topic/2422-more-proper-testing-better-armbian-experience/
 
We provide even daily builds of this(all) kernel(s), but we won't hear any of pleads for help, because such service is stupid, costly, inefficient, ... supporting stable kernel is already way over for a free amateur service. Developing kernels are built daily for developers and for testing, that we are able to improve them ... and one day, when we are satisfied with quality, put them out.
 
That's the point.

Holy cow.. I had no idea how ugly the wiringpi C library really is... it's really ugly.. not that I know what I'm doing--but It's ugly.  

BTW: Reasons why 1st 'Earth-friendly EOMA68' design relies on an Allwinner SoC: https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor

BIG tnx  zador.blood.stained for hi quality answers
 
if you really want to use I2S on this board the best option would be to unsolder R69
 
i have made it and i2s dac work fine , tomorrow i will try fix wifi poweron
 
i still like my tiny board ))))
 
some pics for another guys who like connect i2s dac

PA20 is not available on the header, it is used for controlling wireless chip power. It can only be used by soldering a wire to one of pads for resistor R69 (can be seen on the board between wireless chip and Ethernet transformer, resistor itself needs to be desoldered) and changing wireless driver configuration. 

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

Instead, we were rewarded. Not many got this privilege.
 
 
 
https://distrowatch.com/weekly.php?issue=20170116#donation

I'd say go with WiringPi, so we could reuse existing projects for Rpi. If you'd go with pyA20, then fork it and make it compatible with Rpi.GPIO so we can reuse those projects for RPi .

My personal preference is that the wiring should follow the Arduino libraries.
My thinking is that it you do that then you get some compatibility with all the Arduino based peripherals to some degree out of the box.
Python should follow based on a solid C/C++ implementation of the drivers/ APIs.
 
But just a biased opinion.
Disclaimer lots of years in the C/C++, C#  world, not so much in the Python world.

Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590
 

Great news: linux-sunxi community got boot from SPI NOR flash to work: http://linux-sunxi.org/Orange_Pi_Zero#Mainline_U-Boot
 
Apritzel also managed to hack the function of the 'power button' to become a FEL button instead (so you're able to boot from SD card by pressing the button even if a 'firmware' is already stored in SPI flash -- useful only for OPi PC 2 now since Zero is missing the button).
 
What's missing still? SPI NOR flash soldered on the Zero by default as it's already the case with OPi PC 2. So please make some noise to convince Xunlong soldering the same 16 Mb (2 MB) flash on the Zero starting with next production batch. Please leave feedback in OrangePi forum and on Aliexpress!

You could manually install X without a larger desktop environment on the console-only version of Armbian or strip away the unneeded parts of the desktop version.
You should then be able to use "startx" to run the X server on-demand for a single application. eg. "startx /usr/bin/mpv --fullscreen video.mp4"

I think we should edit all fex files for H3 boards, remove all definitions from [gpio_para] section and add a comment that this section is obsolete.

yes, it has same or better functionality and it must be present anyway (pinctrl) if you want to have useful kernel.