lanefu

https://github.com/armbian/build/commit/f6402803c261b7a683eeb091f62a684bfd1ef8e8
https://github.com/armbian/build/commit/518ef98107a6705ba6649acdb1481cafedc9766d

Software support is not fast food.

Edit: User Space IO depracated. Use Java Periphery instead https://github.com/sgjava/java-periphery
 
https://github.com/sgjava/userspaceio
 
After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
 
GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
 
Based of some of the questions I had in the past please note the following:
gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local. Demo program using hardware PWM to flash LED:
 

Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).

Hi all, for today this work ok on H3 (recording from webcam here)
 
git clone https://github.com/stulluk/FFmpeg-Cedrus.git
git clone https://github.com/uboborov/ffmpeg_h264_H3.git
cp /root/ffmpeg_h264_H3/cedrus264.c /root/FFmpeg-Cedrus/libavcodec/cedrus264.c
cp -R /root/ffmpeg_h264_H3/sunxi /root/FFmpeg-Cedrus/libavcodec/arm
apt-get install libpulse-dev libv4l-dev libmp3lame-dev libx264-dev
cd FFmpeg-Cedrus
./configure --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libv4l2 
make -j 4
make install
ffmpeg -version
ffmpeg -h encoder=cedrus264
ffmpeg -f v4l2 -video_size 1280x720 -i /dev/video0 -pix_fmt nv12 -r 25 -c:v cedrus264 -vewait 5 -qp 30 -t 60 -f mp4 test.mp4 -y
====
And you can use software-encoder, it work better then you expect. Example for slow CPU and bitrate limits
 ffmpeg -f v4l2 -video_size 1280x720 -i /dev/video0 -pix_fmt nv12 -r 25 -c:v libx264 -b:v 4M -maxrate 4M -bufsize 1M -preset ultrafast -t 60  -f mp4 test.mp4 -y
 
 

If anybody missed it, there is an openwrt image now.
 
https://openwrt.org/toh/hwdata/xunlong/xunlong_orange_pi_r1



 

On my journey to finding the best solution for cross SBC/cross language GPIO support I went through the same issues as Python by the C side author did it seems and landed on CFFI. This is faster than ctypes and seem more natural to program with. ctypesgen (the code generator) doen't really support Python 3, so I've hit a dead end there. It seems like JNA is still the best choice for Java bindings, so I'm sticking with that for now. In any event I threw together a button press app that uses CFFI and libgrpiod. I'll be updating my bindings project to support this soon.
 
libgpiod version 1.1.devel
Name: gpiochip1, label: 1f02c00.pinctrl, lines: 32
Press button within 5 seconds
Falling edge timestamp 02/10/2018 19:49:05
""" Test blocking event using built in button ------------- Should work on any board with a button built in. Just change chip and line value as needed. """ import sys, time from argparse import * from cffi import FFI parser = ArgumentParser() parser.add_argument("--chip", help="GPIO chip number (default 1 '/dev/gpiochip1')", type=int, default=1) parser.add_argument("--line", help="GPIO line number (default 3 button on NanoPi Duo)", type=int, default=3) args = parser.parse_args() ffi = FFI() # Specify each C function, struct and constant you want a Python binding for # Copy-n-paste with minor edits ffi.cdef(""" enum { GPIOD_LINE_EVENT_RISING_EDGE, GPIOD_LINE_EVENT_FALLING_EDGE, }; struct timespec { long tv_sec; long tv_nsec; }; struct gpiod_line { unsigned int offset; int direction; int active_state; bool used; bool open_source; bool open_drain; int state; bool up_to_date; struct gpiod_chip *chip; int fd; char name[32]; char consumer[32]; }; struct gpiod_chip { struct gpiod_line **lines; unsigned int num_lines; int fd; char name[32]; char label[32]; }; struct gpiod_line_event { struct timespec ts; int event_type; }; const char *gpiod_version_string(void); struct gpiod_chip *gpiod_chip_open_by_number(unsigned int num); struct gpiod_line *gpiod_chip_get_line(struct gpiod_chip *chip, unsigned int offset); int gpiod_line_request_falling_edge_events(struct gpiod_line *line, const char *consumer); int gpiod_line_event_wait(struct gpiod_line *line, const struct timespec *timeout); int gpiod_line_event_read(struct gpiod_line *line, struct gpiod_line_event *event); void gpiod_line_release(struct gpiod_line *line); void gpiod_chip_close(struct gpiod_chip *chip); """) lib = ffi.dlopen("libgpiod.so") print "libgpiod version %s" % ffi.string(lib.gpiod_version_string()) gpiod_chip = lib.gpiod_chip_open_by_number(args.chip) # Make sure GPIO chip opened if gpiod_chip != ffi.NULL: print("Name: %s, label: %s, lines: %d" % (ffi.string(gpiod_chip.name), ffi.string(gpiod_chip.label), gpiod_chip.num_lines)) gpiod_line = lib.gpiod_chip_get_line(gpiod_chip, args.line) # Verify we have line if gpiod_line != ffi.NULL: consumer = sys.argv[0][:-3] if lib.gpiod_line_request_falling_edge_events(gpiod_line, consumer) == 0: timespec = ffi.new("struct timespec*") timespec.tv_sec = 5 print("Press button within 5 seconds") rc = lib.gpiod_line_event_wait(gpiod_line, timespec) if rc == 0: print("Timed out") elif rc == 1: event = ffi.new("struct gpiod_line_event*") # Read event off queue lib.gpiod_line_event_read(gpiod_line, event) if event.event_type == lib.GPIOD_LINE_EVENT_RISING_EDGE: print("Rising edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Falling edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Unable request falling edge for line %d" % args.line) lib.gpiod_line_release(gpiod_line) else: print("Unable to get line %d" % args.line) lib.gpiod_chip_close(gpiod_chip) else: print("Unable to open chip %d" % args.chip)  

