MitchD

This has been replaced by: User Space IO get more details on this thread.
 

 
Well, it's time to say goodbye to sysfs and hello to libgpiod! @zador.blood.stained pointed me in the right direction, but you need to do one little hack I'll explain below involving compiler_types.h. I tested this on a NanoPi Duo, but it should work on any mainline Armbian release (and other distros as well) as long as the kernel is >= 4.8. Try ls /dev/gpiochip* and see if anything is listed. If so, then proceed.
 
I'm continuing work on my Github site https://github.com/sgjava/libgpiod-extra, so please report any issues there. There is an Armbian install script that automates the steps below I generated the Python wrapper, but there's a lot of functions to test, so I'm not sure of the quality. I'm working on some simple Python tests.
sudo armbian-config, Software, Headers sudo apt-get install libtool pkg-config git clone https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git cd libgpiod mkdir -p include/linux cp /usr/src/linux-headers-$(uname -r)/include/linux/compiler_types.h include/linux/. ./autogen.sh --enable-tools=yes --prefix=/usr/local CFLAGS="-I/usr/src/linux-headers-$(uname -r)/include/uapi -Iinclude" make sudo make install sudo ldconfig Let's try some commands:
 
sudo gpiodetect
 
gpiochip0 [1c20800.pinctrl] (224 lines)
gpiochip1 [1f02c00.pinctrl] (32 lines)
 
sudo gpioinfo | grep "\[used\]"
 
    line  10:      unnamed "nanopi:blue:status" output active-high [used]
    line 166:      unnamed         "cd"   input  active-high [used]
    line 202:      unnamed  "interrupt"   input  active-high [used]
    line 205:      unnamed      "reset"  output   active-low [used]
    line   6:      unnamed          "?"  output  active-high [used]
    line   7:      unnamed   "vcc-wifi"  output  active-high [used]
    line  10:      unnamed "nanopi:green:pwr" output active-high [used]
 
Notice how it found the Duo's built in LEDs
 
Now let's test the Duo's built in button (press and release 3 times):
 
sudo gpiomon --num-events=3 --rising-edge gpiochip1 3
 
event:  RISING EDGE offset: 3 timestamp: [1516774143.944174870]
event:  RISING EDGE offset: 3 timestamp: [1516774145.123474395]
event:  RISING EDGE offset: 3 timestamp: [1516774145.987531088]
 
Wire up LED (the normal way) and use Duo's IOG11 then to turn on and off:
 
sudo gpioset gpiochip0 203=0
sudo gpioset gpiochip0 203=1
 
Python code
import time from libgpiod.libgpiod import * chip = gpiod_chip_open("/dev/gpiochip0") line = gpiod_chip_get_line(chip, 203) # The will set line for output and set initial value (LED on) if gpiod_line_request_output(line, "test", 0) == 0: time.sleep(3) # LED off gpiod_line_set_value(line, 1) gpiod_line_release(line) gpiod_chip_close(chip) More reading at https://www.cnx-software.com/2017/11/03/learn-more-about-linuxs-new-gpio-user-space-subsystem-libgpiod and https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README. Maybe @Larry Bank will work on ArmbianIO II It looks like in the old Github site there was a milestone to create Python and C++ wrappers https://github.com/brgl/libgpiod/milestone/3. Once I learn more about libgpiod I may just generate them like I did for ArmbianIO.

OK, I got it to build finally! I'm working on a how-to and will post that once I verify the steps and that it actually works, thanks!
 

https://photos.app.goo.gl/u3N8Drw54kMDl6DE2
 

change your /etc/network/interfaces file to look like:
auto eth0 iface eth0 inet static     address 192.168.100.1     netmask 255.255.255.0  
and type
sudo ifdown eth0 && ifup eth0  
With that you should be able to ssh into the device using ssh USER@192.168.100.1

Ok, I updated the boot manager so it is now more portable and added some convenience features as well.
Be aware that it is not beginner friendly, you need at least some knowledge about writing and editing u-boot scripts, Uart cable is not needed but can be useful during testing and setting up.
I rewrote the script in python using curses so It's now more elegent (in my opinion anyway) I tried to get it as close as I can to look like grub2 interface:

