Search the Community

I put a copy of the kernel image I'm using on filebin for one of the guys on irc: https://filebin.ca/3dBZ0qmNivMa/Image-3.10.107-pine64 Of course I forgot you'd also need a copy of the modified uboot, and it's been long enough since I've looked at uboot that I'll have to dig around to find where I left a copy. I'll update when I find it. OK, here's the uboot to go with the above kernel: https://filebin.ca/3dBng1sFqg02/linux-u-boot-pinebook-a64_5.32_arm64.zip The zip file contains the uboot binary and a very simple script to install it. Check the device in the script matches the device for the emmc on your machine before running it, which will need to be done as root/sudo. I'll try and get these contributed as patches to armbian as soon as I can (sorry for the delay, work has been very busy recently)

After doing some research I came to the conclusion that blindly trusting in MAC address randomization working as expected isn't a good idea, that I lack time and will to test whether Pinebook really does it correctly and that we can't 'prevent' predictable network device names anyway (eg. Debian declares the old scheme deprecated in version 9 and not available any more in 10). So I'm fine with the proposed fix.

Why? This disabled predictable network device names, but we are also talking about MAC address randomization which is IMO only useful for portable devices (so only for the Pinebook) "Predictable names" were added mostly for USB (and PCI/PCIe) devices so you could plug them in any port at any time and would get a permanent MAC address based device name, so yes, it's not very useful for SDIO and memory-mapped devices, but I wouldn't jump to "zero improvement" and "lot of complexity" conclusions straight away. If we disable this, IMO it's better to do it with an udev rule than with kernel command line modification.

And then reverting the additional NM defaults change back? Also individually for the Pinebook? As far as I understood the 'problems' are nmtui connect problem reported by Igor (most probably since NM changing MAC address in between call of nmtui and trying to establish connection?) According to the github issue syslog spamming (which I consider not being a problem since 'attaching to a network seems to have stopped the noise as well') According to the same github issue 'NetworkManager is keeping the CPU busy'. Does this change after stopping MAC address randomization? Is NM silent now or is it still busy bot now with the same MAC address? Adding to the above I wonder what's the state of affairs wrt Wi-Fi powermanagement and NM in Stretch (since dmesg output on Github seems to indicate it's not working as on Jessie or Xenial). I haven't looked into this myself but to me the issues that should been looked at a little bit closer wrt Stretch are powermanagement settings constant try to search for networks (how to disable this would be my first question) nmtui-connect problems (if we can stop NM from permanently searching for open Wi-Fis on its own is this still an issue then?) Adopting a workaround that's 'recommended' by countless Debian/Ubuntu users reminds of the 'UAS is evil' stupidity mess we have to deal with in the Linux world.

We can always override settings by adding another file specifically for the Pinebook.

I'm really not sure since MAC address randomization should be considered an essential feature these days especially when we think about supporting devices like PineBook. At least I would suggest to first check whether stopping device renaming isn't the better option as described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839605#25 Does this apply to Stretch too?

i'm trying to make suspend on lid close work. i saw in this thread that some people are aware that there's a problem. i'd prefer to achieve this from within xfce4-power-manager. here's the thing: 1. using the normal xfce desktop * for "when laptop lid is closed", only 'lock screen' and 'switch off diplay' are available * "System sleep mode" is completely grayed out, as well as security 'lock screen when system is going to sleep' * the 'Ask' option is available only for "Buttons". Choosing it, then choosing "Suspend" from the dialog, causes the ui to hang (desktop darkened), but after a minute i can 'escape' out of it. * 'systemctl suspend' suspends as expected (without locking the screen) 2. using plain openbox without display manager (i.e. console login & startx instead of nodm) or desktop environment, xfce4-power-manager autostarted * for "when laptop lid is closed", 'lock screen', 'switch off diplay', 'suspend' and 'hibernate' are available, but only the first 2 work * "System sleep mode" gives me a choice between 'suspend' and 'hibernate' - only suspend works (!) as expected. * security 'lock screen when system is going to sleep' is not greyed out, and un/checking it works as advertised * the 'Ask' option is available only for "Buttons". It does nothing. * 'systemctl suspend' suspends as expected (without locking the screen) in other words, choice nr. 2. works in all aspects except the lid switch! i tried to let systemd handle the lid switch - to no avail. i also tried to not use xfce4-power-manager at all, only systemd - to no avail. reading `man logind.conf` i notice this: Interesting... 'udevadm monitor' showed nothing for opening/closing the lid. dmesg showed this: hall: (D) hall_isr hall: (I) HALL_CLOSE hall: (D) hall_isr hall: (I) HALL_OPEN every time i open/close the lid... so, where exactly would i have to add this "power-switch" udev tag? phew, my head swims... any ideas? maybe a secret solution already exists?