Hoped to find something like voltage monitoring (on input) but as far as I understand the manual of the AXP805, there is no such possibility.   Would it make a goods beginners board (as soon as kernel is 'in a good shape') cause it would avoid 'powering gone wrong'...   - anyway, every barrel plug powered board is a bit more beginners friendly..
I don't follow sunxi mailing list fully (mostly cause I wouldn't understand most of the things discussed there.. ), but as I saw for the A64s PMIC was a bit problematic (handled by AR100, whereas complier for it is not GPL). As I understand, this issue was solved with those commits. Is the H6 also affected by such problems? (Allwinner had PMIC since a long time on the AR100 but it was possible to avoid using it). 
More experienced users have to decide if it's worth to use this kernel... But nice to see that allwinner publishes this stuff faster than in the past.  btw. for those interested in it: https://github.com/Allwinner-Homlet?tab=repositories there you go.  

My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
 
The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.

... or not. Merged here and renamed this thread to include "Orange Pi One Plus" in the title.

A 4.9 kernel is released by Allwinner yesterday (as UTC+8).
 
P.S. AXP805 has only power key (for power down functionality) and DCDC+LDO, like RK805 from RK(used with RK3328, also OTT):-)

Gaze longingly at it's many ports and connectors.

search the docker registry for armhf   then youll find ubuntu and alpine containers to base your builds on.     ioft/armhf-ubuntu:xenial  is one i use a lot

Frustrated yes, but also a positive step forward.    Sometimes the FUD for stuff like this scares organizations to patch.    I've been trying to get the blessing to do bulk patching for 2 years and finally my company is ready to do it!.

Big digression but:
 
In regards to @tkaiser negative and pessimistic suggestions to keep dropping board support for problem boards,  I think he is absolutely correct.
 
While Im not a big Armbian user (we have our own linux based OS stack that we created from scratch and an ubuntu 16.04 derivative we tailored), I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project. Once you have a board up and running, even at just 25% of completion, every TV Box shitter and their dog wants it all working, right now, on mainline, with 8K support, running from a nokia 3210 charger, etc, etc.
 
There seems to be enough engineering resource to support about 10 major boards with minor variations. To my mind it would make much more sense and make Armbian a much more valuable project to support less boards to a higher level and to have fully standardised functionality across all "officially" supported boards. Officially supported boards get support for 3/4/5 years or whatever. You dont even try to support a board unless every critical dev on the project has at least one of them.
 