Now let's explain How it works:
First, the sdcard must contain at least two fat32 partitions:

-First partition(fat32) (label=RECOVERY) content:
This partition contains the main boot manager files:
1-aml_autoscript is the script that is used to update the u-boot environment to allow for our method to work
2-dtb.img a dtb file, make sure to replace it with the appropriate one for your device I compiled it from coreelec source https://github.com/CoreELEC/device-trees-
amlogic
3-Image is the kernel image of the boot manager
4- multiboot.script is the script that is executed to display the boot manager
5-update.zip use this in your update app in android to flash the aml_autoscript above and make the bootloader ready for our boot manager
 
 
-Second Partition(fat32) (label=BOOT) content:
This partition contains at least the config.yaml file that contains general settings for the boot manager and the boot entries to be listed.
Mote that I have a folder(multiboot) that contains the boot files for my distros(kernel,initrd,dtb and boot script) you don't have to put them in this partition you can put them anywhere (another partition on the sd card, a USB drive or even in  the internal EMMC) just make sure to have the correct path and device id for them in the config.yaml file.
Also If you want to use the remote control instead of a keyboard to select the os place the correct remote.conf of your remote in the root of this partition.
 
the structure of config.yaml is like this:
generalSettings: default: 5 rememberboot: true timeout: 10 menu: - bootscript: /multiboot/COREELEC/u-boot.script device: mmc 0:2 devicefs: fat name: COREELEC - bootscript: /multiboot/armbian-3.14.29-mate/u-boot.script device: mmc 0:2 devicefs: fat name: armbian-3.14.29-mate - bootscript: /multiboot/dvb_test/u-boot.script device: mmc 0:2 devicefs: fat name: dvb_test - bootscript: /multiboot/kernel-3.14/u-boot.script first you set the general settings:
- timeout: this is how many seconds the boot manager should wait before booting into the default boot entry
- default: this is the zero based index of the default distro that the boot manager will boot to after timeout, note that index 0 is reserved for the internal EMMC boot so your menu starts at index 1.
- rememberboot: if this is set to true then the manager will remember the entry that you selected and save it's index in the default entry above so the next time you boot this will be your default entry.
 
