Search the Community

Showing results for tags 'mainline'.

  • 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
    • Reviews, Tutorials, Hardware hacks
    • Help wanted
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker - supported boards and images only
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner A64, H5, H6 and H616
    • Armada A388, A3700
    • Amlogic S905(x), S922X
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Rockchip 3399
    • Other supported boards
  • Development
    • Development
  • TV Boxes's General Chat
  • TV Boxes's Reviews/Tutorials
  • TV Boxes's FAQ
  • TV Boxes's TV Boxes running Armbian
  • TV Boxes's Rockchip CPU Boxes
  • TV Boxes's Amlogic CPU Boxes
  • TV Boxes's Allwinner CPU Boxes
  • Android fanboys's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues
  • Kobol Forum's Helios4
  • Kobol Forum's Helios64

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


Location


Interests

  1. In the FriendlyARM thread http://www.friendlyarm.com/Forum/viewtopic.php?f=53&t=1427&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"?
  2. Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian. It seems to work totally fine, with a few caveats. First: Sample images of it in action -> https://imgur.com/a/vXQEM Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11 Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11 Howto: just put the patch into userpatches for the sunxi-next kernel, and build. it should apply cleanly. Its for H2+/H3. I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards. You then need to edit /boot/armbianEnv.txt add tve to overlays to enable it. the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this. If you want to turn TV out off, just remove tve from the overlays line. My armbianEnv.txt overlays looks like this: overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well: extraargs=drm.debug=0xF Its not needed, unless you really want the debug info. Notes: 1. The default mode is PAL, with 720x576 resolution. Thats outside of normal PAL displayable area, and so the screen overscans. I dont know how to correct this, although its mostly just annoying with terminals. I also don't know how to change the video mode to NTSC. 2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity. Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded. A way to resolve this is use : # apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one. its much easier to read. Look at the help for fbterm to work out everything it can do. 3. I used the program "fim" to display the test images. there are others for doing stuff on the terminal. 4. I haven't tried X. I am not interested in running an X terminal on a TV, but it should probably work fine. Other than that it all seems good. I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy) The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND. i soldered one inside my RCA connector, it fits fine and isn't too difficult. IF you don't do this the image will bloom and look like total crap, so you have been warned. As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it. I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build. If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian. EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver. I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system. Original code is here: https://github.com/Icenowy/linux/tree/tve-v2
  3. From reading through the forums I cobbled together what I thought might work for getting spi nor to boot, but it fails: Activate the spi-jedec-nor overlay in /boot/armbianEnv.txt : overlays=spi-jedec-nor param_spinor_spi_bus=0 Then, after reboot, "cat /proc/mtd" should produce something like this : dev: size erasesize name mtd0: 00200000 00001000 "spi0.0" Here is where it fails - I just get the heading, with no mtd0: 00200000 00001000 "spi0.0". Should I be using a different param_spinor_spi_bus? I assume that once that works, the following will work? apt-get install mtd-utils cat /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/sunxi-spl.bin /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/u-boot.itb > /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/u-boot-sunxi-with-spl.bin flashcp /usr/lib/linux-u-boot-next-orangepizeroplus_5.38_arm64/u-boot-sunxi-with-spl.bin /dev/mtd0
  4. 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.
  5. We have initial support for Pine64/Pine64+ for a long time in our repository but not released any official images yet. Since this will change soon a sneak preview what to expect. Hardware related issues: Please don't blame Armbian for the few design flaws Pine64 and Pine64+ show: These boards use Micro USB for DC-IN which is the worst possible decision. Most USB cables have a resistance way too high and are responsible for severe voltage drops when consumption increases, then the tiny Micro USB contacts have also a pretty high contact resistance and also maximum amperage for this connector is limited to 1.8A by USB specs. So in case you want to do heavy stuff immediately look into linux-sunxi wiki page for Pine64 to get the idea how to use the pins on the so called Euler connector to power the board more reliably. If you think about buying a Pine now consider ordering their PSU too since there cable resistance shouldn't be a problem (should also apply to the Micro USB cables they sell) The only led on this board is a power led that immediately lights when power is provided. Pre-production samples had a green led, on the normal batches this has been replaced with a red led. So there's no way for an OS image to provide user feedback (activate an led when u-boot or kernel boots) and the red light has often been interpreted as 'something is wrong' USB: you find 2 USB type A receptacles on the board but only one is a true USB host port, the other/upper is A64's USB OTG port exposed not as Mini/Micro USB (with ID pin to be able to switch roles) but as a normal type A port. Expect performance to be lower on this port. I've also never been able to do disk benchmarking on the upper port but that might have changed in the meantime (I only have a pre-production developer sample here). Please note also that the maximum amperage available on the USB port is 650mA so connecting bus-powered USB disks might already exceed this so be prepared to use a powered USB hub in between A64 is prone to overheating but unfortunately the Pine64 folks do not sell the board with an effective heatsink by default (compare with ODROID-C1+ or ODROID-C2 for example how it looks like if the vendor cares about heat dissipation). They promised to provide a good heatsink as option but at least I'm not able to find one in their online store. But a heatsink is mandatory if you plan to run this device constantly with high loads, otherwise throttling will occur (when we tested an unrealistic heavy workload without a heatsink -- cpuburn-a53 -- A64 had to throttle down to as less as 600 MHz (for some numbers see IRC log from a while ago) Not a real hardware issue but a problem anyway: the HDMI driver in Allwinner's BSP does not negotiate any display output with a lot of displays that are connected with a HDMI <--> DVI converter or use non-common resolutions. Better do not expect any display output if your display is neither connected directly using HDMI nor capable of 1080p (we can't do anything here since Allwinner's driver uses closed source blobs and no documentation or code with useable license exists) On a couple of Gbit equipped Pine64+ users report that they're not able to negotiate Gbit Ethernet reliably and have to force the connection to Fast Ethernet (since we know that the RTL8211E PHY used on the boards needs an additional ~350 mW when negotiating a Gbit Ethernet connection this might be related to power problems or maybe different PHY batches or something else). Confirmed in the meantime to be a hardware issue. Now combine Micro USB encouraging users to combine this SBC with crappy phone chargers, 'smart' hubs/chargers that do only provide 500mA since Pine64 isn't able to ask for more and crappy USB cables leading to voltage drops (all sorts of power related issues 'by design' due to crappy Micro USB connector) with a missing custom led able to be used to provide user feedback while booting and the inability to use a lot of displays then you might already get what a support nightmare this device is. The only reliable DOA detection method without a serial console is to ensure you have a working SD card (test it before using either F3 or H2testw as outlined in our docs), then check download integrity of the Armbian image (again see the documentation), then ensure you burn the image correctly to SD card (see docs), insert SD card, power on the board and wait 20 seconds. If then the leds on the Ethernet jack start to flash randomly at least the kernel boots and after waiting an additional 2 minutes you'll be able to login with SSH or serial console (for the latter better choose the EXP header over the Euler connector -- reason here) Anyway: In case you run in booting or stability problems with Armbian on Pine64/Pine64+ be assured that it's not an Armbian issue. You run into any of the problems above therefore please try to resolve them on your own and send your complaints to Pine64 forum and not ours: http://forum.pine64.org/forumdisplay.php?fid=21 (really, we don't do hardware and these issues are all related to hardware design decisions) Expectations: The Pine64 folks did a great job raising expectations to the maximum. They advertised this board as 'first $15 64-Bit Single Board Super Computer', promised an average consumption of just 2.5W, the SoC remaining at 32°C and a few other weird things while they already knew that reality differs a lot (the journey started here last Dec). Pine64 is not a 'Super Computer' but most probably the slowest 64-bit ARM board around due to A64 being limited regarding maximum cpufreq and overheating issues (40nm process being responsible for) and lack of fast IO interconnections (only one real USB 2.0 host port present, no eMMC option possible, no SD card implementation using the faster modes). If you then combine the high expectations with a rather clueless kickstarter crowd (many of them not even getting that they did not buy products but backed a project) and the hardware flaws it's pretty obvious why their forums are full of complaints and why they receive so much boards as being DOA that work flawlessly in reality. So why bringing Armbian to Pine64? Since for some (headless) use cases these boards are really nice and also cheap, A64 support is progressing nicely thanks to our awesome linux-sunxi community and also a few more A64 devices will be available soon. What do you get with Armbian on Pine64? User experience will not be much different compared to longsleep's minimal Ubuntu image. If you prefer Debian then at least you can be assured that our images do not contain bad settings and silly bugs like the one's from official Pine64 downloads section (since they fiddle around manually with their OS images for example all Pine boards running these have the same MAC address by default which will cause network troubles if you've more than one board in the same collision domain). We use the same thermal/throttling settings like OS images based on longsleep's kernel (since we helped developing them back in March), we use the same BSP kernel (patched by Zador up to the most recent version back in May) and share a few more similarities since our modifications were sent back to longsleep so all OS images for Pine64 might be able to benefit from. Differences: You don't need to execute longsleep's various platform scripts since kernel and u-boot updates are done using the usual apt-get upgrade mechanism in Armbian. You also don't need (and should not use) scripts like pine64_tune_network.sh since they decrease network performance with Armbian (stay with our defaults unless you're an expert). And a few more tweaks might result in better performance and at least by using Armbian you have the usual Armbian experience with some additional tools at the usual location, automatic fs resize on first boot and so on. We already provide a vanilla image currently based on kernel 4.7 but that's stuff for developers only, see below. Performance with legacy Armbian image: 'Out of the box' CPU performance with A64 is not that great unless you are able to benefit from the new CPU features: A64 uses Cortex-A53 CPU cores that feature 64-bit capabilities (which are not that interesting since A64 devices are limited to 2 GB DRAM anyway at the moment) but more interestingly ARMv8 instruction set can be used which might increase performance a lot when software will be compiled for this platform. Best example: the commonly mis-used sysbench cpu test: When running an ARMv6 'optimized' sysbench binary on an ARMv8 CPU then performance will be 15 times slower than necessary (applies to the RPi 3 or the upcoming Banana Pi M64 when used with their OS images) But as soon as ARMv8 optimized code is used A64 can really shine in some areas. I used the default sysbench contained in Ubuntu Xenial's arm64 version, tried it with 20000 settings and got less than 8 seconds execution time (an RPi 3 running Raspbian has the faster CPU cores but here it will take 120 seconds -- just due to different compiler switches!). Then I tried whether I can optimize performance building sysbench from source using export AM_CFLAGS="-march=armv8-a -mtune=cortex-a53" and got 11 seconds execution time, so optimized code led to a huge performance loss? Not really, I checked out sysbench version 0.5 by accident and there for whatever reasons execution with ARMv8 optimization or in general takes longer (great! benchmark version influences execution time, so one more reason to never trust in sysbench numbers found on the net!). Using the '0.4' branch at version 0.4.12 I got an execution time of less than 7.5 seconds which is a 10 percent increase in performance for free just by using appropriate compiler flags: Another great example how using CPU features or not (NEON in this case) influences performance and 'benchmarking gone wrong' numbers are Linpack's MFLOPS scores. By choosing the package your distro provides instead of using one that makes use of your CPU's features you loose at lot of performance, ruin every performance per watt ratios and behave somewhat strange Someone sent me Linpack MFLOPS numbers generated with Debian Jessie which is known for horribly conserative compiler settings when building packages -- if you switch your distro from Jessie to Ubuntu Xenial for example you get a 30 percent improvement in sysbench numbers, yeah that's the 'benchmark' we already laughed at above. With Jessie's/Raspbian's hpcc package, Pine64+ gets a score of 1625 MFLOPS and RPi 3 just 1035. So is Pine64 1.6 times faster than RPi 3? Nope, that's just 'benchmarking gone wrong' since these numbers are the result of a joke: Using tools for 'High performance computing' with standard settings (no one interested in HPC would ever do that). By using the correct Linpack version that makes use of NEON optimizations on both CPUs we end up with 3400 MFLOPS (Pine64 at 1.3 GHz) vs 3600 MFLOPS (RPi 3 at 1.2 GHz). So if we're talking about this use case (HPC -- high performance computing) RPi 3 easily outperforms A64 (please keep in mind that the 3400 MFLOPS I got are the result of overclocking/overvolting at 1296 MHz, Pine64 is limited to 1152 MHz by default so we're talking about 3000 MFLOPS for A64 vs. 3600 MFLOPS for RPi 3's SoC. So it's not Pine64 being 1.6 times faster but RPi 3 being more suited for Linpack numbers and this type of benchmarks only shows how wrong it is to use distro packages that are built using conservative settings (which is a must if the distro wants to support a wide range of different SoCs!) Anyway: I's obvious that in case you want to use Pine64 for number crunching or performance stuff in general evaluating whether compiling packages from source might improve performance is a great idea (at least it's obvious that from a performance point of view using an ARMv6 distro with ARMv8 SoCs is stupid -- reality with Raspbian running on RPi 3 and BPi M64). ARMv8 also provides crypto extensions that might be used with OpenSSL for example. Didn't look into it yet but maybe huge performance gains when using a Pine64 as HTTPS enabled web server or VPN endpoint are possible just like we've already seen with sysbench. Network performance: Pine64+ combines the SoC internal GbE MAC implementation (the same as in H3 and A83T SoCs from Allwinner) with an external RTL8211E PHY as used on most GbE capable SBC. Default iperf performance with Armbian/Xenial: +900 MBits/sec in both directions (920/940 MHz) so no need for further tuning (please read through this explanation here why blindly trusting in iperf numbers is always stupid and why it's neither necessary nor useful to further tune network settings to get better iperf numbers). Please keep in mind that for yet unknown reasons a couple of Pine64+ are reported to not reliably work at Gbit Ethernet speeds. Please also keep in mind how settings might matter. If you run a standard iperf test in 'passive benchmarking' mode you might get throughput numbers 200-250 Mbits/sec lower than ours maybe just due to a wrong cpufreq governor. Ethernet throughput scales linearly with CPU clockspeed with most cheap ARM SoCs (our only known exception from this is Solid-Run's Clearfog which uses a SoC optimized for IO and network throughput) so by using the ondemand governor with wrong/default settings for example you ensure that an idle SBC will only slowly increase clockspeed when you start your iperf test. This is Armbian switching from interactive to ondemand governor now being below 700 Mbits/sec just due to adjusting CPU clockspeed too slow: The other stuff normally 'benchmarked' is not worth mentioning/testing it so just as quick notes: A64 is showing the same SDIO limitation as most other SoCs limiting sequential transer speeds to/from SD card to ~23MB/s (do the math yourself: SDIO with 4 bit @ 50 MHz minus some overhead is 23 MB/s) -- fortunately that's rather uninteresting since random IO matters on SBCs and there it's your choice to choose between crappy cards that horribly suck or follow our recommendations and choose a really fast card. But Pine64 can not use the faster eMMC interface so if you really need high IO bandwidth and high IOPS better choose a different device USB is USB 2.0 so expect ~35MB/s with BSP kernel and ~40MB/s with mainline kernel and UASP capable disk enclosures for individual USB connections (UASP + mainline kernel might show high random IO numbers if used together with an SSD!) HW accelerated video decoding is already possible (see here for the codec matrix) and situation with HW accelerated video encoding looks promising too: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/ In case one is interested in performance testing on SBCs monitoring what's happening is mandatory. Currently our armbianmonitor tool does not install the necessary templates on A64 so still my script to install this stuff on A64 should be used: http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-a64.sh (read the script's header how to install) Performance with vanilla Armbian image: Not interesting at all at the time of this writing since while Pine64 happily boots mainline u-boot/kernel it's way too early to do tests in this area. Currently there's no access to the AXP803 PMIC from mainline kernel so not even VDD_CPUX voltage regulation works and as a result cpufreq scaling is also not working and the SoC is clocked pretty conservative. Since most performance relevant stuff running on cheap ARM SoCs depends on (switching as fast as possible to) high CPU clockspeeds benchmarking is absolutely useless now. You should also keep in mind that many core features still not work with mainline kernel so this is really stuff for developers (who normally prefer their own way to boot their freshly compiled kernels). So please don't expect that much from vanilla images for A64 boards now, better choose the legacy variant. The future? A few more A64 boards are announced or already available as dev samples, for example the aforementioned BPi M64 (possible advantages over Pine64: sane DC-IN, real USB OTG, more USB host ports behind an internal USB hub, eMMC available and custom leds being able to provide user feedback, everything else is more or less the same as the 2 GB Pine64+) or Olimex working on both an SBC and an A64 based Laptop. And then Xunlong announced 2 new SBC based on Allwinner's H5. H5 (product brief) seems to be A64's bigger sibling providing video/GPU enhancements, 3 true USB host ports in addition to one USB OTG (just like H3 where we can use all 4 USB ports that do not have to share bandwidth), integrating a Fast Ethernet PHY (just like H3) but lacks PMIC support (again just like H3, so no mobile useage, no battery support out of the box and it gets interesting how VDD_CPUX voltage regulation will work there -- maybe 'just like H3' again). Since A64 shares many/most IP blocks with H3 and A83T from Allwinner I still hope that H5 will be just a mixture of A64 and H3 and we will get full support based on what we now have for these 2 other SoCs pretty fast. But that's 100 percent speculation at this moment Update regarding longsleep's pine64_tune_network.sh script. Benchmark results don't get automatically worse when applying the tweaks from his script but the result variation gets huge (730 - 950 Mbits/sec, exceeding 940 Mbits/sec is already an indication that buffers are invoked): So better enjoy defaults unless you really know what you do since network performance tuning works in different directions. Stuff that might increase throughput might negatively affect latency and vice versa. So if you start to tune, tune for your specific use case!
  6. 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.
  7. I am using a orangepi win plus. I have attached a ssd1306 OLED display to the board, using i2c1 interface, using the luma.oled library as driver. import sys from PIL import Image from PIL import ImageDraw from PIL import ImageFont import subprocess from luma.core.interface.serial import i2c from luma.core.render import canvas from luma.oled.device import ssd1306, ssd1325, ssd1331, sh1106 from time import sleep serial = i2c(port=1, address=0x3C) device = ssd1306(serial, rotate=0) width=device.width height=device.height image = Image.new('1', (device.width, device.height)) # Get drawing object to draw on image. draw = ImageDraw.Draw(image) # Draw a black filled box to clear the image. draw.rectangle((0,0,device.width,device.height), outline=0, fill=0) padding = 2 top = padding bottom = device.height-padding # Move left to right keeping track of the current x position for drawing shapes. x = 0 while True: # Draw a black filled box to clear the image. draw.rectangle((0,0,width,height), outline=0, fill=0) # Shell scripts for system monitoring from here : https://unix.stackexchange.com/questions/119126/command-to-displa$ cmd = "hostname -I | cut -d\' \' -f1" IP = subprocess.check_output(cmd, shell = True ) cmd = "top -bn1 | grep load | awk '{printf \"CPU Load: %.2f\", $(NF-2)}'" CPU = subprocess.check_output(cmd, shell = True ) cmd = "free -m | awk 'NR==2{printf \"Mem: %s/%sMB %.2f%%\", $3,$2,$3*100/$2 }'" MemUsage = subprocess.check_output(cmd, shell = True ) cmd = "df -h | awk '$NF==\"/\"{printf \"Disk: %d/%dGB %s\", $3,$2,$5}'" Disk = subprocess.check_output(cmd, shell = True ) # Write two lines of text. draw.text((x, top),"IP:"+str(IP,encoding = "utf-8"), font=font, fill=255) draw.text((x, top+8),str(CPU,encoding = "utf-8"), font=font, fill=255) draw.text((x, top+16),str(MemUsage,encoding = "utf-8"), font=font, fill=255) draw.text((x, top+25),str(Disk,encoding = "utf-8"), font=font, fill=255) device.display(image) sleep(0.5) At the kernel version 5.3.9, the display worked perfectly, without any problem. But after updating the kernel version to above 5.4.20, the same code don't work at all. Traceback (most recent call last): File "./test_oled.py", line 12, in <module> device = ssd1306(serial, rotate=0) File "/usr/local/lib/python3.6/dist-packages/luma/oled/device/__init__.py", line 188, in __init__ self.clear() File "/usr/local/lib/python3.6/dist-packages/luma/core/mixin.py", line 46, in clear self.display(Image.new(self.mode, self.size)) File "/usr/local/lib/python3.6/dist-packages/luma/oled/device/__init__.py", line 220, in display self.data(list(buf)) File "/usr/local/lib/python3.6/dist-packages/luma/core/device.py", line 46, in data self._serial_interface.data(data) File "/usr/local/lib/python3.6/dist-packages/luma/core/interface/serial.py", line 119, in data write(list(data[i:i + block_size])) File "/usr/local/lib/python3.6/dist-packages/luma/core/interface/serial.py", line 128, in _write_large_block self._bus.i2c_rdwr(self._i2c_msg_write(self._addr, [self._data_mode] + data)) File "/usr/local/lib/python3.6/dist-packages/smbus2/smbus2.py", line 637, in i2c_rdwr ioctl(self.fd, I2C_RDWR, ioctl_data) TimeoutError: [Errno 110] Connection timed out Because the luma.oled library just uses the linux kernel i2c interface like the /dev/i2c-1, so it is more likely a bug related to kernel.
  8. Hi! Now that the camera interface has been merged in mainline Kernel, I would like to try to use the OrangePi OV5640 camera module on my OrangePi One. So with the latest Armbian Bionic (20.02.1, kernel 5.4.20), I have been trying to get a device tree overlay. But for now, it fails to compile with: $ sudo armbian-add-overlay sun8i-h3-csi.dts Compiling the overlay Error: sun8i-h3-csi.dts:27.23-24 syntax error FATAL ERROR: Unable to parse input tree Error compiling the overlay My current overlay looks like this: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <&reg_aldo1>; DOVDD-supply = <&reg_dldo3>; DVDD-supply = <&reg_eldo3>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; fragment@2 { target = <&csi>; __overlay__ { status = "okay"; port { csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;` Also, according to the documentation, the regulator fields are required but this board does not have much regulators (like AXP209), so I have no idea what to write here. But this is my first time writing a device-tree overlay so I am not sure what is wrong with this line. Could someone guide me to get my overlay right? And, does anyone already got the CSI interface working with OV5460 sensor on a H3 based board? Thank you.
  9. Hello all I want to control some GPIO pins on my NanoPi Neo (H3) board and installed WiringNP. Executing commands results in the error piBoardRev: Unable to determine board revision from /proc/cpuinfo I've traced the source of the error down to this line, where WiringNP tries to open /sys/class/sunxi_info/sys_info to determine which board it is running on. This path is not present in my Armbian os. I'm using 4.11.12-sun8i #20 SMP armv7l armv7l armv7l GNU/Linux Am I missing something here? Or are there alternatives to using WiringNP?
  10. Hey guys, I've spent the last couple of weeks trying to get a TFT display with touch screen to work on my Orange Pi PC board, and I've decided to share my step-by-step solution here. This tutorial is heavily based on Guide: How to use Touchscreen + LCD on H3 devices by Kutysam, but I had to do some extra steps for it to work properly. This tutorial is only for Mainline kernel, I was able to get the graphical screen working with Kutysam's guide for Legacy, but couldn't make the touch work. First of all this is the display I'm using: LCD module Pi TFT 3.5 inch (320*480) Touchscreen Display Module TFT for Raspberry Pi 3. I believe it is a clone of this Waveshare screen. Also, I am using the image Armbian_5.38_Orangepipc_Debian_stretch_next_4.14.14_desktop, but it should work for the headless version (server) too, if you install a display manager, desktop environment and the X server. All the commands below are assumed to be run as root user. If you're not root, add "sudo" to the beginning of each command. --- Preparation First of all make sure you have the latest package updates by running apt-get update && apt-get upgrade This might take a while. If the packages have been installed successfully, reboot. On a fresh install I was getting the following error message: If that happens to you, just run the command again and it should download everything properly. If it still isn't working you could try cleaning the apt cache. After that, install these Make prerequisites: apt-get install build-essentials For some reason the linux-headers package for sunxi is not included in the repository, this thread might explain it better than me. Either way, download and install the package with dpkg: wget http://apt.armbian.com/pool/main/l/linux-4.14.18-sunxi/linux-headers-next-sunxi_5.41_armhf.deb dpkg -i linux-headers-next-sunxi_5.41_armhf.deb Now we need to edit armbianEnv.txt to enable the overlays for spi and cs1 nano /boot/armbianEnv.txt Add the following lines to the end of the file (Be careful with spaces in the end of the lines... I lost a couple of days trying to figure out what the problem was when I had an extra space after "param_spidev_spi_bus=0" ) overlays=spi-spidev spi-add-cs1 param_spidev_spi_bus=0 param_spidev_spi_cs=1 And reboot. Screen Now we need to configure fbtft and fbtft_device on boot. Note: I had to put "98" in the start of the filename, or else I'd get the following error: "fbtft_device: spi_busnum_to_master(0) returned NULL" in dmesg after I installed the touchscreen. I believe it has something to do with the load order, so if you're having problems with this file you could try changing the prefix to 99 or removing it. nano /etc/modules-load.d/98-fbtft.conf Insert the following on the file: fbtft fbtft_device Now we have to load fbtft_device options on boot. Open the file with: nano /etc/modprobe.d/fbtft.conf Add the following: options fbtft_device rotate=90 name=piscreen speed=16000000 gpios=reset:2,dc:71 txbuflen=32768 fps=25 And reboot. At this point your screen should at least turn black. For me, the GUI wouldn't load unless I typed 'startx' on the console. So this is how I fixed it to always display the GUI on boot: apt-get install xserver-xorg-video-fbdev nano /usr/share/X11/xorg.conf.d/99-fbdev.conf Insert this in the file: Section "Device" Identifier "piscreen" Driver "fbdev" Option "fbdev" "/dev/fb0" EndSection At this point the screen should be displaying the Armbian GUI, with mouse and keyboard working, but without touch screen. Let's fix that. Touch First we need to download and compile the ads7846 driver (apparently it is compatible with xpt2046). mkdir ds7846 cd ds7846 wget https://sourceforge.net/p/openipmi/linux-ipmi/ci/master/tree/drivers/input/touchscreen/ads7846.c?format=raw mv ads7846.c?format=raw ads7846.c nano Makefile Insert the following on the makefile: obj-m := ads7846.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean install: $(MAKE) -C $(KDIR) M=$(PWD) modules_install Now let's compile and load the module into the kernel: make make install depmod Now we'll build and install the ads7846_device module from fbtft_tools: cd .. git clone https://github.com/notro/fbtft_tools/ cd fbtft_tools/ads7846_device make make install depmod Let's load ads7846 and ads7846_device on boot sudo nano /etc/modules-load.d/99-ads7846.conf After that let's load the options for ads7846_device. These configs worked best for me, but you can play with them and tweak if needed. nano /etc/modprobe.d/ads7846_device.conf Insert the following: options ads7846_device model=7846 cs=1 gpio_pendown=1 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900 Reboot, and the touch should be working! Well, for me not entirely. The Y axis seemed to be reversed, so here are the steps I took to configure it: First of all, we need xinput to configure the touch screen options. Install it with this command: apt-get install xinput Now we need to set the "swap_xy" option to 0 in ads7846_device configuration file. Open it with: nano /etc/modprobe.d/ads7846_device.conf Replace its contents with this: options ads7846_device model=7846 cs=0 gpio_pendown=1 keep_vref_on=1 swap_xy=0 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900 Reboot to apply the changes. Now we need to find out the touchscreen name on xinput. Run this command: DISPLAY=:0.0 xinput list You should get a list of pointer devices, and the touchscreen should be on it. In my case the name is 'ADS7846 Touchscreen'. At this point you might get an "unable to connect to X server error". If that's the case, you can add the required X permissions for your user with the command (taken from this ask ubuntu answer): export XAUTHORITY=$(eval echo ~`who | grep tty7 | sed 's/\([a-z]*\).*/\1/'`)/.Xauthority And "xinput list" should be working. Now we can try to configure it with xinput's "set-prop" parameter: DISPLAY=:0.0 xinput --set-prop 'ADS7846 Touchscreen' 'Coordinate Transformation Matrix' 0 -1 1 1 0 0 0 0 1 Test your display to see if it works. This matrix worked best for me, but you might need to tweak it. Refer to this guide for more info on how coordinate transformation matrices work. Now you need to run this command every time the session starts. To automate it, I added the command to the .xsessionrc file: nano /home/{your username}/.xsessionrc Append the xinput set-prop command: DISPLAY=:0.0 xinput --set-prop 'ADS7846 Touchscreen' 'Coordinate Transformation Matrix' 0 -1 1 1 0 0 0 0 1 If you have multiple users logging in the session displayed on your screen, you might need to add this file for every user. ".xsessionrc" was the only file where I could get this working. And that's it! Your display + touch screen should be working properly now! I am still very newbie with Armbian and single board computers, and there is much I don't understand yet, so if you have any questions, comments or suggestions on this guide please post them below. See you all.
  11. I am changing the file/folder permission using chown but is it not permanent chown proxy:proxy a.log ls -l total 0 -rw-r--r-- 1 proxy proxy 0 Apr 10 07:30 a.log Now after some time that include reboot ls -l total 0 -rw-r--r-- 1 root root 0 Apr 10 07:30 a.log I am using armbian on orange pi zero plus uname -r 5.4.14-sunxi64
  12. 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.
  13. as described in: https://gitlab.freedesktop.org/mesa/mesa/issues/2377 it's possible to use meson HW video codec now, but in the URL, not very clear, does any one know how to use it?
  14. Today I swapped my old Neo2 against a Neo2 LTS 1GB in my NAS case - so I had a old Neo2 512MB free for the black Aluminum-OLED-case which I got in a drawer. Now I did try to activate the OLED in ARMBIAN 5.67 user-built Debian GNU/Linux 9 (stretch) 4.19.4-sunxi64 Linux npi-neo2-27 4.19.4-sunxi64 #6 SMP Fri Nov 30 14:02:43 +03 2018 aarch64 GNU/Linux First (like on a i2c-clock" I activated i2c0 in armbian-config: root@npi-neo2-27(192.168.6.27):~# armbian-config System --> Hardware --> [*] i2c0 After the reboot I checked for the i2c-OLED-device and got: root@npi-neo2-27(192.168.6.27):~# apt install i2c-tools root@npi-neo2-27(192.168.6.27):~# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- After some trial and error(-messages) I did found the following dependencies for compiling/installing the software for the OLED-Board: apt-get install python-setuptools libjpeg-dev After that I did the normal "5 Enable NanoHat-OLED manually" from http://wiki.friendlyarm.com/wiki/index.php/NanoHat_OLED with root@npi-neo2-27(192.168.6.27):~# cd /home/guido root@npi-neo2-27(192.168.6.27):~# git clone https://github.com/friendlyarm/NanoHatOLED.git root@npi-neo2-27(192.168.6.27):~# cd NanoHatOLED root@npi-neo2-27(192.168.6.27):~# ./install.sh And after the next reboot the OLED-Display did work
  15. Hi Team I have two brand new Orange PI Zero LTS. Is this supported with the normal Zero download? Thanks
  16. K-worker takes 10-20 % of one cpu core with later kernels. Does the 4.17 kernel still have this problem? Or is bionic a solution?
  17. 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,
  18. Hi, I am trying to interface I/O expander MCP23017 to Nano Pi Neo2(Hardware specs:1 GB RAM, Gigabit Ethernet . Software specs: Debian Buster with Armbian Linux 4.19.59-sunxi64 ) . The issue I am having is I am not able to see the device when I run sudo i2cdetect -y 0 . I have enabled i2c overlays in /boot/armbian.txt . I am using 10 K Ohm pull-ups on SDA and SCK . I get no activity while running i2cdetect on the oscilloscope on SCK and SDA lines . Is this an issue with the kernel ?
  19. Hello guys. After a long time unsuccesfully trying to use a NanoPi Neo to record I2S data, I wonder if is there some NanoPi board that is capable of such thing. Can you suggest one? Thank you very much!
  20. Edit: Please see my second post in this thread. I think I've identified exactly what my problem is, please see my second post in the thread. I need to change the display mode to something that my own TV is able to display. But no matter what I've tried, I haven't been able to change the display mode. How do you do it? ---- Hello, I just got an Orange Pi PC. I installed using the Armbian_5.32.170629_Orangepipc_Ubuntu_xenial_dev_4.11.7.7z image. I'm able to log in through SSH, and I've installed all updates (apt-get update && apt-get upgrade) I have the Orange Pi PC connected to my HDMI television. The screen appears blank, nothing appears on it at any time. I tried experimenting with the disp_mode option in armbian-config -> System -> Bootenv. I tried "disp_mode=1280x720p60" and "disp_mode=640x480p60", neither have worked. The default didn't work either. edit: The screen is still blank. Since I posted, I've also tried putting these setenv video-mode sunxi:1280x720-24@60,monitor=dvi,hpd=1,edid=1 disp.screen0_output_mode=1280x720p60 in /boot/armbianEnv.txt, and then running "sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr" and rebooting a few times. I also put 'saveenv' at the end of /boot/boot.cmd. None of this seems to have changed anything. What would you suggest I try doing next? ------- beyond this line, information taken from my Orange PI PC: ------- Kernel version: Linux orangepipc 4.11.12-sun8i #16 SMP Tue Nov 7 00:24:13 CET 2017 armv7l armv7l armv7l GNU/Linux dmesg: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.11.12-sun8i (root@armbian) (gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08) ) #16 SMP Tue Nov 7 00:24:13 CET 2017 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=50c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Xunlong Orange Pi PC [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x7cc00000 [ 0.000000] On node 0 totalpages: 253952 [ 0.000000] free_area_init_node: node 0, pgdat c0b5fd80, node_mem_map ef740000 [ 0.000000] Normal zone: 1728 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 57344 pages, LIFO batch:15 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: Using PSCI v0.1 Function IDs from DT [ 0.000000] percpu: Embedded 16 pages/cpu @ef6ec000 s34572 r8192 d22772 u65536 [ 0.000000] pcpu-alloc: s34572 r8192 d22772 u65536 alloc=16*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 252224 [ 0.000000] Kernel command line: root=UUID=37031002-c65e-4113-b451-f4b61a52ca54 rootwait rootfstype=ext4 console=tty1 console=ttyS0,115200 hdmi.audio=EDID:0 disp.screen0_output_mode=640x480p60 panic=10 consoleblank=0 loglevel=1 ubootpart=5fabfc8f-01 ubootsource=mmc sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] allocated 1015808 bytes of page_ext [ 0.000000] Memory: 971892K/1015808K available (6144K kernel code, 386K rwdata, 2392K rodata, 1024K init, 328K bss, 27532K reserved, 16384K cma-reserved, 212980K highmem) [ 0.000000] Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf800000 - 0xbfe00000 ( 6 MB) .text : 0xc0008000 - 0xc0700000 (7136 kB) .init : 0xc0a00000 - 0xc0b00000 (1024 kB) .data : 0xc0b00000 - 0xc0b60980 ( 387 kB) .bss : 0xc0b62000 - 0xc0bb40b0 ( 329 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.000000] arm_arch_timer: Architected cp15 timer(s) running at 24.00MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [ 0.000005] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [ 0.000013] Switching to timer-based delay loop, resolution 41ns [ 0.000176] Console: colour dummy device 80x30 [ 0.000188] console [tty1] enabled [ 0.000209] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000) [ 0.000219] pid_max: default: 32768 minimum: 301 [ 0.000387] Security Framework initialized [ 0.000397] AppArmor: AppArmor disabled by boot time parameter [ 0.000442] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000449] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.001095] CPU: Testing write buffer coherency: ok [ 0.001476] CPU0: update cpu_capacity 1024 [ 0.001483] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.001799] Setting up static identity map for 0x40100000 - 0x4010004c [ 0.002497] smp: Bringing up secondary CPUs ... [ 0.013099] CPU1: update cpu_capacity 1024 [ 0.013104] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.023742] CPU2: update cpu_capacity 1024 [ 0.023747] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.034355] CPU3: update cpu_capacity 1024 [ 0.034361] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.034424] smp: Brought up 1 node, 4 CPUs [ 0.034431] SMP: Total of 4 processors activated (192.00 BogoMIPS). [ 0.034434] CPU: All CPU(s) started in HYP mode. [ 0.034436] CPU: Virtualization extensions available. [ 0.035297] devtmpfs: initialized [ 0.041046] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5 [ 0.041277] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.041292] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 0.042083] xor: measuring software checksum speed [ 0.134194] arm4regs : 1261.600 MB/sec [ 0.234238] 8regs : 750.000 MB/sec [ 0.334290] 32regs : 768.000 MB/sec [ 0.434336] neon : 1282.400 MB/sec [ 0.434340] xor: using function: neon (1282.400 MB/sec) [ 0.434429] pinctrl core: initialized pinctrl subsystem [ 0.435275] NET: Registered protocol family 16 [ 0.437588] DMA: preallocated 2048 KiB pool for atomic coherent allocations [ 0.438792] cpuidle: using governor ladder [ 0.438918] cpuidle: using governor menu [ 0.439619] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. [ 0.439623] hw-breakpoint: maximum watchpoint size is 8 bytes. [ 0.624562] raid6: int32x1 gen() 189 MB/s [ 0.794585] raid6: int32x1 xor() 160 MB/s [ 0.964699] raid6: int32x2 gen() 255 MB/s [ 1.134879] raid6: int32x2 xor() 198 MB/s [ 1.304999] raid6: int32x4 gen() 258 MB/s [ 1.475036] raid6: int32x4 xor() 193 MB/s [ 1.645149] raid6: int32x8 gen() 247 MB/s [ 1.815145] raid6: int32x8 xor() 172 MB/s [ 1.985255] raid6: neonx1 gen() 494 MB/s [ 2.155299] raid6: neonx1 xor() 366 MB/s [ 2.325413] raid6: neonx2 gen() 663 MB/s [ 2.495416] raid6: neonx2 xor() 478 MB/s [ 2.665552] raid6: neonx4 gen() 796 MB/s [ 2.835623] raid6: neonx4 xor() 533 MB/s [ 3.005714] raid6: neonx8 gen() 703 MB/s [ 3.175760] raid6: neonx8 xor() 485 MB/s [ 3.175765] raid6: using algorithm neonx4 gen() 796 MB/s [ 3.175768] raid6: .... xor() 533 MB/s, rmw enabled [ 3.175771] raid6: using intx1 recovery algorithm [ 3.175984] reg-fixed-voltage usb0-vbus: could not find pctldev for node /soc/pinctrl@01f02c00/usb0_vbus_pin@0, deferring probe [ 3.177092] SCSI subsystem initialized [ 3.177252] libata version 3.00 loaded. [ 3.177484] usbcore: registered new interface driver usbfs [ 3.177538] usbcore: registered new interface driver hub [ 3.177614] usbcore: registered new device driver usb [ 3.177796] media: Linux media interface: v0.10 [ 3.177837] Linux video capture interface: v2.00 [ 3.177898] pps_core: LinuxPPS API ver. 1 registered [ 3.177902] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 3.177917] PTP clock support registered [ 3.178254] Advanced Linux Sound Architecture Driver Initialized. [ 3.179377] clocksource: Switched to clocksource arch_sys_counter [ 3.179523] VFS: Disk quotas dquot_6.6.0 [ 3.179578] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 3.180187] simple-framebuffer 7e000000.framebuffer: framebuffer at 0x7e000000, 0x3f4800 bytes, mapped to 0xf0a80000 [ 3.180196] simple-framebuffer 7e000000.framebuffer: format=x8r8g8b8, mode=1920x540x32, linelength=7680 [ 3.199053] Console: switching to colour frame buffer device 240x33 [ 3.217288] simple-framebuffer 7e000000.framebuffer: fb0: simplefb registered! [ 3.225112] NET: Registered protocol family 2 [ 3.225634] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [ 3.225720] TCP bind hash table entries: 8192 (order: 4, 65536 bytes) [ 3.225831] TCP: Hash tables configured (established 8192 bind 8192) [ 3.225919] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 3.225973] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 3.226178] NET: Registered protocol family 1 [ 3.226566] RPC: Registered named UNIX socket transport module. [ 3.226570] RPC: Registered udp transport module. [ 3.226573] RPC: Registered tcp transport module. [ 3.226576] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 3.226814] Trying to unpack rootfs image as initramfs... [ 3.520024] Freeing initrd memory: 5012K [ 3.521968] audit: initializing netlink subsys (disabled) [ 3.522100] audit: type=2000 audit(3.510:1): state=initialized audit_enabled=0 res=1 [ 3.522271] Initialise system trusted keyrings [ 3.522392] workingset: timestamp_bits=14 max_order=18 bucket_order=4 [ 3.529716] zbud: loaded [ 3.532770] NFS: Registering the id_resolver key type [ 3.532797] Key type id_resolver registered [ 3.532800] Key type id_legacy registered [ 3.532811] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 3.532814] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 3.533811] JFS: nTxBlock = 7760, nTxLock = 62080 [ 3.542065] SGI XFS with ACLs, security attributes, realtime, no debug enabled [ 3.549335] Key type asymmetric registered [ 3.549443] bounce: pool size: 64 pages [ 3.549504] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247) [ 3.549633] io scheduler noop registered [ 3.549637] io scheduler deadline registered [ 3.550032] io scheduler cfq registered (default) [ 3.550037] io scheduler mq-deadline registered [ 3.554693] sun8i-h3-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver [ 3.556449] sun8i-h3-r-pinctrl 1f02c00.pinctrl: initialized sunXi PIO driver [ 3.608571] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled [ 3.611159] console [ttyS0] disabled [ 3.631309] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 41, base_baud = 1500000) is a U6_16550A [ 3.631357] console [ttyS0] enabled [ 3.635226] brd: module loaded [ 3.641528] loop: module loaded [ 3.642817] libphy: Fixed MDIO Bus: probed [ 3.644268] usbcore: registered new interface driver catc [ 3.644313] usbcore: registered new interface driver kaweth [ 3.644317] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver [ 3.644360] usbcore: registered new interface driver pegasus [ 3.644414] usbcore: registered new interface driver rtl8150 [ 3.644476] usbcore: registered new interface driver r8152 [ 3.644519] usbcore: registered new interface driver lan78xx [ 3.644576] usbcore: registered new interface driver asix [ 3.644619] usbcore: registered new interface driver ax88179_178a [ 3.644661] usbcore: registered new interface driver cdc_ether [ 3.644703] usbcore: registered new interface driver cdc_eem [ 3.644752] usbcore: registered new interface driver dm9601 [ 3.644795] usbcore: registered new interface driver sr9700 [ 3.644853] usbcore: registered new interface driver CoreChips [ 3.644912] usbcore: registered new interface driver smsc75xx [ 3.644973] usbcore: registered new interface driver smsc95xx [ 3.645015] usbcore: registered new interface driver gl620a [ 3.645058] usbcore: registered new interface driver net1080 [ 3.645108] usbcore: registered new interface driver plusb [ 3.645152] usbcore: registered new interface driver rndis_host [ 3.645196] usbcore: registered new interface driver cdc_subset [ 3.645240] usbcore: registered new interface driver MOSCHIP usb-ethernet driver [ 3.645306] usbcore: registered new interface driver cdc_ncm [ 3.645351] usbcore: registered new interface driver huawei_cdc_ncm [ 3.645394] usbcore: registered new interface driver cdc_mbim [ 3.645403] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.645406] ehci-platform: EHCI generic platform driver [ 3.645555] ehci-platform 1c1a000.usb: EHCI Host Controller [ 3.645580] ehci-platform 1c1a000.usb: new USB bus registered, assigned bus number 1 [ 3.646196] ehci-platform 1c1a000.usb: irq 27, io mem 0x01c1a000 [ 3.669419] ehci-platform 1c1a000.usb: USB 2.0 started, EHCI 1.00 [ 3.669690] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.669697] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.669702] usb usb1: Product: EHCI Host Controller [ 3.669708] usb usb1: Manufacturer: Linux 4.11.12-sun8i ehci_hcd [ 3.669713] usb usb1: SerialNumber: 1c1a000.usb [ 3.670252] hub 1-0:1.0: USB hub found [ 3.670294] hub 1-0:1.0: 1 port detected [ 3.670874] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.670892] ohci-platform: OHCI generic platform driver [ 3.671043] ohci-platform 1c1a400.usb: Generic Platform OHCI controller [ 3.671066] ohci-platform 1c1a400.usb: new USB bus registered, assigned bus number 2 [ 3.671199] ohci-platform 1c1a400.usb: irq 28, io mem 0x01c1a400 [ 3.743624] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.743631] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.743637] usb usb2: Product: Generic Platform OHCI controller [ 3.743642] usb usb2: Manufacturer: Linux 4.11.12-sun8i ohci_hcd [ 3.743647] usb usb2: SerialNumber: 1c1a400.usb [ 3.744117] hub 2-0:1.0: USB hub found [ 3.744153] hub 2-0:1.0: 1 port detected [ 3.744742] usbcore: registered new interface driver cdc_wdm [ 3.744826] usbcore: registered new interface driver usb-storage [ 3.745508] sun6i-rtc 1f00000.rtc: rtc core: registered rtc-sun6i as rtc0 [ 3.745514] sun6i-rtc 1f00000.rtc: RTC enabled [ 3.745561] i2c /dev entries driver [ 3.748895] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) [ 3.750063] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 3.809405] sunxi-mmc 1c0f000.mmc: base:0xf13d2000 irq:25 [ 3.810305] ledtrig-cpu: registered to indicate activity on CPUs [ 3.810378] hidraw: raw HID events driver (C) Jiri Kosina [ 3.810534] usbcore: registered new interface driver usbhid [ 3.810537] usbhid: USB HID core driver [ 3.810989] Initializing XFRM netlink socket [ 3.811680] NET: Registered protocol family 10 [ 3.828718] Segment Routing with IPv6 [ 3.828797] NET: Registered protocol family 17 [ 3.828828] NET: Registered protocol family 15 [ 3.828876] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 3.828917] 8021q: 802.1Q VLAN Support v1.8 [ 3.828954] Key type dns_resolver registered [ 3.829318] Registering SWP/SWPB emulation handler [ 3.829956] registered taskstats version 1 [ 3.829960] Loading compiled-in X.509 certificates [ 3.830032] zswap: loaded using pool lzo/zbud [ 3.831494] Btrfs loaded, crc32c=crc32c-generic [ 3.839011] Key type encrypted registered [ 3.844868] ehci-platform 1c1b000.usb: EHCI Host Controller [ 3.844900] ehci-platform 1c1b000.usb: new USB bus registered, assigned bus number 3 [ 3.845118] ehci-platform 1c1b000.usb: irq 29, io mem 0x01c1b000 [ 3.856568] mmc0: host does not support reading read-only switch, assuming write-enable [ 3.858479] mmc0: new high speed SDHC card at address 59b4 [ 3.859081] mmcblk0: mmc0:59b4 00000 7.48 GiB [ 3.860321] mmcblk0: p1 [ 3.869434] ehci-platform 1c1b000.usb: USB 2.0 started, EHCI 1.00 [ 3.869617] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.869624] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.869629] usb usb3: Product: EHCI Host Controller [ 3.869635] usb usb3: Manufacturer: Linux 4.11.12-sun8i ehci_hcd [ 3.869640] usb usb3: SerialNumber: 1c1b000.usb [ 3.870151] hub 3-0:1.0: USB hub found [ 3.870186] hub 3-0:1.0: 1 port detected [ 3.870791] ehci-platform 1c1c000.usb: EHCI Host Controller [ 3.870822] ehci-platform 1c1c000.usb: new USB bus registered, assigned bus number 4 [ 3.871037] ehci-platform 1c1c000.usb: irq 31, io mem 0x01c1c000 [ 3.899393] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 [ 3.899569] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.899576] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.899581] usb usb4: Product: EHCI Host Controller [ 3.899586] usb usb4: Manufacturer: Linux 4.11.12-sun8i ehci_hcd [ 3.899591] usb usb4: SerialNumber: 1c1c000.usb [ 3.900093] hub 4-0:1.0: USB hub found [ 3.900126] hub 4-0:1.0: 1 port detected [ 3.900671] ehci-platform 1c1d000.usb: EHCI Host Controller [ 3.900694] ehci-platform 1c1d000.usb: new USB bus registered, assigned bus number 5 [ 3.900862] ehci-platform 1c1d000.usb: irq 33, io mem 0x01c1d000 [ 3.929388] ehci-platform 1c1d000.usb: USB 2.0 started, EHCI 1.00 [ 3.929562] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.929568] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.929573] usb usb5: Product: EHCI Host Controller [ 3.929579] usb usb5: Manufacturer: Linux 4.11.12-sun8i ehci_hcd [ 3.929583] usb usb5: SerialNumber: 1c1d000.usb [ 3.930074] hub 5-0:1.0: USB hub found [ 3.930104] hub 5-0:1.0: 1 port detected [ 3.930628] ohci-platform 1c1b400.usb: Generic Platform OHCI controller [ 3.930649] ohci-platform 1c1b400.usb: new USB bus registered, assigned bus number 6 [ 3.930769] ohci-platform 1c1b400.usb: irq 30, io mem 0x01c1b400 [ 4.003536] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 [ 4.003543] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.003548] usb usb6: Product: Generic Platform OHCI controller [ 4.003554] usb usb6: Manufacturer: Linux 4.11.12-sun8i ohci_hcd [ 4.003558] usb usb6: SerialNumber: 1c1b400.usb [ 4.004062] hub 6-0:1.0: USB hub found [ 4.004097] hub 6-0:1.0: 1 port detected [ 4.004640] ohci-platform 1c1c400.usb: Generic Platform OHCI controller [ 4.004661] ohci-platform 1c1c400.usb: new USB bus registered, assigned bus number 7 [ 4.004793] ohci-platform 1c1c400.usb: irq 32, io mem 0x01c1c400 [ 4.073536] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 [ 4.073543] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.073548] usb usb7: Product: Generic Platform OHCI controller [ 4.073554] usb usb7: Manufacturer: Linux 4.11.12-sun8i ohci_hcd [ 4.073559] usb usb7: SerialNumber: 1c1c400.usb [ 4.074123] hub 7-0:1.0: USB hub found [ 4.074154] hub 7-0:1.0: 1 port detected [ 4.074704] ohci-platform 1c1d400.usb: Generic Platform OHCI controller [ 4.074727] ohci-platform 1c1d400.usb: new USB bus registered, assigned bus number 8 [ 4.074862] ohci-platform 1c1d400.usb: irq 34, io mem 0x01c1d400 [ 4.143539] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001 [ 4.143546] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.143551] usb usb8: Product: Generic Platform OHCI controller [ 4.143556] usb usb8: Manufacturer: Linux 4.11.12-sun8i ohci_hcd [ 4.143561] usb usb8: SerialNumber: 1c1d400.usb [ 4.144096] hub 8-0:1.0: USB hub found [ 4.144128] hub 8-0:1.0: 1 port detected [ 4.144752] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator [ 4.145084] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver [ 4.145093] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 9 [ 4.145291] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002 [ 4.145298] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.145303] usb usb9: Product: MUSB HDRC host driver [ 4.145308] usb usb9: Manufacturer: Linux 4.11.12-sun8i musb-hcd [ 4.145313] usb usb9: SerialNumber: musb-hdrc.1.auto [ 4.145925] hub 9-0:1.0: USB hub found [ 4.145960] hub 9-0:1.0: 1 port detected [ 4.146729] of_cfs_init [ 4.146811] of_cfs_init: OK [ 4.146918] vcc3v0: disabling [ 4.146924] vcc5v0: disabling [ 4.146929] usb0-vbus: disabling [ 4.146932] ALSA device list: [ 4.146934] No soundcards found. [ 4.148452] Freeing unused kernel memory: 1024K [ 4.210247] random: systemd-udevd: uninitialized urandom read (16 bytes read) [ 4.210737] random: systemd-udevd: uninitialized urandom read (16 bytes read) [ 4.215005] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.259512] usb 4-1: new high-speed USB device number 2 using ehci-platform [ 4.275069] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.276706] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.277113] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.277527] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.277935] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.278380] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.278752] random: udevadm: uninitialized urandom read (16 bytes read) [ 4.477828] usb 4-1: New USB device found, idVendor=1737, idProduct=0078 [ 4.477838] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4.477844] usb 4-1: Product: Linksys RangePlus Wireless Network USB Adapter [ 4.477849] usb 4-1: Manufacturer: Cisco-Linksys LLC [ 4.559432] usb 8-1: new low-speed USB device number 2 using ohci-platform [ 4.823449] usb 8-1: New USB device found, idVendor=045e, idProduct=00f9 [ 4.823460] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 4.823466] usb 8-1: Product: Microsoft Wireless Desktop Receiver 3.1 [ 4.823471] usb 8-1: Manufacturer: Microsft [ 4.941559] input: Microsft Microsoft Wireless Desktop Receiver 3.1 as /devices/platform/soc/1c1d400.usb/usb8/8-1/8-1:1.0/0003:045E:00F9.0001/input/input0 [ 5.009720] microsoft 0003:045E:00F9.0001: input,hidraw0: USB HID v1.11 Keyboard [Microsft Microsoft Wireless Desktop Receiver 3.1] on usb-1c1d400.usb-1/input0 [ 5.009795] microsoft 0003:045E:00F9.0002: fixing up Microsoft Wireless Receiver Model 1028 report descriptor [ 5.025226] input: Microsft Microsoft Wireless Desktop Receiver 3.1 as /devices/platform/soc/1c1d400.usb/usb8/8-1/8-1:1.1/0003:045E:00F9.0002/input/input1 [ 5.089594] microsoft 0003:045E:00F9.0002: input,hidraw1: USB HID v1.11 Mouse [Microsft Microsoft Wireless Desktop Receiver 3.1] on usb-1c1d400.usb-1/input1 [ 5.517909] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DTO !! [ 5.517949] sunxi-mmc 1c0f000.mmc: data error, sending stop command [ 5.518010] mmcblk0: timed out sending r/w cmd command, card status 0x900 [ 5.838687] random: fast init done [ 6.008398] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 6.510902] systemd[1]: System time before build time, advancing clock. [ 6.541371] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN) [ 6.541865] systemd[1]: Detected architecture arm. [ 6.610269] systemd[1]: Set hostname to <orangepipc>. [ 7.023974] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DTO !! [ 7.024020] sunxi-mmc 1c0f000.mmc: data error, sending stop command [ 7.024075] mmcblk0: timed out sending r/w cmd command, card status 0x900 [ 7.424401] systemd[1]: Listening on fsck to fsckd communication Socket. [ 7.449732] systemd[1]: Listening on Syslog Socket. [ 7.479508] systemd[1]: Reached target Remote File Systems (Pre). [ 7.509767] systemd[1]: Listening on Journal Audit Socket. [ 7.539933] systemd[1]: Created slice User and Session Slice. [ 7.569634] systemd[1]: Listening on udev Control Socket. [ 7.600216] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 8.285193] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 9.469037] input: r_gpio_keys as /devices/platform/r_gpio_keys/input/input2 [ 9.533300] thermal thermal_zone0: failed to read out thermal zone (-16) [ 9.724525] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok [ 9.832307] rc rc0: sunxi-ir as /devices/platform/soc/1f02000.ir/rc/rc0 [ 9.837662] Registered IR keymap rc-empty [ 9.837989] input: sunxi-ir as /devices/platform/soc/1f02000.ir/rc/rc0/input3 [ 9.838129] sunxi-ir 1f02000.ir: initialized sunXi IR driver [ 9.880263] lirc_dev: IR Remote Control driver registered, major 244 [ 9.896406] mousedev: PS/2 mouse device common for all mice [ 9.911563] rc rc0: lirc_dev: driver ir-lirc-codec (sunxi-ir) registered at minor = 0 [ 9.911576] IR LIRC bridge handler initialized [ 10.099477] usb 4-1: reset high-speed USB device number 2 using ehci-platform [ 10.299509] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected [ 10.354168] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected [ 10.355002] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 10.356291] usbcore: registered new interface driver rt2800usb [ 10.369922] rt2800usb 4-1:1.0 wlx98fc11ca00b2: renamed from wlan0 [ 10.910102] systemd-journald[328]: Received request to flush runtime journal from PID 1 [ 10.960265] libphy: 1c30000.ethernet: probed [ 10.964606] Generic PHY 1c30000.ethernet-0:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=1c30000.ethernet-0:01, irq=-1) [ 10.964618] sun8i-emac 1c30000.ethernet: device MAC address slot 0 02:81:31:1b:c3:da [ 10.965884] sun8i-emac 1c30000.ethernet: device MAC address slot 1 33:33:00:00:00:01 [ 10.965957] sun8i-emac 1c30000.ethernet: device MAC address slot 1 33:33:00:00:00:01 [ 10.965962] sun8i-emac 1c30000.ethernet: device MAC address slot 2 01:00:5e:00:00:01 [ 10.965975] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 11.131715] random: crng init done [ 12.673680] IPv6: ADDRCONF(NETDEV_UP): wlx98fc11ca00b2: link is not ready [ 12.673859] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' [ 12.676617] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 [ 13.039959] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 13.194067] IPv6: ADDRCONF(NETDEV_UP): wlx98fc11ca00b2: link is not ready [ 13.194114] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 13.194260] sun8i-emac 1c30000.ethernet: device MAC address slot 1 33:33:00:00:00:01 [ 13.194266] sun8i-emac 1c30000.ethernet: device MAC address slot 2 01:00:5e:00:00:01 [ 13.194271] sun8i-emac 1c30000.ethernet: device MAC address slot 3 33:33:ff:1b:c3:da [ 13.529563] IPv6: ADDRCONF(NETDEV_UP): wlx98fc11ca00b2: link is not ready [ 16.368152] wlx98fc11ca00b2: authenticate with 08:bd:43:a5:ae:54 [ 16.407902] wlx98fc11ca00b2: send auth to 08:bd:43:a5:ae:54 (try 1/3) [ 16.410065] wlx98fc11ca00b2: authenticated [ 16.419501] wlx98fc11ca00b2: associate with 08:bd:43:a5:ae:54 (try 1/3) [ 16.422956] wlx98fc11ca00b2: RX AssocResp from 08:bd:43:a5:ae:54 (capab=0x411 status=0 aid=10) [ 16.431758] wlx98fc11ca00b2: associated [ 16.432149] IPv6: ADDRCONF(NETDEV_CHANGE): wlx98fc11ca00b2: link becomes ready [ 283.748868] sun8i-emac 1c30000.ethernet: device MAC address slot 1 33:33:00:00:00:01 [ 283.748911] sun8i-emac 1c30000.ethernet: device MAC address slot 2 01:00:5e:00:00:01 [ 283.748936] sun8i-emac 1c30000.ethernet: device MAC address slot 3 33:33:ff:1b:c3:da
  21. Hi, OPiPC with latest mainline (ARMBIAN 5.34 user-built Ubuntu 16.04.3 LTS 4.13.12-sunxi). Need to test the I2S0. From what I see in patches, the I2S driver code is already there so I just need an overlay to use it. Is there any DT overlay for using the H3 I2S0 with any codec ? Even as a generic simple-audio-codec ? Christos
  22. Hello, I have installed ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.14.70-sunxi on a Banana Pi M2+ and I need to read and write to the GPIO pins from a bash script, does anyone have a workable solution? I tried with an Orange Pi in the past and I compiled a binary to access the gpio values but it did not work and I cannot find that source any more. Thanks in advance.
  23. I have Orange PI PC Plus with GC2035 camera module. Upgraded to 4.13.6 sunxi-next mainline kernel and noticed that GC2035 camera driver is gone! Why is it so? Maybe someone forgot to include this driver to the kernel? People are still using these cameras and need them! If it was a conscious decision to remove the GC2035 camera from the sunxi-next tree - then, well, it was a horrible decision that should be reversed. Please return this driver. https://github.com/avafinger/gc2035 Earlier it was at ./drivers/media/video/sunxi-vfe/device/gc2035.c location, but now the directory structure could be very different...
  24. Trival endevour, though fun and easy to do. Text and diagram taken from zip file attached. Orange Pi Zero fan self adapting to temperature, inside Shenzhen Xunlong Software CO.,Limited manufacturered low profile (non-expansion board version) case. Probably can be used with other SBC's. FanDaemon source provided. Comes with no warranty of any sort. Use at your own risk. The software included works with Mainline Kernel 4.13 Armbian image. Run armbian-config - system - hardware, use arrow keys to highlight "pwm" and press spacebar to [*] enable it. Select save and reboot. Install the fan how you wish. I used a 5volt 3cm wide (bigger will not fit), 1cm thick blower fan from ebay (sucks air in from below, blows from side) glued to the ceiling of the case against the top vents. Could also cut holes into the roof and mount a regular fan to blow air out the top, or on top of the sbc and leave vents unaltered. Use sticky tape to cover the extra vent slits and round the blower fan if there is a gap, to stop leakage. I filed the power cable hole in the case wider, to allow more air flow. Mosfet I used was "FQP30N06L/FQP30N06" very common and cheap if you can wait several weeks for shipping from ebay. 10kohm resistor between outer pins using wires with 2.54 header plugs. Tight fit but doable. You can use either the +3.3v power rails (pin 1 or 9 on 26 pin header) or +5v for faster fan speed, or for fans that do not handle the lower voltage. For some reason when using +5v, I only got a very narrow range of operation or 2 effective speeds whereas with 3.3v, duty cycles 20% to 100% worked. For +5v, pin 1 on the 13 pin header can be used, however the wire tends to hand right on top of fan and risks it being sucked into the blades. Put the fand executable where ever you want and do... chown root fand chmod u+x fand (I used midnight commander and used in its File menu, set owner can execute and chown adding file to root user and root group) fand software needs root priviledges for manipulating the pwm interface in /sys folder. Maybe another user in wheel group would do? run sudo crontab -e and below "# m h dom mon dow command" add (#how to customise below) @reboot sleep 10 && nohup /root/fand/./fand 48000 5 1 65 10 100 & Remember to press enter after "&" as the crontab requires a new empty line after declaring the last cronjob. Sleep is added as I found if the daemon was started too early, there was a chance the fand would fail to start for whatever reason. * e.g. above for FanD executable located in /root/fand/ sets Duty Cycle freqency to 48000Hz (or something or rather), temperature check at 5 second intervals temperature/DT% 1c(10%DT) to 65c(100%DT) #fand command line is as below /(path to execultable)/./fand duty cycle (Duty Cycle (DT) frequency) (polling interval in seconds) (min temperature, lowest DT% => 1) (temp for max DT%) (& to fork into background) FanD shows Duty Cycle % in its process name when using the "top" command, scroll down using down arrow if you cannot see it at first. To compile included fand.c source, if you edit it or do not trust the included binary. gcc -std=gnu99 fand.c -o fand Daemon has negligible memory and cpu usage. You can also set a fixed speed with console commands in a script as root. You may need to experiment with values. echo 0 > /sys/class/pwm/pwmchip0/unexport echo 0 > /sys/class/pwm/pwmchip0/export echo normal > /sys/class/pwm/pwmchip0/pwm0/polarity # set the DT period to 30000 ns echo 30000 > /sys/class/pwm/pwmchip0/pwm0/period # e.g. set the duty cycle to 15000 ns (50%DT?) echo 15000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable to disable pwm (and the fan), as root enter... echo 0 > /sys/class/pwm/pwmchip0/pwm0/enable Longer DT periods/lower DT frequency, if used, produces a humming sound from the motor. Credits to FanD software to Andrea Cioni. Forked by me from github version for better compatibility with Orange Pi Zero. Did not comment changes I made, on account of being too lazy. DT polarity corrected and device in unready state (preventing daemon start) bug improved. I have ceramic heatsinks on both the ram and soc chip bonded using Artic Silver. Dries and cements the heatsinks to surface rather well. With cpu governor set to performance (constant 1200mhz), ambient air about 22celcius at idle the cpu temperature is 40-45celcius using the cronjob given above. OrangePiZero-FanDaemon-and-wiringdiagram-src&binary.zip
  25. Hello Folks, Good day. I hope you're doing great. I'm trying to make the OrangePI 10.1 inch MIPI DSI (product page) work on the most recent (mainline) Armbian build. Building the image using the OrangePI source repositories and following the instructions on OPi4B manual enables the LCD and touch, However, my intention is to make the LCD + Touch work on the most recent Armbian Focal (mainline). I've setup my Armbian build env but I cannot see to find how to enable this MIPI screen on any build options. Here's the instructions from Page #20 of OPi 4B manual: Download the Linux source code and make the following changes in dts --- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi-lcd.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi-lcd.dtsi @@ -40,12 +40,12 @@ max-x = <800>; max-y = <1280>; tp-size = <101>; // <911> for 8 inch // <101> for 10 inch - status = "disable"; + status = "okay"; }; }; &dsi { - status = "disable"; + status = "okay"; panel@1 { compatible = "simple-panel-dsi"; reg = <0>; That specific file doesn't exist on the Armbian build directory tree. I'm not familiar enough with the dts and dtsi files to be integrating it. I've been searching the forum for answers but, so far, I'm not able to make it work. I'm looking for help on enable it and appreciate any pointers or guidance that can help make the LCD + Touch work on a mainline kernel version. I linked some dts files from the OrangePI source repository that "might" help. I'm thankful for any help. Thank you.