By standardised Armbian functionality, I mean things like:
standard Armbian GPIO (+i2c, spi, 1wire, etc) library (@Larry Bank already made a good start here) standard RTC interface, utils and device (we only support 3 RTC drivers) standard NAND interface, layout, device standard GSM interface, utils and device (we only support 5 drivers) standard and predictable network interface naming, handling and utils standard hardware / psu stress test standard sound and video in / out / process utils (standard interface is pretty difficult here I accept) standard remote access interface for cloud control standard config utility standard base OS. pick debian 9 or ubuntu 18.04 for future dev, stop trying to support both (my personal preference is debian but there are good commercial reasons to stick with ubuntu LTS) limited SD card support. dont support any re-badgers (Kingston, entry level sandisk, toshiba, etc ). we only use sandisk extreme plus and sandisk high endurance and have a failure rate of approx 2 in 1000  
That doesn't mean you cant have another 15 "community" supported boards, but with those there is no promise of full functionality and no official support offered. Those boards need to have community champions (individuals that want to help support specific boards, probably because they have them at home) and automated builds of community supported boards, its just means they dont get factored into long term development planning, support and testing.
 
What would you rather see from Armbian?
1) 30+ boards with levels of completion from 20%-95% and different functionality on each (think GPIO, NAND, RTC, GSM, etc)
2) 10 boards with 90%+ level completion and with standardised Armbian specific functionality across all of them? With 20 more community supported unofficial boards. 
 
Once you have structure 2 in place then you also have the correct structure to start making money from commercial support offerings. Think Armbian Gold / Pro whatever where you sell commercial support delivered via a cloud interface where the customers can manage all their devices (1-1M) from a web browser. This is what we do.
 
Controversial suggestion but you should support at least 1 variant of the RasPi. I know the hardware is shit and the RasPi foundation is full of shit but its also the most common SBC on the market. For that reason we do support the RasPi 3 only and while there are concessions to be made we also have roughly 6500 of them on support with our own OS stack at £5/€5 per month per device. We normally manage to get clients off them and onto something better at the next platform refresh.

esspressobin is affected by insanely high delivery cost instead.

I've created Python bindings with Swig using a script that should install all dependencies and create an armbianio module and install locally with pip, so it's globally accessible in Python. I created a PR for Larry, but you can grab it at https://github.com/sgjava/ArmbianIO until the merge happens. I included a simple LED blink program that uses pin 12 (ArmbianIO mapping) for the NanoPi Duo. It would be nice to test other SBCs as well.

Ethernet Patch definitely made my potato solid.  I'm running fresh image now, with consul, nomad, docker and Jira running in a container..  def much faster than on my Opi2e.
 
Thanks for the patches!
 
Linux lepotato 4.14.8-meson64 #2 SMP PREEMPT Sun Dec 24 21:03:07 EST 2017 aarch64 aarch64 aarch64 GNU/Linux  

Ethernet Patch definitely made my potato solid.  I'm running fresh image now, with consul, nomad, docker and Jira running in a container..  def much faster than on my Opi2e.
 
Thanks for the patches!
 
Linux lepotato 4.14.8-meson64 #2 SMP PREEMPT Sun Dec 24 21:03:07 EST 2017 aarch64 aarch64 aarch64 GNU/Linux  

- H6
- 1GB
- gigabit
- 26pin
- powering only via DC input
- PMU AXP805
- 1 x USB2.0 host and 1 x micro USB 2.0
- size: 69x47mm
- weight: 50g
- price USD20-25

Nightly building is back.
https://beta.armbian.com/pool/main/l/linux-4.14.7-mvebu64/

Thank you for the update, I saw the activity in the lists, I should be able to try the patches out soon to see how they work.  For the short term I've been using a wifi dongle.  

BayLibre says they're close to a fix. It's an issue with EEE capability being mis-detected.

We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.
https://www.armbian.com/search_gcse/
 

To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry and sometimes pcs of hardware.

Donations are like love. Unconditional.

I like armbian also because it feels (and is while using debian stretch) like debian or any other real linux.
I dont like these "small" systems whcih only support OpenWRT because it seems either that I cant handle OpenWRT or OpenWRT is very instable.
armbian/debian is for server type systems and mostly doesnt need the multimedia (video) of a raspberry pi.
 
When I was young I dreamed about a computer with multiple systems (like in the AMIGA for every work another chip) and now you can make this true with a $10 board and armbian  and without many  fans in the system and no high power level = no noise

Save your words.  Just give them this link
 
Orange PI FAQ