cvxx

I don't have "sun8i-h3-nanopi-neo-air.dts" file, so I can't evaluate the patch. Same file from linux-sunxi repo looks far too small for the patch: https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-next/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts Just appending same lines to my dts gives an error during compile: # dtc -I dts -O dtb test.dts > sun8i-h3-orangepi-lite-pathced.dtb Error: test.dts:1641.1-7 Label or path ehci0 not found Error: test.dts:1645.1-7 Label or path ohci0 not found Error: test.dts:1649.1-9 Label or path usb_otg not found FATAL ERROR: Syntax error parsing input tree My original dts "sun8i-h3-orangepi-lite.dts" looks like this: https://pastebin.com/6qUhWuTC Any ideas where to apply the patch?

Does 4.14 kernel support otg serial? If yes, how do I enable it?

Oh, I forgot about the TTL onboard... Thanks, the board boots fine, I can log in through the serial connection

Hi, I have flashed Armbian_5.35_Orangepilite_Ubuntu_xenial_default_3.4.113_desktop.img - and it works fine with my Orange Pi Lite v.1.1 But if I flash Armbian_5.38_Orangepilite_Debian_stretch_next_4.14.14.img which is aslo supported, the device does not boot. At least I get no output on HDMI, and no serial console over OTG. So I cannot check if it does not boot at all, or dies somewhere in the middle How can I check why it does not boot?

Switched kernels. Total made 4 tests, here are my results so far: H - Hardkernel's A - Armbian's +---+--------+----------+--------+-----+ | 0 | Kernel | boot.ini | RootFS | 433 | +---+--------+----------+--------+-----+ | 1 | H | H | H | OK | | 2 | A | H | H | OK | | 3 | H | A | A | NO | | 4 | A | A | A | NO | +---+--------+----------+--------+-----+ So, the issue is caused by either boot.ini or root fs. Not easy to swap and test: both are very different boot.ini diff: --- hardkernel\boot.ini Thu Sep 14 14:35:20 2017 +++ armbian\boot.ini Sat Jan 27 18:04:08 2018 @@ -1,10 +1,12 @@ ODROIDC-UBOOT-CONFIG +setenv rootdev "UUID=753f661a-b187-4823-abce-66db73b680af" +setenv rootfstype "ext4" + # Possible screen resolutions # Uncomment only a single Line! The line with setenv written. # At least one mode must be selected. -# setenv m "480x800p60hz" # 480x800 # setenv m "vga" # 640x480 # setenv m "480p" # 720x480 # setenv m "576p" # 720x576 @@ -31,14 +33,10 @@ # setenv vout_mode "vga" # HDMI BPP Mode -setenv m_bpp "32" -# setenv m_bpp "24" +# setenv m_bpp "32" +setenv m_bpp "24" # setenv m_bpp "16" -# Monitor output -# Controls if HDMI PHY should output anything to the monitor -setenv monitor_onoff "false" # true or false - # HDMI Hotplug Force (HPD) # 1 = Enables HOTPlug Detection # 0 = Disables HOTPlug Detection and force the connected status @@ -57,7 +55,7 @@ # UHS Card Configuration # Uncomment the line below to __DISABLE__ UHS-1 MicroSD support # This might break boot for some brand models of cards. -setenv disableuhs "disableuhs" +# setenv disableuhs "disableuhs" # Disable VPU (Video decoding engine, Saves RAM!!!) @@ -75,34 +73,24 @@ # setenv condev "console=tty0" # on display (HDMI) setenv condev "console=tty0 console=ttyS0,115200n8" # on both -# Enable/Disable ODROID-VU7 Touchscreen -setenv disable_vu7 "false" # false -# CPU Max Frequency -# Possible Values: 96 192 312 408 504 600 720 816 -# 1008 1200 1320 1488 1536 1632 1728 and 1824 -setenv max_freq "1536" -# setenv max_freq "1632" -# setenv max_freq "1728" -# setenv max_freq "1824" ########################################### if test "${hpd}" = "0"; then setenv hdmi_hpd "disablehpd=true"; fi if test "${cec}" = "1"; then setenv hdmi_cec "hdmitx=cecf"; fi -if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quirks=0x0eef:0x0005:0x0004"; fi # Boot Arguments -setenv bootargs "root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro ${condev} no_console_suspend fsck.repair=yes vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} monitor_onoff=${monitor_onoff} max_freq=${max_freq} ${hid_quirks}" +setenv bootargs "root=${rootdev} rootwait rw ${condev} rootfstype=${rootfstype} loglevel=1 no_console_suspend consoleblank=0 vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} ${extraargs}" # Booting -fatload mmc 0:1 0x21000000 uImage -fatload mmc 0:1 0x22000000 uInitrd -fatload mmc 0:1 0x21800000 meson8b_odroidc.dtb +ext4load mmc 0:1 0x21000000 /boot/uImage || fatload mmc 0:1 0x21000000 uImage || ext4load mmc 0:1 0x21000000 uImage +ext4load mmc 0:1 0x22000000 /boot/uInitrd || fatload mmc 0:1 0x22000000 uInitrd || ext4load mmc 0:1 0x22000000 uInitrd +ext4load mmc 0:1 0x21800000 /boot/dtb/meson8b_odroidc.dtb || fatload mmc 0:1 0x21800000 dtb/meson8b_odroidc.dtb || ext4load mmc 0:1 0x21800000 dtb/meson8b_odroidc.dtb fdt addr 21800000 if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi -bootm 0x21000000 0x22000000 0x21800000" +bootm 0x21000000 0x22000000 0x21800000

