Search the Community

Showing results for tags 'mainline'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 851 results

  1. About 3 months ago i bought the Orange PI Zero Plus Orange Pi Zero Plus I installed Armbian Stretch and started playing around. I noticed that it got up to 71c which was to much so i shut it down and went on the net to buy some 5v fans to cool it. A month ago I received the first fans and noticed now that Armbian Buster had arrived. Since I hadn't gotten far with the config of Armbian Stretch I started on a new image. But to my disappointment the ARM processor is now clocked to 1008Mhz and not the 1.2Ghz the device is set to by manufacturer. I can guess that it is because of the heat problem that it is now set to 1008Mhz. The problem is through armbian-config there is no longer any an 1.2Ghz option only 1008Mhz . And setting nano /etc/default/cpufrequtils service cpufrequtils restart Doesn't change the actual speed from 1Ghz to 1.2Ghz Some info My kernel is uname -a Linux orangepizeroplus 4.19.63-sunxi64 #5.92 SMP Fri Aug 2 00:18:27 CEST 2019 aarch64 GNU/Linux My /etc/default/cpufrequtils looks like # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1010000 GOVERNOR=ondemand And cpufreq-info shows hardware limits: 120 MHz - 1.01 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz I suppose it's the kernel which decides what is allowed. And I do get that it will keep the heat down and that setting it to 1008Mhz as default is a good idea. But I was hoping to get the option back to choose 1.2Ghz even if it should default to 1008Mhz now where I have bought both 5v fans and NPN transistors to make a little ARM fan for my OPZ+. Ty for reading and best regards, Darkyere
  2. Hello, I have installed Armbian Debian Stretch Next (mainline kernel) on my Odroid C2 and updated to newest version(apt update & apt upgrade). Everything works fine except USB ports. I have USB LTE modem which is not recognized. I have tried "lsusb -v" but with this modem not works. But when I connect USB keyboard first then "lsusb -v" and next I connect LTE modem and type "lsusb -v" then it's works. I also tried connecting USB LTE modem before Odroid C2 boot but this workaround not working. Is there any workaround which not involving connecting more than one USB device? Maybe usb kernel modules (usbcore, ehci_hcd, ...) compiled as external modules will help find workaround?
  3. Hi, I always been an retrorangepi user for my Opi1. but the lastest retrorangepi is stuck at 4.1 (I try the 4.2 slim but it's too slim) and the 4.3 beta also if its named as full, lacks of kodi and many emulators. so, my thought is. What if I build my personal emulationstation + lastest kodi on top of lastest armbian? Can I install armbian and then emustation and kodi? Do I have to install all emulator one by one? or I could use retroarch? Can I setup armbian to boot emustation? I think could be a good thing also for study
  4. Hi, when I try to connect to OPi Zero via USB TTL (PL2303) and run minicom -D /dev/ttyUSB0 -b 115200 -o, it seems to be normal until it booted to the Kernel then it start outputing garbage but when it started without USB TTL it just work normally U-Boot SPL 2019.04-armbian (Jul 16 2019 - 10:53:57 +0200) DRAM: 256 MiB Trying to boot from MMC1 U-Boot 2019.04-armbian (Jul 16 2019 - 10:53:57 +0200) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Zero DRAM: 256 MiB MMC: mmc@1c0f000: 0, mmc@1c10000: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning bus 5 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found <INTERRUPT> => @� 0,ڕ� 0,ڕ� 0,ڕ@� 0,ڕ� 0,ڕ� 0,ڕ @� 0,ڕ @� 0,ڕ� 0,ڕ� 0,ڕ @� 0,ڕ @� 0,ڕ� 0,ڕ� 0,ڕ @� 0,ڕ� 0,ڕ 0,ڕ0,ڕ0,ڕ 0,ڕ 0�B �$�<INTERRUPT> ,ڕ0,ڕ 0,ڕ0,ڕ 0,ڕ 0,ڕ0,ڕ0,ڕ0,ڕ 0,ڕ0,ڕ 0,ڕ0,ڕ 0,ڕ 0,ڕ0,ڕ0,ڕ 0,ڕ0,ڕ 0,ڕ 0,ڕ0,ڕ0,ڕ 0,ڕ0,ڕ => ���)d� 0,ڕ Unknown command '���)d�' - try 'help' ���)d�!iJ ! )d@�H�$B�I�` ! ���BUnknown command '�B' - try 'help'iJ ! !`!iJ ! !` => �B ���)d�!iJ ! )d@�H�$B�I�` ! ���B(I d�!iJ ! !`<INTERRUPT> =>���)d�"BB` B�X�X� ! !2J!�����$(( �X�X�@I > > !`�!$�����!L<INTERRUPT> �B ���)d�!iJ ! )d@�H�$B�I�` ! ���B(I d�!iJ ! !`��� Unknown command '�B' - try 'help' ���)d�"BB` B�X�X� ! !2J!��ĉ�$((�B ���)d�!iJ ! )d@�H�$B�I�` ! ���B(I d�!iJ��!BB @@If@!�IH!A<INTERRUPT> => &&��> �Ȁ@�H� B�&&��> �Ȁ@�H��&&��> �Ȁ@�H� B�&&��> �Ȁ@�H� B�&&��> �Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ=>���)d��BJr2H �B� H�B� �*��H�IH!��Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ@�H� B�&&��> �Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ@�H��&&��> �Ȁ@�H�B�&&Unknown command '���)d��BJr2H' - try 'help'> �Ȁ@�H��&&��> �Ȁ@�H�B�&&��> �Ȁ@�H�B�&&��> �Ȁ@�H� ��1PR�K!H�B (�($���� Unknown command '��1PR�K!H�B' - try 'help'
  5. OPiPC2, with Armbian Bionic desktop mainline based kernel 4.19.y Using it as headless server, all X and desktop stuff removed. Using PuTTY to log in via SSH, line drawing stuff (as usual) only works if translation is set to ISO-8859-1 in PuTTY. mc looks great, but all ncurses-based software (aptitude, htop, bmon etc) does not. Main problem seems that horizontal spacing is "shrunk" whenever there is no text to keep it: This is even more dramatic for menu systems and anything that is column-oriented. Tried dpkg-reconfigure locales to switch system to ISO-8859, but no change, really seems to be an ncurses bug. No such problems with other systems (Raspbian etc.). Is this a known problem? Is there a workaround? Thanks
  6. Hello, I am using OPI one with Armbian_5.90_Ubuntu_bionic_4.19.57, so I fliped my 7" touch screen display vertically (rotated 180) by modifing: /etc/X11/xorg.conf/01-armbian-defaults.conf and it worked, but the touch doesn't correspond with it (still points as it was before rotation). how can i flip the touch information (x,y) coordinates vertically (rotate by 180)? Regards,
  7. Hello,Respected Developers: I'm an Orange Pi user.In the process of using the armbian, I encountered serious problems. My Control Board is Orange Pi PC Plus.Armbian is "ARMBIAN 5.59 stable Ubuntu 18.04.1 LTS 4.14.65-sunxi" I installed jdk and mysql.And run a JAVA program.I set a time zone for Asia-Chongqing,The system language is Chinese,I use three serial ports. When running for a period of time,There will be bugs.About one to three days. The specific phenomena are as follows: 1.Run "date",the time is 1978. 2.Mysql occupy cpu 195%, occupy mem 27%,systemd occupy cpu 34%,Another systemd occupy cpu 14% ,systemd-jo+ occupy cpu 39%. 3.eth0‘s ip disappear,Unable to connect remotely from the network for ssh.I only use serial port to connect. 4.I can't use the reboot command to restart,I input "reboot",It didn't respond. Time automatically changed to 1978. I hope you can help me solve this problem,Thanks very much.
  8. 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.
  9. I'm trying, with no success, to make a 3,5 inch tft lcd screen function with an orange pi zero plus (h5) via SPI. I will love if someone could help me diagnose the reason why I'm failing in doing so. The screen in question is a WaveShare knockoff -> link (the pinout can be found at the bottom of the page.) I'm running Armbian buster 5.92 with the kernel 4.19.63 and all packages upgraded. I also have a working serial connection (using the UART pins located next to Ethernet jack on the board) and am using the 'screen' program to communicate with the device. When connecting the screen and turning on the board the leds on the screen turns on and the display turns a bright white. The display remains this way no matter what I do. My goal is to make the console output to the screen. There is also a 'touch functionality' incorporated, but for me it is secondary. Here is my process so far trying to make the screen work After reading a lot of forum posts for cases similar to mine (but all referring to the zero (h3) board and to a different Armbian/Kernel versions than mine - and also producing different results), I tried to: Activate the 'SPI overlays' needed by editing the /boot/armbianEnv.txt file according to this documentation (I also changed the 'verbosity' parameter to '7' and the 'console' parameter to 'both') overlays=spi-spidev spi-add-cs1 param_spidev_spi_bus=1 param_spidev_spi_cs=1 After rebooting this appear to activate the SPI1 with CS1 as expected $ ls /dev/spi* /dev/spidev1.1 $ sudo dmesg | grep spi [ 2.691646] m25p80 spi0.0: mx25l1606e (2048 Kbytes) [ 4.399025] spidev spi1.1: probing from DT Then I tried to activate and configure the fbtft_device module, that supposedly supports my screen, by creating /etc/modules-load.d/fbtft.conf and adding this two lines: fbtft fbtft_device and also /etc/modprobe.d/fbtft.conf with this configuration options fbtft_device rotate=90 name=piscreen speed=16000000 busnum=1 gpios=reset:2,dc:18 txbuflen=32768 fps=25 Extracted from here After rebooting, again, a new framebuffer device is created $ ls /dev/fb* /dev/fb0 But the screen remains white, with no alteration. In dmesg I can see that SPI1 failed to transfer data and that the fbtft_device is trying to use spi1.0 $ sudo dmesg | grep -i 'fb\|spi' [ 4.391749] spidev spi1.1: probing from DT [ 6.893332] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 6.935810] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 6.953422] m25p80 spi0.0: mx25l1606e spi0.0 40000kHz 8 bits mode=0x00 [ 6.960055] spidev spi1.1: spidev spi1.1 1000kHz 8 bits mode=0x00 [ 6.966595] fbtft_device: GPIOS used by 'piscreen': [ 6.971556] fbtft_device: 'reset' = GPIO2 [ 6.971561] fbtft_device: 'dc' = GPIO18 [ 6.971577] m25p80 spi0.0: mx25l1606e spi0.0 40000kHz 8 bits mode=0x00 [ 6.986087] spidev spi1.1: spidev spi1.1 1000kHz 8 bits mode=0x00 [ 6.986099] spi spi1.0: fb_ili9486 spi1.0 16000kHz 8 bits mode=0x00 [ 7.858552] fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned. [ 9.100443] graphics fb0: fb_ili9486 frame buffer, 480x320, 300 KiB video memory, 32 KiB buffer memory, fps=25, spi1.0 at 16 MHz [ 13.227056] spi_master spi1: spi1.0: timeout transferring 32768 bytes@16000000Hz for 104(100)ms [ 13.227378] fb_ili9486 spi1.0: SPI transfer failed: -110 [ 13.227914] spi_master spi1: failed to transfer one message from queue [ 13.228159] fb_ili9486 spi1.0: fbtft_update_display: write_vmem failed to update display buffer [ 13.341870] spi_master spi1: spi1.0: timeout transferring 2 bytes@16000000Hz for 104(100)ms [ 13.341887] fb_ili9486 spi1.0: SPI transfer failed: -110 [ 13.341907] spi_master spi1: failed to transfer one message from queue [ 13.341917] fb_ili9486 spi1.0: write() failed and returned -110 [ 13.445850] spi_master spi1: spi1.0: timeout transferring 2 bytes@16000000Hz for 104(100)ms [ 13.445864] fb_ili9486 spi1.0: SPI transfer failed: -110 [ 13.445886] spi_master spi1: failed to transfer one message from queue [ 13.445896] fb_ili9486 spi1.0: write() failed and returned -110 [ 13.556038] spi_master spi1: spi1.0: timeout transferring 2 bytes@16000000Hz for 108(100)ms [ 13.556337] fb_ili9486 spi1.0: SPI transfer failed: -110 [ 13.556808] spi_master spi1: failed to transfer one message from queue [ 13.557056] fb_ili9486 spi1.0: write() failed and returned -110 So, according with this fbtft_device documentation I changed /etc/modprobe.d/fbtft.conf to include cs=1 to see if the module would 'use' spi1.1 options fbtft_device rotate=90 name=piscreen speed=16000000 busnum=1 cs=1 gpios=reset:2,dc:18 txbuflen=32768 fps=25 After rebooting, the screen remains white and now dmesg is showing this: $ sudo dmesg | grep -i 'fb\|spi' [ 4.392284] spidev spi1.1: probing from DT [ 6.955069] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 6.997515] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 7.009650] m25p80 spi0.0: mx25l1606e spi0.0 40000kHz 8 bits mode=0x00 [ 7.016383] spidev spi1.1: spidev spi1.1 1000kHz 8 bits mode=0x00 [ 7.016474] spidev spi1.1: Deleting spi1.1 [ 7.027482] fbtft_device: GPIOS used by 'piscreen': [ 7.032449] fbtft_device: 'reset' = GPIO2 [ 7.036490] fbtft_device: 'dc' = GPIO18 [ 7.040409] m25p80 spi0.0: mx25l1606e spi0.0 40000kHz 8 bits mode=0x00 [ 7.047052] spi spi1.1: fb_ili9486 spi1.1 16000kHz 8 bits mode=0x00 [ 7.723075] fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned. [ 8.614341] graphics fb0: fb_ili9486 frame buffer, 480x320, 300 KiB video memory, 32 KiB buffer memory, fps=25, spi1.1 at 16 MHz [ 9.125884] spi_master spi1: spi1.1: timeout transferring 32768 bytes@16000000Hz for 104(100)ms [ 9.136951] fb_ili9486 spi1.1: SPI transfer failed: -110 [ 9.143527] spi_master spi1: failed to transfer one message from queue [ 9.161691] fb_ili9486 spi1.1: fbtft_update_display: write_vmem failed to update display buffer Now it appears that spi1.1 is been deleted and in fact it is not present in /dev/ $ ls /dev/spi* ls: cannot access '/dev/spi*': No such file or directory Now I am stuck. Can someone help me understand and diagnose what is happening?
  10. In the FriendlyARM thread;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 ./ 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 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"?
  11. I have read two old threads in this forum: I have been running this (will post more details if needed) for a few days: VERSION=5.90 DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" NAME="Ubuntu" VERSION="18.04.3 LTS (Bionic Beaver)" Kernel is 4.19.62-sunxi The BPi would hang/freeze, seemingly randomly within a day or two. When it does that, there is no HDMI video or response to ping. After reading the first thread, I did stress test on the BPi for more than 2 days. The BPi actually hold up. So, next I ran "ping -i 30 -D" -- pinging my home gateway every 30 seconds. The BPi has also been up while that is going on. Now its uptime is more than 5 days. I have no problem keeping this going as a workaround -- just thought it may also be of interest to some one.
  12. 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!
  13. Looking for a current realtime RTOS real time deb package or SD card image for the tinkerboard. I have been trying to compile a current real time build. All of my attempts have failed so far. free offer described below
  14. I am very confused. I don't know where the problem is. Have you ever encountered the same problem? Kernel 4.19.80-sunxi Debian Stretch armbian version 5.98 Orange Pi R1 No third-party hardware was added. Pure R1 bare board Start error message: [ OK ] Started LSB: set CPUFreq kernel parameters. [ 8.670214] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 8.681560] pgd = 95d3822c [ 8.684287] [00000000] *pgd=00000000 [ 8.687884] Internal error: Oops: 805 [#1] SMP THUMB2 [ 8.692942] Modules linked in: binfmt_misc 8189es zstd zram lima sun8i_codec_analog snd_soc_simple_card sun8i_adda_pr_regmap snd_soc_simple_card_utils sun4i_i2s gpu_sched ttm snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer sun4i_gpadc_iio snd industrialio soundcore sun8i_ths uio_pdrv_genirq cpufreq_dt uio thermal_sys cfg80211 r8152 usb_f_acm u_serial g_serial libcomposite ip_tables x_tables pwrseq_simple [last unloaded: 8189es] [ 8.730973] CPU: 3 PID: 233 Comm: systemd-journal Not tainted 4.19.79-sunxi #5.98 [ 8.738466] Hardware name: Allwinner sun8i Family [ 8.743191] PC is at rb_erase_cached+0xdc/0x230 [ 8.747744] LR is at rb_erase_cached+0xb5/0x230 [ 8.752296] pc : [<c08f1824>] lr : [<c08f17fd>] psr: 400f00b3 [ 8.758578] sp : cdacbd28 ip : 00000001 fp : cfd71600 [ 8.763820] r10: c0d04d48 r9 : c0d04d48 r8 : c0d04d48 [ 8.769048] r7 : cfd716b4 r6 : 00000000 r5 : 00000000 r4 : cfa1480d [ 8.775587] r3 : cfa1480c r2 : ce5e620c r1 : cfd716b0 r0 : 00000000 [ 8.782131] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment none [ 8.789545] Control: 50c5387d Table: 4daec06a DAC: 00000051 [ 8.795316] Process systemd-journal (pid: 233, stack limit = 0x85b75857) [ 8.802034] Stack: (0xcdacbd28 to 0xcdacc000) [ 8.806419] bd20: 00000001 cfd71680 cd674180 c0d04d48 cfae5500 c0140475 [ 8.814616] bd40: cfdeb538 c01c11a7 00000000 c014172f cd674180 cfd71680 c0d04d48 acfe8204 [ 8.822795] bd60: 0004a000 acfe8204 cdab64e0 acfe8204 00000009 cd674180 cd674100 cfd71680 [ 8.830988] bd80: cfae5500 c0d04d48 c0d04d48 c0d04d48 cfd71600 c0147b41 acfe8204 c0d04d48 [ 8.839187] bda0: ffff0000 cdacbee0 7fff0000 cfae5480 cdacbfb0 cdacbe3c cfd71680 c0901f78 [ 8.847384] bdc0: 00000000 c0d04d48 00000009 cfae5480 00000000 cfd71600 cfae5480 cfd71600 [ 8.855581] bde0: cdacbdf8 acfe8204 c0cb9600 cfd71600 cfae5480 c0cb9600 cdacbe20 c0d04d48 [ 8.863780] be00: c0cb9600 cfae5820 c0901f18 c08f9fc3 00000000 00000000 cfdeb538 acfe8204 [ 8.871978] be20: 00000200 cdab64e0 cdacbdd8 0f0b8000 c08fa607 00000000 cdacbe54 acfe8204 [ 8.880178] be40: 00000000 acfe8204 cdacbe94 ffffe000 00000000 00000000 cdacbe70 c0d04d48 [ 8.888376] be60: 00000000 c0d04d48 cdbfd6ac c08fa607 acfe8204 00000001 00000000 c08fd467 [ 8.896574] be80: cdacbf58 c0276517 be9d9540 00000000 0000001d 00000000 00000019 acfe8204 [ 8.904771] bea0: 01bab150 c02764bd cdbfd680 cdbfd6ac cdacbecc c0d04d48 cdbfd694 c0276029 [ 8.912962] bec0: 00000ae9 00000000 000000fc acfe8204 cdacbecc 00000001 00000000 00000000 [ 8.921148] bee0: be9d9540 cda1ab40 cdbfd680 c08fd487 00000000 00000001 cdbfd694 c02762b7 [ 8.929335] bf00: 00000000 cfb10000 c0d05430 c025699b 00000000 c022c7dd c0d04d48 cdbfd6ac [ 8.937524] bf20: 00000000 00000000 cdbfd694 00000000 ffffe000 00000001 cda1ab40 0000001d [ 8.945712] bf40: 00000003 00000000 00000000 00000000 cdaca000 00000005 0000001d be9d9540 [ 8.953901] bf60: 00000000 acfe8204 00000001 cfae5480 c013b391 cdbfd698 cdbfd698 acfe8204 [ 8.962096] bf80: cdaca000 01bab150 00000001 be9d9540 000000fc c0101224 cdaca000 000000fc [ 8.970286] bfa0: 00000008 c01011f9 01bab150 00000001 00000008 be9d9540 0000001d ffffffff [ 8.978460] bfc0: 01bab150 00000001 be9d9540 000000fc ffffffff ffffffff 0000001d 00000008 [ 8.986630] bfe0: 00000000 be9d9530 00000000 b6d79bf2 000f0030 00000008 00000000 00000000 [ 8.994820] [<c08f1824>] (rb_erase_cached) from [<c0140475>] (set_next_entity+0x61/0x568) [ 9.002994] [<c0140475>] (set_next_entity) from [<c0147b41>] (pick_next_task_fair+0x2b1/0x53c) [ 9.011599] [<c0147b41>] (pick_next_task_fair) from [<c08f9fc3>] (__schedule+0xc3/0x6d8) [ 9.019682] [<c08f9fc3>] (__schedule) from [<c08fa607>] (schedule+0x2f/0x68) [ 9.026727] [<c08fa607>] (schedule) from [<c08fd467>] (schedule_hrtimeout_range_clock+0xf3/0xfc) [ 9.035504] [<c08fd467>] (schedule_hrtimeout_range_clock) from [<c08fd487>] (schedule_hrtimeout_range+0x17/0x1c) [ 9.045671] [<c08fd487>] (schedule_hrtimeout_range) from [<c02762b7>] (do_epoll_wait+0x283/0x37c) [ 9.054538] [<c02762b7>] (do_epoll_wait) from [<c01011f9>] (__sys_trace_return+0x1/0xc) [ 9.062529] Exception stack(0xcdacbfa8 to 0xcdacbff0) [ 9.067577] bfa0: 01bab150 00000001 00000008 be9d9540 0000001d ffffffff [ 9.075747] bfc0: 01bab150 00000001 be9d9540 000000fc ffffffff ffffffff 0000001d 00000008 [ 9.083913] bfe0: 00000000 be9d9530 00000000 b6d79bf2 [ 9.088964] Code: f043 0401 6058 6093 (6004) 681c [ 9.093752] ---[ end trace 64ba3d7f8cd4423e ]--- lsmod: Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 0bda:8152 Realtek Semiconductor Corp. RTL8152 Fast Ethernet Adapter Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@t1000p:~# lsmod Module Size Used by binfmt_misc 16384 1 8189es 864256 0 zstd 16384 4 lima 40960 0 sun4i_i2s 20480 0 gpu_sched 20480 1 lima ttm 57344 1 lima snd_soc_simple_card 16384 0 snd_soc_simple_card_utils 16384 1 snd_soc_simple_card sun8i_codec_analog 24576 0 sun8i_adda_pr_regmap 16384 1 sun8i_codec_analog snd_soc_core 110592 4 sun4i_i2s,sun8i_codec_analog,snd_soc_simple_card_utils,snd_soc_simple_card sun4i_gpadc_iio 16384 0 snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 69632 3 sun4i_i2s,snd_pcm_dmaengine,snd_soc_core snd_timer 24576 1 snd_pcm industrialio 49152 1 sun4i_gpadc_iio snd 45056 3 snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd sun8i_ths 16384 0 zram 24576 2 uio_pdrv_genirq 16384 0 uio 16384 1 uio_pdrv_genirq cpufreq_dt 16384 0 thermal_sys 57344 3 cpufreq_dt,sun8i_ths,sun4i_gpadc_iio cfg80211 393216 1 8189es r8152 49152 0 usb_f_acm 16384 1 u_serial 20480 3 usb_f_acm g_serial 16384 0 libcomposite 40960 2 g_serial,usb_f_acm ip_tables 20480 0 x_tables 20480 1 ip_tables pwrseq_simple 16384 1
  15. 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 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.
  16. I am trying out the latest Armbian Debian Buster release for a Nanopi Neo Air. It is working fine. I've loaded Armbian into the eMMC and I can boot off of it. I have done `apt update && apt upgrade`. Using armbian-config, I have configured Wi-Fi and can SSH in. However, Bluetooth does not work: # systemctl status ap6212-bluetooth.service * ap6212-bluetooth.service - LSB: Patch firmware for ap6212 adapter Loaded: loaded (/etc/init.d/ap6212-bluetooth; generated) Active: failed (Result: exit-code) since Thu 2019-10-24 04:12:56 UTC; 6min ago Docs: man:systemd-sysv-generator(8) Process: 1928 ExecStart=/etc/init.d/ap6212-bluetooth start (code=exited, status=1/FAILURE) Oct 24 04:12:46 nanopiair systemd[1]: Starting LSB: Patch firmware for ap6212 adapter... Oct 24 04:12:56 nanopiair ap6212-bluetooth[1928]: Initialization timed out. Oct 24 04:12:56 nanopiair ap6212-bluetooth[1928]: bcm43xx_init Oct 24 04:12:56 nanopiair ap6212-bluetooth[1928]: Can't get device info: No such device Oct 24 04:12:56 nanopiair systemd[1]: ap6212-bluetooth.service: Control process exited, code=exited, status=1/FAILURE Oct 24 04:12:56 nanopiair systemd[1]: ap6212-bluetooth.service: Failed with result 'exit-code'. Oct 24 04:12:56 nanopiair systemd[1]: Failed to start LSB: Patch firmware for ap6212 adapter. Prior to installing Armbian, using the stock eMMC distribution from Friendlyarm, Bluetooth did work properly. I was able to use `bluetoothctl` to power on the radio and successfully do scans. I do not think it is a hardware issue. Is Bluetooth expected to work out-of-box for this SBC? If not, what needs to be done?
  17. I have an xu4 board with armbian stretch(4.14.141-odroidxu4) and omv installed. I ran a script to transfer system to usb SSD. When i try to reboot the system (from cmd or omv webgui) the system just shuts down and is not started again. What could be the reason for this behaviour.
  18. Hi All, Just wanted to share a good story using armbian. I have used in the past 1-wire probes for temperature, and the process included decompiling, editing and recompiling dtb for my Banana Pi M1, which was not easy at all. Every firmware update deleted by changes and had to redo de recompilation. With latest kernels and armbian version, the process is now extremely easy, just edit: /boot/armbianEnv.txt Adding this lines: overlays=w1-gpio param_w1_pin=PI3 # desired pin(7th pin (GCLK) or number 4 on first column where number 1 is +3V) param_w1_pin_int_pullup=1 # internal pullup-resistor: 1=on, 0=off I just struggled a little bit to find the GPIO code (decompiled dtb and checked possible candidates). Information about temperature is here: cat /sys/bus/w1/devices/XX-YYYYYYY[this is your probe serial, if you have more they will be in /sys/bus/w1/devices/] /w1_slave You have plenty of information here, but don't need to do all they explain, just my edition has been enough:
  19. Hi! New to the forums, this is my first post. I've been trying out some of the pre-built Armbian images on my Orange Pi Zero to get a taste for the OS and it's perfect for my purposes, however I've noticed something odd about the current mainline images that's possibly a small oversight. I browsed the forums before posting and noticed that TV Out functionality has been disabled by default on H3-based boards due to an interference with HDMI output on mainline, which is naturally understandable. There's only one small problem - the same patch has been applied to H2+ boards which lack an HDMI Out altogether. I've explored the image currently provided (the latest Buster/mainline download) and noticed that it too is set to output to HDMI which isn't on the board and isn't supported by the SoC. As such, the board can only operate as headless when those pre-built images are used, which is naturally less than ideal. There *was* a patch available that solved this issue on mainline, however it's rather old, no longer maintained and doesn't work on the latest builds. I'm currently compiling my own image based on the legacy kernel which apparently still supports TV Out by default, but I wanted to ask if it'd be possible for me to adjust the configuration of the current images to simply enable it on what's readily available. I did check /boot/ in search of Script.bin, but the file was not available and armbianEnv.txt doesn't seem to give me the option to change modes, and even if it did, it probably wouldn't change things if the output is disabled altogether. Do you have any advice? I'd very much like to use the latest kernel rather than the legacy one, if possible.
  20. The problem I have an USB endoscope camera that works fine with my Orange Pi lite's normal USB port. However I need both USB port for other devices, so I want to connect this same USB camera, which was orginally marketed as USB otg camera for android phones, using Opi lite's micro usb otg connector. What have I tried - In armbian-config menu, I have enabled usbhost0. I believe this overlay is for the usb otg port, but just to be sure I also enabled usbhost1, usbhost2 and usbhost3. - Using dtc I decompiled sun8i-h3-orangepi-lite.dtb into sun8i-h3-orangepi-lite.dtc. - In this dtc file, I looked up musb, and changed status = "disabled" to "okay", and added dr_mode = "host", like this usb@01c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x6 0x20>; resets = <0x6 0x11>; interrupts = <0x0 0x47 0x4>; interrupt-names = "mc"; phys = <0x18 0x0>; phy-names = "usb"; extcon = <0x18 0x0>; status = "okay"; linux,phandle = <0x47>; phandle = <0x47>; dr_mode = "host" }; - Again with dtc, I compiled the dts to dtb file which replaced the old one (I've made backup). - After reboot, this seemed to have done something root@orangepilite:~$ dmesg |grep musb [ 4.086014] musb-hdrc MUSB HDRC host driver [ 4.086025] musb-hdrc new USB bus registered, assigned bus number 9 [ 4.086290] usb usb9: Manufacturer: Linux 4.14.78-sunxi musb-hcd [ 4.086295] usb usb9: SerialNumber: However, when I connect the camera to the usb otg port, it doesn't work. The LED's on the camera doesn't turn on (so there is probably no power coming from the port, also there are no video devices on /dev/. How do I connect my camera to the micro usb port on Orange pi lite?
  21. My BPi M1 board is working fine, but the old bananalinux is no longer updating. So I downloaded Armbian Bionic mainline image as it is supported. However, after I boot it up, I get no HDMI video signal. I know that the BPi is working as I can see its IP address on my router and ping it. Any suggestions? Try a different image? Build my own? Thank you in advance for helping.
  22. 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.
  23. Hello all, I used using opi one with (Armbian_5.90_Ubuntu_bionic_4.19.57) image. and used the uart0 pins for hardware pwm but the output was around 330mv pwm not 3.3v as i want. my initial thoughts was either the uart0 isn't disabled or there are no pull ups activated, although i tryed using this: Remap pins in FEX: ; Disable debug UART0 [uart_para] uart_debug_port = 0 uart_debug_tx = port:PA04<2><1> uart_debug_rx = port:PA05<2><1> ; Enable PWM0 on PA05 [pwm0_para] pwm_used = 1 pwm_positive = port:PA05<3><0> but there is no FEX but DTB files and i didn't know how to disable uart0 and activate pwm in DTB/DTS files. so how can i get a 3.3v pwm on uart0 (hardware pwm) ?
  24. Hi, I would like to use wiringPi for my NanoPi Neo Air, but after installing wiring P, I only get unable to determine board revision as output from gpio readall. I tried this approaches already: Could someone please explain me how to build wiring P for NanoPi Neo Air so that it is working? On NanoPi Neo Plus 2, I did not have to change anything when installing wiringNP under Armbian.
  25. Hi, I have two OrangePi Lite running side by side. After working fine for about 8 months both started to experience same issue with wireless: The board works randomly for few hours or few days and then looses wireless connection. When this happens reboot does not help as then issue occurs immediately after the boot. Unplugging and replugging power source resolves that for a while and then happens again I suspect it may not be related to a hardware issue or wireless hotspot, as I have at least 3 other clients that continue to work fine. Searching for it on the internet brought this issue with Raspberry Pi: Raspberry uses different wireless chipset either. All that makes me think this may be an issue in the kernel itself Any ideas or thoughts? Workaround also appreciated Thanks