after that you add your menu entries:
- name: is the name of the distribution displayed in the boot menu
- bootscript: this is the path of the bootscript of the distribution (note that this boot script should be capable of booting the distro on it's on, so it must have the correct path of the boot files and pass the correct root parameter to the kernel, see the example u-boot.script files that are included in each distibution)
- device is the device that contains the bootscipt using u-boot format so the first mmc and second partition would be mmc 0:2 , the second mmc and third partiton would be mmc 1:3 .
- devicefs is the filesystem type of the above device, this is usually fat because most of these tv boxes support loading files of only fat32 partitions (except some boards like khadas vim and odroid whose bootloader support ext4 partitions)
 
now let's see an example of a disto bootscript:
 
this the same bootscript that was shipped with balbes150 image I only edited the device to mmc 0:2 because this is where I have my kernel and other boot files, also I prepended the correct path before each file name.
In the uEnv.ini file of this distro I edited the root parameter to use a partition labeled "Debian-3-xfce" and created that partiton using gparted
 
 
I prepared a boot image that contains the boot manager and two distibutions, Coreelec and Debian server.
download the image here and burn it to a new sdcard then use the update application in android and update using update.zip, after that you'll see the boot menu after the reboot
https://drive.google.com/open?id=1dhpcqNrqbW493SK8J_Er9b-ZipJkTfd3
 
 
Below is the old method
 
Hi,
This is my quick and dirty solution to multiboot any amlogic device(actually it can be used on any device that uses u-boot with slight modification):

 

***Warning: the following method was only tested on one device which is KII PRO, I made this method for my own use ,it is a long and a bit complicated to setup for non-experienced users if you want to try it you are trying it at your own risk, I take no responsibility for any damage that may occur to your device.
 
 
 
Preparing the sd card for multiboot:
1- Download the zip file from the attachments multiboot.zip
2-wipe everything in your sdcard (i used a 16 gb card) and create 2 partitions:
-The first one is a fat32 partition, this can be small partition (for me i made it 1gb) it will contain the boot files for the main multiboot system and for any other distributions,i labeled this partition "BOOT".
-The second partition is ext4 partition which will contain the rootfs of your distributions in raw image format, this need to be a big partition i suggest you assign all remaining available space to this partition, also you need to label it "ROOTFS" (this is mandatory).
you can use whatever tools you want(gparted,fdisk...etc)
 

 
3-mount the partitions and extract the zip file to the root of your boot partition(the fat32 partition) and create an empty folder called ‘multiboot’ inside the root of the first and second partitions, so the first partition content should  look like this
▶ tree . ├── aml_autoscript ├── aml_autoscript.zip ├── multiboot ├── config.txt ├── dtb.img ├── s905_autoscript ├── s905_autoscript.cmd ├── umbInitrd └── zImage and the second partition should look like this
▶ tree /run/media/mohammad/ROOTFS/ └── multiboot the ‘multiboot’ folder in the first partition should contains folders with the name of the distro and inside them are the bootfiles of that distro(kernel,dtb,initramfs and s905_autoscript file) the ‘multiboot’ folder in the second partition should contain the same folders as in the first partition and inside the folder there should be an ext4 image of the rootfs of the distro
4- The dtb file i used is for kii pro tv box and you should replace that with the dtb of your device, you can get that from any of balbes150 distributions(3.14.29 kernel).
 
Now you'r ready to boot, all you need is some distros
Preparing the distros:
You can make a partition for each distro on your sd card and use it to store the rootfs but i chose a more portable solution by making a raw partition image for each distro and pass it to the initramfs to be mounted as a loop device.
I will be using one of balbes150 distros as an example (Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_mate_20170907.img.xz)
1-First extract the file 
▶xz -k -v -d Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_mate_20170907.img.xz 2- Now mount the resulting file partitions to some directories, I use kpartx to do it for me automatically
▶sudo kpartx -av Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_mate_20170907.img add map loop0p1 (254:0): 0 262144 linear 7:0 2048 add map loop0p2 (254:1): 0 8812544 linear 7:0 264192 now mount the loop devices (i use udiskctl)
 
▶ udisksctl mount -b /dev/mapper/loop0p1 Mounted /dev/dm-0 at /run/media/mohammad/BOOT1. ▶ udisksctl mount -b /dev/mapper/loop0p2 Mounted /dev/dm-1 at /run/media/mohammad/ROOTFS1.  
df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 2.0G 215M 1.8G 11% /run/media/mohammad/BOOT #this is my sd card #1 partition /dev/sdb2 13G 6.8G 4.8G 59% /run/media/mohammad/ROOTFS #this is my sd card #2 partition /dev/mapper/loop0p1 128M 53M 76M 42% /run/media/mohammad/BOOT1 #this is the mounted distro image #1 partition /dev/mapper/loop0p2 4.1G 2.9G 1.1G 75% /run/media/mohammad/ROOTFS1 #this is the mounted distro image #2 partition
 
3- create a folder with the name of the distro in the multiboot folder you created earlier (in the first and second partitions of your sd card) then copy all the boot files of your distro to the folder in the first partition
▶ mkdir /run/media/mohammad/BOOT/multiboot/armbian-3.14.29-mate #this is the first(fat32)partition ▶ mkdir /run/media/mohammad/ROOTFS/multiboot/armbian-3.14.29-mate #this is the second (ext4) partition ▶ cp /run/media/mohammad/BOOT1/* /run/media/mohammad/BOOT/multiboot/armbian-3.14.29-mate/ 4- now you need to create an ext4 partition image to contain the rootfs of your distro for me I made a 4GB image
fallocate -l 4G system.img mkfs.ext4 system.img  
5-mount the image
 
▶ sudo losetup $(losetup -f) system.img ▶ udiskctl mount -b /dev/loop1 Mounted /dev/loop1 at /run/media/mohammad/71545ae9-33c7-4d99-963e-a5a915464078. 6-copy all the files from the rootfs of your distro image to the newly created image
 
▶ cp /run/media/mohammad/ROOTFS1/* /run/media/mohammad/71545ae9-33c7-4d99-963e-a5a915464078/ UPDATE: edit the "/etc/fstab" inside the system.img file
nano /run/media/mohammad/71545ae9-33c7-4d99-963e-a5a915464078/etc/fstab and comment out the lines that start with "LABEL=ROOTFS" and "LABEL=BOOT" by adding a hash at start of each line
then add these lines to the file :
/dev/mmcblk1p1 /mnt vfat defaults 0 2 /mnt/multiboot/armbian-3.14.29-mate/ /boot none bind this will fix the 0hdmi.service problem
 
 
7- unmount everything
 
▶ umount /dev/loop1 ▶ umount /dev/mapper/loop0p1 ▶ umount /dev/mapper/loop0p2  
8-copy the system.img file to your distro folder in the second partition of your sd card
▶ cp system.img /run/media/mohammad/ROOTFS/multiboot/armbian-3.14.29-mate 9- move to your distro folder in the first partition of your sdcard:
 
▶ cd /run/media/mohammad/BOOT/multiboot/armbian-3.14.29-mate  
10- now you need to edit the s905_autoscript.cmd file ( I use nano editor, you can use any text editor you like), you need to make two types of edits in this file
  - add loop=${mbpath}/system.img to the kernel arguments
  - add ${mbpath}/ before each of uInitrd, zImage and dtb.img
so this
 
 
becomes this
 
 
Note that I removed the lines of booting from usb to decrease the boot time because I know that I’m booting from the sd card, you can leave them if you want.
 
11- compile the script
▶ mkimage -A arm64 -O linux -T script -C none -d s905_autoscript.cmd s905_autoscript 12-copy the dtb file of your device
▶ cp dtb/gxbb_p200_2G.dtb dtb.img  
Modifying u-boot and booting:
insert the sd card in the tvbox and then go to the update and backup app and select zip file to update from and choose aml_autoscript.zip that is on the root of the sd card, the device should reboot and you should now be able to use the multiboot function
 
UPDATE: after booting into the distro disable the resize2fs service using the following command
 
sudo systemctl disable resize2fs Notes(mostly for other developers):
1-I’m a very bad shell programmer, I mostly used snippet from stackoverflow to write the main script (bin/wselector) if you could improve the script or anything in my method that would be appreciated.
2-boot time is very good but there is always a possibility to improve it, somethings that I can think of are:
-buiding a smaller kernel by disabling everything in the kernel except for the framebuffer,mmc and nand driver, fat32 and ext4 filesystem,unfortunately whenever I disable something in the kernel it fails to build
-maybe building a minimum dtb file so that the kernel doesn’t spend time initializing peripherals we don’t need.
-building all binaries in umbInitrd staticaly
 

I just released my multi-system game emulator (GameBoy+NES+GameGear for now). Optimized for directly outputting to SPI LCD displays (e.g. ili9341). Runs on any CPU type, but has optimizations for ARM+X64. I wrote 100% of the code, so it might be behave differently than other game emulators. GB+GG are nearly perfect. NES is missing some popular mappers. The code is very optimized to begin with, but also uses a dirty-tile system to minimize the data sent to the SPI bus. This allows inexpensive SPI displays (e.g. ili9341) to run at or near 60 frames per second for many games even though the SPI bus can only do 30FPS of full screen updates.

https://github.com/bitbank2/sg_free

The SPI display access uses my SPI_LCD library (https://github.com/bitbank2/SPI_LCD). This means that it doesn't need fbtft nor fbcp and can run on any Linux board. It has built-in code to talk to GPIO pushbuttons, so no special drivers/software are needed to run on "GBZ" systems. Below is a photo of SmartGear running on an Orange Pi Lite with the PiPlay Portable prototype hardware.

I actually wrote the exact procedure  Edit /etc/modules. Remove g_serial and add g_ether instead .... save and reboot.
 
But remember, it's still only a theory. I haven't tested this.

- 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

Hi, guys. I need some help in understanding of usage AR100 (OpenRISC) coprocessor inside H3 SoC for the own real-time tasks.
 
Now i'm using mainline kernel built with RT-PREEMPT patch. I'm using it with Machinekit (LinuxCNC) software to control stepper drivers/motors via GPIO step/dir pulses. But step pulses frequency is too slow (about 17 kHz) because the RT kernel latency is about 30 us.
 
I think we can use the built-in coprocessor for the realtime GPIO toggling. The AR100 and main Cortex-A7 can talk to each other with built-in MSGBox. And the question is - how to launch my own firmware on the AR100 core?

I'm using Machinekit with my GPIO driver. I have a big CNC machine (4 axes).
 
yep. 2279 microseconds is bad result

mainline should support slave mode
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sunxi/sun4i-i2s.c?h=v4.15-rc2#n502
there is also a few patches which I haven't delivered yet here
https://github.com/codekipper/linux-sunxi/commits/sunxi-wip
however I still need to test these properly before pushing for mainline. I'm also trying to come up with a cleaner solution for when the codec expects 32bits frame width.
 

If somebody interested, here is a few photos where LinuxCNC running on the Orange Pi One.
Debian Jessie, FULL RT patch.

I'm not sure if anyone is interested in a very small distro without gcc, but I spent some time the last week using buildroot and armbian's source files to create a 3.4.112-rt image for the nanopi neo. It is going to be part of a realtime audio project (think synth or guitar pedal) that I'm working on and it demands a quick boot, among other things. 
 
There is also a mainline version, but it doesn't have all the fixings you folks like, so I don't know if you'd want to use that. 
 
You can find the build scripts and config files on my github. I'll be posting the legacy image in a zip file tonight, once I verify everything is reproducible. 
 
I would like to thank the Armbian developers for all their time and energy doing what they do. Their code and guides have helped me understand how one would even attempt something like this, and I'm very grateful. If you ever use my image, please donate to the Armbian community. 
 
The screenshot is proof that the system works, and how much ram it uses while forwarding a puredata session over X-forwarding. 
 
I'm open to any questions. Thanks. 

Welp. It currently works for...more than a couple employees and has been tested using various means/devices for months.

I could go into more detail but your opinion does not apply to my specific circumstance. Regardless, thanks for the criticism. (seriously)
In my experience every 'small business' solution to this has been to simply, not have a time clock. Again, I could go into details but I'm not the trend that every local business owner I've met, has set.

I don't know what you mean by terribly complicated but I beg to differ. Let OPiZ offer RFID interface to a Gsheet. Let Gsheet functions calculate all the math.
This solution in tandem with a 'profession' timeclock that costs several hundred not $25 dollars, to create a physical timecard that needs to be digitized later, produces (dare I say) foolproof results.

Im running Armbian Debian Stretch mainline  with 4.14.3-rt4 on a NanoPi Neo Plus2 ( Allwinner H5 ).
The patch applied just fine and performance is good.
 
T: 0 ( 1634) P:99 I:1000 C:1810076 Min:      6 Act:    9 Avg:    8 Max:      32
T: 1 ( 1635) P:99 I:1500 C:1206709 Min:      6 Act:    7 Avg:    8 Max:      44
T: 2 ( 1636) P:99 I:2000 C: 905025 Min:      6 Act:    7 Avg:    8 Max:      37
T: 3 ( 1637) P:99 I:2500 C: 724014 Min:      7 Act:    7 Avg:    7 Max:      31
T: 4 ( 1638) P:99 I:3000 C: 603343 Min:      7 Act:    7 Avg:    8 Max:      42
 
uname -a:
Linux nanopineoplus2 4.14.3-rt4-sunxi64 #8 SMP PREEMPT RT Sat Dec 2 22:08:45 CET 2017 aarch64 GNU/Linux
 
 
Latest Armbian = 

Wanted to automate payroll. Needed to be as simple/easy on the eyes as possible for your run of the mill user.

General functionality is that it makes digital timecards for every employee action/swipe of an RFID tag. Every swipe also punches a Google Sheet based on company department, by utilizing regex to find column associated with employee name, then the row based on today's date. It then punches current military time to corresponding clock in/out offset. The timecard math is all done using the Google spreadsheet functions to discern overtime, total hours, etc... More will be included later to automate even the spreadsheet template even though copy/pasting once every 15 days is trivial.

It's comprised of a OPi-Zero, MFRC522 RFID Module (for employee badges) a modified case, multi LED for clock in/out prompting, Google Sheet API and several existing dependencies/repos on GitHub. The most important 'juicy', details are documented on GitHub which will get you installed and running with the API, Module, LED, etc.... With more details to come, including step by step instructions on setting up Google Sheet API, etc.... Let me know what the community thinks.

https://github.com/BiTinerary/TimeClockPi

Installation >> Connect MFRC522 Module and run >> git clone https://github.com/BiTinerary/TimeClockPi && bash ./TimeClockPi/requirements.sh

On 1st Dec. the latest 4.14 rt patch has been released
-> https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/
So it might be possible to test now with new 5.36 and 'mainline' option.
 

Hey @MX_Master, reporting in with some more numbers with the 4.13 RT stuff. 
 
# uname -a Linux nanopi-neo 4.13.11-rt3 #2 SMP PREEMPT RT Thu Nov 30 11:17:18 CST 2017 armv7l GNU/Linux # cyclictest -a -t -n -p80 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.11 0.10 0.03 1/94 920 T: 0 ( 915) P:80 I:1000 C: 238476 Min: 6 Act: 9 Avg: 9 Max: 38 T: 1 ( 916) P:80 I:1500 C: 158983 Min: 5 Act: 9 Avg: 9 Max: 27 T: 2 ( 917) P:80 I:2000 C: 119238 Min: 8 Act: 9 Avg: 8 Max: 17 T: 3 ( 918) P:80 I:2500 C: 95390 Min: 7 Act: 9 Avg: 9 Max: 16  

H2+/H3/H5 boards overview (early 2018 update)
 
For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2):
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless):
Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT,  Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header)
NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet
General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet

It would be best to extract the Device Tree from any original image that runs on this device with Ethernet, eMMC and LCD backlight. While Ethernet and eMMC configuration can be easy to adapt from working images, LCD backlight may be difficult to enable without any documentation (i.e. device schematics).

Hi,
 
I've been struggling also with all the info in this thread but finally succeeded to make decompile/edit/compile the dtb file (assume this file as BIOS for ARM  )
I'm putting all commands here as reference for me as well :
 
cd /boot/dtb sudo cp sun8i-h3-orangepi-one.dtb sun8i-h3-orangepi-one.dtb.old sudo dtc -I dtb -O dts -o sun8i-h3-orangepi-one.dts sun8i-h3-orangepi-one.dtb sudo sed -i -e 's/dr_mode = "otg";/dr_mode = "host";/g' sun8i-h3-orangepi-one.dts sudo dtc -I dts -O dtb -o sun8i-h3-orangepi-one.dtb sun8i-h3-orangepi-one.dts Explanation of different lines:
 
1. go to dtb directory
2. make backup of the compiled file in case something goes wrong
3. decompile the file to be able to alter it with text editor
4. change the string from "otg" to "host"
5. compile the altered file back to binary format dtb
 
 
The only bad thing with all this above is that if you upgrade your kernel the info will be lost so you have to do it again.
I don't get why this parameter is set by default to "otg"?

Try those:
 

If you are using the mainline kernel, you can use configfs for setting up USB HID. Try this example:
    modprobe libcomposite     mount -t configfs none /sys/kernel/config     cd /sys/kernel/config/usb_gadget     mkdir g1     cd g1     mkdir configs/c.1     mkdir functions/hid.usb0     echo 1 > functions/hid.usb0/protocol     echo 1 > functions/hid.usb0/subclass     echo 8 > functions/hid.usb0/report_length     cat my_report_desc > functions/hid.usb0/report_desc     mkdir strings/0x409     mkdir configs/c.1/strings/0x409     echo 0xa4ac > idProduct     echo 0x0525 > idVendor     echo serial > strings/0x409/serialnumber     echo manufacturer > strings/0x409/manufacturer     echo HID Gadget > strings/0x409/product     echo "Conf 1" > configs/c.1/strings/0x409/configuration     echo 120 > configs/c.1/MaxPower     ln -s functions/hid.usb0 configs/c.1     ls /sys/class/udc > UDC  
Which I got from my own working USB OTG ethernet + midi + file storage script and this example here. Note that they create a file called "my_report_desc" for HID specific stuff. 

Thanks! Also found this thread now and it also says about libcomposite.  

Will try it out.
 

DT changes should look like this: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/32-h3-DT-add-mali-node.patch.disabled