Tested "performance" governor, tested same boot.ini params - didn't help Can I try to run Hardkernel's kernel on Armbian root file system? Is it enough just to replace uImage and modules dir to test this case?

After more testing it looks like I have to put the sender close to the receiver, like few centimeters. Then it shows codes received. Previously, with Hardkernel's image it worked fine at the distance ~ 6 meters What could be the root cause? Some power limit on the pin? Cpu clock? Please, any suggestion to troubleshoot

Hi, I was using Hardkernel's provided image for Odroid C1 and that was working fine. There is bunch of test sensors attached to gpio, like DHT22, BMP085, DS18B20 and 433 mhz receiver. Now I have tried to switch to Armbian and all the sensors keep working as they did, except 433 mhz receiver The RFSniffer I use is this one: https://github.com/ninjablocks/433Utils I changed WiringPI PIN to be used to "5": --- a/RPi_utils/RFSniffer.cpp +++ b/RPi_utils/RFSniffer.cpp @@ -22,7 +22,7 @@ int main(int argc, char *argv[]) { // This pin is not the first pin on the RPi GPIO header! // Consult https://projects.drogon.net/raspberry-pi/wiringpi/pins/ // for more information. - int PIN = 2; + int PIN = 5; Also tested pin 6 - doesn't work Any ideas what may be the difference between Hardkernel's image and Armbian's that made 433 receiver to stop working? Thanks

As most of boards are using wifi I wanted to confirm if KRACK vulnerability has been fixed in Armbian? https://www.krackattacks.com/

Yes, I definitely connected to a wrong pin. Now all works. Thanks!

Is "PH20" an equivalent of "GPIO-4"?

I tried to follow your steps, but I still get these: Should it work on Armbian 5.25 and kernel 4.9.7 Feb 2 01:52:06 CET 2017?

After some testing I found the same behavior with legacy kernel 3.4.113 The thing is that while "digitalRead" returns me "0", I execute "gpio readll" in a command line and I see that there pin's status is shown correctly - it is "1". Very weird and so far I have no idea how to troubleshoot such issue. All worked fine when my BananaPi was running Lubuntu 14.04 from Lemaker. Now, after upgrade to Armbian 16.04 this issue appeared. Really strange

That worked after applying this patch: https://github.com/armbian/build/blob/master/extras/rtl8192cu.sh#L25-L50 Thanks

$ modinfo 8192cu | grep vermagic vermagic: 3.4.113-sun5i preempt mod_unload modversions ARMv7 p2v8

