Search the Community

Make it yourself. I now us the Khadas VIM3 for that with a big RavPowe 26800mAh Power Banks. Either a 7" or a 13" display. With the small display, one powerbank is enough for about 15 hours. Big display is a little less than 10 hours. I charge my power banks with solar panels. So I always have power. The Pinebook pro should be released one of these days. It's only got a 10 000mAh battery, but if you bring a power bank wih you it'll last a long time. Greetings.

Yesterday I compiled Armbian_5.97_Pinebook-a64_Debian_buster_dev_5.3.0-rc8_desktop for my non-Pro Pinebook. While booting the screen was very dim So I searched on the net for a command and came to the one you had in your error-message above But the value 51 for brightness was too high to be set. I did read out the actual dim value as 2: #read-out display brightness pkexec /usr/sbin/xfpm-power-backlight-helper --get-brightness 2 and I did set (via /etc/rc.local) a for-me-default value of 8: #set display brightness pkexec /usr/sbin/xfpm-power-backlight-helper --set-brightness 8 A value of 10 was to bright for me

The Emulator compiled even on a Pinebook A64, but is slower than on the NanoPi K1 Plus

One minute ago ..... on Pinebook buster .... ansible@pinebook:~$ LANG=C LANGUAGE=C sudo apt update Hit:1 http://ftp.fr.debian.org/debian buster-backports InRelease Hit:2 http://ftp.debian.org/debian buster InRelease Hit:3 http://security.debian.org buster/updates InRelease Hit:4 http://ftp.fr.debian.org/debian buster-updates InRelease Ign:5 http://ftp.debian.org/debian stretch InRelease Hit:7 http://ftp.debian.org/debian stretch Release Ign:6 https://apt.armbian.com buster InRelease Err:8 https://apt.armbian.com buster Release Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 193.40.103.96 443] Reading package lists... Done W: http://apt.armbian.com/dists/buster/InRelease: No system certificates available. Try installing ca-certificates. W: http://apt.armbian.com/dists/buster/Release: No system certificates available. Try installing ca-certificates. E: The repository 'http://apt.armbian.com buster Release' no longer has a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

have the same kernel and we don't support 3rd party hardware if its not specifically declared. As you can see on the download pages ... some 3rd party works, for else is everything but switching it on. Modern kernel is basically written from scratch by community. And if we (community) didn't develop that, support for that LCD does not exits. Displays are not my field so I can't give you any useful tip except ... have you tried to boot images for Pinebook perhaps?

hi, you need to overid the dtp file in here ll /boot/dtb-5.1.7-sunxi64/allwinner/ total 968 drwxr-xr-x 3 root root 4096 Jun 15 12:19 ./ drwxr-xr-x 3 root root 4096 Jun 15 12:21 ../ drwxr-xr-x 2 root root 4096 Jun 15 12:19 overlay/ -rw-r--r-- 1 root root 33668 Jun 14 23:52 sun50i-a64-amarula-relic.dtb -rw-r--r-- 1 root root 35345 Jun 14 23:52 sun50i-a64-bananapi-m64.dtb -rw-r--r-- 1 root root 34228 Jun 14 23:52 sun50i-a64-nanopi-a64.dtb -rw-r--r-- 1 root root 35180 Jun 14 23:52 sun50i-a64-olinuxino.dtb -rw-r--r-- 1 root root 35776 Jun 14 23:52 sun50i-a64-orangepi-win.dtb -rw-r--r-- 1 root root 34570 Jun 14 23:52 sun50i-a64-pine64-lts.dtb -rw-r--r-- 1 root root 35082 Jun 14 23:52 sun50i-a64-pine64-plus.dtb -rw-r--r-- 1 root root 35004 Jun 14 23:52 sun50i-a64-pine64.dtb -rw-r--r-- 1 root root 36584 Jun 14 23:52 sun50i-a64-pinebook.dtb -rw-r--r-- 1 root root 34582 Jun 14 23:52 sun50i-a64-sopine-baseboard.dtb -rw-r--r-- 1 root root 36526 Jun 14 23:52 sun50i-a64-teres-i.dtb -rw-r--r-- 1 root root 31397 Jun 14 23:52 sun50i-h5-bananapi-m2-plus-v1.2.dtb -rw-r--r-- 1 root root 31004 Jun 14 23:52 sun50i-h5-bananapi-m2-plus.dtb -rw-r--r-- 1 root root 29328 Jun 14 23:52 sun50i-h5-emlid-neutis-n5-devboard.dtb -rw-r--r-- 1 root root 29798 Jun 14 23:52 sun50i-h5-libretech-all-h3-cc.dtb -rw-r--r-- 1 root root 32108 Jun 14 23:52 sun50i-h5-nanopi-k1-plus.dtb -rw-r--r-- 1 root root 29396 Jun 14 23:52 sun50i-h5-nanopi-m1-plus2.dtb -rw-r--r-- 1 root root 29316 Jun 14 23:52 sun50i-h5-nanopi-neo-core2.dtb -rw-r--r-- 1 root root 29412 Jun 14 23:52 sun50i-h5-nanopi-neo-plus2.dtb -rw-r--r-- 1 root root 29061 Jun 14 23:52 sun50i-h5-nanopi-neo2-v1.1.dtb -rw-r--r-- 1 root root 29065 Jun 14 23:52 sun50i-h5-nanopi-neo2.dtb -rw-r--r-- 1 root root 29991 Jun 14 23:52 sun50i-h5-orangepi-pc2.dtb -rw-r--r-- 1 root root 29918 Jun 14 23:52 sun50i-h5-orangepi-prime.dtb -rw-r--r-- 1 root root 29138 Jun 14 23:52 sun50i-h5-orangepi-zero-plus.dtb -rw-r--r-- 1 root root 29143 Jun 14 23:52 sun50i-h5-orangepi-zero-plus2.dtb -rw-r--r-- 1 root root 27608 May 30 22:14 sun50i-h6-orangepi-3.dtb <---------------------------------------- -rw-r--r-- 1 root root 27359 Jun 14 23:52 sun50i-h6-orangepi-lite2.dtb -rw-r--r-- 1 root root 26874 Jun 14 23:52 sun50i-h6-orangepi-one-plus.dtb -rw-r--r-- 1 root root 27617 Jun 14 23:52 sun50i-h6-pine-h64.dtb