I got a mainline kernel up and running. It detects the mmc ok, but clearly fails to get it into hs200 or hs400, so I'm not going to get any clues from the new driver. kB reclen write rewrite read reread read write 102400 4 10712 11284 11803 11642 5615 8249 102400 16 15740 16719 18346 18308 12720 15285 102400 512 21920 22029 22545 22659 21987 21794 102400 1024 22085 22075 22784 22810 22470 21942 102400 16384 21628 22318 23012 23019 23007 21744 the /sys info suggests it's in 50MHz sdr mode: root@pinebook:/sys/kernel/debug/mmc2# cat ios clock: 52000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) I contacted SanDisk to see if they would provide a datasheet or app note for the chip, but they politely declined. Such is life.

While I had the pinebook open just now I grabbed the chip markings from the emmc module. SanDisk SDINADF4-64G 7265DRKGP02Z I haven't had any luck finding a real datasheet or application note for the SanDisk modules, so if anyone finds one please throw me a link

That's a hack for the old stock kernel which we don't use on this board. We use that kernel on a similar board - Pine64 and Pinebook but haven't managed to adjust it for Oranges or Bananas ... we lack resources and working mostly with a modern kernel. That one is not very far away.

Sorry I have missed you were using a pinebook. I'm use mainline on a Pine64 and it's working fine but I'm not using any desktop / gui About aufs vs Overlay2 : when I was still using my SDCard as storage for my docker containers (one year ago), I had a lot of performance problem with aufs -> using overlay2 solved most of it. Back I was reading this site and it convinced me https://github.com/chriskuehl/docker-storage-benchmark But I'm not selling anything, if it works good enought don't touch it

Legacy. I haven't had a chance to try mainline on the pinebook yet (which would be an interesting thing to do), but my understanding is that it isn't ready for desktop/gui use yet. As far as aufs vs Overlay2 goes, I read enough to realise there's a lot of political stuff around the adoption into the kernel and newer distributions, but I haven't seen any technical comparisons of the two. Apart from the bug above, aufs seems to have been working extremely well, but I guess if the momentum now is behind overlay2 then that's the direction we will all be going in.

Hi, I hit a problem on pinebook where docker would hang with defunct processes consuming high cpu. A bit of googling turned up a known problem with aufs as the cause, so I grabbed the patches, combined them and created a pull request https://github.com/armbian/build/pull/772 I gave the resulting kernel a fairly good work-out this evening and it seems to be working fine now.

Is the charging current adjustable? I'd quite like to be able to set the charge current to a relatively low value if I'm using the pinebook, and then boost it to a higher value as part of the suspend/shutdown sequence.

I remember reading somewhere (probably in this thread) tkaiser saying that charging the battery generates a lot of heat that transfers to the cpu through the shared heat-sink. I normally put the pinebook on charge when I'm not using it, so it's not something I'd run into before, until the battery got low today and I plugged it in. My word! It's really warm and it's the first time I've seen thermal throttling in normal use. I was coming around to the idea of liking not having a fan, but if you want to use while charging, I think adding a fan would be a good idea, although it's likely to be an ugly hack. Perhaps I'll stick to charging overnight