The following wifi dongle does not work with legacy kernel: Bus 002 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter $ uname -a Linux bananapi 3.4.113-sun7i #40 SMP PREEMPT Thu Feb 2 01:44:33 CET 2017 armv7l armv7l armv7l GNU/Linux Freshly flashed Armbian_5.25_Bananapi_Ubuntu_xenial_default_3.4.113_desktop

OK, I will try to power through gpio pin to see if there is any difference

Hi, I have connected additional USB port on the GPIO header. The port works fine when I plug something on a running system. But if the device is connected before powering Zero - port does not recognize the device. So I need always unplug and plug back after rebooting. Boot with device connected: [ 63.360183] usb 7-1: device descriptor read/64, error -110 [ 63.650188] usb 7-1: new full-speed USB device number 3 using sunxi-ohci [ 64.370172] eth0: no IPv6 routers present [ 78.830243] usb 7-1: device descriptor read/64, error -110 [ 94.120185] usb 7-1: device descriptor read/64, error -110 [ 94.410620] usb 7-1: new full-speed USB device number 4 using sunxi-ohci [ 104.830295] usb 7-1: device not accepting address 4, error -110 [ 105.010283] usb 7-1: new full-speed USB device number 5 using sunxi-ohci [ 115.430172] usb 7-1: device not accepting address 5, error -110 [ 115.437760] hub 7-0:1.0: unable to enumerate USB device on port 1 Unplugging and immediately plugging back: [ 7105.464608] ohci_irq: fullspeed or lowspeed device disconnect [ 7105.464655] ehci_irq: highspeed device connect [ 7105.480187] ehci_irq: highspeed device disconnect [ 7105.614571] ehci_irq: highspeed device disconnect [ 7107.123168] ehci_irq: highspeed device connect [ 7107.400250] usb 3-1: new high-speed USB device number 4 using sunxi-ehci [ 7107.640543] rtl8192cu: Chip version 0x10 [ 7107.747882] rtl8192cu: MAC address: 00:13:ef:60:0b:fd [ 7107.747906] rtl8192cu: Board Type 0 [ 7107.748118] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 [ 7107.748252] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin [ 7107.748730] usbcore: registered new interface driver rtl8192cu [ 7107.752527] ieee80211 phy2: Selected rate control algorithm 'rtl_rc' [ 7107.770511] rtlwifi: wireless switch is on Is there a way to fix it so device is always recognized during boot? If not - is there at least a way to soft-unplug/plug usb device without having physical access to the board? Thanks

Hi, After upgrading from Lemaker Lubuntu with 3.4 kernel to the latest Armbian with 4.9 kernel my application that reads INPUT PIN using wiringPi is behaving very strange and unstable. I simply make a pin INPUT and check the value using gpio read command. When I short the pin the value returned by gpio command changes not always immediately. Some times it takes up to 5 seconds to refresh the value. I mean, it keeps returning me "0" while the pin is shortened and only few seconds later it starts returning me "1". WiringPi is installed from this repo: https://github.com/LeMaker/WiringBP Is it still fully compatible with 4.9 kernel? Or do I need to use some other version or tune my DTB/DTS? Anyone else noticed any lags with reading wiringpi gpio input pin? Thanks

Can you please point me to a wiki or instructions how to compile/decompile dts/dtb and where are they located? I'm not yet familiar with the process Thank you!

Hi, I have just upgraded my BananaPi from Lemaker's Lubuntu 3.4 kernel to the latest Armbian with kernel 4.9 and I can't enable 1-wire to read ds18b20. I suspect the enabling procedure has changed? What I did was: 1. bin2fex /boot/script.bin > script.fex 2. vi script.fex Appended this section exactly as it was on my previous Lemaker kernel 3.4: [w1_para] gpio = 4 3. fex2bin script.fex > /boot/script.bin 4. reboot 5. echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 6. modprobe w1_gpio 7. modprobe w1_therm 8. ls /sys/bus/w1/devices/ empty answer In the "known issues" currently it is written that "Different GPIO numbering compared to the legacy kernel". How different is that? Do I need to use different "[w1_para] gpio = 4" value in script.bin with the new kernel? Thank you

I'm also looking for a way to make the MAC persistant

Check if there is no wpa_supplicant running already