Installed the 5.1.6 -dev build. Same no backlight with the LCD, however, reverting https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/xxx-pinebook-revert-pwm-polairity-TEMP-WORKAROUND.patch and then adding in the https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/need-to-check/fix-pinebook-backlight.patch both seem to work here, working backlight with the LCD. Tested multiple reboots as well as startup from shutting down.

So, because I got on the idea of "is the hdmi broken" - I took the tape off... it would appear that with the Armbian 5.1.5 kernel..... hdmi output is happening... Boot output goes to the hdmi monitor, and not the pinebook lcd, however the login is definitely on the pinebook's lcd - blindly logging in works, but the lcd is still considered primary, so the menu and so forth is on the pinebook itself, the external hdmi monitor does show a background image and I can move the cursor around on it. Interestingly enough, not distorted at all, although all it has is the background image. The LCD backlight still doesn't appear to be powering on. Looking through the patches, I saw https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/need-to-check/fix-pinebook-backlight.patch - and figured I'd give it a shot... with that applied, which removes the "backlight:" the lcd flickers twice during boot, and then about 2 or 3 minutes later, the backlight turns on (sadly, nothing seems to be in dmesg output) - however, as soon as I attempted to log in, the lcd backlight shut off again. Unfortunately, I haven't been able to reproduce that, it only happened that one time. I definitely think something is up when hdmi is enabled now, so that's where I'll dig. I apologize if I'm updating too often, I'm kind of using this as a stream of consciousness as I work through the patches.

A bit more digging - taking the dts from 5.1.5/5.1.6 without any changes has a working backlight (and audio!) - so it's definitely something in the patches applied on Arabian. I'm going to start digging through them. I'm not sure if it matters or not, but my Pinebook showed up with tape over the hdmi port, could it be that hdmi is completely broken with the 1080p lcd on 11"?

That indeed isn't good at all. I'm from Europe so I haven't got a clue where to buy when you're from South-America. It's this PSU. https://www.cloudmedia.com/?product=rock64-pinebook-pine-h64-5v-3a-switching-power-supply I'm using a different one for it, a 4A EU PSU. But 3A should be sufficient. This is what you need to look for : 5V (at least) 3A Type H 3.5mm OD/1.35mm ID barrel ‘coaxial’ type I'd trow away that PSU you've got before it damages anything(hd/sd-card). I've seen a lot of undervolting in my times but under 4V is very rare. With a good PSU/cable you should never go under 4.8V. (tell that to the raspberry pi foundation) Good luck, greetings.

Double check if this is not solo a problem of our patch set, which it is different than mainline in some details. Especially this patch https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/xxx-pinebook-revert-pwm-polairity-TEMP-WORKAROUND.patch which naming tells things will be changed, but we didn't get that far yet to sort things out ...

I don't have a pinebook, so not sure if this is helpful... someone should give it a try... GETTING A VIRTUAL TERMINAL Linux provides six virtual consoles (text-based command-line interfaces). Simultaneously, pressing the Control (Ctrl) and Alternate (Alt) keys with any of the functions keys from F1 through F6. For example, press Ctrl-Alt-F1. Return to the graphics screen by pressing Ctrl-Alt-F7.