Hi, I'm trying to iterate quickly to test out some ideas on the mmc driver, so I was wondering if it is possible to prevent re-downloading the sources every time. It looked like IGNORE_UPDATES=yes might be what I want, but when I tried that I got a failure during compile_atf: [ o.k. ] Installing [ rkbin-tools ] [ o.k. ] Cleaning output/debs for [ pinebook-a64 default ] [ o.k. ] Cleaning [ o.k. ] Compiling ATF [ o.k. ] Compiler version [ aarch64-linux-gnu-gcc 6.4.1 ] [ o.k. ] Started patching process for [ atf pine64-pinebook-a64-default ] [ o.k. ] Looking for user patches in [ userpatches/atf/atf-pine64 ] make: *** No rule to make target 'bl31'. Stop. [ error ] ERROR in function compile_atf [ compilation.sh:65 ] [ error ] ATF compilation failed [ o.k. ] Process terminated I'm using docker so my command line was $ ./compile.sh docker IGNORE_UPDATES=yes

Ok, I removed the insufficient u-boot patch (we tested yesterday also with the wrong module -- FORESEE and not SanDisk). Are you able to generate a PR against https://github.com/armbian/build with the necessary changes to both u-boot and kernel? BTW: Would be interesting to get output from the following (sample output for 16GB FORESEE eMMC in my Pinebook here: http://sprunge.us/JcZG) git clone https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git cd mmc-utils make ./mmc extcsd read /dev/mmcblk0 | egrep -v '0x00$|0x0000$|0x000000$|0x00]$'

Quick update for anyone following this thread but not having seen With lots of help from Tkaiser and more we now have the pinebook booting from the new Sandisk 64G modules (older modules used Foresee chips and may still be available for a while). It needs a relatively small patch to the mmc driver in both the kernel and u-boot, and we're trying to home in on the safest minimal patch to add to the armbian builds. The speed delta noted above is related - one of the reasons that u-boot was failing is that for some reason the driver fails to switch this module into high speed mode. We haven't solved that yet, but even so the system is very usable running from the new cards. I'm optimistic that we'll get the card running faster with time (we may need some help from the original authors of the driver, or at least find the programming guide for the chip though).

Since I had Pinebook today in my hands again after a long time I wonder what's missing to move it from WiP to supported section? We should collect/include @James Kingdon's patches of course to get everything working with Pine's new eMMC modules Then I had to realize that profile-sync-daemon isn't enabled so this needs a fix too And then I wonder whether we shouldn't install zram-config by default? And do you think it would be a good idea to ask Pinebook users after account creation whether they've 11" or 14" (to adjust /etc/X11/xorg.conf.d/50-pine64-pinebook-touchpad.conf) or could this be stuff for armbian-config?

I threw the following patch in and rebuilt u-boot: http://kaiser-edv.de/tmp/NumpU5/linux-u-boot-pinebook-a64_5.32_arm64.deb -- at least on my Pinebook with 16 GB eMMC everything ok after 'dpkg -i linux-u-boot-pinebook-a64_5.32_arm64.deb && reboot'. @James Kingdon are you able to test this too? diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index d160bd5..c9f0b9e 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2272,7 +2272,7 @@ static int mmc_complete_init(struct mmc *mmc) err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); - return err; + /* return err; */ } init_part(&mmc->block_dev); /* it will send cmd17 */

Let me test this later with the 16GB eMMC on my Pinebook -- if it's sufficient we might provide a small u-boot package to fix this. Related: the 'performance' numbers you provided for your 64 GB eMMC are better at small block sizes than the 16 GB eMMC I tested but seem to be limited to the 'usual' 23 MB/s sequential barrier we see with SD cards on Pinebook and other Allwinner devices (due to using the slowest SDIO mode there). Can you please provide output from 'armbianmonitor -u' now and also re-test the 64 GB module after switching to performance cpufreq governor ('cpufreq-set -g performance' )?

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)

It should work unless broken. I am running my Pinebook from eMMC and install went smoothly.

I must admit that I didn't tried it on Pinebook, since I'm still running ayufan image ont it. But nand-sata-install should work the same way as for other boards ... Do you have an USB-TTL to Audio Jack to figure out where it is choking ?

Hi, just a quick sanity check - is install to eMMC on pinebook known to be working (with recent Armbian images from the wip section), and is nand-sata-install the right way to do it? It just occurred to me that I might be spinning my wheels trying to figure out something that just isn't ready yet Thanks, James