sgjava

@lsmod I ended up writing my PWM code against sysfs to keep it portable. https://github.com/sgjava/userspaceio/tree/master/pwmio/c/src So if you do not want to use the rest of User Space IO at least you have simple C code to deal with PWM.

https://github.com/sgjava/userspaceio is my github and libgopid is at https://github.com/brgl/libgpiod

@berbec I2C mono displays are fast enough for text, etc. I was also able to drive I2C at 28 FPS playing video. The down side is you have to overclock I2C and CPU utilization is higher than an SPI display. For a color display you pretty much have to use SPI. See https://bbs.nextthing.co/t/chip-mini-oled-display-luma-oled-chiptimus-prime/15673/19

Take a look at https://bbs.nextthing.co/t/chip-mini-oled-display-luma-oled-chiptimus-prime/15673 Even though it was for the CHIP it should give you the directions to get an I2C and SPI display up. For Duo and SPI: @Larry Bank has optimized display drivers for a few displays as well, but I'm not sure they are SPI.

That's basically just changing only the dr_mode to otg which was the first thing I did. I'll run the FriendlyElec dtb for now since I need the OTG more than temp. I have to force compile to generate a dtb: sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /soc/pinctrl@1c20800/wifi_wake@0 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@240000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@480000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@648000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@816000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@912000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@960000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1008000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1104000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1200000000 has a unit name, but no reg property sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1296000000 has a unit name, but no reg property

The FriendlyElec dtb has: usb@1c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x3 0x20>; resets = <0x3 0x11>; interrupts = <0x0 0x47 0x4>; interrupt-names = "mc"; phys = <0x10 0x0>; phy-names = "usb"; extcon = <0x10 0x0>; status = "okay"; dr_mode = "otg"; phandle = <0x49>; }; Armbian dtb: usb@1c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x3 0x20>; resets = <0x3 0x11>; interrupts = <0x0 0x47 0x4>; interrupt-names = "mc"; phys = <0x11 0x0>; phy-names = "usb"; extcon = <0x11 0x0>; status = "okay"; dr_mode = "peripheral"; phandle = <0x3a>; }; Some of the addresses are different like phys, extcon and phandle and dr_mode is set to "otg" of course. I think when I was playing around with it I just tried the FriendlyElec section and it still doesn't work. There may be other sections of the device tree that need to be changed as well. It's a monster to diff. sun8i-h2-plus-nanopi-duo.friendlyelec.dts sun8i-h2-plus-nanopi-duo.dts

@raschid Yes, I've already started comparing the DTS files a few days ago but got side tracked. I'll look at it tonight and report back here.

@raschid temp does work fine, but OTG doesn't work with the Armbian DTB. I'm working on getting the OTG port to work with the Armbian DTB since it does work with the FriendlyElec DTB, but breaks temp. NanoPi Duo v1.1 supports OTG (you power off VIN instead of the single USB port). This allows you to attach USB devices without the NanoPi shield.

Actually it was my bad. I was using the FriendlyElec dtb to access the USB OTG not supported yet by Armbian. I'm going to revisit this and see if I can make the changes to the Armbian dtb to get both temp and OTG.

Woo hoo, this is working in latest dev release: cat /sys/class/thermal/thermal_zone0/temp 34727 uname -a Linux nanopiduo 4.17.0-sunxi #130 SMP Sat Jun 9 00:26:00 UTC 2018 armv7l armv7l armv7l GNU/Linux

Is there a way to patch the current kernel or do you have to patch source and build it?

Something like this? http://lkml.iu.edu/hypermail/linux/kernel/1511.2/02815.html

Did a little more digging and /sys/class/thermal/thermal_zone*/mode shows disabled. Maybe this is disabled in the kernel @Igor

OK, I did the following: cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1008000 GOVERNOR=conservative sudo rm /lib/systemd/system/ondemand.service sudo systemctl daemon-reload sudo reboot cpufreq-info -o minimum CPU frequency - maximum CPU frequency - governor CPU 0 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 1 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 2 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 3 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative

OK, I'll check for a init.d or systemd conf tonight when I get home and see if I can figure it out. I'll report back here.

I tried poking around /sys/class/thermal/cooling_device*. The old way was /sys/class/thermal/thermal_zone*/temp, but now cat sys/class/thermal/thermal_zone0/temp returns Invalid argument.

Running latest Ubuntu 18.04 for NanoPi Duo with updates as of last night and CPU governor stays at ondemand even though I set it to conservative in /etc/default/cpufrequtils and reboot. CPU frequency settings do take effect, just not the governor.

Part of being on the leading edge I suppose The upgrade seemed to work although I'm seeing V4L2 issues I need to figure out.

It's working for me now. Thanks @Igor

It optimized everything out

Yea, that's what I figured, but it's been this way since last night.

sudo apt-get update [sudo] password for servadmin: Hit:1 http://ports.ubuntu.com bionic InRelease Get:2 http://ports.ubuntu.com bionic-security InRelease [83.2 kB] Ign:3 http://beta.armbian.com bionic InRelease Err:4 http://beta.armbian.com bionic Release 404 Not Found [IP: 185.158.177.155 80] Get:5 http://ports.ubuntu.com bionic-updates InRelease [83.2 kB] Hit:6 http://ports.ubuntu.com bionic-backports InRelease Get:7 http://ports.ubuntu.com bionic-updates/main armhf Packages [94.3 kB] Get:8 http://ports.ubuntu.com bionic-updates/universe armhf Packages [78.3 kB] Reading package lists... Done E: The repository 'http://beta.armbian.com bionic Release' no longer has a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

OK, I'll try nmtui on the next Duo I configure to compare the two.

Previously I just edited /etc/network/interfaces (or added file to interfaces.d), but Ubuntu 18.04 uses Netplan now. The old way worked by editing the SD card, so you never had to login into the serial console. I'm not sure if there's a way to do this with Netplan, but this is what I did to get wifi working: Login via serial console or plug in Ethernet (I used the Duo mini shield which has Ethernet port) sudo nano cat /etc/netplan/armbian-default.yaml network: version: 2 renderer: NetworkManager wifis: wlan0: dhcp4: no addresses: [192.168.1.69/24] gateway4: 192.168.1.1 nameservers: addresses: [192.168.1.1,8.8.8.8] access-points: yourssid: password: yourpassword sudo netplan generate sudo netplan apply ip a Make sure to modify the addresses, gateway4, nameservers, access-points to fit your needs.

User Space IO uses libgpiod for GPIO stuff and is built from source. The mapping is a bit different than sysfs (the old way of doing GPIO), but pretty straight forward. Each GPIO chip starts at pin 0. It should work with any mainline kernel that supports user space mapping of GPIO, SPI, I2C, PWM and MMIO.