From what I know, Sleep/Hibernate works only on Legacy, since it rely on AR100 ARISC co-processor, not yet supported on Mainline. That is true for all AllWinner SoC, not only H6 ... For more details, here is http://linux-sunxi.org/AR100 For example, it is well known that Pinebook with Mainline, doing sleep simply returns to normal desktop, without even doing a reboot.

Yes. It seems not all boards are affected ... I tested only one Lime and Pinebook IIRC and found no troubles. Reverting back to BOOTSOURCE='https://github.com/anarsoul/u-boot-pine64' BOOTBRANCH='branch:pinebook-wip-20181109' seems like a fix (workaround). Still testing and looking into ...

This is interesting... https://www.cnx-software.com/2019/05/04/pinebook-pro-arm-laptop-video-demo/

root@ICS-Pine64:~# fdtdump / boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb | grep erra **** fdtdump is a low-level debugging tool, not meant for general use. **** If you want to decompile a dtb, you probably want **** dtc -I dtb -O dts <filename> Couldn't open blob from '/ boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb': No such file or directory FATAL ERROR: could not read: / boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb root@ICS-Pine64:/boot/dtb/allwinner# ls overlay sun50i-h5-nanopi-k1-plus.dtb sun50i-a64-amarula-relic.dtb sun50i-h5-nanopi-m1-plus2.dtb sun50i-a64-bananapi-m64.dtb sun50i-h5-nanopi-neo2.dtb sun50i-a64-nanopi-a64.dtb sun50i-h5-nanopi-neo2-v1.1.dtb sun50i-a64-olinuxino.dtb sun50i-h5-nanopi-neo-core2.dtb sun50i-a64-orangepi-win.dtb sun50i-h5-nanopi-neo-plus2.dtb sun50i-a64-pine64.dtb sun50i-h5-orangepi-pc2.dtb sun50i-a64-pine64-lts.dtb sun50i-h5-orangepi-prime.dtb sun50i-a64-pine64-plus.dtb sun50i-h5-orangepi-zero-plus2.dtb sun50i-a64-pine64-plus.dtb-ORIGINAL sun50i-h5-orangepi-zero-plus.dtb sun50i-a64-pinebook.dtb sun50i-h6-orangepi-lite2.dtb sun50i-a64-sopine-baseboard.dtb sun50i-h6-orangepi-one-plus.dtb sun50i-a64-teres-i.dtb sun50i-h6-pine-h64.dtb sun50i-h5-libretech-all-h3-cc.dtb Getting an error here: root@ICS-Pine64:/boot# git-work/dtc/dtc -I dtb -O dts -o sun50i-a64-pine64-plus.dts /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb -bash: git-work/dtc/dtc: No such file or directory root@ICS-Pine64:/boot/dtb/allwinner# git-work/dtc/dtc -bash: git-work/dtc/dtc: No such file or directory

I got here from the lst compile Welcome to ARMBIAN 5.78 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi64 package bsp-kernel[5.78] u-boot[5.78] dtb[5.78] firmware[5.77] config[5.78] Linux npi-a64 5.0.7-sunxi64 #5.78 SMP Wed Apr 10 09:20:27 +03 2019 aarch64 GNU/Linux defconfig for this image seems to come from ./build/cache/sources/u-boot/pinebook-wip-20181109/configs/nanopi_a64_defconfig but also here only the lower usb-port does work also upper-port-usb doesnt work at the normal mainline-image ARMBIAN 5.78 user-built Debian GNU/Linux 9 (stretch) 4.19.25-sunxi64 Linux nanopia64 4.19.25-sunxi64 #5.78 SMP Wed Apr 10 13:20:03 +03 2019 aarch64 GNU/Linux

@martinayotte Thank you for the suggestion. I changed to same, rebooted with no luck. Anything else I'm missing like do another make or something? For reference herewith my armbianEnv.txt: verbosity=1 console=both disp_mode=720p60 camera_type=none pine64_lcd=off rootdev=UUID=2a9ed406-bd1a-46ce-b16b-908ee24b8eeb rootfstype=ext4 overlay_prefix=sun50i-a64 overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_spi_cs=0 param_spidev_max_freq=100000000 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u And the contents of my dtb: dtb-3.10.107-pine64 sun50iw1p1-nanopim64.dtb sun50iw1p1-pine64.dtb sun50iw1p1-pine64so.dtb sun50iw1p1-bananapim64.dtb sun50iw1p1-olinuxino-a64.dtb sun50iw1p1-pine64-pinebook.dtb sun50iw1p1-soc.dtb sun50iw1p1-fpga.dtb sun50iw1p1-orangepiwin.dtb sun50iw1p1-pine64-plus.dtb sun50iw1p1-teres.dtb Lastly The test I do to see if it is available is to check /dev for some flavour of SPI?

