Search the Community

Showing results for tags 'mainline'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues
    • Peer to peer technical support
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Development
    • Allwinner H6
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 869 results

  1. According to the specs of the OP PC Plus, it only supports 32GB micro SD. My only 32GB that I have, that I was booting from on the OP PC plus eventually got corrupted, and will not boot, can't format and install armbian or anything. What are my options? Can I somehow boot from a 64GB micro sdcard, or USB from a fresh armbian image write?
  2. Hi, I have a couple of these boards which I have been using with Armbian and the old, 3.10 kernel. Ideally I would really like to go mainline as later kernels have some functionality that would be useful for my use of the board. The only remaining reason (apart from cpu freq.) for sticking to the 3.10 kernel has been the lack of MIPI DSI support in mainline, but now I see that, despite the Matrix at http://linux-sunxi.org/Linux_mainlining_effort still being red for A64 mipi, some work is being/has been done by Maxime Ripard. I'm just wondering if anyone here knows if a working mainline kernel with DSI for the Pine 64 is starting to look like a possibility and if it might be possible to include in an armbian build. I might be able to do some testing of anyone can guide me in making a build with the necessary patches.
  3. Hello, I have a massive problem as the time/date on my Pine64 keep changing randomly to the year 2113. In my project, I use several Pine64s and the problem now occurs on many of these Pine64s. Unfortunately I need the correct time for my project. I am using the following system: ARMBIAN 5.32.170911 nightly Ubuntu 16.04.3 LTS 4.13.0-sun50iw1 (with additional overlays = uart3 and console = ttyS3) Could this be due to the error described in the post and is the bug fixed in kernel version 4.14? Could I install this kernel version 4.14 via armbian-config (next-kernel)? Thanks a lot for help.
  4. I'm trying to disable the HDMI output on my A20-OlinuXino LIME. I have tried to disable the HDMI from the u-boot console using this commands : -setenv video-mode sunxi:1024x768-24@60,monitor=none -saveenv I have also tried to recompile the boot.cmd but even in this way nothing. Corrently i'm using : Linux lime 4.19.62-sunxi #5.92 Where is my mistake? Thanks in advance.
  5. Basic information: Board: Orange Pi Plus 2e Image: Armbian_19.11.3_Orangepiplus2e_buster_current_5.3.9.img Issue: No sound on HDMI output There has been quite a few suggestions for this issue here and and OrangePi Plus and none works for me. Tried following: 0. sudo apt-get update && upgrade 1. Created and Changed /etc/asound.conf Version 1: pcm.!default { type hw card 1 } ctl.!default { type hw card 1 } Version 2: pcm.!default { type hw card 1 device 0 } ctl.!default { type hw card 1 } 2. Verified user is included in group 'audio' and has permissions groups raj tty disk dialout sudo audio video plugdev games users systemd-journal input netdev ssh cat /proc/asound/cards 0 [Codec ]: H3_Audio_Codec - H3 Audio Codec H3 Audio Codec 1 [allwinnerhdmi ]: allwinner_hdmi - allwinner,hdmi allwinner,hdmi cat /proc/asound/pcm 00-00: CDC PCM Codec-0 : CDC PCM Codec-0 : playback 1 : capture 1 01-00: 1c22800.i2s-i2s-hifi i2s-hifi-0 : 1c22800.i2s-i2s-hifi i2s-hifi-0 : playback 1 cat /proc/asound/devices 0: [ 0] : control 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 32: [ 1] : control 33: : timer 48: [ 1- 0]: digital audio playback cat /proc/asound/modules 0 (efault) 1 snd_soc_simple_card Output of: alsamixer -c 1 controls Outputs: asound$ amixer -c 1 controls numid=2,iface=PCM,name='ELD' numid=1,iface=PCM,name='Playback Channel Map' amixer set PCM 10% unmute amixer: Unable to find simple control 'PCM',0 amixer -c 1 set PCM 2dB+ amixer: Unable to find simple control 'PCM',0 Reinstalled - alsa-utils cat /var/lib/alsa/asound.state state.sun4icodec { control.1 { iface MIXER name 'Power Amplifier Volume' value 32 comment { access 'read write' type INTEGER count 1 range '0 - 63' dbmin -9999999 dbmax 0 dbvalue.0 -3100 } } control.2 { iface MIXER name 'Left Mixer Left DAC Playback Switch' value false comment { access 'read write' type BOOLEAN count 1 } } control.3 { iface MIXER name 'Right Mixer Right DAC Playback Switch' value false comment { access 'read write' type BOOLEAN count 1 } } control.4 { iface MIXER name 'Right Mixer Left DAC Playback Switch' value false comment { access 'read write' type BOOLEAN count 1 } } control.5 { iface MIXER name 'Power Amplifier DAC Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.6 { iface MIXER name 'Power Amplifier Mixer Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.7 { iface MIXER name 'Power Amplifier Mute Switch' value true comment { access 'read write' type BOOLEAN count 1 } } } state.SPDIF { control { } } state.Codec { control.1 { iface MIXER name 'DAC Playback Volume' value 45 comment { access 'read write' type INTEGER count 1 range '0 - 63' dbmin -7308 dbmax 0 dbvalue.0 -2088 } } control.2 { iface MIXER name 'Line In Playback Volume' value 3 comment { access 'read write' type INTEGER count 1 range '0 - 7' dbmin -450 dbmax 600 dbvalue.0 0 } } control.3 { iface MIXER name 'Line Out Playback Volume' value 17 comment { access 'read write' type INTEGER count 1 range '0 - 31' dbmin -9999999 dbmax 0 dbvalue.0 -2100 } } control.4 { iface MIXER name 'Line Out Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.5 { iface MIXER name 'Mic2 Playback Volume' value 3 comment { access 'read write' type INTEGER count 1 range '0 - 7' dbmin -450 dbmax 600 dbvalue.0 0 } } control.6 { iface MIXER name 'Mic2 Boost Volume' value 4 comment { access 'read write' type INTEGER count 1 range '0 - 7' dbmin 0 dbmax 4200 dbvalue.0 3300 } } control.7 { iface MIXER name 'Mic1 Playback Volume' value 3 comment { access 'read write' type INTEGER count 1 range '0 - 7' dbmin -450 dbmax 600 dbvalue.0 0 } } control.8 { iface MIXER name 'Mic1 Boost Volume' value 4 comment { access 'read write' type INTEGER count 1 range '0 - 7' dbmin 0 dbmax 4200 dbvalue.0 3300 } } control.9 { iface MIXER name 'ADC Gain Capture Volume' value 3 comment { access 'read write' type INTEGER count 1 range '0 - 7' dbmin -450 dbmax 600 dbvalue.0 0 } } control.10 { iface MIXER name 'DAC Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.11 { iface MIXER name 'DAC Reversed Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.12 { iface MIXER name 'Line In Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.13 { iface MIXER name 'Mic1 Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.14 { iface MIXER name 'Mic2 Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.15 { iface MIXER name 'Mixer Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.16 { iface MIXER name 'Mixer Reversed Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.17 { iface MIXER name 'Line In Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.18 { iface MIXER name 'Mic1 Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.19 { iface MIXER name 'Mic2 Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.20 { iface MIXER name 'Line Out Source Playback Route' value.0 Stereo value.1 Stereo comment { access 'read write' type ENUMERATED count 2 item.0 Stereo item.1 'Mono Differential' } } } state.allwinnerhdmi { control.1 { iface PCM name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 comment { access read type INTEGER count 6 range '0 - 36' } } control.2 { iface PCM name ELD value '0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read volatile' type BYTES count 128 } } No luck till date. Thanks Rajesh
  6. I installed the latest 5.4.8 Buster Desktop image on my Orange Pi +2e board but find the Mali drivers are (Utgard) missing or not loaded. I have tried to follow every possible links including (https://linux-sunxi.org/Mali_binary_driver) related to get VDPAU / VAAPI and GPU but with very little success. I want to have HW acceleration enabled for playing MPEG in full screen mode 1920x1280 resolution using mpv. The frame drops are significant. Questions: Are Mali drivers included in this build? If it is then how can I go about adding those drivers. Is there any licencing issues in adding Mali drivers to the Armbian image? Is there any chances of Lima drivers being included in future releases? There are Mali drivers available on ARM developer site that provides GPU Kernel Device drivers. Can I use them to build the custom Armbian image? Appreciate any help in this matter. Thanks Rajesh
  7. Hi everybody, I need your help in setting the default values of some or all GPIO Pin, so that it will be always activated after reboot instead of deactivated like the default is today. The reason for this is that I've connected a relaisboard to some GPIO Pins that will need "1" to be deactivated . Everything works fine, I can control and work with these Pins like needed by using "1" for OFF and "0" for ON. After booting up my BPI I initialize the needed GPIO Pins via export the pins. That will create virtual directories for these Pins with these defaults: direction -> in value -> 0 Like I mentioned, my relaiseboard need a logical 0 to be activated, so when I switch the direction to out, my motor on the related relay start to spin. Doing a sequence of create via export, set direction to out and set value to 1 will we fast, but will activate the motor for a short time, this is what I must avoid! Instead of rebuilding the HW for using the value "1" to been activated instead of "0" I try to change the GPIO default value from 0 to 1 what means deactivated/not active for my relaisboard. Since this is a BPI M2 Zero and there are no newer images I think I need to do this via the script.bin file. I've found for my pin PA08 these entries, but have no idea what default means what: smc_sda = port:PA08<2><default><default><default> scr_sda = port:PA08<2><default><default><default> Please can someone help me doing this or point me to an example how this must be done ? Regards WolliK
  8. Hello, I have Banana Pi R2 with armbian bionic. Have two wlan cards both USB, both works. But earlier when I used openwrt on x86 my both wlan and lan were bridged and had one IP - which was router IP. Here with armbian wlan hotspot get other IP than armbian itself. Is there any way to change it to bridge? Or best practices is to leave it as is? regards, Maciek
  9. Is anyone still working with cubietruck? I installed the latest mainline image over Christmas expecting it to have the cedrus driver but apparently it does not. I thought that everything except HDMI audio should be working in mainline now. So I installed the latest legacy image. It plays videos well but bluetooth doesnt work. I switched it on in armbian-config and 'rfkill list' shows it as not disabled but the bluetooth manager shows no adapter and search is grayed out. This is a regression as it used to work to some extent. Also, very importantly for me, neither image switch over to battery power when the AC goes out. This also used to work on legacy, unless it was cubian that worked and armbian never did, I should keep notes...
  10. Is it possible that there have been some image changes that broke the XR819 wifi completely? The available images for download on the Armbian page (5.3 server, and 5.4 minimal) as well as a custom built "legacy" branch linux-4.19 image all show the same behavior, The wlan0 interface is not active and it's not possible to bring it up. And dmesg shows that module has been initialized but not much more. Armbianmonitor support info: 5.3.9 official buster server image: http://ix.io/240Y 4.19.88 self-built, two days ago, legacy branch: http://ix.io/240U Everything below is from the official image, but the 4.19 image shows the exact same It is definitely not a hardware issue, I have a SD card with a an older 4.19.72 image (when the branch was still called "next") that works just fine. ifconfig -a ifconfig root@orangepizero:~# ifconfig wlan0 up SIOCSIFFLAGS: Invalid argument root@orangepizero:~# rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no root@orangepizero:~# journalctl -b | grep xradio Nov 19 08:08:00 orangepizero kernel: xradio_wlan mmc1:0001:1: Input buffers: 30 x 1632 bytes Nov 19 08:08:00 orangepizero kernel: xradio_wlan mmc1:0001:1: Firmware Label:XR_C01.08.0043 Jun 6 2016 20:41:04 Nov 19 08:08:28 orangepizero NetworkManager[1057]: <info> [1574150908.3204] rfkill0: found WiFi radio killswitch (at /sys/devices/platform/soc/1c10000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy0/rfkill0) (driver xradio_wlan) root@orangepizero:~# uname -a Linux orangepizero 5.3.9-sunxi #19.11.3 SMP Mon Nov 18 18:49:43 CET 2019 armv7l GNU/Linux
  11. Armbianmonitor for 5.4.6: http://ix.io/260C From switching between 4.19.x and 5.4.x kernels I noticed that the lower cpu frequencies got missing. It should start at 120MHz like this: root@horangepione:~# uname -a Linux honeypot2 4.19.84-sunxi #19.11.3 SMP Mon Nov 18 18:39:42 CET 2019 armv7l GNU/Linux root@horangepione:~# cpufreq-info -o minimum CPU frequency - maximum CPU frequency - governor CPU 0 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 1 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 2 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 3 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand Though on 5.4.x the minimum frequency is 480MHz. Since the default cpufrequtils file was not there I created one: cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=120000 MAX_SPEED=1200000 GOVERNOR=ondemand It seems to have an effect because when changing the minimum frequency it clocks up as it should. Frequencies beyond 1.01GHz missing as well but that is a different story...I guess. Cheers Werner
  12. Well, no fancy introduction here, because this doesn't pretend to be a script for the general use, only for testers who want to try the current *very early* status of the media capabilities in the Armbian meson mainline kernel. Warning: It will replace your current kernel with a pre-compiled nightly 4.19.20. Instructions: Download, untar and run. If you need further instructions, then you are not ready for this script (again, it is very unpolished, not for general use). Download link: https://mega.nz/#!YvYUhayC!CI1fl52V4tV0G4oqUib4W-NlMpVSpLDp8kmo74g-V08 Things that you can try with this script, on a X session: Use a 1080p@30fps h264 video, and play it with "mpv -hwdec <filename>". You'll see in the logs that it is decoding through v4l-m2mcopy Install and run glmark2-es2 Use Chromium WebGL Play a 1080p@30fps video in YouTube in full-screen smoothly. I'm pretty sure it is not really using HW decoding as it claims (there is no initialization message in dmesg), but it's smooth for sure. Gstreamer is tested not to work, in some other forum I was told that Bionic version is not enough and I need to compile a newer one. Performance is not in any way good, but it is a starting point. Anyway, the first TO-DO is getting the mali module integrated into the kernel, so there is no need to compile it separately.
  13. Hello all, Recently, I bought an Orange Pi Win Plus board and have installed Armbian on SDcard and it works fine but when i try to install it on emmc using "sudo nand-sata-install" it just shows "install/update the bootloader on SD/eMMC" in the options instead of "boot from eMMC - system on eMMC" as i have seen on the internet . so guys! what am i doing wrong!? Regards,
  14. Hi guys, I have recently bought a Rock64 to improve the performance of my VPN gateway. First tests look very promising as you can see here: root@rock64:~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 15394610 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 12591175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6719021 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2448108 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 352617 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 177668 aes-128-cbc's in 3.00s OpenSSL 1.1.1d 10 Sep 2019 built on: Sat Oct 12 19:56:43 2019 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-H2OJIf/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 82379.18k 268611.73k 573356.46k 835620.86k 962879.49k 970304.17k root@rock64:~# openvpn --genkey --secret /tmp/secret root@rock64:~# time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc Sat Dec 14 10:26:40 2019 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode real 0m4.978s user 0m4.945s sys 0m0.032s Unfortunately when executing a simple curl, the throughput is very low: root@rock64:~# curl -L https://speed.hetzner.de/1GB.bin > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 1000M 2 29.9M 0 0 2090k 0 0:08:09 0:00:14 0:07:55 3106k When using Ubuntu 18.04 Bionic I am reaching speeds of 8,4MByte/s. I have checked the openvpn process and it seems that it is only using 25% of CPU, whereas when using in Ubuntu it is using 50-60%. What are the differences here and why is Armbian limiting the process to 25%? Thanks! Bye
  15. Hello, I am going to start looking into running Docker on OPi +2E soon, but before I get stuck in details I would like to know whether other people have had experience with it..? In particular, I would like to know what to expect when trying to run Docker on an OPi +2E. Having a report from prior experience would be helpful. As far as I understand, Docker is still in pretty much experimental stages on ARM. Kind regards, @ullbeking
  16. Hi everyone! I'm trying to build my own distribution for the Pine64, and I use armbian as a working reference. I'm able to compile ATF + U-boot + Kernel + rootfs and the board actually boots and I get a console over the serial interface and over HDMI. The problem is that GbE Ethernet does not work. It appears that the 8211 phy is not powered. The good guys on the pine64 IRC pointed to the ATF, where the DC1SW regulator should be turned on in order to power the phy. On armbian everything works just fine. I think I messed up something in the build - wrong version / config / dts in either ATF, U-boot or the linux kernel. I tried to understand how the armbian Pine64 image was built - but since I'm totally new to armbian I got lost pretty quick. So basically I want to know how can I find the following information: 1. What version + platform of ATF is used? Is it from the official ARM repo, or some fork? 2. What version + config + dts of U-Boot is used? 3. What version + config + dts of Linux is used? Is it mainline / LTS kernel? are there any special patches applied that I should be aware? I know it is a bit weird question to ask here, but I really want to learn how to create my distro, and armbian is a great reference.
  17. I'm using g_ether to connect OrangePiPc+ to network over USB OTG. On legacy kernel, that was giving 140 Mbits/sec IN (download from network to OrangePiPc+) and 170 Mbits/sec OUT. After upgrading to mainline kernel 4.19.62 (or 5.3.9), IN throughput degraded to 93-98 Mbits/sec (while OUT improved reaching up to 210 Mbits/sec in CDC EEM mode). This easily reproducible on both my boards OrangePiPc+ and OrangePiZero with latest Bionic images (clean installations + "modprobe g_ether iProduct="Linux-USB Ethernet/RNDIS Gadget" iManufacturer="Netchip Technology, Inc." dev_addr=02:81:05:F0:5C:24 host_addr=02:81:05:F0:5C:23 use_eem=0" ). Any ideas where is the bottleneck and how to resolve it? Tried several USB cables and USB host devices. Throughput measured by iperf; samba and nfs are showing the same. ifconfig stats indicating 0 tx/rx errors.
  18. I tested the recently added sunxi-dev patch to improve the SATA write speed. Here are the results: Board: Cubietruck OS: Ubuntu Bionic (18.04.2), Armbian 5.86 Kernel: 5.1.0 with and without RFC-drivers-ata-ahci_sunxi-Increased-SATA-AHCI-DMA-TX-RX-FIFOs.patch SATA-device: SAMSUNG SSD 830 Series, 256GB Measurement method: dd if=/dev/zero of=/tesfile bs=? count=? oflag=direct bs: measured 4k, 64k and 1M block sizes count: adjusted to ensure that data written is ~500MB Measurements below are made with kernel 5.1.0 without (before) and with the mentioned patch: dd bs Before MB/s After MB/s Increase 4k 13.3 19.0 43% 64k 35.9 82.0 128% 1M 42.5 112.0 164% As you can see, the SATA write speed improved, especially when using larger block sizes. Up to now, no negative side-effects encountered.
  19. Hello guys, I am experiencing such a problem: When I boot my orangepi it starts and it is visible in the router's page view getting IP with dhcp. As soon as I connect over ssh (at least this is the way to trigger it, not sure if it is hapening automatically after a while), the device disappears from the network and it is no more available! I have seen this behaviour happening on 2 different routers. Then I rebooted the device again and in the router config I put the same IP statically linked to the device and I tried to connect over ssh and it worked without disappearing anymore. So it sounds like a bug somewhere using dhcp protocol. Is someone else experienced such problem? How I can help to definitely fix this annoying bug? Thanks, Gianni
  20. Hi guys, I am trying to use TP-Link dongle WN722N v3 as an access point . I am using Nano Pi Neo Core EMMC with expansion board running Armbian Buster with Linux 5.3.9-sunxi . The device can detect wifi signals nearby as seen on nmtui in managed mode . I followed the instructions on https://forum.odroid.com/viewtopic.php?f=52&t=25472&sid=84d2b8f1e7ad477e9907591eb7fb030d to configure as access point . However , I get an error every time like this . root@Cyborg:~# nmcli connection up HotSpot ifname wlx503eaaa2df7b Error: Connection activation failed: Connection 'HotSpot' is not available on device wlx503eaaa2df7b because profile is not compatible with device (the device does not support Access Point mode) Output of dmesg | tail -n 20 on inserting the dongle . [ 1225.431164] ---[ end trace 91514764a9d606b4 ]--- [ 1225.431176] RTW: rtw_wdev_free(wdev=3fa7fa4c) [ 1225.431184] RTW: rtw_wiphy_free(phy1) [ 1225.431222] RTW: rtw_usb_primary_adapter_deinit((null)) [ 1225.431227] RTW: rtw_dev_unload: bup==_FALSE [ 1225.431239] RTW: +r871xu_dev_remove, hw_init_completed=0 [ 1225.431664] RTW: WARN free_recv_skb_queue not empty, 8 [ 1225.431719] RTW: usb attached..., try to reset usb device [ 1225.557473] usb 3-1: reset high-speed USB device number 3 using ehci-platform [ 1225.714010] In rtw_drv_init return -ENODEV [ 1225.714340] Chip Version Info: CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0) [ 1225.763898] r8188eu 3-1:1.0 wlx503eaaa2df7b: renamed from wlan0 [ 1226.629967] MAC Address = 50:3e:aa:a2:df:7b root@Cyborg:~# I know the dongle works because I used it on a Nano Pi Duo running FriendlyARM's running Ubuntu Linux kernel version 4.14.0 . I am really confused . Is it a kernel issue ? My main intention is to use some GPIOs using Wiring Pi and run an apache webserver on it . I want to use the dongle to serve HTML pages over a hotspot . Any help is appreciated .
  21. I have tested Armbian_19.11.3_Orangepipc2_bionic_current_5.3.9 and Armbian_19.11.3_Orangepipc2_buster_current_5.3.9 images from the official download site. The Debian Buster image is fast and stable. The Ubuntu Bionic build have random hangs on different boot positions. Sometimes works, but after reboot it hangs again randomly. I have burned the the images to the same microsd card. (Toshiba 32GB) I have tested with other microsd cards like Sandisk Extreme 32GB, Samsung EVO+ 32GB. I have the same results. The power supply is enough for the board. (5V 4A) This is not my first orangepi board, so I know how to burn the images to the sdcards. screenlog.bionic.0 (problems) screenlog.buster.0 (all ok) With freshly burned sdcard, sometimes it take a lot of time to boot with the Bionic release. Or simply hangs on different boot positions. Sometimes it gives the following errors: usually hangs in this position:
  22. Hello, After upgrade Armbian (4.19.69-meson64) to Armbian Buster with Linux 5.3.11-meson64 warning messages shows up on boot in dmesg: ... [ 1.973932] Key type encrypted registered [ 1.985109] dwc2 c9000000.usb: c9000000.usb supply vusb_d not found, using dummy regulator [ 1.985153] dwc2 c9000000.usb: c9000000.usb supply vusb_a not found, using dummy regulator [ 1.986616] phy phy-c0000000.phy.0: USB ID detect failed! [ 1.986623] phy phy-c0000000.phy.0: phy poweron failed --> -22 [ 1.986643] ------------[ cut here ]------------ [ 1.986700] WARNING: CPU: 3 PID: 68 at drivers/regulator/core.c:2036 _regulator_put+0x34/0xd8 [ 1.986702] Modules linked in: [ 1.986709] CPU: 3 PID: 68 Comm: kworker/3:1 Not tainted 5.3.11-meson64 #19.11.3 [ 1.986711] Hardware name: Hardkernel ODROID-C2 (DT) [ 1.986719] Workqueue: events deferred_probe_work_func [ 1.986724] pstate: 60000005 (nZCv daif -PAN -UAO) [ 1.986728] pc : _regulator_put+0x34/0xd8 [ 1.986732] lr : _regulator_put+0x34/0xd8 [ 1.986733] sp : ffff000011683af0 [ 1.986735] x29: ffff000011683af0 x28: 0000000000000000 [ 1.986739] x27: ffff80007f2ac6b8 x26: ffff000011106530 [ 1.986743] x25: 0000000000000000 x24: 0000000000000009 [ 1.986746] x23: ffff000011683bb8 x22: ffff80006a1c2b00 [ 1.986750] x21: ffff0000113916c8 x20: ffff80006a1c2d00 [ 1.986753] x19: ffff80006a1c2d00 x18: ffff0000113ae000 [ 1.986756] x17: 000000003ae42590 x16: 00000000ed672116 [ 1.986760] x15: 00000000fffffff0 x14: ffff0000114be0fa [ 1.986763] x13: 0000000000000000 x12: ffff0000114bd000 [ 1.986767] x11: ffff0000113ae000 x10: ffff0000114bd748 [ 1.986770] x9 : 0000000000000000 x8 : 0000000000000001 [ 1.986774] x7 : 00000000000000eb x6 : ffff0000114bd000 [ 1.986777] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.986780] x3 : 00000000ffffffff x2 : 3c797d94ab3f0f00 [ 1.986783] x1 : 0000000000000000 x0 : 0000000000000024 [ 1.986787] Call trace: [ 1.986792] _regulator_put+0x34/0xd8 [ 1.986796] regulator_put+0x2c/0x40 [ 1.986800] regulator_bulk_free+0x30/0x50 [ 1.986805] devm_regulator_bulk_release+0x18/0x20 [ 1.986810] release_nodes+0x1b0/0x220 [ 1.986814] devres_release_all+0x34/0x58 [ 1.986818] really_probe+0x1b8/0x3d0 [ 1.986822] driver_probe_device+0xdc/0x130 [ 1.986825] __device_attach_driver+0x88/0x108 [ 1.986828] bus_for_each_drv+0x78/0xc8 [ 1.986831] __device_attach+0xd4/0x158 [ 1.986834] device_initial_probe+0x10/0x18 [ 1.986837] bus_probe_device+0x90/0x98 [ 1.986840] deferred_probe_work_func+0x88/0xd8 [ 1.986846] process_one_work+0x1e0/0x338 [ 1.986850] worker_thread+0x240/0x440 [ 1.986854] kthread+0x120/0x128 [ 1.986859] ret_from_fork+0x10/0x18 [ 1.986861] ---[ end trace 629d4ecc13425951 ]--- [ 1.986907] ------------[ cut here ]------------ [ 1.986942] WARNING: CPU: 3 PID: 68 at drivers/regulator/core.c:2036 _regulator_put+0x34/0xd8 [ 1.986943] Modules linked in: [ 1.986948] CPU: 3 PID: 68 Comm: kworker/3:1 Tainted: G W 5.3.11-meson64 #19.11.3 [ 1.986950] Hardware name: Hardkernel ODROID-C2 (DT) [ 1.986954] Workqueue: events deferred_probe_work_func [ 1.986958] pstate: 60000005 (nZCv daif -PAN -UAO) [ 1.986962] pc : _regulator_put+0x34/0xd8 [ 1.986965] lr : _regulator_put+0x34/0xd8 [ 1.986967] sp : ffff000011683af0 [ 1.986969] x29: ffff000011683af0 x28: 0000000000000000 [ 1.986972] x27: ffff80007f2ac6b8 x26: ffff000011106530 [ 1.986976] x25: 0000000000000000 x24: 0000000000000009 [ 1.986979] x23: ffff000011683bb8 x22: ffff80006a1c2b00 [ 1.986983] x21: ffff0000113916c8 x20: ffff80006a1c2e00 [ 1.986986] x19: ffff80006a1c2e00 x18: ffff0000113ae000 [ 1.986989] x17: 000000003ae42590 x16: 00000000ed672116 [ 1.986993] x15: 00000000fffffff0 x14: ffff0000114be0fa [ 1.986996] x13: 0000000000000000 x12: ffff0000114bd000 [ 1.987000] x11: ffff0000113ae000 x10: ffff0000114bd748 [ 1.987003] x9 : 0000000000000000 x8 : 0000000000000001 [ 1.987006] x7 : 0000000000000118 x6 : ffff0000114bd000 [ 1.987010] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.987013] x3 : 00000000ffffffff x2 : 3c797d94ab3f0f00 [ 1.987016] x1 : 0000000000000000 x0 : 0000000000000024 [ 1.987019] Call trace: [ 1.987023] _regulator_put+0x34/0xd8 [ 1.987027] regulator_put+0x2c/0x40 [ 1.987030] regulator_bulk_free+0x30/0x50 [ 1.987034] devm_regulator_bulk_release+0x18/0x20 [ 1.987038] release_nodes+0x1b0/0x220 [ 1.987041] devres_release_all+0x34/0x58 [ 1.987044] really_probe+0x1b8/0x3d0 [ 1.987048] driver_probe_device+0xdc/0x130 [ 1.987051] __device_attach_driver+0x88/0x108 [ 1.987053] bus_for_each_drv+0x78/0xc8 [ 1.987056] __device_attach+0xd4/0x158 [ 1.987059] device_initial_probe+0x10/0x18 [ 1.987062] bus_probe_device+0x90/0x98 [ 1.987065] deferred_probe_work_func+0x88/0xd8 [ 1.987069] process_one_work+0x1e0/0x338 [ 1.987072] worker_thread+0x240/0x440 [ 1.987075] kthread+0x120/0x128 [ 1.987078] ret_from_fork+0x10/0x18 [ 1.987081] ---[ end trace 629d4ecc13425952 ]--- [ 1.987135] dwc2: probe of c9000000.usb failed with error -22 [ 1.987536] dwc2 c9100000.usb: c9100000.usb supply vusb_d not found, using dummy regulator [ 1.987581] dwc2 c9100000.usb: c9100000.usb supply vusb_a not found, using dummy regulator [ 2.024002] mmc0: new HS200 MMC card at address 0001 ... I haven't had any system hangups yet but I am worried.
  23. I have a 1 GB Renegade board and downloaded Armbian_19.11.3_Renegade_buster_current_5.3.11 image to install. Noticed it was only 510MB of RAM. Relevant extracts from serial log: U-Boot 2017.09-armbian (Nov 19 2019 - 00:09:05 +0100) Model: Firefly ROC-RK3328-CC DRAM: 510 MiB ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to Armbian Buster with Linux 5.3.11-rockchip64 System load: 0.10 0.14 0.06 Up time: 2 min Memory usage: 22 % of 472MB IP: 192.168.11.175 CPU temp: 44°C Usage of /: 5% of 29G [ General system configuration (beta): armbian-config ] Last login: Sat Nov 23 22:48:50 2019 Using armbian-config I downgraded to kernel 4.4.198 and I now have 919MB of RAM. U-Boot 2017.09-armbian (Nov 19 2019 - 00:01:47 +0100) Model: Firefly ROC-RK3328-CC DRAM: 1022 MiB ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to Armbian Buster with Linux 4.4.198-rockchip64 System load: 0.10 0.09 0.03 Up time: 2 min Memory usage: 8 % of 919MB IP: 192.168.11.173 CPU temp: 43°C Usage of /: 5% of 29G [ General system configuration (beta): armbian-config ] Ray
  24. I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-) The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc. (I wish it had 1GB of RAM but that's a different subject.) I'd love to use these boards for a number of projects. As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board. I also enabled the allowed clock changes to 1.2GHz for cpufreq. All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v. I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v. I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board! I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board. So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board. And now it works great! VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems. Would anyone have an idea why Xunlong doesn't solder this part on the board by default? They include all the other parts in this part of the power circuit, just not this MOSFET. I was going to buy a few more of these boards, and I'd like to be able to clock them up. Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...? Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis? My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS). By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds. Thank you!
  25. In the FriendlyARM thread http://www.friendlyarm.com/Forum/viewtopic.php?f=53&amp;t=1427&amp;p=5685#p5685 we did try to use A64 images from the Pine64 or the BananaPi M64 with the NanoPi A64. The last times we did that with less success - OK Sytem is running but Network/Sound has to added via USB. No suppport for the onboard devices But today a user did wrote that - with the actual stable Pine64-image ( Armbian_5.69_Pine64_Debian_stretch_next_4.19.13 ) WiFi is useable. So I flasded the Pine64-image to a MicroSDCard and did boot. Additiionally I did see with "aplay -l" the HDMI and the analog Sound-device. But ethernet isnt "connected" right via the .dtb armbian inside can see the ethernet-part of the SoC (set IP and see MAC) and the external RTL8122E Phy blinks the Link and Transfered-Packets via LED.... My first idea was to edit the Pine64 DTB to match the NanoPI A64 DTB in the ethernet-part - but with these Pins & PHandle's I did get stuck BUT my second idea did work much better, because in the armbian-build-system I also did see the sun50i-a64-nanopi-a64.dtb So I checked the board-config-file for the pine64.conf ( under ./build/config/boards/ ) - there is an entry for a defconfig file and the armbin-build-system has also a defonfig file for the nanopi-a64 ./build/cache/sources/u-boot/v2018.11/configs/nanopi_a64_defconfig while the NanoPi A64 isnt (official) supported by the Meneu-System of the armbian-build-system. So I copied ./build/config/boards/pine64.conf to ./build/config/boards/nanopia64.conf and did edit it like in the following way: # A64 quad core 512MB-2GB SoC GBE BOARD_NAME="NanoPiA64" BOARDFAMILY="sun50iw1" BOOTCONFIG_DEFAULT="sun50iw1p1_config" BOOTCONFIG="nanopi_a64_defconfig" # MODULES="sunxi_codec sunxi_i2s sunxi_sndcodec 8723bs" MODULES_NEXT="" # KERNEL_TARGET="default,next,dev" CLI_TARGET="bionic,stretch:next" DESKTOP_TARGET="xenial:default" # CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" and did compile for the NanoPi A64 with ./compile.sh EXPERT="yes" in ./build/ Now I could select the NanoPi A64 (falsely) as supported board and did select DEV (armbian 5.71 with Kernel 4.20) I did build the console and the Desktop-version. In the console-version I was happy to see eth0 & wlan0 working, but the HDMI and analog soundsystem is missing (which was visible in Pine64 next 4.19.13) So there was no need for a RTL8211E-driver (because its only a PHY) like I did read before at http://linux-sunxi.org/Ethernet#Realtek_RTL8211E In the Desktop-version the GUI did start without problems (not fast, but useable) - like on a older pinebook (a64) build Maybe DEV was "too much"? I will try the NEXT for my NanoPi A64 File Or maybe the nanopi A64 dtb isnt correct on the "sound-part"?