Earlier today I pushed a fairy large patchset containing various functional improvements of many boards. If you have Allwinner board and some spare time: 1. Build DEV image/kernel with https://github.com/armbian/build (you need to add EXPERT="yes" to the config to unlock) 2. Install DEV kernel from beta repository Optional Defreeze kernel updates Switch to nightly kernel (armbian-config -> system -> Nightly) Reboot Switch to other kernel (armbian-config -> system -> Other -> DEV) When board came up, do some exploration. Most important information is to find out if there is a regression toward kernel 4.14.y! Then make a test report https://github.com/armbian/testings#how-to-create-a-test-report. If you know how to fix certain problems, you are more than welcome! Our resources are tiny and we can't possible fix all problems This topic is a place to discuss how certain problems/bugs can be solved. When reporting a bug, provide logs with: armbianmonitor -u Bugs: - serial gadget console is not working (anywhere?) - Pinebook doesn't boot properly - Mesa (OS Mali drivers are enabled by default) / WebGL works on Debian based Chromium, fails on Ubuntu I checked those: Orangepi PC2 http://ix.io/1s2c (hdmi, dvfs) @tkaiser SBCBENCH: http://ix.io/1s5d ( @hojnikb available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz) Olinuxino A64 http://ix.io/1s2d (hdmi, dvfs, wireless, usb, battery) SBCBENCH: http://ix.io/1s5e tested battery charging/discharging Olimex Teres 1 A64 (hdmi, dvfs, wireless, usb, battery) http://ix.io/1tJg Orangepi Prime SBCBENCH: http://ix.io/1s5R (once "powered off" during benchmarking at 92C) Orangepi +2e SBCBENCH: http://ix.io/1s5T Orangepi Win SBCBENCH: http://ix.io/1s8c Cubietruck SBCBENCH: http://ix.io/1u3W OrangepiZero +2 H3 SBCBENCH: http://ix.io/1pqd Orangepi One H3 SBCBeNCH: http://ix.io/1psZ Orangepi Lite H3 http://ix.io/1u6R Nanopi Neo2 http://ix.io/1u4A (with NAS http://ix.io/1uUM) Orangepiplus http://ix.io/1u5H Orangepi Zero H2+ http://ix.io/1u9b Nanopi Air http://ix.io/1u9d With problems: Pinebook Confirmed working: Neo2 v1.1 512MB Neo2 v1.1 1GB Pine64 Orange Pi Zero Plus2 H5 Nanopi Duo http://ix.io/1uVC Orangepi R1 http://ix.io/1uaP Nanopi Neo Core 2 LTS Nano Pi Neo Plus2 Tritium H3 and H5 Orange Pi Zero Plus Bananapi M1 For now. BTW. Do you want to become a (Allwinner) board maintainer? Duties: - responsible for content at the download page, - running latests updates and managing bug list there.

As always the question is what you want to do with it I'm typing this on a Pinebook which is fast enough for what I use it for. My Orange Pi Zero is fast enough for file and network services that I use it for. My RPi Zero is fast enough for running RISC OS. It's all down to your use case.

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere. TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too. Basics first: Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different! Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines. We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk. Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account: Pre-production board, 4GB, RTL8211E PHY: Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW Production board, 1GB, RTL8211F PHY: Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0). So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself. Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735 What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001 So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port. Nope, doesn't work any more, see below for details. How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago): The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s): USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s): USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111 I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts. Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened. So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise). When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters). The 5V power requirements for JMS578 + 3.5" HDD disk were as follows: USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

There is a RTL8723BS on OrangePiPrime (and in Pinebook too if I recall correctly), and it is working fine with both NEXT or DEV images.

Doesn't seems to work on Pinebook with Armbian 4.20.y. I will probably check with an Ayufan image later ...

My last update on this issue in case someone is working to get sound on A64 (>= 4.20). I tried every patch out there, triple checked the code , same situation, no sound. I must have missed something or overlooked something. I finally tried Vasily's kernel and for my surprise no sound. Last hope, i tried Vasily ARCH img, no luck, no sound even on Pine64. Maybe it works on Pinebook,....

Any objections to merge/move H5 and A64 from https://forum.armbian.com/forum/18-allwinner-a64-h5-h6/ to https://forum.armbian.com/forum/27-mainline-kernel/ ? Before Allwinner A64, H5 & H6 Pine64, H64, Pinebook, Olimex Teres, Olinuxino A64, Orange Pi PC2, Zero+ 2 H5, Prime, Win; NanoPi Neo 2, Neo+ 2, M1 Plus 2, FriendlyElec K1+ After Allwinner H6 Pine H64, Orange Pi One +, Lite2